Comments on GnuCash project goals

[Stanley A. Klein]

I am a home-based, small-business user who currently uses Quick Books
(actually Quick Books Pro version 5.0) for my consulting business.  I would
like to be able to eventually switch to an open source/free software
business accounting program. GnuCash appears to have the closest current
possibility of eventually meeting my needs.  (I also think it is important
to have alternatives to proprietary products, given the evolving situation
in which proprietary providers are aggressively over-protecting their
intellectual property.)

However, I looked over the GnuCash project goals and I take issue with some
of the statements there.  There are some features there that are
nice-to-have but I don't have them now and don't miss them.  There are
other features that are important and not on the list.

Some of the specific statements I take issue with are as follows (for these
I've copied the goal statements and interspersed my comments):

>Requirements

?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. 

For a home-based consulting business, I do not use the accounting system
anywhere near full time, and its usability by a non-accountant (me) is very
important.


>     Business systems require network support, and the ability to support
multiple >simultaneous users.

Not needed for a business of my size.

 
>     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.


Nice but not necessary.  Maybe a more big-league business accounting
requirement.

 
>     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 

I have two depreciation schedules to deal with, the Federal income tax and
the state personal property tax.  I let my income tax program do the
Federal taxes (complicated) and do the state personal property tax (simple,
straight line depreciation) myself on a spreadsheet.  I transfet (re-enter)
the total (state) depreciation to the accounting program, because the state
requires that I submit a balance sheet.  (I didn't need to do a balance
sheet as a sole proprietor, but I started to need one when I formed a
single-member LLC.)


>          Shipping and Receiving 
>          Accounts Receivable, Accounts Payable (A/R, A/P) 
>          Credit Card Processing 
>     Support for calculations associated with accrual accounting. 

I run my business on the cash basis and ran into an accrual accounting
issue with Quick Books when I did a job in one year and got paid the next.
It turns out to be a report generation issue, not a fundamental accounting
engine issue.  The switch in Quick Books seems to just affect the Profit
and Loss report, although I haven't searched thoroughly.

>     Ambitions for the future might include interfaces to online shopping
carts, credit >card clearing interfaces, and ERP
>     systems. 


When you get to ERP, you are in the big leagues.


>Reconciling Those Needs>>

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

>     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.

See comments above on accrual accounting.

I think the accounts receivable and payable are handled as "other asset"
accounts.  I spent some time keying in part of my chart of accounts to
GnuCash and I don't know where the sophistication is (unless it's in the
transactions -- such as order entry/invoicing -- that need to be handled).


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

>     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). 


So do small, small business users.


>     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. 


I don't think Quick Books has an SQL engine associated with it.  If it
does, it is quite invisible to the user.  I am my own DB admin, so any
magic has to be done by me.


>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.


Some further comments on detailed features:

1.   GnuCash needs the ability to import Quick Books files.  They are in
"QBW" format.

2.   An important feature is the ability to tag income and expense accounts
with the tax line item under which they are to be accumulated in a tax
report.  Quick Books does it, but isn't very flexible in handling some
categories of items.

3.   Payroll is very complicated.  As a one-person business, I don't have
any (my draws are all counted as equity draws by Quick Books).  In the US,
you have the Federal rules plus 50 sets of state tax rules.  A small enough
business might be able to do it by hand and key-enter the results, or it
could be done by some kind of mini-language (like spreadsheet cell
functionality) feature that allows the user to program the local (country
and state) calculations and put the results in the right places.  Updating
would have to be done by reprogramming when necessary.  (This is something
accounting consultants might take up as s service, or it could be done by
having knowledgeable users post the changes to an e-mail list.)

4.   What you call "expense accounts" should be put at the bottom priority.
 My version of Quick Books doesn't do it.  I have three "credit card"
accounts (that are actually expense accounts between myself and the
business).  They are a travel account, a petty cash account, and an account
called "paid by personal check" that covers things like the business split
of the phone bill.  I keep local travel, telephone bill reconciliation, and
petty cash expenses on spreadsheets, and transfer them to the business
books a few times a year.  When I take an out-of-town trip, I do a trip
expense voucher using a modified version of the template provided in my
word processor (Wordperfect) that has some spreadsheet functionality.  I
then transfer (by re-entering) the column sums to my business books.  One
problem I have with Quick Books is that I can't set up an "Overhead"
customer and treat unreimbursed trips (e.g., to professional meetings) as
projects for that customer.  Quick Books wants to bill all customers.  I
have to create special "vendor/other names" for each trip to accumulate
trip costs and relate them to the expense voucher.

There are probably a lot of other issues I will come across as I explore
GnuCash.  My experience thus far is currently limited to installing it (it
took some time to work out the symbolic links for slib and guile under RH
7), entering part of my chart of accounts, and reviewing the project goals.

I assume I've posted these comments to the right place.  I don't regard
myself as a developer (I don't think I know any of the relevant development
languages used in GnuCash), but these are not necessarily issues for the
user list.  


Stan Klein
Principal Consultant
Stan Klein Associates, LLC