possible existing solutions that may be of help

[Bradley M. Kuhn]

Josh Berkus wrote at 19:47 (EDT) on Monday:
> The issue that a fiscal sponsor has is that they have a set of
> earmarked funds which are *orthangonal to* the rest of the chart of
> accounts.

Actually, Conservancy ended up putting the temporarily
restricted fund accounting into its chart of accounts.  Our accountants
found this as strange initially -- preferring the Income accounts to be
temporarily restricted but *not* the Expense accounts -- but they also
felt that what we were doing fit fine with GAAP [0].  You'll see how
this is done as I finish up the documentation of Conservancy's existing
system in: https://gitorious.org/ledger/npo-ledger-cli

> Both Ledger-CLI's tagging, and the capabilities of relational
> databases, make it entirely possible to flag each transaction with
> multiple orthagonal categorizations.  We need to use this capability.

I don't know if that's the right thing to continue or not.  I can
imagine other ways to do it that works well.  (For example, I could push
everything in the direction of the "Program:" tag that Conservancy uses
rather than the chart of accounts.  However, the reason I embedded this
data as part of the chart of accounts was precisely because Ledger CLI
(before it had tagging) couldn't handle the complexity another way.
With the tagging, it can, but I doubt other systems have flexibility
like Ledger CLI's '--pivot', frankly.)

This is why I feel like I'd love for Ledger CLI to be used as an "double
entry accounting engine" underneath something else.  Effectively, Ledger
CLI could be middleware -- handling the math part and data storage
through its API -- and the backend of Ledger CLI can be configurable
(although storing data in plain text files is the only backend currently
supported).

That said, these comments show my biases toward Ledger CLI, which is
exactly why I won't be the primary person doing the evaluation. :)
Conservancy may go this way, but I am going to work with someone else in
the evaluation process to make sure my biases don't dominate us toward
the conclusion I hint at above.

> Attempting to fix this into a single, heirarchical chart of accounts
> -- as FundEZ requires you to -- means enormous duplication of
> categories, as well as a ginormous list of accounts every time you
> book a transaction, making data entry very burdensome.

Indeed, I've found this true with the system Conservancy is using, since
apparently Conservancy just reinvented what FundEZ does using Ledger CLI. :)

> Existing proprietary fund accounting packages don't seem able to cope
> with this, let alone to gracefully handle the frequent exceptions to
> the same rule.

So, as I haven't exactly documented yet, what Conservancy does is things
like this:


 2012-05-03 Sir Moneybags
        ;Entity: Sir-Moneybags
        ;Program: Project A:Direct Fundraising
    Accrued:Accounts Receivable:Project A  $100,000.00
    Income:Main Org:Donations              $-10,000.00
        ;IncomeType: Donations
    Income:Project A:Donations             $-90,000.00
        ;IncomeType: Donations


I'll put more about what the does in the documentation I'm writing up on
our current system.


[0] For those that don't know, GAAP is an acronym for Generally Accepted
    Accounting Principles.  AFAICT (and with much research that
    Conservancy did to understand what GAAP is), this is a "I know a
    good system when I see it" standard that accountants/auditors apply
    to accounting systems and procedures.
-- 
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy