A new proposal for the financial system.

Since the bill regarding Neualtenburg affairs has been determined as contrary to the Constitution by the Scientific Council, and since many other structural problems with the system it proposed have been pointed out, I’ve drafted here a new proposal which may solve many of the problems. Since the constitution points out that the “governmental role” of the Artisanal Branch “is to act as Treasury …”, the first part of this proposal is offered as simply a member of the Neualtenburg group, since I am not a member of the “Artisanal Branch”.

I suggest that, as is being done now, a single avatar be designated as the receiver and payer of all funds of the city, and further function as the designated “owner” of the Neualtenburg “private sim”. I suggest that this avatar hold this position for a one year term, and that following January 1 of each year, a new avatar, belonging to a different member of the Artisanal Branch, be appointed to serve this function. (See my notes below regarding the transfer costs).

Since Ulrika has demonstrated that an avatar/server relationship can be established by which every transaction experienced by that avatar can be transmitted to an off-world server, I suggest that the script be modified to achieve the following goals. First, that it be a script that annually can be transferred to a new avatar. Second, that the script be such that it can demonstrate to a reasonable level that every transaction experienced by the avatar is recorded on the off-world server (probably just make the script public). And third, that the data received by the server be filtered and organized in such a way as to present standard financial journals and reports appropriate to the needs of the city.

If members of the Artisanal Branch wish it, I’d be more than happy to help set up the financial reporting structure that would insure clear information to the members of the group. But, whether or not I am asked to help, these are the issues that a reporting system must address.

First, that the source of each transaction be easily identified, and by source, I mean the vender, more importantly than the item sold. Neualtenburg, now, in its very simple pre-organization state, seems afflicted with any number of venders plopped down here and there selling things. The approved venders must be easily identifiable through the financial reports. Un-approved venders (those venders not feeding into the city financial system) must be identified and removed.

Second, the transactions must be summed by vender, and then below that by groups, or categories of vender. The city must have a way of knowing where is revenues are coming from so as to make informed decisions regarding the budget.

Third, likewise for the expenses. The expenses will fall into two main categories. Automatic, and manually initiated by the avatar owner. Automatic expenses are those like at the casino, where the machines pull funds from the account as part of their mechanism. And manual expenses are those like paying a bill for advertising. Paying the monthly Linden fee is actually manual, since the L$ account of the avatar is not affected, only the credit card of the owner. The owner must convert the L$ accumulated by the avatar into US$ in order to cover that. So, the transactions all must be clearly identified in journals, and those journal items must be summed in groups according to the kind of expense.

As a side note, I remain enthusiastic about Talen’s proposal that the casino have its own avatar. The casino, if successful, may generate hundreds of transactions per day, both incoming and outgoing. I feel if would be far more efficient for clear data organization if the increase (or decrease) in the casino avatar account be transferred to the main account each month.

Third, the transactions must be summed by month. This goes for all income and expense transactions, because the “lifeblood” issue for Neualtenburg, at least at the beginning, will be the monthly obligation to the Lindens. The monthly report of income and expenses is the clear, public statement to the citizens of how the group did. The “month-after-month” sequence of these reports shows in what direction we’re going.

Fourth, there are many transactions which are not income or expenses. The “bonds” as proposed by Gwyn, are actually loans, money that the city owes and will someday have to repay. And the purchase of the island is not actually an expense, but rather a long term investment which will last many years. So, that’s actually something the city “owns”. These transactions get listed in a different journal, and they form a different report, called the balance sheet. This report is the listing of everything the city owns minus everything the city owes, resulting in a number which is the “net worth” of the city. This net worth is the value that all the members of the group have a share in. Each time the monthly report of income and expenses arrives, the bottom line of that either adds to or subtracts from what the city owns, and the net worth changes. That’s how we grow.

Anyway, enough of my lecturing on how to do finances. These are my proposals to the Artisanal Branch on how to set up a transparent financial system for Neualtenburg. While the RA has no direct authority over how its done, the RA does have a real interest in how its done, since that group must pass the budget and set the taxation amounts.

