By Jonathan Corbet
June 13, 2012
Last month, your editor
described LWN's
need for a non-proprietary accounting system and the difficulty of finding
such a thing in the free software community. While there is no shortage of
systems that can perform basic double-ledger accounting, it is rather
harder to find a system that has everything needed to actually run a
business. Since then, a number of people have mentioned a system simply
called
Ledger. After some
experimentation, it is now time to pass on some impressions of how this
system works.
Ledger takes an interesting approach to the problem in a couple of ways.
One is that it is a purely command-line program; there is no graphical
interface of any type. The other is that Ledger does not actually maintain
any sort of database of accounting data; instead, it reads that data from a
plain-text file that the user manages separately. The result is a system
that is quite powerful in some ways while falling short in others.
The file format is relatively simple; entries span multiple lines, with all
but the first being indented. An example shipped with the program looks
like this:
2004/05/27 Book Store
Expenses:Books $20.00
Liabilities:MasterCard
This transaction took place in a book store, where $20 was moved from the
Liabilities:MasterCard account to Expenses:Books. The final line lacks a
dollar value, so Ledger fills it in to make the transaction balance; more
complex split transactions would require explicit values for each account
involved. The transaction above has not been reconciled; otherwise there
would be an asterisk between the date and the description fields.
Other types of entries are possible. There is a mechanism for adding
"period entries," describing transactions that happen at regular
intervals. These entries are not really a form of recurring
transaction—ledger seems to lack support for those. Instead, period
entries are used to describe budgets that can be compared against actual
income and expenses. "Automated transactions" are also supported, but
those aren't recurring transactions either; they are a mechanism to add
splits automatically to other transactions.
The syntax for both types is terse and arguably obscure (period entries
start with a
"~", for example); it can take a little while to understand
everything that can appear in the ledger file.
What has been described thus far doesn't involve the Ledger program at
all; this file must be created and maintained via some other mechanism. In
many cases, that mechanism will be a text editor; inevitably, there is an
Emacs mode to make things easier. For those who want a more graphical
experience, Ledger can read (uncompressed) GnuCash files, but there are a
couple of caveats. One is that the Ledger developer (John Wiegley seems to
do almost all the work on Ledger)
is somewhat unenthusiastic about this approach; the manual asks: "why
would anyone use a Gnome-centric, multi-megabyte behemoth to edit their
data, and only a one megabyte binary to query it?" The other is
that this support appears to be lacking from the in-development 3.0
release. So, while using GnuCash works for now, it's not clear that it
will continue to work in the future.
One could also imagine various automated
mechanisms for generating the file from other data sources. Ledger itself
never modifies the file; it is simply a consumer of the data contained
therein.
As consumers go, it's a powerful one. There is a fairly long list of
reports that can be generated. As one might expect, Ledger supports a
complex command-line interface that can be used to filter transactions and
control the format of the resulting report. The syntax is (once again) terse, but,
given time, a suitably motivated user can create almost any sort of
text-oriented report one might like. Pie chart aficionados will be
disappointed at the outset; there is no graphical output from Ledger. With
a bit of work, though, one can get Ledger output into a tool like Gnuplot
and produce all kinds of pretty charts.
In summary, Ledger isn't really an accounting system; it's a
report-generation utility designed to work with a specific text file
format. There are both advantages and disadvantages to its approach. On
the up side, Ledger could be an ideal solution for relatively small
operations where the people involved are happy to use command-line
utilities and do some scripting to make the pieces of a full business hold
together. The plain-text ledger file is ideal for anybody wanting to use a
tool like Git to track changes over time (or to merge changes done by more
than one user). The tool is fast, lightweight, and will never imprison
one's accounting data in a black-box binary data file.
On the other hand, it is hard to imagine scaling Ledger even to a business
the size of LWN, much less something larger. The tool has clearly been
written with speed in mind; it can process a file with many thousands of
transactions quickly. But the file itself can only become unwieldy,
especially if there are many sources of data feeding into it. Plain-text
files lose some of their appeal when they get to be tens or hundreds of
thousands of lines in length.
Ledger also lacks features that a typical small-business accounting program
would be expected to support. These include:
- Invoicing. One can certainly enter information about an invoice as an
accounts receivable entry, but there is nothing tying it to the actual
invoice sent to a customer. Anybody wanting standard invoice formats,
summaries of outstanding invoices, or per-customer reports will have
to implement them separately.
- Check printing. Yes, it is still necessary to write checks at times.
- Integration with bank accounts. That said, LWN has to do its own
processing of files from banks before feeding the data into QuickBooks
now, so things would not necessarily change a lot in a move to Ledger.
- Recurring transactions. Again, one can certainly script such things,
but it must be done separately.
- Tracking of contractors and creation of tax data (and, in the US, 1099
forms).
- Easy execution of routine tasks like account reconciliation. Ledger
can certainly provide a register view showing unreconciled items, but the
editing of those items must be done elsewhere (in that big text file).
The other problem with a tool like Ledger is that it can complicate
dealings with one's accountant, assuming said accountant is not comfortable
with command-line tools. Generating the basic reports that an accountant
would want to see will not be that hard. But a good accountant will want
to dig through the entries to be sure that everything makes sense and,
perhaps, add a journal entry or two to straighten them out. Ledger makes
that level of interaction impossible for most accountants, and that will
complicate life for many businesses trying to use it.
The bottom line, so to speak, is that Ledger is probably not the solution
to LWN's accounting problems, though it might work quite well for simpler
businesses with fewer customers, transactions, and accounts. For us, there
are too many pieces that would have to be added, some of which would be
less than straightforward. So the quest continues; stay tuned.
(
Log in to post comments)