Brought to you by

Lollies, cake and dev superstars

Posted 8 years ago in Xero news by xero
Posted by xero

At university you know the stuff they’re teaching you must be important, but by the 3rd year you start to get the sneaking suspicion some of the assignments they’re setting you are just their way of messing with you. So I was amazed on the first day of my internship at Xero that the task I was set was VERY similar to an assignment I had just completed in my last trimester. Another shocking thing I’ve discovered is that accounting is actually really interesting! Not the actual accounting of course (don’t be ridiculous) but the programming behind it. It’s actually amazing!

The opportunity to get behind the scenes at Xero is thanks to the Summer of Code program. This  matches students like me with IT companies in Wellington, New Zealand (the home of Xero HQ) where you do an internship over the summer break. So you get real life experience in the industry you aspire to become a part of. And you get paid for it!

I started at Xero in mid November and since then I’ve have been working on creating demo applications for the Xero API in several different programming languages, creating both a web application and desktop application in each. Work at Xero has been full of surprises. A lot of assumptions I had had about working in the “real world” are actually completely wrong and it’s taught me many invaluable life lessons.

For one, the love of cake and lollies are not forgotten at Xero, ever. I’ve also discovered (sadly) that creating a full multi green coloured interface is not a colour scheme my boss is appreciative of. Another crucial lesson I’ve learnt is that computers do not magically work better because you’re at work. When I crash my computer I spend the time it needs to restart, building a can-castle with bottle trimmings (we get free coke!). It’s becoming an architectural master piece complete with people and a moat.

Some assumptions have however, proven to be true. The dreaded work day early starts have unfortunately (or fortunately depending on your can/bottle-castle outlook) reinforced my V addiction – the caffeinated miracle drink that wakes me up. And the pure amazing brilliance of the gurus on the dev team I work with has surpassed my expectations. It’s insane how much they know about this stuff!

What’s also great about the The Summer of Code is the regular seminars (open to anyone in the IT industry). This series is being sponsored by Xero (as it happens) this year. The seminars are great get-togethers which widen your outlook , allowing you to see what companies are out there and what they do. I also get to see my friends who are also doing Summer of Code. Quite a  quite a few of them are planning to stay on at the companies where they are interns, though I’m opting to do an honours year.

If you have a chance to do Summer of Code or there’s a similar program in your country or city – go for it!


David Hillary
January 20, 2010 at 9.28 am

Hi, would you care to tell us what you found that was the same? last year I did a paper on accounting information systems and now that I’m doing another financial accounting paper over summer I’m trying to get my head around how the computerised accounting systems could or would handle end of period account closing (I’m suspecting they don’t close accounts at all, and just do fancy queries to get the right data to the right place).

Mark Blundell
January 21, 2010 at 5.56 pm

Hi David
Yes we keep all data for all time in the database, we don’t close accounts and purge detail data. So if we need the balance of an account which is a balance sheet account, then we simply query the sum of all entries – up to the date the user asks for. If the account is a P&L account then we run two queries:
The first is the sum of all entries up to the beginning of the financial year
The second is the sum of all entries up to the date specified by the user in their report. By subtracting the first value from the second we get movements in a period.

With good database design and fast servers, which Xero has, we can let SQL Server sort out the heavy lifting freeing us to build features at a faster rate than if we had to continually aggregate data into periodic balances.

David Hillary
January 21, 2010 at 8.35 pm

Mark thanks for the details, and it is how I expected it. As far as I understand the traditional accounting cycle (and I could be wrong) the closing process does not purge any data, it only transfers the balance to the trading account, profit and loss account or similar, leaving a zero balance to start the next accounting period. So the old transactions are sill there, just the balance has been zeroed.

Do the MYOB and Quickbooks type software products do the same query style process or close P&L accounts?

I find it strange how they teach the accounting cycle incorporating the close temporary accounts and post to balance sheet, without any qualification that this is just one method, and that the close account steps may be redundant under computerised accounting.

Also, in the Accounting Information Systems course they mention the ‘posting’ process as being automated, however, with relational databases, if I understand it correctly, the data exists in only one place, and is therefore not ‘posted’ (i.e. copied) at all, it is merely queried to return either a) a list of transactions of the same type (e.g. sales) or b) a list of transactions on the same account (e.g. depreciation expense).

Rod Drury Xero
January 21, 2010 at 9.28 pm

Great discussion.

Also to note that in a modern relational system you need to then have the concept of a ‘lock date’, which we do in Xero. This provides a mechanism for the financial controller to effectively stop others posting back into what would be a closed period in traditional systems.

Another important point in the relational design is avoiding the use of repeating hierarchies in the chart of accounts. For example schools often have repeating categories for various reporting requirements which leads to a blowout of the chart (we often see over 600 account codes), leading further to admin people need to learn the specific rules of their chart, and reporting becomes very complex.

Instead we have designed Xero to use the power of the relational database by using tracking categories. These are essentially very flexible cost centers. Right now we’re working on beefing up reporting using this more relational model.