BTW, I said above I’d comment on the annual transfer expense of changing the sim ownership. The monthly fee to the Lindens is US$195, amounting to US$2340 per year. This proposal would increase that fee to US$2440 per year, or US$203.33 per month. I think US$8.33 per month is a reasonable amount to pay for a system of rotating financial responsibility.

Sudane

You are now.

It just hit me. There is no barrier to entry in the Guild. To be a member, one must simply be productive (hold meetings, build structures, code, make vendors, make objects, sell products). Because you are taking a lead on the finances, you are a member. If you continue to serve, your rank within the branch will rise. The only restriction is, that because you're a member of the RA you cannot vote in the Guild.

This sounds good to me. We might want to move the date to coincide with an election but otherwise it sounds like a good compromise.

This isn't entirely accurate. It's a little more ad hoc than that. Right now it's the vendors which send sales reports by email to the server every time a sale is made. I'm currently working with FlipperPA (still owe him a PM) to have his online service generate an email and send it our server for accounting for online sales. By keeping track of the vendor sales, we know our balance -- provided that there are no manual withdrawals.

Currently there is no mechanism (LSL) to find the balance of an avatar or to determine if money is transfered to or from them (that I know of). To do that, we'll have to create a script that we can enter an amount into, which then sends a withdrawal statement to the server. Right now I have a question posted in the Scripting Tips forum for a more elegant solution but as of yet haven't had a reply. I think what we'll need in the end is a building that serves as a bank where the city avatar can use an ATM that reports withdrawals to the server. Because we've never withdrawn money, I haven't written this yet (it should be trivial).

The big problem is, that we'll never know for sure what the avatar balance is unless we log in as that avatar and look at the balance with our own eyes. Alternatives might be requiring the avatar to transfer all assets to GOM once a week where a few people could share an account to view the balance. We could put the GOM terminal in our bank.

This sounds great! If you could type up an example of what it should look like, I can code it up.

Vendors can be identified individually by their location (sim and coordinates), however to implement what your suggesting, I'll have to issue a unique serial number for each vendor. It shouldn't be too hard.

Good stuff! I have to run to a doctor's appointment right now. After I'm back I'll go through the second half.

~Ulrika~

I just received help in the Scripting Tips forum! With the use of "curl" and "awk" (Unix command-line tools), a player was able to extract the value of an avatar's account from the SL website! This means that we will always be able to track exactly what the balance of our city avatars are, allowing for greater transparency and peace of mind.

I'm having the code sent to me. Once I get it integrated into the website, I'll post a link.

~Ulrika~

I stated this in the previous email but I thought it's worth repeating as it is quite confusing. The sales emails that are sent to the server are generated by scripted objects (vendors) not avatars. In the casino we'll have to modify the gaming systems to send emails for every transaction. Whenever we want to transfer money between avatars, we'll have to manually make that entry ourselves with some sort of ATM that we'll have to code.

With the new code that pulls the balance of an account off of the SL webpage (mentioned in the previous post), there might be a way that we can automate the recording of transactions between city avatars.

No problem. I just need a sample report and I can code things up quickly.

Hmm. The revenue on the first phase of the project was 1/20th of the outlay. I liked the idea of privatization as it frees us from the corporation paradigm, where as a group we're responsible for creating a profit. By selling land like SL does, it becomes the responsibility of the individual land owners.

Either way, I do think implementing this is necessary and should be done regardless of how we approach the second phase.

I agree to rotating ownership as long as the rotation rate is kept low. Once or twice a year would be fine with me.

Alternatively, we could always set our sights on multiple island sims, if the privatization scheme is successful, placing a different member in charge of a each sim.

~Ulrika~

