GnuCash Personal Finance Manager

GnuCash Project Goals

The people behind GnuCash aim to create a world-class GPL'ed Open Source Personal Financial Application for GNU/Linux and other Unix's. This page reviews some of the technical issues and development status surrounding this project. It is a kind of an FAQ for developers and contributors, providing status, and suggesting directions and technologies for deploying new features. If you simply want to get a better idea of what GnuCash is and what it does, visit its home page. The home page contains screen shots, news items, and mailing list archives.

There are currently several different versions of GnuCash. We've adopted the kernel numbering scheme: even minor release numbers (1.4.x, 1.6.x) are considered to mark stable releases, while odd numbers (1.5.x, 1.7.x) mark development releases.

The latest version is available only via CVS. Occasionally, some of the more stable CVS versions are given a version number, and packaged as a precompiled deb or RPM install package. Naive or beginning users should probably stick to version gnucash-1.6.0. More adventurous users can try one of the 1.7.x releases, However, keep in mind that they are in a state of constant change and will often be unstable.

This document is divided into several sections.

  1. Architectural Goals
  2. Requirements
  3. Sizings
  4. Features

Architectural Goals

There are some over-reaching design principles and philosophies that we intend to maintain. Some of these concepts and terms are introduced in this section.

Separation of GUI and Data

First, we must maintain a clean separation between the data structures and the GUI that manipulates them, along the lines of the Model-View-Controller paradigm.

GnuCash also needs to deal with multiple distributed data sources: stock quotations from the net or transaction confirmations from online banks and brokerage houses, or from more mundane sources, such as file imports, or merger of data from several users. Amongst these terms, the concept of a global Model-View is dated, and somewhat inappropriate. Rather, we need to be concerned about how data is represented in the local address space of the GUI, how the GUI manipulates it, how data is brought in and merged from external sources, and how that data is again output, whether to a file or a local or remote database.

Thus, the View essentially represents a local data cache of the data that is immediately present and being displayed, reported, and manipulated. The Model is the abstraction of that data that the GUI (the controller) can act on.

The Financial Engine

In GnuCash, the Model is implemented via the Engine API, and the View is the data that is currently in the Engine. Thus, the Engine is a set of programming API's that the GUI (or a script, or even a clever command-line-addict) can use to manipulate the data.

Currently, the Engine provides basic accounting structures These include:

The Engine has a basic two-phase commit model, and a query mechanism for finding the data needed for reports and views. The goal of the two-phase commit and query model is allow the creation of multi-user server based backends, such as an SQL backend, and RPC client-server backend, or an XML-based HTTP/web backend. This design seems to work for the above-named backends.

The Engine currently handles only a basic set of data sources:

However, since the Engine is meant to be the interface between the GUI and the financial data, it is really intended to be able to do much more. In particular, it should be possible to create a peer-to-peer network model, where gnucash peers can synchronize data between themselves. The engine should also be expandable to handle other sources of data, such as OFX/IFX, the Open Trading Protocol, or the OMG CORBA General Ledger submission. In particular, it should be possible to use GnuCash not only to view data from these sources, but also to manipulate it and send it back.

Modularity, Extensibility and Customization

The above structure should lead us to view GnuCash not so much as a tightly integrated application, but rather as a loose confederation of component objects, libraries and interfaces. This has a number of advantages for both the deeloper and the user. For the developer, it allows parts to evolve semi-independently of one-another, and to be used in other, non-gnucash projects. For the user, a good extensibility allows the use of arrangements: a way of broadly customizing the appearence and behaviour of gnucash, and then allowing users to very easily share these customizations with one another. Such arrangements might be collections of canned reports, e.g. for business or home user. Or they might be the menu contents: one menu arrangement is for gbeginners, another for 'power users', a third for business owners. Th goal is that broad areas should be not only customizable, but it should be possible, even easy, to trade these customizations between users.