During 2010 we’ll be delivering much more of this to enable what we call ‘relational accounting’. That’s been a personal goal since we started Xero and we are making good progress.

Relational accounting solves a huge number of issues and we think will be a be contributor to increased productivity.

Glad you asked, love talking about this stuff,


David Hillary
January 22, 2010 at 10.42 am


I’m sure I’m not the only one who can’t figure out what you mean by ‘repeating hierarchies in the chart of accounts.’ Would you kindly explain, please?

I do understand how, especially in traditional accounting systems, accounts are opened solely for the purpose of reporting, i.e. accounts are closed and the balances are collected from them by transferring to other accounts, and then the balances in those accounts are distributed to other accounts. The transactions on the account then provide a record of how the reported figure was derived, or how the balance was distributed. For example, in a partnership, trading income and expense accounts are closed to a ‘trading account’ which is used to derive a trading profit (i.e. gross profit) figure. The trading account is closed by transferring its balance to the ‘profit and loss account’ along with the balances of all other income and expenses accounts, to collect the net profit figure. The profit and loss account is closed to the appropriation account (or profit and loss appropriation account), and this account then distributes the partnership net profit to the various partners’ capital accounts. So in this example the following accounts are used for the following reporting purposes:
1. trading account calculates gross profit, and shows how it was derived
2. profit and loss account calculates net profit, and shows how it was derived
3. appropriation account shows how net profit was ditributed to the partners.

With a relational database, these accounts need not exist, and the related reporting requirements can be served instead by running queries. It also eliminates the end of period account closing process.

As an aside, I presume it is the ‘profit AND loss account’ because income is treated as profit and expenses as losses, otherwise it would be called the profit or loss account, no?

Rod Drury Xero
January 22, 2010 at 6.17 pm

Here’s an example of a repeating hierarchy:

10110 Social Studies – Books
10120 Social Studies – Staff Costs
10130 Social Studies – Electricity
10210 History – Books
10220 History – Staff Costs
10230 History – Electricity

Much better to have the expense categories

– Books
– Staff Costs
– Electricity

and Tracking Category called Class, which might include the entries
– Social Studies
– History

Reporting is then done by a combination of Chart of Account entries and Tracking Categories.

Much more flexible, easy to understand and requires much less custom reporting which saves big $’s for many entities. Like schools.

Does that make sense?


David Hillary
January 23, 2010 at 8.30 am

Rod, YES, that makes a lot of sense now. The reason they are called repeating hierarchies is because they are repeated for each subject in this case, and because they are a hierarchy for each subject (i.e. they all aggregate into Social Studies and History in this case).

Of course you could structure it the other way around also:
10110 Books -Social Studies
10120 Books – History
10130 Staff Costs -Social Studies
10210 Staff Costs -History

And which way is ‘right’ is debatable.

This relates to what I studied in management accounting: categorisation and recatergorisation of income and expenditure etc. There is the natural classification (books, staff costs, electricity), and the functional classification (administration, marketing, history teaching), and the product (year 10 NZ history, year 11 NZ history etc.). On top of this you have the fixed/variable cost/revenue distinctions used for cost-volume-profit analysis, and the departmental and/or responsibility classifications as well.

So xero just uses tracking categories for as many different distinctions as are required and this enables rapid and flexible reporting. But this raises the question about the rules for using tracking categories, e.g. what tracking categories are mutually exclusive, what tracking categories types are mandatory (and in what circumstances), and who is authorised to add which tracking categories to an item of income or expenditure (and exceptions for allocated overheads, for example), and whether there are any restrictions on which accounts can be linked to a tracking category. And which defaults should be set up to make data entry or tracking category assignment faster or automated. And how these settings should be accessed when setting up or modifying a user, or setting up or modifying a tracking category. You guys and girls will be busy!

Rod Drury Xero
January 23, 2010 at 5.45 pm

Yes, you’ve got it.


March 14, 2010 at 3.53 pm

I’m amazed that Xero has “account numbers” and flat account lists 🙁

Really, please, please, please, Xero, look at Quickbooks sometime, better, get somebody who uses QB in their small business to show you. I’m trying Xero out at the moment but it’s totally doing my head in having to deal with such a “flat” system and arbitrary numbers.

Xero is supposed to make accounting easy isn’t it? I have a modicum of accounting knowledge I guess after so many years, but even I don’t want to know about arbitrary codes for accounts, I don’t want to have to remember that “10110” is “Books – Social Studies”, I just want to charge an expense to “Books:Social Studies” (Social Studies account, sub account of Books).

ARGH. Why can’t there be a good accounting system which has Quickbooks ease of use, Xero’s online model with it’s automatic bank account syncy goodness, and Freshbooks customer billing front-end!

It just shouldn’t be this hard :-(((

Rod Drury Xero
March 16, 2010 at 11.28 am

@James. You need to look a bit deeper. You do not need to use account numbers in Xero. We’re like you so designed account numbers to be optional.

Xero is not flat. It’s relational. Check out Tracking. That is how we put ‘shape’ into the the chart. Here’s a movie:

Cheers, Rod

Leave a reply

Your email address will not be published. Required fields are marked *