Invoice & Bill Posting Date Issues Across Multiple Periods

[Adrien Monteleone]

> On Dec 13, 2017, at 9:16 AM, Derek Atkins <warlord at mit.edu> wrote:
> 
> Adrien Monteleone <adrien.monteleone at gmail.com> writes:
> 
>> Thank you Derek,
>> 
>> The inefficiency I referenced was in respect to having to make many
>> accrual entries at the end and beginning of each month simply to shift
>> the recognition of parts of invoices and bills to their proper periods
>> that otherwise would not have to be done if the posting process
>> allowed for using the line-item dates. As it stands, using a single
>> posting date for a bill/invoice that either crosses periods or
>> contains multiple periods results in incorrect recognition. This is
>> what I mean by a carryover limitation of paper ledgers. That practice
>> was necessary with paper. It is not with computers. (at least I don’t
>> see that it is, of course, if you *want* to make all those entries
>> manually, by all means… )
> 
> The design is such that a single invoice is not supposed to cross period
> boundaries.  If you find you are invoicing your customers across
> periods, that implies (to me) that you don't invoice often enough (or
> your periods are way too short).  Making new invoices (at least one per
> period) is rather cheap, so I recommend you do that ;)

This happens for me more with bills than invoices, but with invoicing customers it means not being able to invoice by ‘job’ and instead having to invoice by period. (otherwise, using a ‘non-billed work’ account to match against income, thus more unnecessary correcting entries)
> 
> It's certainly true that the invoice posting and payments could occur in
> different boundaries -- which revert back to the cash v accrual
> accounting question.  In accrual accounting that disparity is fine.

Yes, that disparity is fine and certainly with single-period expenses, there is no issue. The issue is with multi-period expenses on one bill. The limitations of ‘paper’ require correcting entries. But this seems unnecessary to me with computers. That limitation doesn’t seem to be in keeping with any accounting principle but rather appears artificial based on trying to mimic paper entry.

> 
> Oh, and in terms of a vendor bill, in my mind the period is when I
> receive the bill.  If someone did work for me in December and doesn't
> bill me until February, I'm booking it in February.

That would violate the recognition principle. You’re recognizing expenses in a period other than when they were actually incurred. If you invoice in February for work done in December and don’t post the income till February, you are recognizing that in the wrong period as well. Expenses and income will never be matched - violating the matching principle.

> 
>> I’m not asking for the business features to work on a cash basis. I’m
>> wanting them to not cause me to have to make multiple correcting
>> entries for proper expense and revenue recognition. I’m not concerned
>> with recognizing bills/invoices when the money changes hands. I’m
>> concerned with recognizing them when the expense is incurred or the
>> work performed. This works perfectly if everything is tidy in one
>> period. It’s a mess if the ‘document' is not.
> 
> If it's your own invoicing, then just invoice more often.

Generating paper isn’t a determinate of when income is earned. When I invoice it should be irrelevant to that question. Though I suppose for now I’ll have to take the above outlined approach of a non-billed work intermediary account.
> 
> If it's a vendor bill, then treat it as a single transaction regardless
> of when they did the work... Or enter it as multiple related vendor
> bills.
And therein lies the unnecessary extra entries. Either I create multiple bills when there is really only one, or I create one and have to make accrual entries moving amounts between periods - all when the data is known and already entered into GnuCash, just not being used.

> 
>> Perhaps I’m misunderstanding something that you or someone else could
>> help clear up for me. Let’s take a simpler example of a single period
>> bill:
>> 
>> I receive local telephone service in October. The phone company
>> generates a bill for that October service on November 7th. It arrives
>> (postmarked) November 12th. I enter it in GnuCash the same day. The
>> due date is November 27th.
>> 
>> What should my posting date be?
>> 
>> 1) November 7th?
>> 2) November 12th?
>> 2) November 27th?
>> 3) some date in October? (31st perhaps)
>> 4) something else?
> 
> Nov 12.  That's when you received the bill and posted it to your account.
But then the expense gets recognized in November. This is not when I incurred it. (which was October)

> 
>> What should the ‘opening date’ be?
>> 
>> 1) November 7th?
>> 2) November 12th?
>> 3) something else?
>> 4) If I enter the bill on November 13th, is *that* the opening date?
>> 
>> I guess I’m thinking the ‘opening date’ must preceded the posting
>> date, but I suppose that doesn’t matter. (maybe that’s me carrying
>> over from paper here)
> 
> The opening date would be Nov 7.  That's the date the bill is dated.
> 
>> Now, let’s complicate things:
>> 
>> I also receive long-distance telephone service from the same phone
>> company and they bill me on one bill for everything. That November 7th
>> bill is for long-distance calls made in September AND October. All
>> other dates remain the same.
>> 
>> What should my posting date be?
>> 
>> 1) same as above?
>> 2) same as above and then I have to accrue September’s charges back
>> and forth from the above date?
>> 3) some date in September and then accrue October’s charges back and forth?
>> 4) something else?
> 
> Same as above.  It doesn't matter that you made the calls in September,
> it matters that you're being billed in November.

