Accounting systems: a rant and a quest

Whereas if you shell out for Quickbooks, when it terminally breaks you get to keep all the pieces, but they may refund you your original purchase-price.

Software-contracts where somebody actually promises to fix things if they break, costs *MUCH* more than off-the-shelf software. Typically orders of magnitude more.

I think I can sort of see the case you're making, although I don't like the way you phrased it.

Accounting and tax software needs to be very bug-free, due to how mission-critical it is for enterprises. Commercial vendors have an incentive to make their software bug-free because otherwise their reputations are tarnished. What kind of similar incentive can we produce for open source developers of accounting and tax software?

If Red Hat or someone else were to offer a commercial support contract for some open source accounting software, Red Hat would have an obvious financial incentive to keep things working. However, support contracts only really make sense for big companies, not for small organizations like LWN.net. This would also tend to drive the developers towards implementing complex features needed by large organizations, not simple things needed by a smaller operation.

Joel Sposky wrote a pretty interesting article about the pricing of software over here: http://www.joelonsoftware.com/articles/CamelsandRubberDuc.... Software offered with a proper support contract clearly falls into what he would call the expensive category.

In the end, I think that we could probably create a good open-source accounting package. It would have to be extensively unit tested, and the development paradigm might have to be a little more restrained than the usual rapid-release strategy. It might also be a good idea for some organization to hold a trademark on the actual name, sort of like how Mozilla holds the trademark to Firefox.

In contrast, I have a hard time imagining open source tax software coming to pass any time soon. It's just not a very rewarding thing to develop-- it doesn't scratch anyone's itch, and the rules change every year in subtle and complex ways. Perhaps the best thing we can hope for is that there will be an open standard for storing tax data. Unfortunately, the IRS's e-file standard seems to fall far short in this regard.

Actually, you need to take responsibility for your accounting data yourself. It is inexcusable to blindly enter information into a system and blindly trust the results that come out. And unthinkable to then expect someone else to take the blame. Any good accountant will look at the data in at least three different way to ensure that it is correct: double-entry bookkeeping view, financial accounting view, and financial management view, and in at least three different dimensions, such as by income/expense, by account, and by person. The sums of all dimensions better add up the same. She'll know very quickly whether or not the software is correct.

Money is the lifeblood of every business; without it, the business dies. The purpose of accounting is to know where your money is coming from and where it is going. And, at times, how fast the flow is changing. Satisfying the tax man is secondary.

The basis of any accounting system must be the Generally Accepted Accounting Principles (GAAP). While there are localized variances, GAAP is almost as universally used as is the Uniform Commercial Code (UCC).

I've worked, on and off, for a small accountant for 15 years. He spent the previous 17 years building a fairly complete accounting system (general ledger for client data, time & billing for his work with clients, phone logging, lead tracking, etc.) His programmer essentially wrote 2½ programs a week for 17 years, on average; she did use sound practices, such as code-reuse and good structures. But it's still ISAM-based, business BASIC, one-letter variable names, and almost uncommented (to be expected; disk space was at a premium then: it started on an early BASIC system, moved to a DG NOVA, and finally to Unibasic on SCO UNIX).

If I were to build a small business accounting system, I'd start with his and re-implement it using modern languages and a modern UI. And the first premise of the database system would be as already mentioned: every record inserted must include a record insertion date/time, the record this one retired (or null if it's new), a record retirement date/time, the record that retired this one (or null if it's current) and who did each deed. Nothing is ever deleted from the database or updated in it: 'DELETE' and 'UPDATE' don't exist. Call it 40 bytes per record; in 100M records, that's all of 4GB: mice nuts compared to the bit trail you'd get. And accounting is all about traceability.