>>The whole point here is that, other than writing the binding number, nothing touched the invoice or payment record - all of their other fields remained completely intact. Their nature and content never changed. You can imagine how "the invoice now becomes an invoice credit" makes my skin crawl on teeth edge (or whatever is the expression). Invoice is a credit when it's from my supplier, that's his credit and my debit; it's my credit when I issue it to a customer - then it becomes his debit. Anything contrary to that would create a firing squad composed of a dozen of fierce accountants I eventually befriended over the years (but only eventually and not without a fight ;).
>
>I'm still a little unclear. If an invoice is overpaid by $10, does that invoice now become a credit for $10? I do change the original invoice in that I change the balance, taking off whatever was paid (full invoice amount or partial). I just don't let the invoice balance go negative (which turns an invoice into a credit). I create a separate invoice (a credit invoice) for any amount overpaid.

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 ;).