Karen has contributed some useful thoughts in response to my previous post about using Semantic Mediawiki as an accounting system.

One of the key things she highlights that I’d never really put my finger on before, is that traditionally recording financial information is a specialist skill – that of a bookkeeper. This made sense historically when there actually were physical day books and ledgers into which every transaction needed to be entered and then turned into a trial balance to be passed to the accountant. But technology isn’t meant to just replace paper with pixels, it’s meant to enable us to find new and better ways of performing tasks. For some reason bookkeeping software never managed this.

Most people can learn fairly quickly how to add a basic sales or purchase invoice to any financial system, or to record payments for either. This is because all software now hides the underlying double-entry nature of these functions. It’s a simple one-screen process. The software successfully hides the complexity by translating the user input into the full long-winded procedure that would otherwise be required.

But once you get outside this basic comfort zone, the learning curve gets very difficult very quickly. Buying capital equipment via hire purchase? Ouch! Better ask an accountant how to record that. Issuing an annual invoice that a customer pays monthly by direct debit? You need to make manual adjustments every month. Even something as commonplace as payroll is overly complex in most systems (even when you buy their expensive add-ons). Yes, accounting for payroll is complex. The company has to act as an unpaid tax collector, removing PAYE and NIC at source to be paid over to HMRC at a later date along with some extra Employer taxes. The employer and employee might also jointly contribute to a pension scheme, which needs handled separately again. Increasingly companies are also being asked to withhold other money from the employee at source, e.g. for child support. There are too many possibilities for accounting software to be able to hide all the complexity.

In traditional software packages, structure comes first. You can’t just record the data and hope to sort it out later. With a wiki, however, this is reversed. The structure and meaning can emerge later. As long as all data is recorded and annotated in a sensible way, we can work out how to deal with it later. If some new government Mandated Savings System was introduced that requires us to withhold 1% of an employee’s salary every month, to be held for them and paid to them only upon leaving the company, we wouldn’t need to wait for a software update or until an accountant worked out for us what the various balancing entries should be. Someone could just add an extra line to the salary payment entry ([[mss amount:=21.91]]), and working out how to actually account for that not only becomes Someone Else’s Problem, but, critically, can happen at a later date.

And if the structure turns out to be wrong, that’s not a problem either. It’s trivial for someone to just go through and change each entry, or even write a little script to automate this if there’s too much needing changed (with, of course, a full audit trail built in, for all those accountants having heart failure at this point).

It also means that any information that you want to capture for creating management accounts, rather than financial accounts, can be trivially recorded as well. Want to record which sales team is responsible for a sale? Which floor of your office this bottled water bill applies to? Which developer ordered this book from Amazon? Just do it. As soon as you annotate the information, with a new field, the field automatically springs into existence, and it’s instantly possible to query on it. Open a second office? Just inform everyone that they now need to say [[Office::Belfast]] or [[Office::Lisburn]], and you’re done.

The possibilities are, literally, infinite.