Leading items

The Grumpy Editor's guide to personal finance managers (Part I)

It has often been said that free software developers are a self-interested bunch. They will work on programs which are interesting to them personally, while avoiding projects which they may never use. That is why we have several complex window managers but little in the way of free payroll systems.

If this saying is true, one might well wonder: why has it taken the community so long to develop a truly capable personal finance manager? Almost every developer will have a checking account of some variety, bills to pay, taxes to deal with, etc. Tracking accounts in paper registers is tedious and error prone - and nearly impossible once a few complications (such as, say, a spouse whose attention to detail in these matters is sporadic at best, not that your editor would know about such things, honest) are thrown in. Keeping track of one's finances is clearly a job for a computer.

Be that as it may, this is an area which has not drawn much attention from the development community. There has long been little choice for those wanting a free finance manager, and the available applications have lagged behind the proprietary offerings. Perhaps all those desktop hackers are simply pretending not to notice as their spouses balance their checkbooks with Quicken.

That said, the situation is not all bad. Your editor has managed his eternally frightening finances with free software for some years. In more recent times, the number of available packages with a minimum of useful functionality has grown. So it's time for your editor to put together a review of what's available. Personal finance managers are complex applications; as a result, a comprehensive review will be long. This review will be done in two parts; this part looks at basic account functionality, while the next will cover more advanced features.

There are a number of projects out there, but this review will concentrate on three of them. Many of the others have not advanced beyond a simple list of transactions, and many of them have seen no development for years. There are also a few proprietary alternatives available for Linux, but they will not be reviewed here.

This review looks at:

• GnuCash. This package is the reigning champion of free money managers; it was first reviewed in LWN in 1999. The most recent release is 1.8.11, which came out in February, 2005. GnuCash is a GNOME application, but it has not yet made the transition to GTK2.

  As we will see, GnuCash remains the most featureful of the free money managers, though the others are starting to catch up. This package also has high aspirations: it would like to be a full accounting package suitable for use in businesses as well as at home. So, GnuCash is unique in using double entry bookkeeping for all accounts. This is a mixed blessing; the business-related features of GnuCash have been slow to mature, and they seem to have distracted some attention from the personal finance side of the application.

  Nonetheless, GnuCash is the program to beat in the free software community. For this reason, both of the other programs reviewed here are able to import data from GnuCash files.

• Grisbi is a GNOME-based money manager with a distinctly European feel - in fact, the program is developed primarily in French, with an English-language version only becoming available in 2004. Much of the documentation still lacks an English translation. The current version of Grisbi is 0.5.7, released in June, 2005.

• The leading KDE-based application is KMyMoney. Like GnuCash, KMyMoney aims high, and would like to be useful for small business needs. It features double-entry accounting, but lacks some of the other features implemented by GnuCash. KMyMoney 0.8 was released in August, 2005.

First impressions

First impressions matter, especially when one is dealing with one's money. So Grisbi's initial screen - essentially a large, empty, gray box with a small menu bar on top - can be a bit disconcerting. A personal finance manager should be designed to work well for people who are not particularly familiar with computers, so it would be polite, when starting from the beginning, to lead the user through some sort of initial setup. Or, at least, give a pointer in that direction.

