One payment, many invoices: the allocation waterfall
A transfer arrives that settles four invoices, and nothing says which. The four allocation policies, what each assumes about the client's intent, a worked example where two defensible policies produce two very different ageing reports, how a wrong allocation is reversed without touching the payment, and what an accountant needs in the export.
A client sends one transfer for ₹1,43,360. You have four invoices open. Nothing on the transfer says which of them it settles, and no amount of data in your system can recover that fact, because it was never sent. What your system can do is record the decision you make about it, show what the decision did to each invoice, and let you change the decision later without destroying the original.
That is the whole of payment allocation, and it is a smaller and stranger job than it sounds. It is not matching. Matching is the part that either works or does not; the interesting part is what happens after the match is made — which invoice absorbs the money when the transfer is short of the total, which invoice absorbs it when the transfer is more, and what you can still say in a dispute six weeks later. We have an earlier piece on why an invoice and a payment must be different records, and this one assumes it. The question here is narrower and harder: given that allocation is a record, what is a good allocation?
Why paid = true is the wrong model the moment part payments exist
We are not going to re-argue the boolean here; the companion article does that properly. The allocation-specific consequence is worth stating sharply, because it is the part that gets discovered in month four rather than in week one. A flag can express two states and reality has at least five: nothing received, part received, fully received, more received than claimed, and received but applied somewhere else entirely. The moment a client pays in two parts, or pays one transfer across three invoices, the flag has nothing to say about the middle state — and the middle state is where a business actually lives.
The compensating habit is the one to watch. When the flag cannot hold the truth, people start maintaining a balance field, and a maintained field is a second source of truth that disagrees with the money sooner or later. The allocation model has no such field. Outstanding is recomputed as invoice total minus the sum of live allocations, and the state is a label on a projection: issued, partly allocated, fully allocated, over-allocated, and — once a reversal exists — reopened by reversal. Those are consequences of arithmetic, not opinions, which is exactly what makes them safe to build a report on.
The shape: many to many, in both directions
One payment can settle several invoices, and one invoice can be settled by several payments. Those are not two features, they are the same fact seen from either end, and a model that only supports one direction will be worked around in a week. A client who pays three invoices in one transfer is not an unusual case; a client who pays one invoice across a bank transfer, a UPI payment and a cash amount handed across a counter is not unusual either, and both directions have to be representable without a note in a free-text field.
Two rules follow from the shape and are worth stating as rules rather than as preferences. First, an allocation never crosses a counterparty: money received from one client settles that client's claims, and if it is genuinely intended to settle somebody else's, that is a decision with a name on it, not a waterfall consequence. Second, the leftover is a first-class state, not an error. A transfer that exceeds the open invoices for that client does not have to be forced somewhere; it becomes an unallocated credit on the account, which is a real thing a real client has, and which a receivables report must be able to show next to the receivables.
Four allocation policies, and what each one quietly assumes
A waterfall needs a rule for which invoice absorbs the next rupee. There are four rules in ordinary use, and the choice is not technical — each one encodes a different theory of what a client's payment means, and each one is exposed differently when the client later disputes something.
Allocation policies compared (structural comparison — no measured outcomes)
| Policy | What it assumes about the client's intent | How it behaves in a dispute | Where it is wrong |
|---|---|---|---|
| Oldest first, by due date | The client pays in the order the debts came due, which is how most people pay when they batch a transfer | Reproduces the client's own expectation, so a dispute about the allocation is usually a dispute about the invoice, not about your bookkeeping | Ignores a promise to pay a specific invoice on a specific date; can leave a recently-dated claim looking untouched when the client was clearing the oldest one first for a reason nobody wrote down |
| By invoice number | Sequential numbering is a queue, and clients clear queues in order | Legible and easy to explain, because invoice numbers are the thing a client can see | Numbering is usually a configuration of your own system, not a promise the client ever made. Re-numbering after a year breaks the rule silently and retroactively |
| By recorded promise date | The claim the client most recently promised to pay is the claim they paid | The strongest position in a dispute, because the allocation follows a recorded commitment rather than an inferred order | Only as good as the promise recording. Where nobody wrote the date down, this policy silently degrades into oldest-first and the record will not tell you which happened |
| Manual operator choice | A person who can see the client's remittance advice, the phone history, or the payment reference knows something the system does not | The most accurate when the information exists, and the most unreproducible when it does not. Six months later the decision is a name and a date and no reasoning | Does not scale past the person who does it, and cannot be audited by anyone who was not there. This is where most allocation error is actually created |
| Amount match (the shortcut) | A transfer that equals an invoice settles that invoice | The worst place to be caught. It is indefensible, because it was never a rule — it was a coincidence noticed once | A transfer that exactly equals one invoice while several are open is a coincidence of arithmetic, not a statement of intent. This is the shortcut that produces a wrong book and a defensible-looking report |
One clarification worth making explicitly, because it is where most of the friction sits. A payment arriving with no remittance advice attached is not a sign that the business has no rule; it is the normal condition of a payment. No reference number, no covering email, no note saying what it was for — just money, from a client you know, into an account you use. The response to that absence is a written rule applied automatically, not a person chasing the client for a reference they were never going to send and never had to. The allocation still has to be made, the difference is only whether it is made by the same person every time or by whoever happened to be at the desk on Friday afternoon with a queue behind them.
Worked example: one transfer, four invoices, two defensible books
Everything below is invented to make the arithmetic visible. The workshop, the client, the invoices and every figure are ours; none of it is a customer, a measured result, or advice on the correct tax treatment. The 18% GST rate below is used only to keep the totals checkable, and the rate and place of supply that actually apply are your own to determine with a chartered accountant.
Worked example — invented workshop and client, invented figures, illustration only
| Invoice | Issued | Terms and due date | Taxable | GST at 18% | Total | Past due on 15 Nov |
|---|---|---|---|---|---|---|
| INV-2041 | 12 Aug | 30 days, due 11 Sep | 90,000 | 16,200 | 1,06,200 | 65 days |
| INV-2055 | 20 Sep | 30 days, due 20 Oct | 20,000 | 3,600 | 23,600 | 26 days |
| INV-2063 | 4 Oct | 30 days, due 3 Nov | 50,000 | 9,000 | 59,000 | 12 days |
| INV-2071 | 21 Oct | 30 days, due 20 Nov | 12,000 | 2,160 | 14,160 | not yet due |
| Total open | — | — | 1,72,000 | 30,960 | 2,02,960 | — |
On 9 November the client transfers ₹1,43,360 from an account seen before, with no remittance advice. Two policies are applied, and both are defensible, which is the uncomfortable part. Policy A is the shortcut a busy counter reaches for: the amount matches INV-2063, so settle that, then put the remainder on the oldest. Policy B is the stated default: oldest first, by due date, within this client.
The same ₹1,43,360 under two policies (worked example, illustrative)
| Step | Policy A — amount match, then oldest | Policy B — oldest first by due date |
|---|---|---|
| First target | INV-2063 takes the full 59,000 (the amount matches) | INV-2041 takes the full 1,06,200 |
| Money left | 1,43,360 − 59,000 = 84,360 | 1,43,360 − 1,06,200 = 37,160 |
| Second target | 84,360 goes against INV-2041, leaving 1,06,200 − 84,360 = 21,840 | 37,160 goes against INV-2055, clearing 23,600 and leaving 37,160 − 23,600 = 13,560 |
| Third target | Nothing left | 13,560 goes against INV-2063, leaving 59,000 − 13,560 = 45,440 |
| Result on 9 Nov | INV-2063 settled; INV-2041 open 21,840; INV-2055 open 23,600; INV-2071 open 14,160 | INV-2041 and INV-2055 settled; INV-2063 open 45,440; INV-2071 open 14,160 |
| Total outstanding | 21,840 + 23,600 + 14,160 = 59,600 | 45,440 + 14,160 = 59,600 |
Both books show ₹59,600 outstanding, which is the correct answer and the least interesting one. The interesting part is the state of each invoice. On 15 November, Policy A's book has ₹21,840 sitting 65 days past due in the 61–90 band and ₹23,600 sitting 26 days past due in the 16–30 band. Policy B's book has ₹45,440 sitting 12 days past due in the 0–15 band and ₹14,160 not yet due at all. One book reads as a collection problem with a worried client. The other reads as a client paying on time, slightly behind.
Same bank statement. Same money. Same total. The difference is entirely in the decision about which invoice the money landed on — and if you are reading this to work out which book is the true one, notice that neither of us can know. The client sent ₹1,43,360 with no advice, and the truth is not in the data. What the data supports is the weaker and more useful claim: Policy B matches the convention most clients use when they batch a transfer, and Policy A was a coincidence. That is a reason to prefer B and to say so, not a proof that B is right.
The second transfer, and why exactness is rare
On 24 November a further ₹59,600 arrives. Under Policy B it clears the remainder of INV-2063 (₹45,440) and INV-2071 in full (₹14,160), and 45,440 + 14,160 = 59,600, so the book lands exactly on zero outstanding. That exact landing is a coincidence of a constructed example, and real transfers are not like that. They land ₹12 short because a client deducted a bank charge, or ₹340 over because a customer added a courier amount, or they are for a different client entirely and arrived in the same batch. Each of those is an ordinary event and each of them needs a home, which is why an allocation model has to represent three things the boolean never could: a short payment, an overpayment held as credit, and a receipt that belongs to nobody yet.
When the client disputes the allocation
On 3 December the client says ₹70,200 of the 9 November transfer was for other work and is being withheld. Seventy thousand two hundred is 23,600 plus 46,600, and under Policy B that money sits as the whole of INV-2055 plus part of INV-2041. So the reversal is specific: unallocate 23,600 from INV-2055 and 46,600 from INV-2041, leaving those two invoices open at 23,600 and 46,600 respectively, and leave the ₹70,200 as an unallocated credit on the account.
Three things about that state are worth sitting with. First, the total receivable is unchanged at ₹70,200, and the client's balance is unchanged at zero — the money never left, and the only thing that moved is the link. Second, the ageing report changes shape immediately: INV-2041's reopened ₹46,600 ages from its 11 September due date, so by 15 December it reads as 95 days past due, in the 90+ band, for a client who paid on 9 November and had the money taken back off the invoice by a decision rather than by a bank. That is not a bug in the ageing report; it is what a reopened claim genuinely is. But it does mean the value date of the money and the date of the allocation have to be recorded separately, and both have to reach the accountant — otherwise a reversal silently rewrites history. Third, the reversal is a normal event with a normal cause, and it should carry a reason and an author the same way an allocation does.
Reversal, not edit — but a different reversal from the one in the ledger
Our piece on storno accounting covers the principle properly, and we will not restate it: a booked entry is cancelled by an equal and opposite entry rather than deleted, so the original and the cancellation both remain visible. Allocation applies the principle with a twist that is easy to get wrong, and getting it wrong is expensive. The payment is not what is being reversed. The money arrived, it is in the bank, and the payment record stays exactly as it was recorded, with its amount, date, method and reference. What is reversed is the link between that payment and that invoice.
This is a real distinction and it is worth being pedantic about, because a system that treats a wrong allocation as a bad payment will do one of two things, both wrong: it will edit the payment amount, which falsifies a bank fact and quietly breaks the day-end cash figure for that shift, or it will delete the payment and re-create it correctly, which loses the original entry timestamp and the identity of the person who recorded it. A third option is to let the allocation row carry a negative amount. That works arithmetically and it is the design we would argue for, provided the reversal names the allocation it reverses, records who did it and why, and is never presented as a payment — because the moment a negative payment exists, the cash reconciliation for that day has two ways to be wrong and nobody can tell which one happened.
What an accountant needs in the export, and why
The test for an allocation export is not completeness, it is reproducibility: given the rows, can the balances be re-derived without asking a question of the person who exported them? An export that shows a paid status is a screenshot of a conclusion. An export that shows the rows the conclusion came from is something a person can check.
What the export has to carry, and the failure each item prevents
- One row per payment: payment id, received-at date and time, method, counterparty, the payer or account it came from, and the bank's own reference where there is one. Without the reference, a re-import of the same statement cannot be recognised as the same money
- One row per allocation: allocation id, the payment it draws on, the invoice number, the invoice date, the gross amount allocated, the tax component inside that gross, the allocation date, and whether the policy applied was the stated default or a manual override
- One row per reversal: the allocation it reverses, the reason, who authorised it, and when. A reversal without a parent allocation id is indistinguishable from a correction nobody made
- Both dates, kept apart: the date the money arrived and the date it was applied. Late entry and reversals move invoices between ageing bands, and only the pair of dates lets anyone reconstruct why
- Terms and due date per invoice, so the ageing can be recomputed on the reader's own basis rather than inheriting ours
- The unallocated column, itemised by client, including credits on account. Money received and not applied is the single most common line an allocation export omits and the one most likely to be discovered as an error
- Short-pay differences stated as their own field rather than absorbed into a balance, so a client who deducted a charge produces a visible difference instead of a plausible total
- The derived states reproducible from the rows above — invoice total, sum of live allocations, sum of reversals, balance — so any figure you quoted last month can be re-derived rather than trusted
Where this connects to the ageing report
An ageing report is computed from allocations every time you open it, which is why the policy question above is a receivables question and not a bookkeeping detail. Our piece on reading an ageing report covers how to read the bands; this article supplies the input that decides what lands in them. Three connections are worth naming explicitly, because each one is a place where a book can look clean and be wrong.
An unallocated receipt is the first. Money arrives, covers four invoices, and sits unallocated while the cash is visibly in the bank. Every one of those invoices reads as fully outstanding, and the oldest of them looks like the worst failure in the business. The second is a reversal, as worked above: an invoice that was settled in November and is reopened in December returns to a band measured from its due date, not from the day the client actually paid you. The third is late entry — an allocation recorded on the 3rd for a transfer that arrived on the 29th moves an invoice between bands after the fact, which is exactly why a report with no as-of moment cannot be compared with last month's. In all three cases the ageing report is faithfully reporting a decision made somewhere else.
Where this stops, honestly
Three boundaries belong here rather than in a footnote. First, allocation does not recover information that was never sent. A transfer with no remittance advice and no bank reference cannot be resolved by any system; it can only be recorded as a decision, and a good system will leave it unallocated rather than invent a match. Second, allocation is not a substitute for chasing. Reallocating money that arrived does not make a client pay the balance, and a policy that reallocates aggressively can move a genuine old debt out of sight while a new one absorbs the credit — which is why an unallocated credit on an account is a conversation, not a bookkeeping tidy-up. Third, this is an operational record, not the books. It stops at the claim and the cash; statutory accounting, ledgers and financial statements remain your accountant's work, and the export above is designed to be a clean input to that rather than a substitute for it.
What we have not measured
Nothing in this article is measured. We have not counted how often client payments arrive without a remittance advice, have no measurement of how much time a defensible allocation policy saves at month end, and hold no data on which allocation policy clients in fact expect — the claim that most clients pay oldest-first is a convention we are relying on and arguing for, not a finding. The worked example is arithmetic we constructed to make the difference between two policies visible; the figures, the workshop and the client are invented. What we would want to instrument before claiming anything: the share of receipts that arrive unallocated, the share of those later allocated manually, the number of allocation reversals per month and their stated reasons, and the share of collections decisions that had to be reversed because the client disputed them. Until those are counted, the claims here are about structure and the reasoning behind it, and you can test both against your own last twenty receipts.
Frequently asked questions
One payment came in for four invoices and there is no remittance advice. How should it be allocated?
As a decision, made deliberately and recorded as one. Apply a stated default — oldest first by due date, within that client only — because it matches how most people pay when they batch a transfer, and let a person override it whenever real information exists. What you must not do is match on amount: a transfer that exactly equals one invoice while several are open is arithmetic coincidence, not a statement of intent, and it is the shortcut that produces a book which looks defensible and is not.
Can one payment settle several invoices, and can one invoice be settled by several payments?
Both, and a model that supports only one of them will be worked around within a week. The allocations between a payment and an invoice are many-to-many, the outstanding balance on each invoice is the invoice total minus its live allocations, and the state you see — issued, partly allocated, fully allocated, over-allocated — is derived from that arithmetic rather than stored on the invoice.
What happens if money is allocated to the wrong invoice?
The allocation is reversed, not the payment. The money arrived and is in the bank, so the payment record keeps its amount, date, method and reference; what changes is the link, and the reversal names the allocation it reverses, who authorised it and why. The invoice returns to outstanding and the amount becomes an unallocated credit on the account. Editing the payment amount instead would falsify a bank fact and quietly break the cash figure for that shift.
Should I write off the balance of an invoice when a client short-pays?
No, and the short payment should be a visible difference rather than an absorbed balance. A client who deducts a bank charge has not settled the invoice, so the outstanding stays open by the amount they withheld, and the difference is recorded as a difference. A write-off is a decision with consequences for your accounts and is your accountant's call — our job is to make sure the amount being discussed is the real one.
Does a reversal change the ageing report?
Yes, and that is correct rather than a defect. Ageing is measured from the promise the client was given, so an invoice reopened by a reversal returns to the band its due date puts it in, even though the client paid weeks earlier. That is why the export has to carry both the date the money arrived and the date it was applied — with only one of them, a reversal silently rewrites the history a report was built on.
Does NoxOrigin post these allocations to my books or file my returns?
No. NoxOrigin records the payment, the allocation and the reversal, and produces the receivables reports those records support. It does not post to a ledger, prepare a trial balance, or file GST returns, TDS, or any other statutory return. The export is designed to be a clean input for your accountant, and the treatment of advances, credit notes and part-payments is theirs to confirm.