One Payment, One Invoice
A payment record here is thorough: a reference, a transaction id, an attachment, who recorded it, the balance after it, its currency, and the journal entry it produced. It belongs to exactly one invoice. A customer who pays four invoices with one transfer needs four records.
The position, immediately
A payment is tied to a single invoice. There is no allocation across several, so one bank transfer settling four invoices is entered as four payment records sharing a reference. The record itself is genuinely well built and posts to the ledger, which a credit note does not. Plan the data-entry convention before your first month rather than after it.
Customers do not pay invoices. They pay amounts. The mapping between the two is the entire job of a receivables clerk, and it is the thing a payment record either helps with or does not.
What a payment record holds
More than most, and it is worth listing because the quality here is real.
The customer and the invoice. The amount, and the balance due after it. The method, a reference number and a transaction identifier. The date. Who recorded it. A status. Its own currency. An attachment — so proof of payment lives with the payment rather than in an inbox. A metadata payload. And the identifier of the journal entry it produced.
That last one matters more than it looks. A payment posts to the ledger and knows which entry it created, so the trail from a bank reference to an accounting entry is a single hop. A credit note in the same module posts nothing at all, which is a difference in rigour worth noticing between two documents that both reduce what a customer owes — see A Credit That Reads as Cash.
A reference, a transaction id, an attachment and a journal entry. Everything except the ability to point at more than one invoice.
The one thing it cannot do
Spread itself. The invoice reference on a payment is singular, and there is no allocation table behind it, so one receipt cannot be applied across several outstanding invoices.
In practice that means the common case — a customer paying their statement — is entered as several payment records that together add up to the transfer.
| What the customer did | What you enter | Awkward? |
|---|---|---|
| Paid one invoice in full | One payment | No |
| Paid one invoice partly | One payment; the balance stays | No — this is handled |
| Paid four invoices with one transfer | Four payments sharing a reference | Yes, and it is the common case |
| Paid an amount that does not match any invoice | A judgement about how to split it | Yes — and the judgement is not recorded anywhere |
| Paid in advance, before an invoice exists | Nowhere to put it | Yes — there is no unallocated receipt |
The last two rows are the ones that cost time. A payment with no invoice to attach to has nowhere to live, so it waits — in an inbox, on a note, in somebody's memory — until an invoice exists to hang it on. And a payment that does not match any combination of invoices requires somebody to decide the split, with nothing recording that a decision was made.
Why a dollarised trading economy hits the multi-invoice case hardest
Not for a monetary reason — for a behavioural one. Where transfers are cheap and settlement is fast, customers consolidate. They do not pay invoices as they fall due; they pay a round figure against a statement, weekly or monthly, and expect you to work it out.
That is a compliment to the relationship and a cost to the clerk. Every consolidated payment becomes several records, each needing the same reference typed again, and the reconciliation back to one bank line is done by eye.
It also interacts with something already published: the customer statement does not show credit notes, so a customer paying against a statement is paying against a figure that may be higher than what they owe — see The Statement and the Document It Omits. Consolidated payment plus an overstated statement is a reconciliation nobody enjoys.
The convention that makes it survivable
-
Use the bank reference verbatim on every split
All four records carry the same reference, exactly as it appears on the bank statement. This single habit turns four unrelated rows into a findable group and it costs nothing.
-
Attach the proof once, to the first record
The attachment field exists on the payment. One remittance advice against the first split, and the shared reference finds the rest.
-
Apply oldest invoice first, always
Pick a rule and never deviate. Where a payment does not match a combination exactly, an unwritten rule means two clerks split the same payment differently and the ageing report becomes a matter of opinion.
-
Hold advance payments outside until the invoice exists
Not ideal, and it is the only option. Keep a short list of received-but-unapplied receipts and clear it weekly, because the one thing worse than a payment in a spreadsheet is a payment nobody remembers receiving.
An allocation is a table
This is a well-shaped build rather than an open one. The payment record already holds everything it needs; what is missing is the relationship between it and more than one invoice.
Payment allocations across invoices
One receipt, several invoices, an amount against each. The record and the ledger posting stay as they are; the link becomes a set of rows.
Unallocated receipts
Somewhere for money received before an invoice exists, sitting against the customer until it is applied. This is the half that removes the spreadsheet.
A suggested allocation
Oldest first, or an exact-match combination, proposed and confirmed. Nice, and clearly third — the rule matters more than the suggestion.
No dates on a public page. Tell us how your customers actually pay — per invoice or per statement — and we will scope it in writing.
Scope payment allocationWhat AWRA OpsHub does today
- A payment record carrying the customer, the invoice, the amount, the resulting balance, a method, a reference number, a transaction id, a date, a currency, a status and a metadata payload.
- The person who recorded it, and an attachment for proof of payment.
- A link to the journal entry the payment produced, so the trail from a bank reference to an accounting entry is one hop.
- Partial payment against a single invoice, with the balance remaining outstanding.
- A payments register spanning the product, and ageing on receivables.
What it does not do
- Allocation of one payment across several invoices. The invoice reference is singular.
- Unallocated or on-account receipts. A payment must name an invoice.
- Any suggested or automatic allocation.
- Any record of how a split was decided when a payment did not match exactly.
- A customer statement that includes credit notes, which is what a customer is often paying against.
Not ours, by choice
- The payment record itself is one of the better-built things in the sales module, and it posts to the ledger — which is more than the credit note in the same module does.
- The shared-reference convention is genuinely effective and costs nothing. It is the difference between four rows and a findable group.
- Nothing here is Ecuadorian. It is what a singular invoice reference does when customers pay by statement; cheap fast settlement is what makes them do that.
Three questions about receivables in any system
One transfer settles four invoices. Show me.
A good answer sounds like
One payment, four allocations.
What it actually means
Ours needs four payments. It is workable and it should not be a surprise in month one.
Where does a payment go if there is no invoice yet?
A good answer sounds like
An on-account balance.
What it actually means
Ours has nowhere. Advance payments are the case most systems in this bracket handle worst.
Does a payment post to the ledger, and can I see which entry?
A good answer sounds like
Yes, with the entry identified.
What it actually means
Ours does both. Ask the same question about credit notes, because the answer is often different for two documents in one module.
Write down your allocation rule this week
Oldest first, same reference on every split, proof attached once. Three sentences, and your ageing report stops being a matter of opinion.
Write the conventionFrequently asked questions
Can I record a part payment?
Yes. A payment for less than the invoice total leaves the balance outstanding and the record carries the balance after it, so partial settlement against one invoice is handled properly. It is settlement across several invoices that needs several records.
What do I do with a payment received before invoicing?
Hold it outside the system until the invoice exists, and keep a short list you clear weekly. There is no on-account balance, so the discipline is the list — and a weekly rhythm is what stops it becoming a month of unexplained bank lines.
How should I split a payment that does not match anything?
Pick a rule and apply it every time — oldest invoice first is the usual choice and the easiest to explain to a customer. What causes trouble is not the rule you choose; it is two people choosing differently, because nothing records that a judgement was made.