KMyMoney starts in the usual manner for KDE applications - slowly, and with a lot of strange stuff written to the standard output. Once you get past that, a splash screen comes up, followed by a window with a place to click to go through a set of setup screens. It asks for a bunch of personal information, the purpose of which is not entirely clear. Next, the user gets to pick a "base currency," with the Afghani being the rather unhelpful default. Almost every imaginable currency is available, from the Mongolian Tugrik to "Gold." After picking from a directory of account templates (they could have set a default from the currency the user just chose, but don't), the user lands in the main KMyMoney2 screen.

GnuCash throws up a "tip of the day," immediately overlaid by a little window giving an opportunity to create accounts from scratch or import a QIF file. The former option yields a "druid" which enables a choice of currency and presents a set of common accounts to create. GnuCash arguably has the most capable and friendly startup mechanism, but it must be said that its continued use of GTK1 shows. It simply is not as pretty as other GNOME applications, large pulldown menus (currency choice, for example) cannot be navigated with the scroll wheel, and it feels generally older.

Account creation

One way or another, users will have to create accounts in their shiny new finance manager. So each application provides an account creation screen. We'll get into those shortly, but, first, it's worth looking at the types of accounts which are supported by each application.

• A money manager must support accounts which hold money. All three of them understand basic bank accounts - KMyMoney distinguishes between checking and savings accounts, though it is not clear how it treats them differently. All three have "cash" accounts - bank accounts without the bank, essentially.

• Another common feature is accounts for liabilities - loans, credit cards, etc. Grisbi provides only a single "liability" account. GnuCash adds credit card accounts as a separate type, while KMyMoney goes even further with a separate loan account type.

• All three packages have accounts for assets - a place to keep track of the value of your car, for example. Many dotcom veterans will appreciate this; it makes the "net worth" calculation look much nicer if you can include the value of that 1999 Ferrari. GnuCash has a separate "equity" account type which is used for initial conditions - your net worth before GnuCash entered the picture. The equity account is needed to make all of the double-entry accounts balance out.

• GnuCash is alone in having income and expense accounts. This type of account is required if you are going to do double-entry bookkeeping - every transaction must be represented as a transfer between accounts. Since KMyMoney claims double-entry capability as well, it presumably implements a similar type of account, but they are presented to the user as "categories."

• Grisbi does not have any sort of account for investments. There is a general "investment" account type in KMyMoney; GnuCash, instead, provides separate currency, stock and mutual fund account types.

• Finally, GnuCash has "accounts payable" and "accounts receivable" account types which are used with its small business features.

GnuCash takes a "one big window" approach to account creation - everything one may wish to add is to be found there. Some of the fields are obvious, others less so. "Commodity" is, for most accounts, the currency in which the account is denominated. The "account code" is a number which, seemingly, only affects the order in which the accounts are sorted in the main window. It is nice to have the control, but a modern user expects to be able to effect that sort of ordering just by dragging the accounts around. The account type must be chosen from a tiny, scrolling window. With GnuCash, one must also choose a "parent account," because accounts are stored in a hierarchical manner.

What the GnuCash account creation window lacks is any way of creating accounts (such as mortgages) involving regular, complicated payments. That capability does exist, but it is to be found deeply under the "actions" menu in the main window. The "Mortgage/Loan Druid" is highly capable, though with some strange defaults (interest rate of 0.001%, for example). It understands things like escrow accounts and mortgage insurance, and can set up everything which is needed to track the loan. It gives every impression of being a feature which was bolted on relatively late in the game, however.

KMyMoney has the slickest new account creation dialogs. A request to create an account leads to a series of graphics-heavy windows appropriate for the type of the account. Unlike GnuCash, KMyMoney tracks "institutions" as separate entities, and can (optionally) associate accounts with them. Accounts involving regular payments (such as credit cards) will draw an offer to set up a scheduled transaction. Setting up a loan requires entering interest and payment information as well. The mortgage mechanism is a little less sophisticated (it does not understand escrow accounts, for example), but it has everything which is truly needed.

KMyMoney implements hierarchical accounts, but there is no way, in the account creation process, to specify where in the hierarchy an account should be created. Accounts can be moved later, however.

Creating an account with Grisbi starts with selecting the account type. Then the main application window is taken over by a form where the relevant information can be filled in. Grisbi, like KMyMoney, keeps track of financial institutions. Grisbi accounts can also have minimum balances associated with them; running an account below the minimum yields a warning.

Grisbi accounts have a currency associated with them; your editor was somewhat surprised to see that the Euro was the only option provided. As much as your editor would have rather had all of his accounts in Euro over the last few years, that is not the case. Currencies, as it turns out, are one of the stranger corners of the Grisbi interface. It is possible to change the list of "known currencies" under the Edit->Preferences menu. Clicking on the "Add" button yields the usual lengthy list of currencies, sorted in a way seemingly designed to force both North Americans and Europeans to scroll for a long time before finding anything useful. Once the currency has been "added," it is available for use in new accounts. But this dialog is not available until at least one account has been created. So those of us unlucky enough to have our accounts in $US must first create a throwaway Euro account before adding our native currency (which Grisbi clearly knows about) to the "known currencies" list.

Grisbi has no notion of hierarchical accounts, and no "druids" for the addition of more complicated accounts.

Entering transactions

Personal finance applications offer no end of features and capabilities to users. What most of those users will spend their time actually doing, however, is entering transactions into the program. It would thus make sense for those working on this kind of software to focus a great deal of effort toward making this task quick, easy, and relatively easy to get right.

GnuCash is the clear winner in this area. The register window has all of the information required, and is highly configurable. Transactions can be entered quickly, with no need to use the mouse once the process is started. GnuCash remembers transactions, so it can expand names and cut back on typing. Nicely, it seems to have some way of tracking which descriptions are used most often, so the suggested expansion is usually the one you want. For payees which have been seen before, GnuCash will fill in the transfer account (read "category") and the dollar amount seen the previous time. As a result, many transactions can be entered with very few keystrokes. The only slight glitch is that the transaction memory is local to each account, so things do not always expand when one might expect them to.

GnuCash allows the date to be changed with the + and - keys (= works in place of +, saving wear on the little finger). A + in the number field will generate the next check number. This number is calculated from whatever was entered last, rather than from the largest number ever seen; this feature is much appreciated in households where more than one checkbook is in use for the same account. Unfortunately, there is no way for GnuCash to help effect any control over what the spouse does with that other checkbook.

The KMyMoney register, instead, is harder to work with. Starting a new transaction requires an action with the mouse. Thereafter, everything can be done with the keyboard, but more keystrokes are required. When GnuCash proposes an expansion for a payee, a single tab is sufficient to accept it, set the category, and move the cursor to the amount field. KMyMoney requires a combination of tabs and carriage returns before it will move on to the category field - and, if you get the combination wrong, it will simply enter an incomplete transaction. Several fields must be tabbed through to get to the amount. KMyMoney will remember categories and amounts (but only after you find and turn on the relevant configuration option).

KMyMoney can also guess check numbers (again, after an option has been explicitly turned on), but it is a simple "biggest yet" calculation with no attention to the numbers the user is entering at the time. The check number cannot be incremented or decremented with any keys that your editor was able to find. KMyMoney will warn the user if a transaction with a duplicate number is about to be entered; GnuCash does not perform that check. The date can be adjusted using the up and down arrows, but something inspired the KMyMoney developers to have the arrow keys adjust the year of the transaction by default. Even your editor does not normally get quite that far behind in his checkbook maintenance; it should not be necessary to hit two right-arrows to be able to change the day of the month.

KMyMoney requires the user to choose between five different types of transaction to enter: checks, deposits, transfers, withdrawals, and "ATM." GnuCash has done away with that distinction; everything is a transfer. Things are simpler that way; there should be no need to categorize transactions for the application in this manner.

While KMyMoney is, in many ways, a very nice application, the slower transaction entry process would, on its own, be enough to disqualify it as far as your editor is concerned. Fortunately, none of the issues mentioned here should be particularly hard to fix.

In many ways, Grisbi almost gets transaction entry right. It is possible to get through most of the form by tabbing, payees are expanded and previous information substituted, and check numbers are guessed based on what was entered previously. Your editor had some difficulty at the beginning, where Grisbi was convinced that transactions were being entered in Euro; since the account was in dollars, Grisbi asked for a conversion factor. Once told to use dollars for transactions, however, Grisbi remembered - but transactions should default to the currency associated with the account.

Dates can be adjusted with + and -. Unlike GnuCash (and a number of other programs), Grisbi does not accept = as a substitute for +. Each Grisbi transaction always starts with the current date; it would be more useful to use the date of the previous transaction, as GnuCash and KMyMoney do. But the truly obnoxious feature is that Grisbi assumes that all transactions are done with a credit card (for a checking account, even), and telling it that a check is involved requires using the mouse. That slows down the entire process.

GnuCash is also able to work with banks supporting the (German) Home Banking Computer Information (HBCI) protocol, but your editor, lacking bank accounts in Germany, was unable to test this feature.

There is much to be said for not typing in transactions at all. Quite a few banks will make transaction information available via the OFX/QFX file format, and all three programs reviewed here are able to import that format. GnuCash sorts imported transactions into three piles - those which it cannot import at all, those which need to manually have transfer accounts (categories) set, and those for which it was able to guess categories itself. The category assignment process is a bit cumbersome (it would be nicer if the same interface was used here as in the register) but effective. The automatic assignments appear error prone, so one needs to glance them over before finishing the task.

Grisbi will simply import the whole set of transactions into the indicated account with no category information at all; the user must go in afterward and fix things up one by one. Unfortunately, your editor was unable to build OFX support for KMyMoney.

Reconciliation

The other common time-consuming task performed with personal finance managers is account reconciliation, otherwise known as the process of figuring out why the bank thinks you have less money than you thought you had. The reconciliation process tends to be tedious, with occasional unpleasant surprises. A finance manager can do nothing about the financial pain involved in reconciliation, but it should at least make the process as quick and straightforward as possible.

The GnuCash reconciliation process starts with a request for a statement date and ending balance. GnuCash attempts to come up with a default date, but the results are occasionally strange. The window also asks whether subaccounts should be included in the process, and gives the opportunity to enter an interest payment. The actual reconciliation window contains two panes; GnuCash, unlike other programs, separates deposits and debits for this process. The key by which items are sorted can be selected by clicking on the column heading - a nice feature if you like to have checks listed in number order, rather than by date. Reconciling items is a simple matter of clicking on them. Double-clicking on an item will bring up a register window with the cursor at that item, allowing quick corrections to be made. The register window can also be used to enter new transactions (all those ATM withdrawals you forgot, for example) at any time.

The reconciliation process in KMyMoney is similar; during the setup phase, it also allows the entry of bank charges, however. The reconciliation window has a single pane, with deposits and debits mixed together and sorted in date order. There does not appear to be any way to change the sorting order. Double-clicking on a transaction allows it to be edited in place. KMyMoney allows the user to "postpone" the completion of the reconciliation process, and will remember the relevant information for the next time.

The Grisbi reconciliation option is hard to find - it is not anywhere in the menubar. Instead, one must go to the "transactions" window, then hit the "reconcile" button on the lower left. Statement information is then entered in the left column; there is no provision for the entry of interest payments or bank fees. Clicking on transactions will cause them to be marked as reconciled (at least, one assumes that "P" means reconciled in some language); double-clicking allows them to be edited in the bottom part of the window. The process is ended with the "OK" button on the lower left; that button is not active until everything balances out (there is no "postpone" option).

Conclusion to Part I

With the features described above, any of these three programs can be used to keep track of a set of bank accounts. Personal finance programs can offer much more, however. The second part of this article will cover some of the other capabilities expected of a contemporary finance application, including:

• Scheduled transactions - tracking (and reminding about) payment which are to happen in the future.

• Loan tracking, including tracking the current principal balance.

• Reports. Can you see where the money is going, how it got there, and make a nice pie chart out of it?

• Investment tracking: stocks and funds, dividend reinvestments, capital gains, use of online price information, etc.

• Budget creation and tracking.

If space and time allow, the second part may also include a look at the business features offered by GnuCash. Or that part may have to wait for the Exceedingly Grumpy Editor's Guide to Small Business Accounting Packages.

Your editor's final comment is this: for many years, there was only one free personal finance application of any note: GnuCash. It is now interesting to see there are three viable programs out there. The situation has changed significantly - for the better - over the past year. Come back for the second part (to be published, probably, near the beginning of October) to complete the tour of what these programs can do, and a final recommendation from the editor.

[Part 2 is now available]

Comments (61 posted)

Mercurial: an alternative to git

One of the more visible outcomes of the BitKeeper fiasco earlier this year was the development of git to replace the use of BitKeeper for kernel development. A less prominent, but equally capable alternative began development at roughly the same time. Matt Mackall started work on Mercurial just a few days after git and since that time it has made great strides as a distributed source code management system. It has matured to the point where at least one large project, the virtual machine monitor Xen, is using it to manage their code.

Mercurial, like BitKeeper, git and others is targeted at projects where the developers are spread out geographically and need to be able to perform source code management functions without the bottleneck of a central repository. Matt adopted the design goals that Linus used for git (speed, distributed operation, and trustability) and added the additional constraints that it should be CPU, storage, and bandwidth efficient. Mercurial is written in Python, with some C extensions for CPU intensive pieces and is fairly small, weighing in around 7500 lines of code.

Disk based storage of Mercurial revisions is done using delta compressed revision logs (revlogs) that are stored with disk access optimization in mind. The revlogs are stored in a directory structure that mirrors the structure of the project and filesystems are generally optimized for this kind of access. Over time, fragmentation of revlogs will occur, but a tar or copy of the directory will have the side effect of defragmentation. Other SCMs that use filenames based on the SHA1 hash of the contents (git for example) tend to require more disk seeking because file locality is a function of the hash rather than the filename. Because the revlogs are smaller than keeping each individual revision of a file as a separate object, Mercurial uses less bandwidth when syncing repositories as well.

A single command, called 'hg' after the chemical symbol for mercury, is the command line interface to Mercurial and provides a consistent set of switches used for various source code management tasks. Users of CVS or subversion will find it immediately familiar to type commands like 'hg commit' or 'hg update'. Also, there is the 'hg help' command which gives a quick overview of the commands available and a summary line for each of the individual commands.

The framework that Mercurial provides will be familiar to anyone who has used a distributed SCM. The push/pull style of development where tree maintainers pull changes from contributor's feature branches and merge them into their current working tree is the model best supported by Mercurial. Both HTTP and SSH are supported for network syncing and the hg command itself can be run as a server to export a repository for pulling via hg and for browsing via the web.

Various extensions and other tools have been created for Mercurial, or, in some cases, ported from git. Visualization tools for examining repositories are available as well as conversion utilities to convert repositories from other SCM systems. Chris Mason's Mercurial Queues extension adds patch management features, similar to quilt, to hg.

Interoperability with git is clearly a feature desired by Matt and the other developers. Matt's intent with Mercurial was to create a tool that he could use for kernel development and since the various official kernel trees are using git repositories, tools to extract information from git and into Mercurial have been created. There is a repository that tracks Linus' git repository for the 2.6 kernel and there are plans to add a git export feature to Mercurial.

Mercurial has an active development community, a wiki with a great deal of information for new users, and a very responsive mailing list. It is a fast, scalable, easy to use, and generally well thought out system that is being used for kernel and other development. It currently lacks a few features that developers might want (a way to compare repositories for example), but the pace of development has been rapid and these holes are likely to be filled quickly. For anyone who is thinking about using a distributed SCM, Mercurial is definitely worth a look.

Comments (28 posted)

Page editor: Rebecca Sobol
Next page: Security>>