On Periods, Reports, and Cash v. Accrual Accounting

[Derek Atkins]

Hi, all.

This might be a bit rambling (and a bit long), but please bear with
me.

I've been looking at a couple of (related) bug reports concering
reporting, accounting periods, and cash v. accrual accounting and come
to the realization that they are extremely related problems.  I've
been running into a number of problems with reports that assume you
can base a transaction's period on its date (or worse, assumes that
certain accounts are zero at the start of the period) and it's caused
a BUNCH of problems.

First, let me give a bit of background (just to make sure we're all on
the same page).

With accrual accounting, you account for each transaction when it
happens.  You send an invoice to a customer on March 1st, you book the
income on March 1st.  They pay you on April 1st, you account for the
payment on April 1st.  Similarly with expenses, you create the
transactions as they happen.  This is how GnuCash currently implements
transactions (in particular the business functions, but also Credit
Card accounts).  You record the transactions as they happen.

With cash accounting, you account for everything based on when the
money enters/leaves your bank (cash) account.  This means you don't
account for income until it hits your account, and you don't account
for expenses until you write that check to pay for them.  If you pay
for an expense with a credit card, you still don't account for the
expense until you pay the credit card (at least according to my
accountant).

There really isn't a big difference between cash v. accrual accounting
EXCEPT when dealing with accounting periods.  In particular, the
question is: when looking at a transaction -- regardless of the 'post
date' (or 'enter date') -- what is the 'effective date' of the
transaction?  If post the 'post date' and 'effective date' are within
the same accounting period, then you can effectively treat cash and
accrual account the same.  However, what if you're close to the end of
a period and the post date and effective dates cross that boundary?

Here's a real-world problem.  My fiscal year is a calendar year, and I
maintain a cash accounting system (for tax purposes).  I paid for an
item in mid-December (2002) with a credit card.  I didn't get the bill
until January (2003), and paid it in January.  Accordinly, this
transaction effectively belongs in FY03, even though it was posted to
the expense account in CY02 (to match when the expense hit the credit
card).  Similarly with A/R (and A/P); the income transaction (income
-> A/R) is posted at time T0 when the invoice is sent, but the payment
(A/R -> Bank) is at time T1 when the check arrives some time later.
When cash-accounting, you need to look at the income transaction as if
it effectively occured at T1, even though the transaction is posted at
T0.

This became a problem because I was trying to run a P&L and Balance
Sheet reports but they didn't match.  The "Net Profit" in the Balance
Sheet did not match the "Net Profit" on the P&L.  One reason is that
the P&L Report has a start date, but the Balance Sheet does not.  This
means that the P&L and Balance Sheet are theoreitcally covering
different transactions, unless all your income and expense accounts
are zero at the start of the P&L.  However, in my case (as above)
there were FY03 transaction recorded in CY02, which means they were
covered in the Balance Sheet but not in the P&L -- at least until I
back up the start date of the P&L before the start of CY03.

Even worse, it's possible to have some transactions in CY02 that
belong in FY02, but they could be dated AFTER the CY02 transactions
that belong in FY03!  For example, I buy something on a credit card on
December 20, and write a check (for another expense) on December 28.
The Dec 20 transaction is FY03, where the Dec 28th txn is FY02.  So,
just adjusting the start dates on the P&L and Balance Sheet don't
necessarily help.

As I mentioned, the Balance Sheet doesn't have a start date -- it
assumes the start date is when all the income/expense accounts were
zero (when computing the Net Profit).  I could easily add a start date
there (indeed, I've got the code to do it), but that still doesn't
help when you have transactions that are effective later than they are
posted.  So, in addition to a start date, I'd need some way to
determine if a particular transaction belongs in the report.  Worse,
this approach would require changing all the reports to have this
transaction period decision intelligence.

So, I've been trying to think through how to solve all this and
realized that in many cases there is a simple solution: Periods.
Instead of trying to group transactions by date for various reports,
group them by Periods.  Then all the reports can just say "report from
the beginning of period X through the end of period Y" and it will get
all the right transactions.  No more worries about "dates".

Then all we need is a single, centralized, intelligent method for
determining what Period a Transaction belongs to.  All transactions
belong to a Period.  When you create a new Period from the current
Period, you examine all the Transactions and make a determination of
which transactions need to move forward into the new Period.  I'll
leave it open ended, for now, how to determine when a transaction
belongs to the current Period and when it belongs to the new one.

The cool thing is that this approach lets us easily decide whether to
report transactions on a cash or accrual basis, just by flipping a
switch in how periods are built.  For accrual reporting you need do
very little -- a transaction would rarely (if ever) need to be
effectively in another period.  For cash accounting, you need to pull
accrued transactions forward until the cash is exchanged (generally
for certain types of liability and asset accounts, like Credit Cards,
A/R, and A/P).

Before I go down this road I was hoping to get feedback on this idea
and hopefully flesh it out a bit more.  I was thinking that we might
want to have a hierarchy of Periods (month, quarter, year) -- so a
transaction would have a parent Period, and Periods could have parent
(and children) Periods.

One major gotcha: do Periods need to necessarily completely contain
other Periods?  For example, I can certainly posit a reason to have a
week Period -- but a week does not necessarily fit completely within a
month, quarter, or year.  I suppose one could force a designation, but
which one?  We could say that a week belongs to the month with the
most number of days (e.g the week of March 30 - April 5 belongs to
April, 2003, and week of April 27 - May 3 also belongs to April).  Or
perhaps the week belongs to the month that has the last day of the
week (e.g. March 30 - April 5 belongs to April, but April 27 - May 3
belongs to May).

Then there is the question of mapping Accounts to Periods, or changing
the Account tree over time....

There is also the question of how Periods relate to GNCBook*,
GNCSession*, and data-store URIs (including multiple XML files).  I
would think that initially we could just store multiple periods in one
book/file and later provide a means to create a split one file into
two at some period boundary.  But that's for a later discussion.

Anyways, I acknowledge that this is a lot to chew...  I've said a lot,
and rambled even more.  If you read this far I am extremely impressed.
I think we really need to solve this problem, and relatively soon.

Ok, so, my asbestos suit is on so fire away!

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available