Long-time LWN readers will be aware that your editor has, for some time,
been looking for a free accounting system which would handle the needs of a
small business like, well, LWN. So it is with some interest that your
editor has followed the progress of the
2.3 development series. GnuCash is
currently in the "string freeze" stage: development is seen as being close
enough to done that no more changes to any visible text are allowed. So
perhaps it's time to look at what the GnuCash developers have done this
The actual list of new features is surprisingly short; much of the work in
this development cycle has been aimed at internal improvements. Near the
top of the list is the ability to use WebKit to render graphs along with
GtkHTML. Your editor will confess that he has not tested out this feature;
HTML rendering is a tiny part of what GnuCash does, so the availability of
an alternative rendering engine is not particularly exciting.
The other headline feature is more interesting, though: the GnuCash
developers have added a database backend which is capable of interfacing
with Sqlite, MySQL, or PostgreSQL. The XML-based native file format is
adequate for personal finance uses (though it is quite bulky), but it does
not scale well to the numbers of transactions seen in a typical business
setting, and it is not well suited to a multi-user, integrated workflow.
GnuCash had a database backend in the 1.6 days, but it was never well
supported and it did not work with the GnuCash business features. The
database backend in 2.4 has been redone from the beginning, and it supports
all of the program's capabilities.
Those wanting to use this feature need to be prepared for a bit of a rough
start, though; the related documentation is, one might say, sparse.
Actually, this documentation does not exist at all. What your editor
figured out is this: users should create an empty database (default name is
"gnucash") to hold the accounts. The relevant libdbi drivers must be
installed on the system. Then, opening GnuCash and selecting "save to"
will yield a dialog with a pulldown at the top; the default value in that
pulldown will be "XML". If GnuCash sees any database drivers, the
associated databases will show up as options on that menu; selecting
"postgres" will allow the accounts to be saved into the selected
A couple of related notes: GnuCash looks in /usr/lib/dbd for the
database drivers. Fedora x86-64 puts them in /usr/lib64/dbd. The
result is that GnuCash behaves as if the database option simply did not
exist. Your editor retains a longstanding grudge against whoever came up
with the /usr/lib64 idea; it seems to break every application
which it comes into contact with at least once. The other thing to bear in
mind is this: if you give GnuCash a password for access to the database, it
will store that password - in plain text - in your .gconf directory.
The database-backed mode looks and works almost identically to the
file-backed mode. The biggest visible difference is probably the lack of a
"save" button; when working with a database, all changes are committed
immediately. The program will also populate the working directory with
files named like translog.20100517132703.log. Leaving log files lying
around is a habit GnuCash has
had for a long time, but, in the absence of an accounts file, GnuCash has
to improvise when it comes to the naming and location of the log files.
Working from a database should offer some performance advantages when doing
searches through large accounts, but that's not the real reason your editor
is interested in the feature. What is far more compelling is
(1) interoperability with other business processes, and
(2) multi-user access to the accounting database. Unfortunately,
GnuCash 2.4 does not seem to properly support either of those features.
Even a small business like LWN generates thousands of transactions over the
course of a year. Unsurprisingly, it can be quite difficult to find
anybody who is interested in typing all of those transactions into the
accounting system - especially when "the computer" already knows all about
them. In the current system, getting this information into the accounting
database is done through a bunch of glue scripts and the always
hair-raising QuickBooks import process. Certainly it would be nicer to
just store that data directly into the accounting database.
This sort of direct storage is certainly achievable with GnuCash, but it
won't be easy. The database schema is surprisingly hard to find; there is
version of it available in an old mailing list posting, but that's
about it. Said schema is heavily reliant on GnuCash's "GUID" type - a
32-character ASCII representation of a 16-byte internal object identifier.
So even storing a simple transaction requires generating new GUIDs and
digging around to find the other GUIDs necessary to tie the transaction in
properly. It is, in other words, messy, error-prone, and just crying for a
nice API that could be called at a higher level. One assumes that said API
will exist in library form someday, but it is not there now.
Parallel access is not there either; the FAQ is
clear on the subject:
Even the dbi (SQL) backend which will appear in the upcoming 2.4
release is currently not designed for true multi-user
access. Trying to work with multiple users at the same time in the
same database can cause data loss. You can however share the
database with different users, provided you ensure serialized,
This makes storing the accounts in a centrally-located database actively
dangerous. If GnuCash cannot have two clients running safely with the same
database, it should go out of its way to prevent that from happening (as it
does with the file backend). But there are no checks for concurrent access
in the current 2.3.12 development release.
While GnuCash does have some support for dealing with various tax regimes,
it's still not where it needs to be to displace other applications. Among
other things, it simply has no provision for storing some of the required
being a US-based business, needs to track which of its authors needs to
receive 1099 forms at the end of the year and produce those forms at the
right time. The production side could perhaps be made to work relatively
easily: GnuCash has a scripting engine which enables the creation of custom
reports - as long as the user is not afraid of programming in Scheme. But,
without the ability to track who needs those forms (and their tax numbers),
the report generator simply lacks the information it needs.
Time for one final grumble. In current stable GnuCash, the QIF importer
(useful for importing credit card transactions, for example) is fast,
efficient, and flexible. In 2.3, importing
has turned into a slow, click-intensive, error-prone process. Users are
supposed to classify transactions without seeing the amount of each, for
some strange reason. In general, GnuCash is moving forward in this
release, but importing transactions has regressed.
Import dialogs notwithstanding, the general appearance of GnuCash has
changed little in this cycle. It remains the solid, workhorse financial
management program that your editor has used for years. For those who
would like to see a bigger change, there is something on the horizon,
though it doesn't look like it will be ready for the 2.4 release. The Cutecash project has set
itself the goal of taking the GnuCash engine and putting a Qt-based
interface onto it. It will be interesting to see where the developers go
with this project.
Meanwhile, lest your editor seem just a little too grumpy, let it be said
that GnuCash seems to be headed in the right direction. It has been more
than good enough for most personal finance management for some time, and it
is slowly developing the features it will need to compete in the business
area. One of these years it should start displacing proprietary accounting
tools in a serious way.
to post comments)