For the casino, the details are almost certainly not important. Unless we need to understand and analyze the internal functioning of the casino, i.e. which machines are more profitable than others, etc. If the Unix code can pull a balance on the casino avatar's account, and, if the avatar is in some "trusted" relationship to the city government (so that inappropriate withdrawals are not possible), then the monthly balance should be fine. Modified game machines and thousands of emails should really not be necessary. From the change in that balance, periodic transfers can be made to the main city account.

I may be mis-understanding you here. But, let us never fool ourselves that we can be relieved of responsibility for generating sufficient revenues to ensure the existence of the city. The land "owners" are only responsibile for their monthly payments. We may not have to generate a "profit" (although we probably should, for the long term responsible management of the project as a whole). But one way or another our plan leads us into something shaped like a "corporation paradigm".

Regarding the financial reports that I've suggested, I'll try to work those descriptions up. The details will get rather lengthy. Perhaps I can email them to you, rather than fill up the "digital air waves" ? Or, if that's not felt appropriate, I can certainly add them here.

Sudane

Thousands of emails are not a problem. Even at a rate of 1000 emails a day, it would be a small fraction of the bandwidth to and from our websites. I for one would prefer detailed data on the games. We would know who our top customers are, what games they prefer, when they play, the distribution of spending by customer (almost always a power law), and so on. We can even see changes in sales before and after making a modification to a game. As a member of the Guilde, I'd like to require this of all machines in our city.

What I want, is to relieve members of the government from the obligation of creating a profit for investors (not eliminating the responsibility of paying bills). I think by shifting the burden of making profit back onto the land owners it frees us from having to do all the work to make a profit (I worked my tail off for months) and makes it a more natural system like SL where we distribute that responsibility. I'd even go so far as to bill the city as nonprofit.

Here is fine. All I really need is an example form showing how you want the data laid out. Perhaps two or three different pages that show the data in different forms. You could even type it up using the "[ code ]" tags.

~Ulrika~

This post is basically meant for Ulrika as my suggestions on how to setup the financial data on the website. But certainly anyone should feel free to ask questions if something isn’t clear.

I'm sure its not in the most convenient form. It's the best way I could devise what's needed.

I’m proposing that the data received from the various money-related sources (venders, casino machines, rental thingies, citizens) be sorted and filtered and summed in ways which output a standard financial report for Neualtenburg. It need not be complicated; most important is has to have a clear format, and enable a number appearing on the report to be followed back to the journal (list of transactions) from where that number came.

On any level of this, you should be able to secure the data to selected people. And each level might be different. The top level reports might be for all citizens, the individual vender reports might be only for the shop owner themselves, and a city liaison assigned to that relationship. These would be policy decisions that must be made.

I’ll start with the venders. A vender would actually be the property of the store owner, although obviously the city will have to register it and certify its script. The vender will stream data to the server, idea-wise at least, one record for each transaction. That record goes into a journal for that vender, just a database of all the transactions. While some of the data might be interesting to those doing economic analysis of that particular vender, the only part interesting to the financial reporting is the gross sale price x the tax rate, and the date.

So, a journal of all the transactions for each vender. Totals in that journal at the end of each month for gross sales and tax amount. Those totals from all those journals carry into the first report, a list of all venders (or groups of venders arranged by some system of interest) along with their monthly revenues and tax amounts. Very very simple. Each vender is clearly identified, so that non-participating venders can be removed. And, the totals at the bottom of the report show how much income came in from the revenue category “Venders”.

Same thing with the other categories of revenues. Obviously there’ll be differences, particularly in that some other categories will be businesses owned by the city, like the casino, or like rental income from houses and shops. The casino, in particular, may want to be done differently, because the actual funds received are really less “revenue” than the difference of funds received minus pay-outs made. But that can be determined as it’s coded. And citizen “taxes”, however that gets defined, can be a simple list of people and the monthly receipts from each.

Now, we’ve got a report for each revenue category. The first part of the top-level “Income Statement” will be showing a single line item for each of those revenue categories for a given month.

INCOME
-------------
Venders 10000
Casino 90000
Rentals 15000
Citizen Taxes 10000
-------------
Total 125000

