>This is where we differ - neither the invoice, nor any other record for itself, doesn't have any balance. It's either credit or debit, and has that one amount. Balance is what one gets after totaling records, i.e. it's a result, not a field.
>
>In my universe, nothing can change the nature of an invoice - it's an invoice forever; likewise, an advance payment will remain advance payment forever. It may happen later that other transactions relate to these transactions, and that the customer's balance varies because of them, but in the end we only care about the customer's current debt, and its age. If it ever comes to calculating interest on the debt, we have the due dates and dates on payments, so we have the debt amount on any day of the year - we can calculate interest anytime.
>
>If one wants to go into detail, and to know the history of payment(s) on any particular invoice, there were a few scenarios available for your case:
>- post the payment as is, then post two corrections - a $10 payment and $-10 payment (i.e. a cancellation, so we actually post a zero, which does nothing). Then apply payment and the $-10 to the invoice - this zeros out, so we can bind it and forget it. You are left with a $10 remainder of a payment, which is just a general payment, applicable to anything - you can treat it as an advance payment, return it or do anything with it.
>- post the payment in two parts; the amount that covers the invoice, and the remainder. The invoice and the first part zero out, we can bind them; the remainder is just the same as the $+10 remainder in the first version.
>- post as is and do nothing, keep unbound until a matching set of invoices and payments accumulates (i.e. until there's a new invoice that the customer pays $10 short, at which point he's balance reaches zero), and then just bind everything he has.
>
>Either of these was possible in several ways - either as an option when the payment was entered in the ledger, or as a part of automatic procedure, or as a later manual (but software assisted) procedure, depending on user's settings.
>
>Any of these scenarios would be visible any way the customer history is printed - by post date, by due date, or by bind number. In the latter case, it was becoming quite obvious how the balance would go to zero every couple of lines - or as many as dozen lines in some cases (like a shop which gets delivered to 2-3 times a day, is invoiced daily, but pays weekly).
>
>Like I said - a different universe. Whatever I heard about the way accounting is done here, is just as confusing to me, as this may be confusing to you ;).

Yeah, keeping a balance field in the invoice record breaks data normalization. Purists would say never do that. Always calculate the balance. I believe that there are times it makes sense to break normalization. A balance field in an invoice record is one of those times. Thanks for the input.