[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Voiding a invoiced transaction]

Thanks Josh

Very interesting email.  There are a few points I am not quite clear
on (exactly how we adjust inventory and COGS numbers-- whether it is
the reverse of the invoice or an adjustment to current FIFO figures).
However, this email is very interesting because it brings up a point I
had not considered at all:  invoices voided for reasons other than
that they were invalid in the first place (for example, products
destroyed in transport, or the like).  This makes the problem far more
complex and I will have to think about this a lot more.

The way I see it is:
1)  At the end, there may need to be adjustments to the COGS and
inventory accounts to ensure that inventory for non-discreet (i.e.
most) items remains at valid FIFO figures.   I didn't see any
discussion of this problem in the accountant's reply and until I hear
otherwise, I will assume it is necessary.  This being said, it may not
be strictly necessary in this case because of the fact that we do
inventory on a continuous basis.

If we want to get into an argument why stock numbers are probably not
OK, I will submit my thoughts.  However, I think we are probably in
agreement here.

2)  There are valid reasons to reverse an invoice some time after it
was issued  (Ship and invoice, item is lost in the mail.  A week later
your accounting period changes, and two weeks after that, you reverse
the invoice).  In these cases, *inventory may not always be returned
to the on-hand stock.*  This means we may have to have an additional
option of "Void as Loss" or something similar.  After a while, it
might be necessary for larger users to be able to have such things
automatically handled against an allowance as well.  And although such
an allowance system may seem overkill for a small business, it may
allow for much greater accuracy in reporting if sufficiently

I have a feeling that we are at least a version away from having core
people be able to tackle this issue effectively.  However, having a
good and robust system for dealing with these cases is clearly
something we want to have done sooner rather than later.

Best Wishes,
Chris Travers

On 10/10/06, Joshua D. Drake <..hidden..> wrote:
This is from my CPA.

-------- Original Message --------
Subject: Voiding a invoiced transaction
Date: Tue, 10 Oct 2006 16:44:46 -0700
From: David Kawasaki <..hidden..>
To: Joshua D. Drake <..hidden..>

The following things should occur, not necessarily in this order, but
should be all made to the current period...not effecting any prior
period (i.e., month):
Reverse the sale -
Debit the corresponding revenue account
Credit the accounts receivable account - two parts to this - one
recorded in the general ledger, the second adjusting the subsidiary
ledger (or client-detail screens)
This side of the entry should illicit a response for the client, invoice
number, etc. (the more ways to bring it up, the better)
The entry into the client detail should effectively offset the invoice
(no longer outstanding) and show up in the client screen similar to a
payment on account, except with a different description
Reverse the cost of sale, if applicable -
Debit the appropriate inventory account (two parts to this - one
recorded in the general ledger, then second adjusting the inventory
ledger (item specific)
The appropriate inventory item should be gleaned from the original
invoice - and if returned, should be added back to the counts
An option should be given to input another account for the cost
adjustment, assuming the inventory does not come bake (i.e. damaged,
spoiled, etc.). These should not enter back into the inventory system.
Credit the corresponding cost of sales
In all cases, an accounting trail is a must. That is to say, each entry
into the accounting system should generate a line item transaction in
some part of a report. Example, the general ledger could capture just
the transaction summaries for the posting period, as long as there is a
way to print the detail of these summaries (usu prompted before posting).

First try. I know I used some acctg jargon, but I'm sure most should be
aware of them. If not, I can explain differently. Also not sure of the
amount of detail needed. Let me know and I can tweak one way or another.

This notice is required by IRS Circular 230, which regulates written
communications about federal tax matters between tax advisors and their
clients. To the extent the preceding correspondence and/or any
attachment is a written tax advice communication, it is not a full
"covered opinion." Accordingly, this advice is not intended and cannot
be used for the purpose of avoiding penalties that may be imposed by the

David Kawasaki, CPA
PH: (503) 297-1072
FAX: (503) 297-6634
E-MAIL: ..hidden..

E-mail sent through the Internet is not secure. The information
contained in this e-mail, including attachments, is privileged and
confidential. It is intended only for the use of the individual(s) named
above. If you are not the person for whom this e-mail is intended,
please delete it and notify me immediately (ph. 503-297-1072). Any
dissemination, distribution or copying of this e-mail, including
attachments, is strictly prohibited.


   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
Ledger-smb-devel mailing list