Changes to the accounting system in 2020

[Martin Michlmayr]

SPI has made two substantial changes to its accounting system and
books in 2020:

* Migration from cash basis to accrual basis: the accrual basis is a
method of accounting which gives a more accurate picture of the
financial status.  It also makes it easier to track outstanding
payments.

* Migration from ledger to beancount: both are text-based, FOSS
accounting systems.  Beancount offers a number of advantages, in
particular a Python API which can be used to access data and to extend
the functionality of the accounting system.

We have used the migration to beancount to improve the accounting
process in a number of ways, in particular to add more automation and
checks.

* Importers for various donation platforms to reduce the amount of time
  it takes to import data while making the process less error-prone.
  We use OFX/CVS importers from beancount, but we have written importers
  for a number of donation platforms that are used to donate to SPI
  (e.g. Network for Good, CyberGrants).

* Scripts that encode business logic in order to automate common
  processes.  For example, when importing bank transactions, scripts
  now look up outstanding accounts payable and assign transactions
  accordingly.

* Validation of data through plugins, such as ensuring that payments
  match the accrued amounts, checking payees for misspellings, and more.

* Bank reconciliation: due to the way checks are handled, a bank
  reconciliation showing differences between the bank statements and our
  books of record has to be generated every month.  This process
  is handled by a script. (Checks are recognized immediately when they
  are received/sent, not when they are actually deposited by the bank.)

Finally, we improved the internal documentation considerably,
documenting not only the accounting system, but also common tasks and
areas, such as onboarding of new projects, vendor management, and more.
While the documentation isn't 100% complete, I'm pretty happy with the
current state, in particular I think it does a good job of reducing the
"bus factor" (i.e. someone else could take over if I'm hit by a bus).

# Future work

* Reporting: the reporting script is still the old one, and it's no
  longer fit for purpose.  I need to replace it completely, which is
  more complex than one would expect for a number of reasons.
  (One reason is that projects want monthly reports that are fairly
  stable, but, especially now that we're on the accruals basis,
  things change sometimes: e.g. donation platforms often inform us
  months later of donations but we recognize the donation on the
  day it was made, not when we were informed.)

* Customized reporting: we sometimes do some customized reports for
  projects; it would be good to automate those.

* Item-level data for projects: we intend to share transaction data
  with projects, but again this is slightly more complex than one
  might think. (One reason is that one transaction can involve
  multiple projects, so we have to write a script that splits up
  such transactions.)

* PayPal importer for beancount: almost everything is beancount "native"
  now except the reporting script (we convert from beancount to ledger
  and run our old ledger reporting script) and PayPal (we use our old
  ledger script and convert to beancount).  The reason I haven't
  converted the PayPal importer is because it contains quite a bit of
  business logic, but I'll convert it eventually.

-- 
Martin Michlmayr
Contractor, Software in the Public Interest, Inc.