Another unbalanced balance sheet

Robert Locke rlocke at ralii.com
Tue Jan 25 20:25:39 EST 2005


On Tue, 2005-01-25 at 22:24 +0000, Neil Williams wrote:
> On Tuesday 25 January 2005 9:59 pm, you wrote:
> 
> Sorry, went to the wrong list. My fault. Too many open email windows!
> 
> > >On Tuesday 25 January 2005 7:35 pm, Robert Locke wrote:
> > >They start off with an opening balance, 0 hopefully, and a series of
> > > invoices and payments. The final balance clearly indicates the amount
> > > outstanding. If that happens to coincide with a specific invoice, fine.
> > >
> > >> When a customer pays an amount that obviously belongs to a later
> > >> invoice, then that invoice should be marked paid and the older invoice
> > >> should be left open.
> 
> Not at all - you set the dates of the report and that will include invoices 
> that are paid as well as those outstanding. It's a FULL statement, exactly 
> like a bank.
> 
<snip>

Let's try this another way.

Yes, some customers can be satisfied with a statement, carry-forward,
balance, in which case the FIFO method is functional.  Apparently that
is the way that your business is conducted and I can see it's usefulness
given the volume you talk about.

I also agree that an invoice is never unposted and that when a "credit
memo" needs to be generated, one is done.  Oh, but in your case, the
credit memo just decrements a balance figure....

Now, when the volume of invoices is low and I would also add the volume
of customers is low, and each invoice represents a separate job/customer
PO/department/pass-through client, our business model really must track
by invoice, not some global balance (and no, I do not want to create one
customer for each invoice).  This is particularly important based on
subcontracted service-oriented work....  I get paid when my customer
gets paid type of tracking.

While it may not apply to your method of doing business and
communicating with your customers, let me also say, that those of us
looking to be able to apply payments to particular invoices (and allow
me to add credit memo's to particular invoices), are not just pulling
this out of our proverbial.  This ability exists in other "business"
accounting packages, so apparently it is a valid and used feature,
though perhaps not by you.

So, let me draw on the package I used before switching to gnuCash, the
dreaded Quickbooks.  In that program, when I received a payment from a
customer, it would bring up the list of open invoices and automatically
apply the payment amount in the same fashion that gnuCash does now, by
splitting the payment across the oldest invoices.  When a customer had
paid an invoice "out of order" for me, I simply adjusted which invoices
the amounts were applied to.  When the next payment came in, or I
generated an "open invoices" report, I saw the actual open invoices, not
simply the "latest" batch of invoices.

Now, back to gnuCash, the method I use to "get around" this and convince
gnuCash to sort of track invoices paid....  When I receive a payment
from a customer, it applies as gnuCash chooses to apply it (by creating
multiple transactions against oldest invoices).  What I then turn around
and do following it, is open the A/R register and choose "Reconcile".  I
then flag the payment(s) created by gnuCash and flag the invoice(s) I
and the customer believe have been paid.  This works for me because I do
not receive partial payments for an invoice (if I did, I would simply
leave it "un-reconciled").  Then I change my view in the register to
only show me "Un-reconciled Transactions" and I have a visual of my old
"Open Invoices" report.  Now if I could just print that view, but that's
another RFE....

Now, don't get me started on Accrual vs. Cash-based Accounting.... :-)

--Rob
-- 
Robert Locke
Principal, Master Technologist
RAL-II Consulting, LLC



More information about the gnucash-user mailing list