An Introduction to Pirate Bookkeeping
Mass Pirates use gnucash to maintain their financial records. GnuCash is a mature piece of software, it's cross platform, and its .xml data files get along well with version control software.
In past years, we organized our books as follows:
- A set of asset accounts (bank account, payment processor, undeposited checks)
- Donors. Every donor had a separate account
- Expenses. Every vendor had a separate account
This structure made it easy to see who our money came from, and who it went to. It was motivated by OCPF's reporting requirements. Unfortunately, this structure made it difficult to categorize inflows and outflows. For example, you couldn't answer questions like "how much did we spend on outreach", or "how much did we get in credit card contributions" without doing a lot of data massaging.
This year, I'm trying a different approach: we have income accounts for each kind of contribution we want to track, and expense accounts for each kind of expenditure we want to track. Here's a screen capture of the current account structure:
But how do we satisfy OCPF's requirements, in terms of tracking
contributors and expenses. This is where GnuCash's business features
come in.
Every contributor becomes a GnuCash customer. All monetary contributions flow through an A/P account called "A/Payable". Here's how we'd process a $50 check from Alice Smith.
- Create a Customer for Alice Smith. We'll use the customer fields to record Alice's address (which OCPF requires for contributions of $50 or more).
- We create a $50 invoice for Alice Smith. Creating an invoice shifts $50 from the Income:Mailing account into A/Receivable.
- We enter a $50 payment. The payment moves $50 from A/Receivable to Assets: Checks Received.
- When we deposit the checks, the money moves from Checks Received to Rockland Trust.
Yes, that's a total of four steps, but it captures the cash flow we're interested in. We see $50 of mailed donations, the money winds up in our bank account, and we can attribute it to Alice.
Let's work through a payment example: we'll write a $50 check to Acme printing for some flyers.
- We create a Vendor record for Acme Printing
- We create a bill from Acme Printing, in the amount of $50 dollars. This shifts $50 from A/Payable to Expenses:Outreach.
- We pay the bill from our checking account. This shifts $50 from Rockland Trust to A/Payable.
End result: we've captured the $50 outreach expense, and we can attribute it to Acme Printing. We also have a vendor record where we can store Acme's address for convenient access.
In short: all money in flows through accounts receivable, and all money out flows through accounts payable. Those two accounts are the key to keeping track of "who gave it" and "who got it".
Now, there's just one detail to tie up: In-Kind contributions (which have to be reported separately). For these, I've set up an A/P account called "In-Kind/Payable" and an A/R account called "In-Kind/Receivable". The general flow
- Income:In-Kind > In-Kind/Receivable > Assets:In-Kind
- Assets:In-Kind > In-Kind/Payable > Expenses
In short: in-kind contributions also flow through A/P and A/R accounts. By using separate A/P, A/R accounts, we can easily separate in-kind contributions and expenditures from "ordinary" contributions and expenditures.
Here's a full example, where I paid for our PO box as an in-kind contribution.
- Create Vendor for "US Postal Service"
- Create bill from US Postal service, moving money from In-Kind/Payable -> Expenses:Office.
- Pay bill from US Postal Service, moving money from Assets:In-Kind -> In-Kind/Payable.
- Create Customer for Myself
- Invoice Myself, moving money from Income:In-Kind -> In-Kind/Payable
- Pay Invoice, moving money from In-Kind/Payable -> Assets:In-Kind.