As noted in the other reply, it most certainly does matter when I make the calls and doesn’t matter when I get billed for them. That’s the whole point of the recognition principle. The exchange of information about expenses and income is not a determinate of when they were incurred or earned, the date of the actual activity determines that. The phone company earns the income and should realize it in September for the September calls, and October for the October calls. (they didn’t earn the October money until then) The fact that they bill it in November doesn’t change when they earned it. The same goes for the other side of that coin with respect to my expenses.

Here’s an extreme example to illustrate this:

The phone company provides you local and long distance service each month. In November, they bill you for October local service and long distance calls made in both September and October. You either don’t get the bill for some reason, the phone company forgot to include you in the billing, a computer glitch on their end, you lose it, accidentally throw it away, the post office lost it, you forget to enter it in GnuCash - whatever, and you don’t pay the bill before the next billing cut-off date.

Then in December, the phone company sends you another bill, for November’s local service, long distance calls made in October and November, and the past due amount from the November bill. You enter this bill the day you get it. According to what you are telling me - all of this gets recognized in December because that’s the period you entered the charges into GnuCash. That’s clearly incorrect with respect to the recognition principle.

> 
>> What should the ‘opening date be?
>> 
>> 1) same as above?
>> 2) some date in September?
>> 3) something else?
> 
> Same as above.
> 
>> (Thankfully, I don’t have to deal with customer charge-backs using the
>> business features in this scenario as not only is there a limitation
>> of one customer & job per bill, there is the added limitation of one
>> period. But it would be nice to see how much expense a particular
>> customer is ‘costing' me.)
>> 
>> Derek, thank you very much for your time and effort and thank you for
>> writing the business features in the first place! Long ago I was sold
>> on GnuCash over other options precisely because I found this mailing
>> list and found that developers are active on it. I can’t express
>> enough how valuable that is and how much it is appreciated. I shudder
>> to think of the cold, faceless brick wall I would encounter (and have)
>> with other software. GnuCash and its developer team deserve FOSS
>> awards for sure.
>> 
>> Please don’t take anything I say here as any form of criticism or
>> complaint. I’m merely trying to understand how this is supposed to
>> work. (furthering my understanding of accounting in the process) I
>> appreciate that you wrote these features based on your own needs and
>> experience.
> 
> Not at all.  Just trying to backfill the 15+ years of history ;)
> 
> I'm sure I didn't get everything right.  I was very new back then, and
> didn't understand accounting nearly as well as I do now.  But I needed
> something that would work for my consulting company, so I wrote
> something that worked for me (trying, of course, to make it more
> general).  I know I missed corner cases that apply to others' uses.
> Cash v. Accrual was never handled.  Similarly, applying multiple
> invoice-line-item dates into multiple transaction dates was even never a
> glimmer of concept that should even be considered.  This is especially
> true as a transaction only has one post date, and there is a 1:1 mapping
> of Invoice <-> Transaction.
> 
> What you're asking for would absolutely violate the 1:1 mapping.  I
> think it would be very hard to make that change.

What is the necessity of the 1:1 mapping? What accounting principle is this adhering to? Why must it not be violated? Why is a bill or invoice considered a ‘single transaction’ instead of a set of information to generate at *least* one, but possibly multiple transactions?

Certainly, there are many examples where someone can enter transactions separately using only one debit and one credit between only two accounts. But there are plenty of examples where entry, even on paper, can be made more efficient by combining related entries that happened on the same day as a result of a single real-world transaction into a single journal transaction with multiple debits and credits to multiple accounts. Traditionally, a General Journal accomplishes this with a single transaction that is then cross-entered into T-accounts as single debit-credit entries. The business features even recognize this partially with respect to the line items by allowing you to assign different accounts to apply each line to. (otherwise a bill or invoice could only hit one expense or income category at a time)

I don’t see why entering a single document, a bill/invoice, which contains information from multiple real world transactions occurring on different dates has to be consolidated into a single date transaction. In fact, doing this outside of the business features would be entirely inappropriate. Even a paper entry that attempted this would be an error because it combines physically separate events together. (and would usually require accrual entries to fix)

At the end of all of this, I don’t see this as a cash vs. accrual question because I’m not concerned with when the cash changes hands. To me this is a period recognition problem where the recognition is presently geared towards a paper date, not the activity date. I’m seeing this as why do I have to manually make accrual entries to correct a limitation of the software? and is that limitation absolutely necessary, or just a carry-over from the days of paper entry? and even in the case it is necessary, could this business feature be enhanced by the option to automatically create the necessary accrual entries since all of the needed information already has been entered?

Thanks again for your time and your efforts, for now, I’ll have to take the route of making the extra entries manually. But I hope I’ve illustrated why I see this enhancement is not just a corner case, but extremely useful and vital to properly recognizing both expenses and income in their proper periods.

Adrien


> 
>> Regards,
>> Adrien
> 
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> -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