Payment allocation worksheet, with the policy written down before the money is matched.
One row per invoice — reference, dates, amount — and one line per allocation, showing what a payment applied, what was still unallocated on it afterwards, and the invoice balance after that line. A series of part-payments walks the same ladder, and anything the money cannot explain is left as an unallocated credit rather than pushed onto an invoice to tidy a total. Copy it as CSV and work it in the same week the money lands.
The template, filled with an example
The example carries four fictional invoices for one fictional client and two fictional payments, with an as-on date of 4 October 2026. The policy is written into the header block before a rupee is allocated, every figure on the page is read off the allocation ladder or derived from it, and the ageing is calculated from the dates shown — so you can check the arithmetic rather than trust it.
Illustrative example only. Every company, person, invoice number, payment reference, date, and figure on this page is invented. No benchmark of any kind is claimed here: not an average time to pay, not a typical number of part-payments, not a collection performance. The four invoices and two payments were chosen to make the structure and the arithmetic visible, not to describe a real book. How advances, credit notes, and anything tax-related are treated is your accountant’s call, and nothing on this page is advice on it.
Header block — the policy first
- What this sheet decides
- Which invoices each incoming payment settles, and what is left unexplained
- As on
- 04-10-2026
- Counterparty
- One client on this sheet. An allocation never crosses a counterparty
- Stated default policy
- Oldest invoice date first, within this client. Ties broken by invoice number
- Manual override
- Allowed — but it carries a name and a reason. A silent override is not an override
- What the policy is not
- It is not an inference about what the client meant. Neither payment on this sheet carried a remittance advice
- What no policy can fix
- A transfer with no remittance advice and no bank reference cannot be resolved from the data. It can only be recorded as a decision
- Open invoices at the start
- 4 invoices, ₹2,69,000.00
- Payments recorded
- 2 payments, ₹2,75,000.00 received
- Credit held at the close
- ₹6,000.00 unallocated credit on the account. A real balance, not a rounding adjustment
- Advances, credit notes, and anything tax-related
- The accountant's call. This sheet records the treatment; it does not advise on it
- Prepared by
- Sample Accounts Executive (example)
- Owner of the next review
- Sample Accounts Owner (example)
The payment as it arrived
| Payment ref | Received | Received (INR) | Allocated (INR) | Unallocated credit (INR) | Reference on the payment |
|---|---|---|---|---|---|
| PAY-2026-0091 | 2026-09-28 | 1,20,000.00 | 1,20,000.00 | 0.00 | Bank transfer, no remittance advice |
| PAY-2026-0104 | 2026-10-02 | 1,55,000.00 | 1,49,000.00 | 6,000.00 | Bank statement line only, no remittance advice |
| Total | — | 2,75,000.00 | 2,69,000.00 | 6,000.00 | Received = allocated + credit, on every line and in total |
Neither payment carried a remittance advice, and the bank reference identified the account rather than the intention. That is the whole reason this sheet exists: what follows is a recorded decision under a stated policy, not a recovered fact. A one-to-one amount match is not a policy either — it is a coincidence of arithmetic, and a coincidence should never be recorded as an intent.
The allocation ladder — one line per allocation
| Payment | Step | Invoice or account | Applied (INR) | Payment still unallocated (INR) | Invoice balance after this line (INR) | Basis |
|---|---|---|---|---|---|---|
| PAY-2026-0091 | 1 of 2 | INV-2026-0142 | 86,500.00 | 33,500.00 | 0.00 | Settled in full — oldest invoice date on the sheet |
| PAY-2026-0091 | 2 of 2 | INV-2026-0157 | 33,500.00 | 0.00 | 8,800.00 | Part payment. ₹8,800.00 left open, carried to the next payment |
| PAY-2026-0104 | 1 of 4 | INV-2026-0157 | 8,800.00 | 1,46,200.00 | 0.00 | Closes the balance left open on 28-09-2026 |
| PAY-2026-0104 | 2 of 4 | INV-2026-0163 | 1,05,000.00 | 41,200.00 | 0.00 | Settled in full |
| PAY-2026-0104 | 3 of 4 | INV-2026-0178 | 35,200.00 | 6,000.00 | 0.00 | Settled in full |
| PAY-2026-0104 | 4 of 4 | Unallocated credit on account | 6,000.00 | 0.00 | — | Left over with nothing to attach it to. Held as a credit, not forced onto an invoice |
INV-2026-0157 appears twice, once under each payment. That is the series of part-payments: ₹33,500.00 on 28-09-2026 and ₹8,800.00 on 02-10-2026, which together clear ₹42,300.00. One invoice settled by several payments and one payment settling several invoices are the same fact read from either end, and both have to be representable without a note in a free-text field.
Invoice state on 04-10-2026, after both payments
| Invoice ref | Invoice date | Due date | Value (INR) | Allocated (INR) | Balance (INR) | Ageing | Status | Allocation lines |
|---|---|---|---|---|---|---|---|---|
| INV-2026-0142 | 2026-06-12 | 2026-07-12 | 86,500.00 | 86,500.00 | 0.00 | 84 days past due | Settled | One allocation line — PAY-2026-0091 |
| INV-2026-0157 | 2026-07-24 | 2026-08-23 | 42,300.00 | 42,300.00 | 0.00 | 42 days past due | Settled | Two allocation lines — split across PAY-2026-0091 and PAY-2026-0104 |
| INV-2026-0163 | 2026-08-19 | 2026-09-18 | 1,05,000.00 | 1,05,000.00 | 0.00 | 16 days past due | Settled | One allocation line — PAY-2026-0104 |
| INV-2026-0178 | 2026-09-25 | 2026-10-25 | 35,200.00 | 35,200.00 | 0.00 | Not yet due, 21 days to go | Settled | One allocation line — PAY-2026-0104 |
| Total | 4 invoices | — | 2,69,000.00 | 2,69,000.00 | 0.00 | — | — | — |
4 invoices worth ₹2,69,000.00, ₹2,75,000.00 received,₹2,69,000.00 allocated to invoices, and ₹6,000.00 still sitting on the account as a credit. Receivables at close are ₹0.00 — and that zero is only half the truth, which is exactly why the credit is reported beside the receivables and never folded into them.
The same payment, allocated two defensible ways
₹1,20,000.00 arrived on 28-09-2026 with no advice. The stated default —oldest invoice date first — is what the ladder records. The alternative, largest open invoice first, is defensible too: some clients clear the biggest item first, and after a large quarter of work that is a reasonable thing to assume. Both allocate the same money to the same client, and both are wrong or right only in a way nobody can check from the data.
| Invoice ref | Invoice value (INR) | Open after PAY-2026-0091 — Oldest invoice date first | Open after PAY-2026-0091 — Largest open invoice first |
|---|---|---|---|
| INV-2026-0142 | 86,500.00 | 0.00 | 71,500.00 |
| INV-2026-0157 | 42,300.00 | 8,800.00 | 42,300.00 |
| INV-2026-0163 | 1,05,000.00 | 1,05,000.00 | 0.00 |
| INV-2026-0178 | 35,200.00 | 35,200.00 | 35,200.00 |
| Total receivables after this payment | — | 1,49,000.00 | 1,49,000.00 |
Under the stated default the ₹1,20,000.00 clears INV-2026-0142 completely and ₹33,500.00 of INV-2026-0157, so the oldest ₹1,05,000.00 exposure disappears from the book. Under the alternative it clears INV-2026-0163 completely and puts ₹15,000.00 into INV-2026-0142 instead. Both leave ₹1,49,000.00 outstanding — identical totals — while the ageing reads very differently, because ₹71,500.00 on a July invoice is a different conversation from ₹1,05,000.00 on a September one. The four columns that make the choice reviewable later are the policy or the person’s name on each line, a reason on every override, the date the allocation was made, and the payment’s own value date kept separately from it. With those four recorded, the second book can be produced on request; without them, the choice is not a decision, it is a habit nobody can audit.
Review
- Reviewed on
- 04-10-2026
- Reviewed by
- Sample Accounts Owner (example)
- Allocation lines on the sheet
- 6 — 5 against invoices, 1 held as credit
- Overrides of the stated default
- 0 of 5. Every line was allocated by policy, not by override
- Invoices touched
- 4 of 4
- Invoices settled
- 4 of 4
- Received, allocated, credited
- ₹2,75,000.00 received = ₹2,69,000.00 allocated + ₹6,000.00 credit
- Receivables outstanding at close
- ₹0.00
- Credit carried to the next period
- ₹6,000.00 on the account, shown next to receivables and never netted into them
- Still unexplained
- Which invoice the second payment's extra ₹6,000.00 was meant for. Chase the advice; do not guess
- Next review
- 05-10-2026
Payment allocation worksheet (CSV — illustrative example data) As on,2026-10-04 Field,Value What this sheet decides,"Which invoices each incoming payment settles, and what is left unexplained" As on,04-10-2026 Counterparty,One client on this sheet. An allocation never crosses a counterparty Stated default policy,"Oldest invoice date first, within this client. Ties broken by invoice number" Manual override,Allowed — but it carries a name and a reason. A silent override is not an override What the policy is not,It is not an inference about what the client meant. Neither payment on this sheet carried a remittance advice What no policy can fix,A transfer with no remittance advice and no bank reference cannot be resolved from the data. It can only be recorded as a decision Open invoices at the start,"4 invoices, ₹2,69,000.00" Payments recorded,"2 payments, ₹2,75,000.00 received" Credit held at the close,"₹6,000.00 unallocated credit on the account. A real balance, not a rounding adjustment" "Advances, credit notes, and anything tax-related",The accountant's call. This sheet records the treatment; it does not advise on it Prepared by,Sample Accounts Executive (example) Owner of the next review,Sample Accounts Owner (example) Payment ref,Received on,Received (INR),Allocated to invoices (INR),Unallocated credit (INR),Reference on the payment PAY-2026-0091,2026-09-28,"1,20,000.00","1,20,000.00",0.00,"Bank transfer, no remittance advice" PAY-2026-0104,2026-10-02,"1,55,000.00","1,49,000.00","6,000.00","Bank statement line only, no remittance advice" Total,—,"2,75,000.00","2,69,000.00","6,000.00","Received = allocated + credit, on every line and in total" Payment ref,Step,Invoice or account,Applied (INR),Payment still unallocated (INR),Invoice balance after this line (INR),Note PAY-2026-0091,1 of 2,INV-2026-0142,"86,500.00","33,500.00",0.00,Settled in full — oldest invoice date on the sheet PAY-2026-0091,2 of 2,INV-2026-0157,"33,500.00",0.00,"8,800.00","Part payment. ₹8,800.00 left open, carried to the next payment" PAY-2026-0104,1 of 4,INV-2026-0157,"8,800.00","1,46,200.00",0.00,Closes the balance left open on 28-09-2026 PAY-2026-0104,2 of 4,INV-2026-0163,"1,05,000.00","41,200.00",0.00,Settled in full PAY-2026-0104,3 of 4,INV-2026-0178,"35,200.00","6,000.00",0.00,Settled in full PAY-2026-0104,4 of 4,Unallocated credit on account,"6,000.00",0.00,—,"Left over with nothing to attach it to. Held as a credit, not forced onto an invoice" Invoice ref,Invoice date,Due date,Invoice value (INR),Allocated (INR),Balance (INR),Ageing,Status,Allocation lines INV-2026-0142,2026-06-12,2026-07-12,"86,500.00","86,500.00",0.00,84 days past due,Settled,One allocation line — PAY-2026-0091 INV-2026-0157,2026-07-24,2026-08-23,"42,300.00","42,300.00",0.00,42 days past due,Settled,Two allocation lines — split across PAY-2026-0091 and PAY-2026-0104 INV-2026-0163,2026-08-19,2026-09-18,"1,05,000.00","1,05,000.00",0.00,16 days past due,Settled,One allocation line — PAY-2026-0104 INV-2026-0178,2026-09-25,2026-10-25,"35,200.00","35,200.00",0.00,"Not yet due, 21 days to go",Settled,One allocation line — PAY-2026-0104 Total,4 invoices,—,"2,69,000.00","2,69,000.00",0.00,—,—,— Invoice ref,Invoice value (INR),Open after PAY-2026-0091 — Oldest invoice date first,Open after PAY-2026-0091 — Largest open invoice first INV-2026-0142,"86,500.00",0.00,"71,500.00" INV-2026-0157,"42,300.00","8,800.00","42,300.00" INV-2026-0163,"1,05,000.00","1,05,000.00",0.00 INV-2026-0178,"35,200.00","35,200.00","35,200.00" Total receivables after this payment,—,"1,49,000.00","1,49,000.00"
Two things this sheet deliberately does not do. It does not claim to know what the ₹6,000.00 was for — no remittance advice and no bank reference means the client’s intention is not in the data, and a system that resolves it anyway is guessing with a confident interface. And it does not tell you how to treat the credit, an advance, or a credit note; that is your accountant’s call, and the useful thing this sheet can do is arrive at that conversation holding a decision that is written down, attributed, and changeable without touching the money.
How to fill it in
Four steps, and the first one is the one most sheets skip.
Write the policy in the header, before any money arrives
One line, in words anyone in the office could follow: oldest invoice date first, within one counterparty, ties broken by invoice number. Deciding it while a payment is sitting in the inbox is how the same client ends up with two different books in the same month.
One row per invoice, with its date and its amount
The date is what the policy runs on. A sheet carrying only invoice numbers can be allocated by number — which is your numbering scheme, not a promise the client ever made, and one that re-sequences the day you insert a backdated invoice.
Walk each payment down the list, one line per allocation
Record what was applied, what was still unallocated on that payment afterwards, and the invoice balance immediately after that line. Attribute each line to the policy or to a named person, and carry a reason on every override. In the example that is five lines against invoices and one against the account.
Stop where the money stops explaining itself
When the payment runs out, or the invoices are all settled, or the remainder belongs to nothing you can name — stop. Hold it as an unallocated credit with a reason and chase the advice. Forcing the last few thousand rupees onto an invoice to make a total look complete is the single cheapest way to build a book that cannot be defended.
When to use this, and when to stop
An allocation sheet is the right size of tool for a business where the money arrives without advice and somebody still has to decide what it was for. It stops being the right size when several people are making that decision separately.
When this template is the right tool
- One client's payments arrive without a remittance advice, and you keep re-deciding which invoices they covered.
- Part payments are ordinary for you, so an invoice is only actually paid once the part-payments have been allocated somewhere.
- You want the allocation decision written down, attributable to a person or a stated policy, and changeable later without editing the payment.
- You are a small team where one person knows the whole ledger well enough to hold a policy in their head but not well enough to remember it next month.
When you have outgrown it
- Several people allocate the same client's money differently, and your receivables figure depends on which of them did it.
- Most lines end in a credit nobody chases, because payments arrive by transfer, UPI and cash and only some carry a reference.
- You spend more time reconciling the sheet against your accounting package than the sheet saves you.
- Every allocation is being overridden anyway — at that point the policy is a fiction and what you need is the decision recorded as a deliberate, named action.
The same process in NoxOrigin
An invoice and a payment are different records, and the allocation is the link between them — which is what lets a wrong link be corrected without touching the money. A payment is recorded once, with its own value date, and applied to invoices under a policy you state rather than one you inherit; outstanding is then recomputed as the invoice total minus the sum of live allocations, so “part paid” is arithmetic instead of a flag somebody has to remember to clear. Where a transfer exceeds what is open, the remainder is held as a credit on the account and shown next to the receivables, because it is a real balance and not a rounding artefact. And a credit balance does not quietly disappear: it is carried, visible, until it is explained or applied against a document that deserves it. This sheet stays the right thing to hand someone in their first week, because every column on it maps to a field the system already holds.
- One payment, many invoices: the allocation waterfallThe four policies compared, what each one quietly assumes about a client's intent, and a worked example where two defensible policies produce two very different ageing reports.
- Quotes, Billing & Finance in NoxOriginAn invoice and a payment stay different records; the allocation is the link between them, so a wrong link is corrected without touching the money.
- Invoice and payment trackingPart payments, recorded payment promises, and outstanding balance by client and by age — the other half of the job, once the allocation is done.
- Payment collection trackerThe sibling sheet for what is still outstanding and who chases it, with ageing bands you can take into a review.
- Cash, UPI and card reconciliation worksheetFor the takings that arrive with a reference the bank issued, where the match is a fact rather than a decision.
- Reports & EconomicsQuoted, billed, collected, and outstanding read as four separate states, with a path from any number back to the records behind it.
Payment allocation worksheet questions
What does writing the policy in the header actually buy me?
It makes the default an argument you can point at instead of a habit. Oldest invoice date first is not a law — it is a choice, chosen because it matches the convention most clients use when they batch one transfer across several invoices. Written into the header, two people allocating the same client's money produce the same book, and a reviewer six weeks later can see that the result followed the policy rather than anybody's mood on the day.
The payment was bigger than everything open. Where does the extra go?
It becomes an unallocated credit on the account, and it stays there until you know what it was for. The example leaves ₹6,000.00 in exactly that state. A credit sitting on an account is a real thing a real client has — money you hold that you owe back or owe against — so it belongs next to your receivables in every report, and never quietly netted into them to make a total look tidier than it is.
Can any system work out which invoices a payment was meant to settle?
Not when the remittance advice is missing and the bank reference says nothing. No field in your ledger contains the client's intent, because it was never sent. What a system can do is apply your stated policy, attribute the decision to that policy or to a named person, and let you change the decision later without editing the payment. Anything more would be a guess presented as a record.
Is oldest-first the right policy for us?
It is a defensible default, not a fact. If your clients habitually clear the largest invoice first, or settle the one they gave a written promise date for, write that policy into the header instead — the point is that a stated policy you actually follow beats a good policy you only half use. The guide linked below compares four policies and what each one assumes when a client later disputes the allocation.
The sheet ties out. Do we still need an accountant?
Yes, and the sheet is what makes the conversation short. Received equalling allocated plus credit is arithmetic you can check in ten seconds; how to treat an advance, a credit note, or anything tax-related is the accountant's call, and nothing on this page is advice on it. The sheet's job is to arrive at that conversation holding a clean, attributable record of what was decided and by whom.
Make the allocation a recorded decision, not a monthly guess.
If the outstanding figure depends on who allocated the money, the allocation is the thing worth putting on the record.