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
There are currently several different versions of GnuCash.
We've adopted the kernel numbering scheme: even minor release
numbers (1.2.x, 1.4.x) are considered to mark stable releases,
while odd numbers (1.3.x, 1.5.x) mark development releases.
- The current stable, production release is gnucash-1.4.6 and
is based on the Gnome / GTK libraries.
- The 1.5.x releases focus on adding new features and
improving existing functionality.
The latest version is available only via CVS.
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.4.6.
More adventurous users can try one of the 1.5.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.
- 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.
- Lists of accounts and the transactions in them can be
thought of as a representation of financial data, a
- The GUI that adds, modifies and deletes these should be
thought of as a manipulator of the data, a Controller.
Thus, the Motif or Gnome GUI's are merely two possible
manipulators of the data; others, based on e.g.
web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets
ought to be possible.
- The View of the data is a subset or slice of the
data described by the Model. The View may consist of only the
transactions for the month of May, or only the account totals
for certain accounts. The View is used in part to generate
the reports and graphs, but it is also that which the
Controller interacts with. Views are generated by queries to
the data store.
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
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
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 is fairly poor, and is tightly tied to
the data structures that the GUI manipulates. These data
The Engine has a very simple apply/commit model, and a simple
query mechanism for generating reports and views. The goal of
the commit and query model is to aid/simplify the creation of
& merger with an SQL back-end.
- Transactions, which consist of a set of journal
entries (JE's) whose values sum to zero.
- Journal Entries (internally referred to as
'splits') which record prices and values.
- Accounts, which consist of a list of journal
- Chart of Accounts, which is a hierarchical tree of
The Engine currently handles only a small set of data
- It can import and merge in QIF's;
- It can read and write its own binary byte stream;
- It can get stock quotes from the net.
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 back the Engine onto
an SQL database, and thereby enable multiple users and/or
interface to more complex accounting systems. The engine should
also be expandable to handle other sources of data, such as
OFX, Integrion GOLD, the Open Trading Protocol, the OMG CORBA
General Ledger submission, the
IBM San Francisco business objects,
or closer to home, Linux Kontor. 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
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 online micro-payment systems. 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
aloing 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 should become "The More Sophisticated Financial Web Browser".
Why? Because dyncamically-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. Sure Java plugins can
provide a fancier interface than html forms, but a java plugins
that is sophisticated enough is also slow to download. No two
Java plugins are alike: every site has thier own: no standardization.
Wouldn't you rather use one GUI that you already kn ow for all your
on-line financial interactions? Never mind that many people have
Java disabled in thier browser due to security concerns (oh, tell me
again, you do financial things, and you're NOT concerned about security?)
Finally, no Java plugin provides you with monthly or quarterly
reports of your financial status. Maybe your credit card company
does this over the web, but what if you have two credit cards?
GnuCash can provide a centralized, trusted store for financial
data that no other application can provide. There's 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. There's 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.
GnuCash should be able
to act not only as a secure purse/wallet on the internet, but it
should infact be that trusted financial advisor that no other
technology is in a position to fill.
Implicit in this desire for extensibility is the need to build
financial applications supporting two major classes of users:
They may use some of the same financial terminology, and
hopefully might share a fair bit of code, but have quite
different goals and requirements.
- Home Users
- Small Business Users
Personal Finance Needs
Important properties of a personal finance system
- Needs to be approachable and usable by occasional users
who are not knowledgeable about accounting.
- Ease of use and simplicity is critical.
- A reasonable selection of reports, graphs, charts, and
tools for personal finance, such as mortgage
- Budgeting support needs to be targeted at naive
- Interfaces to on-line banking, shopping, stock
- Support for management of stock portfolios that may
involve considerable sophistication, since individuals
commonly have retirement plans that hold mutual funds,
stocks, options, bonds, and the like.
Small Business Needs
- With a business system, it is likely that there will be
full-time users, which puts the emphasis on
efficiency of user interface rather than on its
approachability to naive users.
- Business systems require network support, and the ability
to support multiple simultaneous users.
- Some business users may want access to the system from an
MS Windows 95/98/NT box. For these folks, a web-based
interface could be just handy. Web interfaces are also nice
for ASP type deployment.
Small businesses do not often have sophisticated investment
portfolios; they instead need support for additional
sophistication in such areas as:
- Payroll (Batch processed and individual)
- Inventory Control & Asset Management
- Amortization Schedules, Depreciation
- Shipping and Receiving
- Accounts Receivable, Accounts Payable (A/R, A/P)
- Credit Card Processing
- Support for calculations associated with accrual
- Ambitions for the future might include interfaces to
online shopping carts, credit card clearing interfaces, and
Reconciling Those Needs
A seemingly contradictory factor is that the kinds of
sophistication that are required vary considerably.
Another set of contradictory requirements has to do with the
back-end, and interfacing to other systems:
- A home user does not generally require most of the
sophistication (sophistry?) of accrual accounting that is
required by business enterprises. Thus, home users don't need
much of the sophistication of an Accounts Receivable
or Payable system, or the bizarre depreciation
policies that crop up in Asset Management systems.
On the other hand, home users are in increasing need of
surprisingly sophisticated financial tools for managing
stock portfolios, including:
- Mutual funds
- Retirement savings plans, with such identifiers as
401(k), IRA, Roth IRA, RRSP
- Corporate stock purchase plans
- Corporate option plans
- Home users need a simple-to-install, simple-to-maintain
system. This essentially rules out the use of SQL for the
storage medium/back-end for home users. (That is, the current
state of the art for SQL on Linux does not offer any simple,
fool-proof management for data).
- By contrast, non-SQL systems for business use are almost
unimaginable. SQL provides a high degree of data integrity
and storage robustness, and also simplifies tremendously the
import and export of data. Powerful SQL tools exist that can
work magic in the hands of a good DB admin.
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.
- Small 0 to 4 pm
- Medium 3 to 12 pm
- Large More than 12 pm
|Themes, Icons, Glitz
|Miscellaneous Small Tasks
|Alerts, Recurring & Scheduled Transactions
|User Preferences/Session Mgmt.
|Books, Accounting Periods
|Automated Test Suite
|Stock Quotes, Price Quotes
|Forced Double Entry
|Annotate with Investment News
|Loan and Mortgage Calculators
|Technical Stock Analysis
|Depreciation, Sinking Funds
|OFX, Online Banking, Trading,
|Tab-delimited ASCII export
|Sync with Palm Pilot
|Emergency Records Organizer
Small Business Features
Features that small/medium businesses expect.
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.
- All GUI messages currently use GNU gettext()
for the message catalogs. Translations exist for English,
British, French, Swedish, German, Japanese.
- Help pages available only in English and French.
- Monetary and string handling done through glibc. The
latest glibc (2.2.3) is needed to get the correct
- Yannick Le Ny <firstname.lastname@example.org> traduction
- Most GUI input elements use the gtk text widget, and
thus use the XIM input method in Asian locales. This
allows e.g. Kanji, Katakana support. However, the
register does not use XIM, and thus doesn't
currently support the Asian languages. This needs
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.
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).
- Adding a custom logo (e.g. company logo/address) to every page
(generically, having a header and footer for every page).
- Allowing user to modify report title/subtitle on the fly
(and possibly add notes at the top or bottom of the report,
e.g. to explain line items).
- Allow user to use the transaction query
interface to pick the set of transactions that will make up
- Memorize the report that was asked for, give that report
a name, and in the future, allow that same exact report
to be re-run. Allow user to edit this report properties
at a later date. Note that the basic idea is similar to
that of memorized queries, discussed below.
Generated reports should be exportable to other gnome
systems (probably using bonobo).
Reports should also be exportable to
the Gnumeric spreadsheet (possibly by writing out gnumeric
file format?? or writing out csv (comma separated values) ?? ).
Tables & etc should be exportable to AbiWord,
StarOffice, other word processors. (formats: docbook sgml?
would then make convert to richtext, TeX easy.)
Must be possible to e-mail reports (including html) to
users. This might be a built-in function of gtk-html?
or a little bitty evolution bonobo part?
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. (this should
be automatic with the gtk-html widget.)
- A general reporting infrastructure was implemented in
Perl, in the form of html-embedded perl (ePerl). However,
this reporting mechanism was abandoned in part because
ongoing build and install problems related to ePerl and
swig. Also, since ePerl didn't participate in the
interpreter even loop, the report generator had to run
as a separate process, reading data via pipes. This was
uglier than some folks liked.
- A general reporting infrastructure has been implemented in Scheme.
Currently, there are simple reports for Profit/Loss,
Balance Sheet, and portfolio valuation.
- Reports are currently displayed with the gtk-xmhtml
widget but are being ported to the gtk-html widget. The
gtkhtml widget should provide printing abilities through
gnome-print (right ????).
- There is currently no way (no longer any way??) to
generate reports from the command line ...
- A list of 'required reports' is needed. Then these
need to be implemented.
- Heavy discussion by Matt martin, Robert Merkel ...
- The following technologies were rejected/unused mostly
because they were too complex, didn't hang together technologies:
SGML and Extensible
Markup Language - XML. In the long run, these are
preferable to HTML, since DSSSL tools such as Jade (James DSSSL
Engine) can be used to convert to RTF, Postscript, etc.
Add to this the consideration that XML is the basis for the
Document Object Model,
which is being integrated into many web-based applications,
and we can see that XML is an increasingly significant
format as we look to the future.
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
- Different graphing packages were evaluated,
Guppi was chosen. Considered & rejected were
plotutils, gnumeric graphing code (Miguel says
they'll replace gnumeric code with guppi.)
Miguel's/Gnumeric requirements were:
interactive plot editing -- each segment attributes
totally settable/controllable -- drag/move callbacks
when segments are click-dragged.
- 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).
- The query engine has been implemented (as of 1.4.0,
- The GUI for creating queries has been implemented
(as of 1.4.0, grib)
- The ability to memorize queries has not
been implemented and awaits further action (see reports,
- Simplified Ledger
Ledger needs various fixes/cleanups. Before any fixups can be
done, agreement needs to be gotten as to what the register
*should* look like.
Multi-Line splits look confusing when viewed from
Stock splits & reverse splits are not displayed correctly.
Currency trading Ledger is confusing.
Stocks and Mutual funds are handled by placing them each in
their own account. Each account can be viewed individually.
If all of the stock accounts are children of a master
trading account, then the trading account can be viewed and
modified in a General Ledger window. The current stock
general ledger window is a bit obtuse, and difficult to
understand and use. A simplified but still powerful ledger
window is desperately needed.
How to most simply allow the user to
enter loads and fees?
Through multi-line transactions. Unfortunately, some users
may not properly understand multi-line transactions,
at least not initially.
Thus, a little pop-up is needed to allow the user to type in
the sales load or fee and such, and then auto-create the
needed journal entries.
Note the current transfer window does NOT allow
a share price to be specified !! Needs fixing ...
- Themes, Icons, Glitz
A variety of finer touches need work:
The following have been completed, but possibly not fully
Hint-of-the-Day. A collection of a some
50-100 hints-of-the-day: short (2-4 sentence)
hints/tips on how to use gnucash. Every time the user
starts gnucash, an new hint shows up ...
Status: Hint infrastructure complete (RGM, version
1.4.0). Need to add
hints (only 6 are currently available).
Themes. Some theme testing required. The
effect of themes on the register window needs to be
reviewed. Some themes look flaky in the main account
window, might be a gtk bug ???
Static Currency Exchange Table
Keep a (semi-)static exchange-rate table. (possibly updated
via net). The table is used to auto-fill currency
exchanges. (the finance::quote perl module now handles
currency exchange rate fetches)
Button Bar A user-configurable button-bar
would be nice too. The button bar is the set of
'buttons' (open, edit...) at the top of a register
window and the main window.
See the section Arrangements for
a discussion of the customization issues.
Household Assets/House Inventory
Add wizard to walk user through a set of questions
about household inventory & help user value them.
(do you own a house? appraised value? mortgage?
do you own jewelry? appraised value? etc.)
In particular, show how appreciation
and depreciation should be treated.
See the section Arrangements for
a discussion of the customization issues.
More account types Introduce more
'fundamental' account types: (amortized) Loan,
Mortgage, ESOP, House, Line of Credit.
Bank name in combo-box pull-down When user
enters a new bank name, should be presented with a
combo-box listing other bank-account names ... (note
this may require implementation of engine callbacks so
that relevant code can be informed when there are new
Pop-up Calculator All price/amount fields
should pop up a calculator widget; output of calculator
gets entered in field.
Pop-up Calendar All date fields should pop up
a calendar widget; selected date should get entered in
Register View Allow user to view only
non-reconciled transactions ...
Configurable main-window Status Bar Bottom of
main window currently shows total asset, and total
income-expense (profits). Make this configurable, so
that user can show arbitrary sums of arbitrary
See the section Arrangements for
a discussion of the customization issues.
Dockable Registers/ aka "Browser Mode".
Currently, when each new register opens, it opens in a
new window. An alternate style would be to 'dock' the
register window in a bigger frame, and just have
'backward/forward' buttons to navigate through
different registers (the way that a browser navigates
web pages.) This of course would be a user
Context sensitive help. When users
create new accounts, need to suggest stuff if the user
typed something unexpected ... (e.g.
non-alphanumeric input) ...
Folder Tabs Currently, Income/Expense
accounts can be shown or hidden by selecting from a
menu. It would be nice to be able to examine different
account types (Asset, Liability, Income, Expense,
Payables, Receivables, Inventory) by selecting a tab
Currency Selection Pop-up Currency field
should get replaced by menu of long-hand currency
names, three-letter ISO 4217 abbreviations, and symbols.
User should be able to hand-enter non-IS4217 currencies.
Done in 1.4.0
Cut-n-paste Cut-n-paste of whole transactions
in the register window... Status: Done. (by Dave
Peticolas, in 1.4.0)
Auto-completion Quick-fill should also
auto-complete amount, memo fields.
Done in 1.4.0, Dave Peticolas
Autoincrement Check numbers should
auto-increment. Hit + key in check number field
(same keystroke as in quicken).
Done in 1.4.0, Dave Peticolas
Navigation Menu navigation using the keyboard
should be possible. Hit the Alt-F to get file menu,
hit Alt-FS to save.
Similarly, tab-key navigation in the register
should be possible.
Done (in 1.3.x ?, Dave & all, partly inherited via gtk
Fly-Over Help When the user pauses the mouse
over a button, "fly-over" pop-up help windows should
Done (in 1.3.x, inherited via gnome/gtk widget set).
Grayed-out Form Help Create grayed out
entries in the ledger, titled "Memo", "Description",
etc, helping users understand what should be typed into
each field. Status: Done (by Dave?), as of version
Key Bindings for Editing Text Fields. The input fields
use the gtk text widget, which provides key bindings that
are similar to the Netscape/emacs key bindings.
This allows e.g. emacs-style ctrl-a,
ctrl-k to do the right thing.
Done (in 1.3.x, inherited via
gnome/gtk text widget).
- Miscellaneous Small Projects
A variety of small internal projects (mostly in the one
The following have been completed:
File Format. Rework to use text file format. Will be
Status: RLB, 2 weeks, half-done.
Auto-pay credit card when reconciling credit card
accounts (Done, Dave).
Auto-add bank fee when reconciling bank accounts.
(Not done, Dave).
Print Register Window. Output register window to
Status: defer indefinitely.
# of decimal places in prices (penny stock).
Part of the big numeric overhaul.
gtkhtml. Move to gtkhtml from gtk-xmhtml.
Done in 1.5, Grib.
print. Print reports, etc. Done in 1.5, Grib.
This came 'for free' with gtkhtml.
key-val pairs. Add generic key-slot mechanism
into accounts, transactions, journal-entries. Done in
guid in fileio. No longer relevant with new file
- Books, Accounting Periods
Ability to close the book at end of the fiscal year. This
consists of several steps:
- Permanently lock some transactions as non-editable.
This should be straight-forward by using the
reconciled field to indicate a locked
value, and not allowing the GUI to edit locked
- Transfer the Income minus Expense for the book period
to an equity account, so that each new period starts with
zero income/expense balances.
- A mechanism to purge really old transactions from the
- Extensions to querying and reporting infrastructure ...
The query changes might be painful ...
A user should be allowed to 'delete' an account
only if it has no transactions in the currently
Of course, it's not deleted from the old books.
From this last, we conclude that every chart of
accounts should have a beginning and ending date (that
match the book period), and the file format needs to
support multiple charts ...
- Memorized Transactions ... Currently, transaction
auto-completion works by auto-completing with the last
'similar' transaction. This ability will get trashed
when books for the old year get closed, because there
won't be 'similar' transactions.
- A mini-design Doc exists in
- 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.
- Bill Gribble has built a prototype based on the
gnome-print. Waiting for gnome-print to mature ...
- Need a sample check/sample transaction to print out
so that user can test printer.
- MICR Fonts are available & brought to mailing list.
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.
New User Setup Provide
a default Chart of Accounts, which will mostly consist
of a default set of 'Categories' (Income/Expense
Accounts). These are categories such as "Automobile
Expense", "Bank Interest Income", and "Employment
Income". The user should be able to select a default
set of accounts, and have those created
automatically. Profiles: home-owner vs. renter
non-for-profit (some non-profits are very very simple,
just a club).
- Account Creation
- QIF Import
QIF Import is just complicated enough that it needs
a wizard walk-through of the steps. Grib has a prototype.
- Budget Setup
Setting up a budget.
- Obscure Corners
Various obscure corners of the application may be
non-intuitive, and need wizard help. e.g. stock splits?
e.g. using foreign currency on a business trip?
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 alllowing 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.
- A list of sample/initial accounts. These might be tailored for a
home user (groceries, gas, electric), an apartment dweller
(rent, laundry), or different kinds of business users.
Because these sample accounts appear in the Arrangement file,
it becomes easy to create & distribute customized arrangements.
- A list of pre-defined reports and graphs. The kind that you'd find
for a home user might be different than for a person managing a stock
portfolio, which is in turn different from what a business might need.
The Arrangement File should include install-specific customizations, such
as the report headers, footers, etc.
- Hint of the day. The types of 'hint of the day' would be different
for new users, than it would be for advanced users. Thus, different
arrangements would have different catalogues of 'hint of the day'.
- Menu Contents & Navigation. New users might be presented with a simple set
of menu contents. 'Power Users' might be presented with deep, nested
sets of menus, with oodles of features.
- Register Layout. The layout of the register might be customized for
different countries: e.g. in Germany, a different type of electronic
banking seems to require the display of account numbers in separate
columns in the register.
The idea for arrangements was inspired by
Adam Curry's commentary on
radio formats and Napster.
- 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
Session management is not implemented; viz, we don't
remember where things were left at when the user shut down
the windowing system, and we don't restore the session
afterwards. This includes: which register windows were left
open, what sizes they were, what their placements on the
screen were, etc. I believe session management needs to be
coordinated with KDE and with gnome, and all compliant
window managers will do the rest (?)
Independently of session management, the register
windows should remember how big they were last time they
were popped up, and they should pop up the same size, again.
The app should remember these sizes from invocation to
- Works good; lots of preferences in the GUI.
Implemented in home-grown scheme.
- These are saved in the '.gnucash/config.auto' file.
The current file format is raw scheme code, rather
delicate to tweak by hand ...
- 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
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.
Scheme/Guile is the central extension language. Guile
interfaces auto-generated using g-wrap.
Optional interfaces to the data engine (for, e.g.
perl) can be generated using
Dave to collate & edit architecture documents.
RLB to provide diagrams.
- Recurring Transactions, Calendar Alerts,
(1)Add support for automatic, recurring transactions,
e.g. mortgage payments, fixed-interest bonds, regular
salary checks, regular gas/phone/electric bills,
(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
(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: need to find/evaluate gnome-calendar/day-planner
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 ????
- Need to create design doc, need to implement engine
pieces, need to hunt down gnome-calendaring bonobo.
- RLB thinks its 2-3 weeks for items 1,2,3.
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.
- Home purchase planner
- Retirement planner
- College tuition planner
- Debt reduction planner
- Scrimp-n-Save planner
- Special purchase planner (big ticket items)
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'.
- A design doc has been submitted by Bob Drzyzgula.
Take a look at ./src/budget.txt in the source
- Bryan Larsen has begun work .. it's scheme based ...
Dave Peticolas has some GUI roughed out ...
Ability to mark certain jopurnal 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 (!)
This requires the following:
- place in the engine where split can be marked
(grib is implementing in a slot, with use with qif import).
- gui where splits can be marked up as beloinging to a certain
- Ability to report by class
- Ability to query by class.
- Automated Test Suite
Build automated test suite, including:
- File IO consistency check. RLB.
- Currency math correctness. Grib.
- Quicken(TM) Import
Ability to import Quicken QIF files. Both MSMoney and
Quicken use QIF files to export data.
Quicken import is implemented and mostly works.
(Bill Gribble, Done, in version 1.4.0)
Need a QIF Import wizard (there are several non-intuitive
steps that need to be performed during import.
A dialogue wizard seems like the best idea to carry
through this process. (grib, in process for 1.5)
Work needs to be done for recurring transactions, etc.
QIF processing, as used for on-line banking, is
not implemented. That is, staged import isn't
Note that since banks use QIF, the correct
way to reconcile bank accounts on-line is through
On one side, we have existing recorded transactions;
on the other, the latest bank statement, in QIF
Now, just put them together ...
Grib estimates 2 weeks for this.
- Quicken(TM) Export
Ability to export Quicken QIF files.
Several design alternatives are apparent:
A special 'report' that writes out qif could be
This would use the 'reports' infrastructure to
- It is fairly easy to traverse the data in the engine
to write out qif files. Just do it.
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 along with everything
else, in the main database, in the transaction table.
This leads to several aesthetic quandaries.
- It bulks up the database with 'less-than critical'
information. That's bad. We need an alternate storage
- Currently, the transactions stored in the engine
are either 'critical' viz.,
record the movement of money, or are non-critical viz.
record things retrievable from the historical record,
This alone is a good reason to ask that price & other
non-critical financial data be stored in a separate location.
Add to this the idea that we should probably store other
'technical' stock data, such as share volume, high/low/close,
daily volatility, etc.
- Quotes.pm can obtain stock quotes from Yahoo (NYSE), Fidelity
Investments, T.Rowe Price, and do automated update of
GnuCash data files (with the gnc-price perl
script). Need to add more data sources. See
src/quotes/gnc-prices for details.
Quote.pm is now a separate development project at
- Need to integrate with GUI. Right now, this is a
stand-alone perl script run from crontab. RLB
has written scheme wrappers for the module. Its ready now, but
not checked into cvs. Will be in 1.5.
- A separate, historical-quote module can be found at the
sourceforge site. It might be a good idea to fold this
together with the Quote.pm module !?
Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
etc. Possibly use a 'configure'-like way of dealing with
- 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
Implement the 'correct' way of handling this when user
is working in multiple currencies on a regular basis.
Simple Exchange Rate Information File Format. Completely
*.ini-centric in layout and design, but otherwise seemingly
- Need to rethink whether the one-shot exchanges
should in fact be recorded full-fledged in the engine.
Also: Euro support is currently hacked in: the EURO is treated as
a 'special' currency. Virtually all the Euro code can be fully
generalized (and should be).
- New split architecture should store quantity and value, and
never the price. This will simplify currency movements
between accounts, without requiring/forcing the use of a
currency trading account. (this also solves problems with
rounding that occur when a price is explicitly specified.)
Grib & dave are working this for next release.
- Forced Double-Entry
The system supports double-entry: every transaction
indicates a pair of accounts: one is debited, and one is
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
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
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.
- April 1998 -- The engine has a couple of flags in it
that control double-entry behavior: it can be made lax or
strict, however, they are compiled in, and there is no
way to change them from the GUI.
- Dec 1998 -- Scrubber functions implemented to crawl
through data, and find all unbalanced or orphaned
- May 2000 -- Default will be changed to double-entry
always. It will not be possible to disable this and move
- 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
- 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
might be more embeddable ... I am told that htdig-API is in
good solid condition for this, but undocumented.
- 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 %__________________
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.
- There is an implementation of the calculation routines by
Terry Boldt in the development branch. There is an initial
GUI implementation of the calculator by Dave.
- 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
- value point or price point
- movement direction
- 'is active' boolean flag (i.e. Should be
possible to 'turn off alert' without deleting it)
- memo text
- 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,
- 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
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
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.
- The parser is fragile because minor DTD
non-compliances are hard to parse, handle and recover
- The parser is huge because the DTD results in
hundreds of (C++) objects being generated.
Run-time parsing may be slower, but on the OFX client
side, this should not be a bottleneck.
- A compile-time parser was developed and
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
- 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
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,
The /rdb format is thus:
field-name tab fieldname tab fieldname \n
value tab value tab value \n
value tab value tab value \n
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.
categorize items according to different tax
- VAT -- Value Added Tax. Varies from country to country.
- Estimate income taxes.
Estimate itemized deductions, find potential
deductions, categorize them
- 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
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.
- Crude transaction logging/auditing in place; should
be suitable for error/crash recovery but has not been
"tried by fire."
- Backup files automatically created and
- 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:
- Linking to "Address Info" ( e.g. names,
- Transaction identifiers
- Part numbers, SKU IDs
- Interest rates
- Budget policy
Note: it makes no sense at this point to make the engine
API much richer than what the GUI can currently
- Locks When splits are implemented, and the
parent transaction has been marked as cleared/reconciled,
should be locked, so that further modifications to the
amount can't be performed (or at least, a warning is
generated to prevent accidental garbaging up of old
routines mostly in place,
these "Transaction processing constructs" should
simplify creation of an SQL back end, or some other
more sophisticated transactional server.
- Multiple currency support is present but still pretty
- Query engine has been broadly extended (Bill Gribble).
Documentation for Query Engine??
- SQL I/O
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
Major points have included:
- The use of a database allows only that data which
is actually in use to be loaded into
memory. This permits managing larger sets of
transactions more efficiently.
- It also allows data to be pushed out to the DBMS
immediately after entry, rather than waiting
for the user to "save the books."
- Using a client/server SQL database might make it easier
to turn GnuCash into a multi-user system.
- By using a well-known DBMS, outside programs are
provided a well-defined way of getting at, and
perhaps even modifying, GnuCash data.
(Actually, this is not true: GnuCash already provides
a uniform, well-documented, preferred data access API.
As long as this
API is used, there is some guarantee that data is stored
in a self-consistent fashion. Not using the GnuCash
programming interfaces risks corrupting the data.
Direct access to the data is dangerous and discouraged.
Furthermore, The API is guaranteed to be backwards
compatible with a variety of data storage formats.
Due to enhancements, the actual form of the data stored in
a flat file, or in the SQL database, may change without
Those SQL databases available on Linux tend to involve
considerable administrative overhead in terms
of getting them set up.
This may be a minor cost to a business enterprise
that routinely hires Database Administrators.
It is not acceptable to require this of
naive users that may find "simple" things like
% su -
# cd /tmp
# rpm -i gnucash-4.1.3.i386.rpm
to be challenging.
It might be useful to use an embedded database engine
like unto Sleepycat
or something like
ISAM (Note CQL++ supports ISAM access methods), or
even an embedded SQL engine such as
The reasons to do so include ... ???
GnuCash presently uses a document-oriented model, where
the entire set of books are loaded in, and
dumped out, all at one fell swoop.
GnuCash needs to be modified to access the database
in a transactional manner. This is at least partly
implemented with the Begin()/End() constructs
in the engine.
Some transactional thoughts: entire SQL
tables/databases do not need to be locked while the
user is editing a transaction via the GUI.
Instead, an optimistic approach, similar to that
employed by CVS (concurrent version system, a mechanism
for storing versions of source code) could be used: if
the edits conflict with changes made by others, edits
are be rejected en-masse, allowing the user to merge
and correct their changes.
Important note: updating SQL does not
require locks to be held for extended periods of
The SQL engine chosen should be fully transactional,
passing the 'ACID' test (Atomicity, Consistency,
does not satisfy the 'ACID' criteria.
- Multi-user Support
Multi-user support should be added with either an SQL
backend to the engine, and/or through CORBA interfaces to
Project Kontor and also FreeMoney is working on SQL
schemas; Kontor is also working on Java RMI/CORBA
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
The following industrial-strength features are
- transaction-oriented queuing of updates
- event subscription channel for updates
- user authentication
- user authorization
- encryption of network connections
- 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
- Record an invoice. Assign it a serial number. Be able
to reprint/report based on invoice serial number.
- Invoice associates customer name to set of transactions.
Need to deal with PIM issue. I.e. need to integrate
with high-function PIM or CRM interface.
- Allow historical browsing of invoices customer by customer.
- To visually design an invoice, need to have a
mini-word-processor/simple drawing plug-in. Is
Abisource/Abiword a candidate? Probably needs bonobo...
- Order Entry
Mini-GUI allowing users to type in orders.
- Should interface to parts/inventory database to confirm
item availability, (maybe recommend additional production)?
inventory should be updated after order placement.
- Automatically update accounts receivable.
- Allow order revision/update (esp. as partial orders are shipped).
- Orders can be invoiced when entered (simple invoicing), or
placed on account (double invoicing).
- Allow back-orders to be printed customer-by-customer, or by
- Allow printing of packing slip.
- Job Costing
- Ability to prepare and track estimates.
- Allow estimate/bid to be converted to a firm order & get invoiced.
- 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.41 -- December 2000