Obviously, pretty simple. (At least as a concept. I’m sure the coding will be a bear!)

The expenses should be done in pretty much the same way, although I don’t know how that data will actually flow from a machine. Obviously, the big one here is the monthly payment to the Lindens. These all may have to be manually entered unless we can access the avatar on the transaction level and export those to the site. But, however it’s done, there must be a transaction listing of each payment of expense. And those transactions need to total, by the month, into the same report levels that the income does.

And, then, of course, appear on the top level “Income Statement” as the totals for the Expense categories for the month. Subtract the two, and you’ve got the “gain” or “loss” for the city for that month.

INCOME
--------

… list of income categories and totals for the month
----------
Total Income for the month

EXPENSES
--------

…. List of expense categories and totals for the month
----------
Total Expenses for the Month

Net INCOME Gain or Loss for the Month


That’s it for the Income Statement.

Now for the Balance Sheet, a bit more hard to understand. The Balance Sheet is the statement of everything we “Own” (called Assets) followed by everything we “Owe” (called Liabilities). The difference between them is the “Net Worth” of the organization. For non-profit organizations, like Neualtenburg, the difference is often called the “Fund Balance”.

The Balance Sheet is built up the same way the Income Statement is. There are journals of transactions (like the journal of all the transactions in the bank account, something we own), or a journal of all the bonds we sell, (something we owe to the people who buy them).

Now, what’s different about a Balance Sheet, from an Income Statement, is that it’s not by the month. You can look at it at any moment and see the balances. Just like a literal bank account; the balance is real information at any moment.

Every transaction in the financial records of an organization is actually two transactions. For example, sales tax adds into the vender line on the Income Statement; cash received from that tax adds into the cash account on the Balance Sheet. On a real financial system this would have to be strictly maintained, so that the overall books “balance”. Here, in our very simple system, complete adherence to the rules of double entry bookkeeping are probably not necessary.

But, the Balance Sheet should be carefully done with 2 entries for each transaction. For instance, the city sells a bond. That bond is cash for the city, goes into the cash account (which is a line under Assets). But it’s also debt for the city, so the same number goes into the “Bonds Outstanding” journal, which totals to the Liabilities section of the Balance Sheet. Even the purchase of the sim, a one-time thing, is 2 entries. The price of the sim lowers the cash account, and it raises an Asset account that we can call “Land”. Both of them are Assets, the transaction lowers one and raises the other.

Bottom line on all this. The Gain or Loss each month on the Income Statement should be added into the Net Worth or Fund Balance on the Balance Sheet, so that the Income Statement starts from zero the next month. But, that Net Worth has also got to be the difference between the Assets and the Liabilities. How this works in practice has got to be one of the truly black arts of modern culture. For our simple (I hope simple) needs, I’m hoping we can shortcut some of this, and still provide a clear and accurate statement of the city’s finances.

I may live to regret this idea of short-cutting the process, but there’s no harm in trying. If the different parts of the financial system get too far out of line, i.e. the Income Statement doesn’t agree with the Balance Sheet, then we’ll have to devise a more rigorous system. But lets try this for now.

I’m sure folks have lost it at various points along the way (unless you’re an accountant or a business owner), so please, ask. I’ll do my best to make things clear. And, believe me, the end result will be worth it. A simple and clear system which is in line with the way the rest of the world does it; something we could pop down in front of any non-Neualtenburger and say: Here’s the real state of our finances.

Sudane

I have some code that should do the trick, thanks to help from Jack Lambert and Rathe Underthorn.

With this code we'll be able to monitor city and casino assets from our alts in realtime. This certainly helps reduce the anxiety I felt about sharing and rotating the city alts.

~Ulrika~

I have the code which reports the city balance patched into the vendor. Right now it's still in PHP (I have to rewrite it in Perl). I'll improve the quality of the output in a few days. For now this is just a demonstration of the technology that allows us to keep track of our city balance in real time.

You can see the current city balance here.

~Ulrika~