In order to facilitate the gluing together of these parts, as well as simplify the questions of customizability, change and rapid development, GnuCash makes use of the Scheme extension language (as implemented in the FSF Guile interpreter), to glue the pieces together. (Note that the engine interface is also available with Perl interfaces, thanks to a SWIG wrapper.

A Web Browser for Financial Data

More and more finacial data is moving onto the web. People shop on-line. They pay bills on-line. There are even some promising e-wallet systems (such as WebFunds). For GnuCash to be relevent in this on-line world, it must be able to interact with these systems. There are several steps that can be taken along this path. First, it must be possible to simply and transparently import financial data off the web. Click on a QIF file, mime-type "application/x-qif"? Gnucash sucks it in without burping. But, in a more distant future, can GnuCash originate transactions? It should be able to!

GnuCash can be and should be "The Sophisticated Financial Web Browser". All GnuCash reports and the help system are HTML-based. In fact, GnuCash has a built-in web browser that can view ordinary web sites. Interactive gnucash components such as the bar and pie charts, or the graphs and reports, can all be served up by a remote web server, as well as locally through the GnuCash application. This allows GnuCash to blur the line between web browser and financial application, and offer the best of both worlds.

Why is this a good thing? One can always have a pure web-based accounting solution (such as SQL-Ledger) that uses ordinary web browsers to view the financial data. But there are problems: dynamically-generated html and cgi-bins aren't as pretty or easy to use, or as fast, responsive or sophisticated, as what you can do with a custom client. That is, GnuCash can be more interactive, easier to user, slicker and more professional looking in style and presentation than a plain-old dynamic website. Financial ASP's simply cannot currently offer the kind of utility, flexibility, responsiveness and integration that GnuCash can offer.

In theory, the 'Java revolution' was supposed to provide this function, with downloadable Java applets providing the 'fancier- than-plain-html' interface. But a Java applet that is this sophisticated would also be large and slow to download: it offers no inherent advantages over native code. Another problem with Java is the inherent propreitary fragmentation: no two Java applets are alike: every site has thier own; there is no standardization.

In order to solve the 'no gui standardization between websites' problem, there are a number of businesses that have arisen to provide "financial aggregation". You sign up with these sites, and let them get all of your credit-card, bank and investment info, and they can provide a unified interface for your bank statements, with graphs and reports (all for a monthly fee). The existance of these services highlights a problem: the inability to aggregate the same data on the users desktop, in a simple, coherent fashion. Let us posit that GnuCash, with the right on-line interfaces, would be a natural for this. For the paranoid, this has the added advantage that no one business has access to all of your financial records.

To put it another way, GnuCash can provide a centralized, trusted store for financial data that no other application can provide. The convenience factor: if you have trading accounts at e*trade and charles schwab, then GnuCash can be the central place where you can oversee all of your investments. The trust factor: maybe you can trust your web bank. Maybe you can trust your web stock account. But can you trust a single web entity with *all* of your financial data? Someone who won't treat you as 'just another consumer' and sell your 'consumer profile' to anyone who cares to stalk (ahem, target) your financial activity (ahem, purchasing) patterns? Didn't think so. Of course, you *could* use some proprietary financial software. Assuming, of course, that you trust it not to have any built-in covert channels: nothing that might send back the make and model of your CPU and the last ten transactions 'home to mommy' for 'diagnostic purposes'. Because open source software, such as GnuCash, can be audited it can be trusted in ways that no proprietary software can be. In an increasingly net-connected world, the ability to build trust through audits will be increasingly important.

Looking Into the Future

Things like support for OFX, and small-business features are hopefully in the near term future of gnucash. Lets take a look at some more far-out possibilities.

An e-wallet, just like a real wallet, stores cash. You can use that cash to pay freinds or businesses. Just like a real wallet, an e-wallet should not charge you monthly fees. It should provide you with some measure of anonymity and privacy. An e-wallet should also do something no ordinary wallet can do: show you a monthly report of expenditures. GnuCash should get e-wallet features.
Authentication, Authorization and Access Control
How does an on-line merchant know that you are who you say you are? How can you use GnuCash to authorize a bill payment? Sooner or later, smart-cards will provide the sort of authentication and access control that is only groped for with PGP/GPG, keyrings, x.509 certificates, and Microsoft Passport/Hailstorm. Of all the electronic things in the electronic world where access control and authentication are important, real money is the most so.
Bill Presentment, Bill Pay
These magic keywords just mean that a merchant wants to send you a bill, and wants you to go to thier website to pay that bill (they want your eyeballs). Of course, for the user, it would be more convenient to have the bill show up on the desktop, inside of gnucash, and get authenticated and paid out from the desktop (by gnucash), as you would do with all of your other bills.


Lets take a look at who the current and potential future users of GnuCash are, and how they might use it. The classes: These different applications may use some of the same financial terminology, and hopefully might share a fair bit of code, but have quite different goals and requirements.

Basic Household Accounting and Budgeting

Important properties of a personal finance system include:

Personal Portfolio Management

Small Business Needs

Reconciling Those Needs

A seemingly contradictory factor is that the kinds of sophistication that are required vary considerably. Consider:

Another set of contradictory requirements has to do with the back-end, and interfacing to other systems:

It may be that these will require completely different systems, and that GnuCash cannot be "all things to all people." This remains to be seen.


This section attempts to guess how hard it would be to implement certain features.

Personal Financial Application

Below are listed the technical work items needed to implement the features that home users might hope to have. They are listed in approximate order of priority.

The right hand column shows a sizing guesstimate. pm == person-months. These sizings are meant to show 'effort needed to complete', rather than 'total effort required'. Thus, half-finished items have smaller sizings.

Feature Sizing Responsible
Internationalization Done -
Reports Medium Stimming/Gribble
Graphs Medium Guppi/Gribble
Transaction Query Small Linas/LewisMoss
Simplified Ledger Done -
Themes, Icons, Glitz Small Various
Miscellaneous Small Tasks Done Various
Alerts, Recurring & Scheduled Transactions Medium ?
Budgeting Medium Dave
Classes/'Action' Field Small ?
Books, Accounting Periods Small Linas
Check Printing Small Grib
Wizards Small Dave, Bill-qif
Arrangements Small ?
User Preferences/Session Mgmt. Done ?
Quicken(TM) QIF Import Small Gribble
IIF Import Small ?
IIF Export Small Grib
Multiple Currencies Medium Rethink Requirements-Linas
Architecture Review Small RLB, Dave
Automated Test Suite Medium ?
Stock Quotes, Price Quotes Small ?
Install Small ? ?
Forced Double Entry Small ?
401K etc. Small ?
Searchable Documentation Done grib
Reconcile Auditing Small ?
Annotate with Investment News Small ?
Loan and Mortgage Calculators Small Dave
Overdraft Alerts Small ?
Technical Stock Analysis Medium ?
Depreciation, Sinking Funds Medium ?
OFX, Online Banking, Trading, Bill-pay Large Dave
Tab-delimited ASCII export Small ?
Tax Preparation Large ?
Sync with Palm Pilot organizers Medium ?
Emergency Records Organizer Small ?

Small Business Features

Features that small/medium businesses expect.
Feature Sizing Responsible
Enriched Engine, Financial Objects Large ?
SQL I/O Done Linas
Multi-User Support Small Linas
Address Book Small ?
A/R, A/P Accounts Payable, Receivable Medium ?
Payroll Medium ?
Invoicing Medium ?
Job Costing Medium ?
Expense Accounts Large ?

Features and Functions

This section reviews the current status of various features. Some of these are 'in process', some are 'almost done', some are 'completely done'. This section thus provides status on both where we've been, and where we're going.
All menus, markup and help-text should be internationalized, so that GnuCash may be usable in any country. This would include the printing of currency values in the local country conventions.

Current status: Essentially Done (?)

A variety of reports, including Net Worth, Balance Sheets, and Profit and Loss statements. These should be printable: that is, exportable as HTML as well as print-ready postscript. These should be easy to customize. Ideally, even novice users should be able to create custom reports.

The Report Generator should be a separate but "dockable" subsystem of the whole. That is, it should be possible to run the report generator in a stand-alone, read-only fashion without having to start up the main application. It should be possible to run reports nightly from a command-line and/or cron job. The GUI should remember what reports were run last time, and these should be re-run/redisplayed whenever the report generator is used.

One difficult aspect of reporting is designing a configurable interface, so that people can build custom reports. The New Reporting Infrastructure is seeking to build this up using Guile. Note there are several flavours of customization:

Note that the customization info should be stored in a Arrangements File (see below).

Generated reports should be exportable to other gnome systems (probably using bonobo). Reports should also be exportable to the Gnumeric spreadsheet (probably by writing out gnumeric file format). Export of CSV (comma separated values) and tab-delimited formats (for other spreadsheet import) would be good. Tables & etc. should be exportable to AbiWord, StarOffice, other word processors. (formats: docbook sgml? would then make convert to richtext, TeX easy.) Export should be as wysiwyg as possible.

Must be possible to e-mail reports (for example, invoices) to users. Suggest an evolution addressbok /mailer bonobo plugin.

Relationship to budgeting not clear ...

Stock portfolio tools should include a Cost Averaging report, Market Index report, Stock Option values, Estimation of capital gains tax liabilities.

Reports should be printable to printer (postscript/ Adobe Acrobat).



Provide support for graphs, charts, etc., such as: Asset allocation pie chart, portfolio value vs. cost, ROI. Graphs should be printable to printer. Graph generation should be fully integrated with reporting, both for data collection via queries, and for displayed output.


Transaction Query
Allow user to build (complex) queries to locate a set of transactions that match some criteria: e.g. a date range, or a matching payee, description, amount, etc. Once a user has created a complex query, it must be possible to memorize it (i.e. give it a name, and store it for future reuse).


Simplified Ledger
Ledger should look clean, work easily.


Essentially done.
Themes, Icons, Glitz
A variety of finer touches need work: The following have been completed, but possibly not fully documented:
Miscellaneous Small Projects
A variety of small internal projects. All have been completed as of 1.6.0
Books, Accounting Periods
Ability to close the book at end of the fiscal year. This consists of several steps:


Check Printing
Create a check-printing ability. Include MICR (Magnetic Ink, Computer Readable) check printing abilities. Yahoo Check Printing provides a list of vendors & printers.

Print vendor/client/payee address on the check (so that check can be mailed with window envelopes.) This requires gnucash to integrate with addressbook.


Create a set of wizards to walk through some of the more complex tasks, such as new user setup, account creation, QIF import, budget prep, obscure functional corners.

Wizards are great, but lets not thow away the denser GUI's. For 8-hour-a-day users, the wizards can be irritating. A single, dense screen can be more efficient and nicer. So when adding wizards, don't dump GUI's !! (instead, make them 'advanced' features).

Status: The following not done:


An "application arrangement" is the defining look-n-feel of an application. The idea is similar to, but not the same as 'skins'/'themes'. Its similar to, but not the same as allowing a user to set 'preferences'. Its similar to, but not the same as, allowing a user to generate customized financial reports. In the context of GnuCash, a 'arrangement' should be a file (that can be traded by users, uploaded and shared) that controls important aspects of how the application is configured.

In particular, the GnuCash Arrangement should include the following:

A good arrangement infrastructure will not only allow gnucash to be configured for different application domains, but also will allow users to fine-tune thier own prefered arrangement. It can also simplify the code base: instead of having two products, a home-user application, and a small-business application, each with a different code base and #defines and what not, instead, we have one code base, and different arrangments for each. However, most importantly, the arrangments should be easy to share between users. They should be such that users are encouraged to trade and use arrangments, and to create new ones that suit thier needs.

The idea for arrangements was inspired by Adam Curry's commentary on radio formats and Napster.

Status: Not started. Individually, all these cusomizable things exist here and there in gnucash, but they cannot be shared between users: a gnucash user cannot mail her favorite 'arrangement' to her freind.

User Preferences, Session Management
A dialog system and file format for manipulating user preferences. Preferences include things like default currency, register layout and colors, etc.

What are some of the competitive preference-handling technologies? Lets get some URL's here ... Following the Unix tradition, there is no global preferences registry. Note that session management and preferences are related things ... sort-of. Right now, we don't treat them as such ...


Done, more or less, version 1.6.0.

Architecture Review
The application is wired together partly with C, partly with Scheme. The architecture of the wiring and how scheme is fit in needs to be reviewed, with a general overview created so that additional extensions may be added in a straightforward manner.

The overall architecture is envisioned thus: All code, including the transaction engine, the file I/O routines, the menus, and the ledger, will be abstracted into compact modules that can function independently of each other. At the highest level, there will be a infrastructure with extension language interfaces that will "wire together" the various modules.

Such "wiring together" will consist of a dispatch infrastructure that will allow arbitrary menu entries to be hooked to arbitrary modules. The configuration for menu entries, and their associated callbacks, will be specified in an extension-language configuration file. At the final stages, it is highly desirable to be able to, in some manner, import new modules without requiring that the application itself be recompiled and relinked.


Recurring Transactions, Calendar Alerts, Scheduled Transactions
(1)Add support for automatic, recurring transactions, e.g. mortgage payments, fixed-interest bonds, regular salary checks, regular gas/phone/electric bills, etc.

(2) Recurring bills, salary income, etc. are simpler to handle, since they don't have interest rates, balloons, etc. They do/will have multiple splits (e.g. payroll gross, fica, futa, income taxes, payroll net).

(3)Provide list of upcoming & recently paid bills/scheduled payments/scheduled deposits for the next 1,2,3,6,12 months. Historical view shows payments crossed out (!?)

(4)Loans & mortgages are one of the more complicated recurring transactions. Typically, there might be a years worth of smaller payments, then a long string of larger payments, followed by a balloon.

(5)Provide a calendar-display of upcoming & past scheduled payments. Clicking on a calendar day should raise up editable list of transactions. Calendaring should include generic red-lettering of important dates: taxes due, insurance renewal dates, domain registration renewal dates, ISP contract expiration date :-). These may or may not be associated with transactions. Memo's should be possible. Pop-ups should happen when dates get close. Technology: best bet is the Ximian Evolution Calander component.

