FinanceFerret/flaws in other software

Overview

The two major contenders in the money manager software niche -- Quicken and Microsoft Money (Q/MM) -- seem to approach the problem more or less the same way. In areas where either of them fall short, the other one does too.

Reconciling Balances

The main problem that keeps coming up with Q/MM is in reconciling your accounting with the bank's. They take the following approach, with the assumption that you are working from a periodical bank statement:

1. You enter the beginning and ending dates of the bank statement
2. You enter the beginning balance of the bank statement
3. For each item shown on the bank statement, you check off the corresponding item in Q/MM -- or enter it, if Q/MM does not have a record of it
4. You cross your fingers and hope that Q/MM's ending balance matches what the bank shows

One problem is with the final step. If there's a discrepancy, how do you figure out where it occurred? You have two numbers that differ by some arbitrary amount. It could be a missing transaction, or it could be a typo. It could have occurred on any transaction between the starting and ending dates.

Most bank statements (printed ones, at least, and some online banking services do as well) will show you a day-to-day running balance.

Q/MM will show you the same thing, but it shows them in the order of the dates you entered for each transaction. This means, for example, that if you buy something with your credit card on June 1 but the bank shows it as June 5, your balance will disagree with the bank's from June 1 to June 5. If you made another purchase on June 4 and it didn't show up on your bank account until June 8, then you have a discrepancy from June 1 through June 8. If you make purchases every few days of a month, then your balance and the bank's will never agree.

Yes, it's possible that the transactions might still come in in the same order -- but there are inevitably other transactions, such as deposits, with differing lags. And let's not even talk about checks -- you write one to someone on June 2, but they forget to deposit it until July 1, when they go to the bank to deposit their paycheck. That throws you off for an entire month with just one transaction.

The whole problem would be solved, however, if Q/MM would let you also enter the date on which the bank shows the transaction, and then sorted by that date when calculating the balance. Q/MM's balance and the bank's would match line-for-line, unless there was an actual discrepancy -- and then you would know exactly where the discrepancy was.

Equity

The other major area in which Q/MM falls short -- and I can't really blame them, because it turns out to be surprisingly complicated -- is Equity. I'm not sure if I'm using it the same way it's normally used in accounting, but I had a concept for which I needed a word, and Equity seemed like a close match. (See wikipedia:Shareholders' equity and wikipedia:Ownership equity for an explanation of equity in accounting.) My usage of the term is explained at length here.

Data Format

Another more technical problem with Q/MM is that their internal data format used by each is "closed" (i.e. proprietary and unpublished) and does not appear to be database-driven. FinanceFerret will use a separate database engine (the engine should ultimately be independent of the code, though it may not be at first) which can be accessed by other programs. This will bring the following benefits:

• Other programs can be written to extend FinanceFerret's functionality, both in reading data and in writing to it. For example:
  • Bill payment reminders
  • Budget warnings ("You are within $x of exceeding your budget for Widgets for this month.")
  • Archiving -- moving old transaction and account data to offline storage
  • Document management -- tie in transactions with images of receipts; quickly print copies of all receipts assigned to a certain category, or view a transaction's paperwork with a single click
  • Graphing -- have your current financial health (for example) shown as a standalone graph on your desktop
  • Multi-user capability becomes an option when using a database engine, as they are designed to allow this
• Reporting can be more rigorous, i.e. rather than looking for all transactions containing the string "JOE'S HARDWARE" or "HARDWARE", we can make an SQL query to find all transactions to/from the "Joe's Hardware" account or assigned to the category "hardware".
• Users will not be stuck with the existing user interface. User data will not have to be "exported" in small chunks if the user wants to switch interfaces.
• Backups can be automated using existing database management tools.

FinanceFerret's data design will be non-proprietary and thoroughly documented; the code which makes it work will be open-source, providing additional "how-to" documentation. The format in which the data is stored will be determined by the database engine. I will be starting with MySQL, which is itself open source.