Accounting
From WhyNotWiki
Accounting edit (Category edit)
[edit] Using a wiki
[Semantic Mediawiki (category)][Creative (category)]
Tony Bowden (2006-09-21). Using a Wiki as an Accounting System (http://nothing.tmtm.com/archives/2582).
In the UK, the de facto accounting system for small business is SAGE. This is most unfortunate, as it is an appalling piece of software for many, many reasons. I can rant for hours on its many shortcomings, but today I’ll mention two of the biggest ones, and how we’ve been able to work around these using a wiki.Firstly, its reporting is terrible. It can, of course, give you all the traditional accounting reports – P&L, balance sheet, cash flow, actual vs forecast, debtors list, creditors list, etc. etc.. In recent years they’ve even added the ability to produce these in HTML. However, there is no way to interrogate the output or investigate things further. When I see a financial report I want to be able to click on any piece of data on it to get further information. This is a classic case of a 90% solution. There are really complex tools available to let you slice and dice data any way you want, but in a small business, just making each number a link to a screen that shows you what makes up that total is generally both necessary and sufficient. SAGE fails miserably here. Many companies I’ve encountered at one stage got their bookkeeper or accountant to print these reports on a regular basis, but never really understood what they were seeing, so eventually reverted to the traditional “gut feel” approach that most small business owners prefer, leaving formal reporting for their annual accounts and their semi-regular reports to the bank manager.
...
This reporting problem falls into the “generally annoying, but I guess I can live with it category”. Historically my general approach has been to export the pertinent information as CSV and manipulate in Excel – what most companies seem to do when they get big enough to move up from having a simple bookkeeper to actually hiring an accountant.
The much bigger problem however, the one that makes me tear my hair out when having to work with SAGE, is how it deals with accruals. This is an accounting concept whereby you are aware of income or expenses that should really apply to an accounting period, but for which an invoice has yet been raised. The classic example is a bill that is issued quarterly in arrears. A quarterly bill for £60 should really be entered as £20 for each of the three months. But when you go to close April’s accounts, that quarter’s bill hasn’t arrived yet, so obviously hasn’t been entered on the system. As such your accounts don’t accurately reflect the costs incurred in the month. So you have to accrue a £20 charge that can be reconciled when the bill finally arrives. Similarly, if the bill is quarterly in advance, you don’t want to just charge the full bill against the month when it arrives, so you assign parts of it to each of the next two months. SAGE makes this remarkably complicated. Bookkeepers and accountants have gotten so used to that they don’t really think about it, but watching the confusion of a new admin assistant learning how to do it drives me insane. Again many small businesses just don’t bother doing this and their monthly accounts swing wildly in the months where the bigger invoices hit.
One of my standard rants to accountants is about how, yes, double entry bookkeeping was a great invention in 12th Century, but it’s no longer a useful metaphor for users of a computerised accounting system that should be able to take care of such things by itself. Business owners and managers want to enter sales and purchases, note when these are paid, and then check it all off against the bank statements each month to make sure nothing untoward has happened. They don’t care, and shouldn’t need to care, about journals and ledgers and trial balances.
But there seems to be no such thing as “modern” accounting software. They’re all just computerised versions of an ancient system. Some manage to hide more of the underlying mechanisms more than others, but it doesn’t take much scratching to discover what’s really under the surface.
When we took over the running of Ireland’s oldest ISP a few years back, the accounts were a mess. Customers were billed monthly, quarterly, six monthly, and/or annually – some in advance, some in arrears, some in the middle of their billing cycle. How they were billed also bore little relation to how they actually paid – many of the customers who got annual bills actually paid monthly, for example. Suppliers in turn tended to invoice quarterly in advance. Large software development projects also carried a substantial Work in Progress element. It was a huge amount of work at each month end to enter all the necessary accruals and movements, and the resulting P&L and balance sheet were mostly incomprehensible due to the wild swings involved in booking or releasing money from customer pre-payments, often received months earlier, but which have to be treated as a liability until that month’s services have been delivered.
The simple solution to this problem is of course to just allow each invoice (whether sales or purchase) to have an associated ‘period’. A phone bill charges for the previous quarter’s calls, and the following quarter’s line rental. Most companies account for these separately so already split the bill and assign each a different nominal code. The trick is to also add the relevant dates to each: calls from April 06 – June 06, line rental from July 06 – September 06. The software can then do all the calculations it needs for accruals each month without the need for a hideously complex manual month-end process. SAGE, however, doesn’t allow you to do this. They’re not alone. Every accountant I’ve spoken to is completely unaware of any low-end financial software that does. But they all agree that it would make the accounting process much, much simpler for most companies. I can’t believe that no-one else has ever thought of doing this, so I’m left with the assumption that it’s just a giant conspiracy to create unnecessary jobs for millions of accountants and bookkeepers.
So, in frustration, we decided to use a wiki for our accounts instead. Mediawiki with the Semantic extensions makes for a very interesting data store, as I’ve written about previously. For basic accounting information there are only really a few key concepts: purchase invoice, sales invoice, payment made, payment received, bank lodgement, bank statement.
Each gets its own Category, and has a set of relationships and attributes defined. Each invoice has attributes for net vat and gross amounts, a nominal code, an issue date, and a from date/to date pair for the period it applies to. Each also has a Supplier/Customer relationship which of course links to the page on the wiki where we’re already storing information for that company. A cheque received relates to one or more invoices, has attributes for the amount, and is related to a Bank Lodgement, which in turn is an amount on a date to a bank etc. A provisional bank statement can then be generated through an query for each transaction applying to that bank in a given period. This can then be visually cross-referenced against the physical statement when it arrives to make sure that nothing is missing or erroneous. Most small companies are on cash accounting for VAT, so the bank statement query can also be set to also include the VAT portion for each transaction, and a simple sum provides all the information necessary for the quarterly VAT return.
Producing a P&L is trickier. The syntax isn’t really expressive enough to do this yet, and I’m not sure it ever will be. Even if it allowed the full Sparql syntax, as has been mooted, I suspect the computations to properly assign invoices over various accounting periods might be too complex. At the minute we produce these by querying the wiki’s underlying database directly with a Perl script that does all these calculations. This also means, of course, that each piece of data on the resulting report can be a link to a page explaining how it’s made up.
The process is, of course, error-prone. But it’s much, much easier to correct errors in a wiki than in SAGE. Mediawiki, of course, maintains a full revision history for every page, so there’s a built in audit trail that’s much easier to examine than the one in most financial systems. There a few scripts that run regularly to look for obvious errors, such as invoice items where the net + vat doesn’t equal the gross. The syntax is still too simplistic for some of the reporting we’d like, so until it provides aggregate functions, or until we learn how to use RDF better, we still have to do too much digging at the raw data with SQL. It’s very far from a complete financial system, as we haven’t really needed to deal with things like share capital (although asset purchases are simply a purchase invoice with a very long from date/to date range, so the bulk of a balance sheet is there). And it’s built on a fast changing base – Semantic Mediawiki is still in the early stages of development. So it’s certainly not something everyone could, or even should, do. But it has allowed us to remove a huge amount of recurrent admin work, see much more clearly what the financial status of the company is in real time, and drill down into that data where something seems puzzling.
...
Tony Bowden (2006-09-23). More on Accounting Wikis (http://nothing.tmtm.com/archives/2584).
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 cope gets very steep very fast. 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. Employer and employee might also contribute to a pension scheme which needs removed and recorded. 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 (21.91), and working out how to actually account for that becomes not just 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 sprints into existence, and it’s instantly possible to query on it. Open a second office? Just inform everyone that they now need to say Belfast or Lisburn, and you’re done.
The possibilities are, literally, infinite.
My work here is done (http://nothing.tmtm.com/archives/2594) (2007-03-06).
As longtime readers will know I have been using wikis for a long time, and most recently have been abusing the Semantic MediaWiki extension to layer a financial reporting tool on top of a wiki. As part of the discussion surrounding this Ross Mayfield of Socialtext had pointed me at Dan Bricklin’s wikiCalc, the project by the inventor of the original computer spreadsheet to merge that concept with a wiki.
Although I don’t believe that that would be able to do what I need yet to build a full financial system, or indeed to do much beyond creating simple web tables, the idea intrigues me greatly, and after a variety of discussions over the last month or so, I’ve decided to join forces with Dan and Socialtext to see what I can do to help it get there.
Aliases: Accounting software, Bookkeeping
| Office | Belfast +, and Lisburn + |
| Mss amount | [Oops! No type defined for attribute] |
