Processing Customer Payments

[Neil Williams]

On Thursday 31 March 2005 7:49 am, Jean Onyango wrote:
> Hi all,
>
> Whenever I process a payment for a later invoice (in cases where the
> customer has many invoices generated for him), the customer report shows
> that the earliest invoice generated has been settled while this is not
> the case.

It should be the case for most businesses - particularly the large ones. We've 
discussed this here before and although some users want it to work 
differently, in terms of the needs of the customer business, it is expected 
that the payments are against the running balance, not individual invoices.

My best tip on this is to not take the easy road of having one customer 
account for all customers. Have one customer reference for every individual 
customer, even if they only ever have a single invoice each. That way, every 
payment is correctly tallied against the outstanding balance for that 
customer.

The main reason for this is in calculating charges for late payment etc. - you 
can't charge for late payment on invoice 00010 when the customer has paid 
since 00010 was invoiced. You charge against what is left after using the 
portion of the payment that is left after 00010 is paid.

00010  £24 Jan
00011  £15 Feb
00012  £15 Mar

If the customer pays you £30, that is set against 00010 and the remainder 
against 00011, leaving £9 unpaid on 00011 and the entire £15 unpaid on 00012.  
It means you can charge the customer a late payment fee for £9 on 00011 NOT 
on the entire £24 on 00010.

Compare it with your bank statement or credit card statement. You pay off a 
portion of the balance and what is left is subject to interest. You don't pay 
interest on the oldest transactions only, you pay interest on the *balance*.

Now consider the problems of a supply business where items can arrive broken, 
missing or just plain unwanted. Returns need to be credited, discounts 
calculated, you get into a horrible mess if you try and do this against 
single invoice numbers. It only works if you give your customer a clear 
report (statement) that says "You owe £xx.xx". Don't tell him he hasn't paid 
invoice 00024, tell him how much he owes.

As long as the statement shows:
1. All his invoices for that period.
2. All his payments for the same period.
3. No invoices belonging to anyone else
4. No payments made by anyone else
5. Dates that approximately match his own bank statements.
then all is well.

> How do I process such payments so that the customer report shows
> correctly which invoices have been settled.

Have one customer report per customer. The customer isn't paying a specific 
invoice, they are paying their account and accounts have a running balance.

> They are bound to dispute 
> the reports generated for them.

I work for a business that generates, checks and pays these kinds of 
statements, invoices and reports on a daily basis. £4,000 per invoice, twice 
a day times 840 customers. There is no way that anyone can pay invoices 
individually in the larger scheme - there are always items returned, items 
broken, credit notes, missing items, extra items, offers, discounts, any 
number of extraneous issues that change the amount payable on any specific 
invoice. What matters is the *balance.*

I invoice this customer daily, I get paid weekly. I send them a statement if I 
have a discrepancy that shows all their payments and all my invoices going 
back to an agreed date before the discrepancy arose.

They are not interested in working out which invoice wasn't paid - they want 
to see why there is a non-zero amount at the end of the report.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050331/87a2d84c/attachment.bin