The exceedingly grumpy editor's accounting system update

So why has this project taken so long? What it came down to is that your editor concluded that he was not sufficiently qualified to rip out a functioning accounting system and replace it with something out of a CVS server somewhere. There is simply too much to know about how the accounting system ties into the company's operations, how our accountant uses it, and how it helps keep the tax agencies happy and the company's officers out of jail. That latter point became especially relevant as LWN's longtime bookkeeper and occasional contributor Dennis Tenney headed off to pursue other opportunities, leaving your editor to take up the legally-liable Treasurer position.

In other words, swapping out the accounting system isn't something to be done on a whim, like, say, putting an -rc1 development kernel onto the production server. Whatever is there has to work. So your editor concluded that the first step in this process was to take over the existing system and come to understand it well enough to be able to properly think about a replacement. After closing out the 2008 books, your editor is able to come to a preliminary conclusion: it is almost possible for a small business to dump a system like QuickBooks and use a free alternative. Almost.

There is an interesting gap in the free software community's offerings in this area. A very small business - one involving a sole proprietor, for example - can use a tool like GnuCash to great effect. Almost everything which is needed is there, and most functions work quite well. On the other hand, a very large operation wanting to install a full-scale ERP system has a wealth of options: Compiere, Adempiere, various packages based on OFBiz, and more. If your operation is willing and able to dedicate full-time staff to developing a customized ERP system and keeping it going, there are plenty of frameworks to start with. These systems are not drop-in tools usable by a small business, though.

Small businesses occupy a niche between the sole proprietor and the massive enterprise. At this level, there's not a whole lot available from the free software community. The most active projects appear to be SQL-Ledger, its fork LedgerSMB, and PostBooks. All three work on top of a PostgreSQL database; SQL-Ledger and LedgerSMB are web-based, while PostBooks is a Qt application. Your editor's sense, at this point, is that PostBooks looks like the most advanced, most ambitious, and most actively-developed project among these three. It is, however, tricky to get running, its development model appears to be strongly cathedral-style (there isn't even a project mailing list), and it is distributed under the questionably-free (though OSI-certified) CPAL license. PostBooks has the look of a classic piece of corporate-controlled open source.

Any of the packages listed above (and GnuCash too) will do basic double-entry accounting. They can produce pie charts, reconcile accounts, and so on. Since they use PostgreSQL with an open (if sometimes poorly documented) schema, integrating them with the rest of the business should be relatively straightforward. They are, in essence, almost everything which is needed to enable a business to move away from a package like QuickBooks.

[PULL QUOTE: The key word is "almost." As far as your editor can tell, there are two crucial bits missing. END QUOTE] The key word is "almost." As far as your editor can tell, there are two crucial bits missing: tax form printing and accountant interfaces.

On the first point: this is the time of year when LWN produces 1099 forms for each of its guest authors - at least, for those who pay their tribute to the U.S. A related form (1096) then goes off to the Internal Revenue Service so they can ensure that none of our authors tries to hide the vast amounts of money we pay them. A tool like QuickBooks tracks payments to outside contractors, and will happily print the requisite forms onto special stock which can be purchased, at exorbitant prices, directly from the application itself. There is no equivalent functionality in the free packages, currently.

In truth, this is an area where free software tends to struggle. The printing of tax forms is just not a task which inspires hackers; it is tedious, subject to highly finicky requirements, and is, for all that it may be considered necessary, somewhat distasteful. This work must be revisited every year as the requirements are subject to the whims of legislators and regulatory agencies. And, lest that challenge seem insufficient, one should also bear in mind that every country's requirements are different, so all this work must be repeated many times over.

Creating this kind of code (and keeping it current) is not fun, it requires some specialized domain knowledge, and it can carry certain kinds of legal liabilities. So it's no wonder that a hacker with some free time will, upon considering this kind of task, usually decide to work on enhancing that Klingon translation of OpenOffice.org instead. The Klingons tend to be more forgiving of bugs.

On the accounting side, the problem gets even worse. A typical business accountant uses proprietary software which, in turn, contains a great deal of knowledge of the tax code. Not all countries have a tax system as twisted and complex as the U.S., but the problem is never simple. Your editor believes that it would be entirely reasonable to require governments to provide free software which interprets its tax codes for ordinary citizens, along with a guarantee that, as long as said citizens fed honest numbers to the system, they would not be subject to penalties if the resulting tax calculation were incorrect. In the real world, though, the job of providing such software falls to companies with a squad of on-staff tax lawyers and a firmly proprietary approach to software distribution. That situation does not appear to be likely to change anytime soon.

For the accountant to use his proprietary tools to come to conclusions about a company's tax situation, he must be able to enter quite a bit of data about where the company's money came from and how it was used. There are a couple of ways in which this can be done: (1) it can be manually entered, at great expense to the company involved, or (2) it can be directly imported from the company's accounting system for free. Small companies tend to be quite sensitive to things involving increased expenses, especially when the expense is for an already unwelcome task like tax compliance. So there is great value in having an accounting system which can export data directly to an accountant's tax preparation tools.

In an ideal world, there would be a nice, XML-based format involving large numbers of acronyms which would make this interoperability possible. In the real world, these formats are proprietary and undocumented. So exporting data to the accountant is not really possible with free tools. And that is the single biggest roadblock to the use of free accounting software in any company whose accounts are even remotely complex. Until free programs can export something which looks like the QuickBooks "accountant's copy," they will not be usable in this context.

What makes this situation even more sad is that, as your editor can now attest through painful experience, QuickBooks really does not have much else to offer. Its interfaces are tedious and error-prone; in many ways, free software has done a much better job. As an example, GnuCash will happily import account data from a bank or credit card company, apply default accounts (categories) learned from experience, filter out any duplicate entries, and allow the user to verify and adjust the whole operation before applying it. QuickBooks is, shall we say, nowhere near as accommodating. Your editor ran into a bug (in QuickBooks 2009) which causes the import operation to fail halfway through; a quick search turned up reports of that bug from 2003. There are reasons why any discussion of QuickBooks harps on the need to perform backups frequently - every fifteen minutes or so is good. Your editor has had to restore those backups many times; meanwhile, use of GnuCash over several years has never, ever resulted in a corrupted database.

What it comes down to is that we have solved at least 95% of this problem, and we have done a better job than the proprietary software companies have. But the remaining gaps are crippling, and they are hard to fill. Accounting file formats are more obscure than, say, document formats; there is no effort to create an OpenLedger specification. Any attempt to create files in those formats from free software is likely to involve reverse engineering efforts, and that will be an error-prone process in an area where errors are most unwelcome. So we may well be stuck with proprietary accounting software for some time yet.

That said, your editor does not intend to give up. There will be ongoing discussions with the accountant and continued tracking of free accounting system projects. The free software community has solved no end of difficult problems over the years; we should be able to find a way to take care of this one too. Stay tuned; hopefully the next update will not be so long in coming.