Design Notes: Most alerts & data storage should be driven out of the engine. This will enable multi-user, distributed use. Note: alerts should be piggy-backed on a general alert infrastructure within the engine, viz, registered callbacks when balances change, so that windows can be redrawn. Not clear on if/how calendar events might be server-ified. (On the other hand, a good calendar should be server-ified, and thus viewable by secretaries, co-workers, etc.)

More complex financial instruments may need a guile-based extension mechanism to compute values .... simple interest/mortgage calculators should be done in C in the engine ... (e.g. depreciation schedules ... under us tax law, a variety of different schedules are allowed ... )

May need interfaces to email for emailed alerts.

Plot forecast graphs based on scheduled income & payments ... is this tied into budgeting ????


Ability to create a budget (i.e. - estimates of future expenditures). Reconcile actual expenditures against future expenditures. Create simple, step-by-step 'financial plan' budgeting GUI's: Create a summary budget/track-record budget report that a professional financial planner/advisor could use.

Note that the above 'step-by-step' budgeters will have a very very different GUI than what the budgeting system required for a small-business might look like.

Note that the utility of budgets is greatly enhanced by using them with 'classes'.


Ability to mark certain journal entries as belonging to a 'class', so that expenses (or income) can be categorized in more than one way. For example, the expense of a trip might include food, travel and lodging, and thus be spread over three different expense accounts. None-the-less, we want all of these entries to be marked as being in the same class. (Alternate names: 'job costing' is the report that's generated, 'cost center', 'cost pool', 'pooling') Note that classes can be particularly useful when used with budgets: viz. I set aside $10K in the budget for some activity, then deduct the actual costs. Note that it should be possible to roll the remainder over to somehere else (!)

Confusion: isn't this what the 'action' field is supposed to do? The 'action' field is under-utilized.

This requires the following:

Automated Test Suite
Build automated test suite, including:

Quicken(TM) Import
Ability to import Quicken QIF files. Both MSMoney and Quicken use QIF files to export data. Need both wholsesale data import, and incremental (staged) merge.


IIF Import
Ability to import IIF (Intuiut Interchange Format, used by Quickbooks) files, quickbooks, some upsacle accounting packages use this format.


IIF Export
Ability to export Intuit IIF files. The IIF format is more rational than the QIF format, and other 'real' accounting apps support IIF. Several design alternatives are apparent:

Status: not started

Stock Quotes, Price Quotes
Add ability to obtain stock, mutual fund, and currency trading data from news agencies, web pages. Add ability to download historical prices as well. (e.g. get 5-year history of mutual fund performance vs. DJIA).

Right now, stock prices are stored in a separate, simple pricedb.


Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux, etc. Possibly use a 'configure'-like way of dealing with install inconsistencies.

Multiple Currencies
Need to support multiple currencies. Work is needed in the GUI. The engine currently supports multiple currencies by treating them as securities, thus allowing currency trading. The currency-trading register needs a complete overhaul as it is obtuse and unintuitive. Weird stuff is in weird columns.

A simplified way of dealing with one-shot currency exchanges needs to be implemented, essentially just a simple calculator pop-up. This might be handy for the occasional business traveler or tourist with some minor currency trades.

Implement the 'correct' way of handling this when user is working in multiple currencies on a regular basis.

SERIFF Simple Exchange Rate Information File Format. Completely *.ini-centric in layout and design, but otherwise seemingly quite complete.


Forced Double-Entry
The system supports double-entry: every transaction indicates a pair of accounts: one is debited, and one is credited.

Double-entry is a powerful way of ensuring the integrity of of the financial data. Currently, while double-entry is supported, its use is not enforced: the user can create dangling transactions, where only one account is indicated.

Although this is acceptable for home use (arguably desirable, since it allows the casual user the simplicity they desire), it is not acceptable for business use. (The counterargument is that casual users that aren't accountants need all the help at getting things right that they can get.)

It must be possible to enforce double entry, so that a transaction cannot be completed until two accounts have been specified.

Restricted Double Note that sometimes, the words 'single-entry' have a an alternate meaning: they can mean 'a double entry account which can only be credited, or debited, but not both'. We need to implement this.

Current status:

401(k), Retirement Savings Plans
401K, 403, IRA, Roth IRA, SEP, Keogh ... Retirement Savings Plans often do not put a high priority on tracking costs, as the tax implication is that amounts are taxable upon withdrawal, meaning that there is little necessity to track capital gains. (huh??)

Annotate with News Stories
Download, save, annotate investment news and research. Provide a way of storing news stories with accounts, and possibly annotating individual transactions in the same way.

Searchable Documentation
Need to add a 'meta keyword' tag to the documentation pages, this will help the search engine (e.g. htdig) better categorize the help. Mifluz might be more embeddable ... I am told that htdig-API is in good solid condition for this, but undocumented.

Status: Done, using a simple keyword search, homegrown. The only problem is it doesn't support compound expressions.

Reconcile Auditing
When a collection of transactions get processed through the reconcile dialogue, user needs to be able to add a note to this, i.e. this set of JE's will be treated as a group. The note (and date) can be later called up as a part of an audit procedure. The act of reconciliation is treated as a historical event that needs to be logged.

Loan and Mortgage Calculators
Provide a variety of simple GUI utilities to allow user to calculate the future value of loans, mortgage payments, interest payments, etc.

Consider the following dialogue layout:

loan amount $_____________ currency _________ (pull-down menu)
Remaining balance $___________
Payment amount $___________
balloon  payment $_____________
other payment $________  (e.g. escrow, tax)
Payment frequency (weekly/monthly/bimonthly/quarterly/yearly)
loan start date mm/dd/yy   length -----(weeks/months/years/payments)
loan time left (number of days/weeks/months, rounded)
number of payments left
interest rate  %__________________
payee ____________
pay-from account __________________
next due date mm/dd/yy
Note that in the above, not all fields are independent: some can be calculated from others. The other payment should bring up a mini-register, allowing user to add any number of splits.


Overdraft Alerts
Overdraft alerts are pop-ups that pop up whenever the user enters a transaction that would move an account below some minimum balance, or above some max balance (for a bank account) or an expense/spending limit is reached (on an expense account). A similar but different alert can be implemented for price highs & lows. Note that these alerts do not require any sort of calendaring or recurring transaction support.

Design requirements: implement multiple (not just two) alerts for any account type. Alert should consist of


Technical Stock Analysis
Provide technical stock analysis graphs, e.g. volume, 90 moving avg, beta, etc. See gstalker for example of how to do it ...

Asset Depreciation, Sinking Funds, Amortization Schedules
Need to support different depreciation schedules (see IRS books for that). Asset depreciation is complex; there are many different depreciation schedules, and these vary from country to country, and change when new tax laws are implemented. It might be hard for free software to provide a no-cost subscription to updated depreciation modules.

OFX support
Provide the SGML DTD parsers to handle the OFX reports that many banking institutions are providing, or will soon be providing, to retail customers. See below for OFX references.

OFX is an open spec from Microsoft, Intuit, and Checkfree, and which will be supported by Integrion. The OFX DTD's are included in the 1.1 distributions. See OFX Home Page for details.

There are two ways to build an OFX parser. One way is to build a compile-time DTD parser that treats the DTD as if it were an IDL, and generates C language stubs for a parser. This approach was attempted and abandoned because it leads to fragile C code and a very large binary.

The other method would be to perform run-time DTD parsing. This is attractive particularly because it is a more commonly-used approach; there are a variety of XML tools available that provide this function.

Run-time parsing may be slower, but on the OFX client side, this should not be a bottleneck.


Note that the organizations developing OFX are looking to use XML as their "formats of the future;" this may encourage the use of one of the many XML parsers available for UNIX.

Other on-line support
>> the German T-Online
>> homebanking system BTX.
>> I Germany we have a very popular online homebanking system,
>> based on the T-Online BTX (Datex-J) system. All of the
>> commercial homebanking software packages like MS-Money or
>> Quicken work with that online system. With that system,
>> you can retrieve  account data from your bank, and also
>> send your transfers.
>> I am using since more than 2 years a GPL software written
>> by a former colleague of mine, Niek Busscher, to work with
>> the T-Online homebanking system. That software package with
>> the name ZKA4BTX is very unknown, since Niek published it only
>> by email.
>> Some words to the features of ZKA4BTX :
>>  - Completely written in Tcl
>>  - Uses Xcept as a BTX browser
>>  - Retrieve account data from multiple banks
>>  - Send transfers, using TAN
>>  - Export retrieved account data to CBB, Xfinans and QIF files      
>>  - Export retrieved account data to CBB, Xfinans and QIF files
>> With a simple click to an icon on my desktop, ZKA4BTX logs into
>> T-Online, gets all my account datas from several banks, and writes
>> (adds) it to my CBB, Xfinans or GnuCash (QIF) files.
>> Another very important thing is that I can do all my transfers
>> offline, editing a transfer sheet, and ZKA4BTX sends these
>> transfers in one step to my bank.
>One thing we could do in the short-medium term is have gnucash
>launch ZKA4BTX to get the data, export it to QIF, and then load
>it in, all through one command.
Tab-delimited ASCII file format
People like to be able to read file contents in ASCII; there are many Unix tools for manipulating ASCII. An ASCII equivalent of the current file format should be easy to develop ... just substitute the writes with printf()s.

The tab-delimited format should be compatible with that of /rdb, aka RAND/Hobbs /rdb or NoSQL. (NoSQL is available as part of the Debian GNU/Linux distribution, for instance.)

The /rdb format is thus:

field-name  tab  fieldname  tab fieldname   \n
------------------------------------------  \n
value       tab   value     tab value       \n
value       tab   value     tab value       \n
etc ...

It is a very simple, very basic flat table format. The use of /rdb with GnuCash should try to match with SQL schemas as much as possible in order to minimize I/O complexity and incompatibility.

Tax Preparation
Gotta prepare those taxes. W-2, W-3, 941, 940 Processing.

Sync with Palm Pilot organizers
There are Quicken-workalikes that run on the PalmComputing platform; it would be good to inter-operate with this. See PalmLink and Palm & Linux.

Emergency Records Organizer
Put together a single-page report showing critical info about accounts, etc.

Logging, Crash Recovery
Logging serves two purposes: (1) return the system to the state it was in on some earlier date. (2) recover from a crash. Probably need two distinct mechanisms to support this. The mechanisms are (A) backup copies. These can be compactly handled via RCS (actually, deltax) for storage. (B) Logging. Write out to disk each & every change made.


Enriched Engine, Financial Objects
The current system makes a distinction between the data (account, transaction) and they GUI that displays it. The data is embedded within and controlled by the "Engine", which is a set of routines to access accounts, transactions, etc. The engine serves as a kind of a dynamic cache between the permanent data repository (file, sql db) and the GUI.

The current engine is rather simple: it provides support for accounts, account hierarchies and transactions consisting of multiple entries.

Many of the features described elsewhere will require that the engine have a far richer, more sophisticated data model, including such things as:

Note: it makes no sense at this point to make the engine API much richer than what the GUI can currently support.

Current Status:

A module is necessary to allow data to be fetched from an SQL database, and for that database to be updated. There has been much discussion about this on mailing lists both for GnuCash and CBB. Major points have included:

Status: Done, more or less, gnucash version 1.6.0, Linas Vepstas. Theres still a laundry list of things that need to be cleaned up, see the README file in src/engine/sql/README.

Multi-user Support
Multi-user support should be added with either an SQL backend to the engine, and/or through CORBA interfaces to the engine. Another possibility is to create a web application server, and have users do much/most of I/O via a web interface, possibly using the register object as a browser plugin. The following industrial-strength features are needed:

Status: Partly done. (gnucash 1.6.0, Linas) The postgres backend fully supports multiple simltaneous users. This includes events for automatic updates of all GUI displays. However, the GUI support is rough, no GUI dialog for user/password.

Address Book
Provide support for client/vendor/customer address books, including street addres, eamil, phone. Also: to-do lists, a mini-contact manager (when is last time this person was paid? what did they say on phone the last time we sent them a check? Is there a dispute?)

Propose: use Ximian Evolution contact manager/to-do lists.

Accounts Payable, Receivable
Add features to track sales receipts and other pending sources of income, as well as owed sums.

Payroll introduces a sizable amount of complexity in terms of the need to comply with constantly-changing government regulations in whatever country one is in. While the GnuCash "engine" might remain free, maintenance of payroll functionality would require "subscribing" to an update scheme; it might be troublesome to try to provide such a "subscription" free of charge.

Invoicing. Note that invoicing and order entry are closely related. Several components:
Order Entry
Mini-GUI allowing users to type in orders.

Job Costing
Ability to prepare and track estimates.

Expense Accounts
Expense Account Automation, including air, car, hotel, dining. Receipts, reservations, cancellations.


All software and technical standard references have been moved to
Draft version 0.51 -- June 2001 Linas Vepstas