The Deposit Nobody Allocated
An advance is received, recorded, and never applied, so the receivables list describes a customer who owes money they have already handed over. What has to be true before an unapplied credit can be allocated, and what guessing costs.
A customer pays you in advance. Forty thousand of their money arrives on a Tuesday, against a quote they are happy with, for work that has not been invoiced yet because the work has not started. Somebody records it as a payment - correctly, because it is a payment, the money is in the bank, and refusing to record it would be worse - and then the day ends. No invoice exists to allocate it to, so nothing is allocated. The payment sits on the customer account as a credit with nothing behind it, and from that moment the business has two incomplete truths about the same customer: the bank says the money is in, and the receivables list says the oldest invoice is entirely outstanding.
Nothing looks wrong. The customer is happy, the money is in the bank, and the person who took the call believes the system knows about it because they put it in. Two months later the same customer receives a statement, and the statement says they owe ninety-four thousand four hundred, which is arithmetically correct and completely misleading, because forty thousand of it has been sitting in the account since April. The first person to read that statement is not the person who recorded the deposit, and they will not find the explanation on the statement, because the statement is built from allocations and the deposit has none.
This is the mirror image of [The Return That Was Never Recorded](/blog/the-return-that-was-never-recorded), where a refund left with nothing allocated to it. Here money arrives with nothing allocated to it, and the cost of that is different in kind. An unallocated refund produces a mystery credit. An unallocated advance produces a customer who appears to be a debtor for money they have already handed over, which is the more expensive of the two failures, because the first conversation about it is a collection conversation.
The argument of this article is narrow. Allocating an advance is a decision, not a clerical step, because there is more than one defensible answer and the choice changes what the customer is told, when they are told it, and what the receivables list means. The problem is not that the system cannot allocate. The problem is that allocating wrongly is easier than allocating deliberately, and nothing in a small business stops the easier version from being chosen by accident, or by somebody guessing at a Friday afternoon.
The distinctionAn advance is money against work that does not exist yet. That is a different record from a payment against an invoice.
The reason the allocation is a decision rather than a chore is that a payment received in advance has more than one honest destination, and they are not interchangeable. It can be held as an unapplied credit against the customer, which is the most defensible default because it claims nothing on either side until somebody knows more. It can be allocated against a specific invoice that exists, which is correct when the customer has said which invoice they are paying. It can be held against the project, so that the work it was given for is invoiced net of it later. It can be treated as a deposit against a milestone that has not been reached, in which case allocating it to an invoice now is not merely unhelpful, it is wrong, because it will make an invoice look settled that is not settled and will leave the real milestone invoice arriving later for money already received. These four are all correct answers to different questions, and the only thing that distinguishes them is what the customer actually said and what your own terms say about how a deposit is drawn down.
That last phrase is the one most businesses have never written down. A deposit is a contract term in substance, even if it was agreed in a sentence on a call, and the sentence usually contains three things: how much, against what, and when the rest is invoiced. What it almost never contains is what happens to the money in the system in the meantime, which is why nobody allocated it. There is no procedure to follow, so the money waits, and waiting is the correct behaviour that then presents as a failure because the receivables list does not know how to present it.
The second thing worth separating is the difference between an advance and an overpayment. An overpayment is money that arrived after the invoice was settled, or more money than the largest open invoice. An advance is money that arrived before the work was billed. They look identical in a payment record - a payment with no allocation - and they are opposites in what the business owes. An overpayment is money the business is holding that it will return or apply. An advance is money the business holds against work it still has to do, and the obligation has not yet been created on the invoice side. Treating an advance as an overpayment produces a refund that should not have been sent; treating an overpayment as an advance produces a quiet forgiveness of a debt that was real. Both are made from the same blank field.
And the third is timing against period. Cash received in April for work invoiced in June is not a customer dispute and it is not a debt; it is a timing difference, and the way a business handles it is a reporting decision about which period the work belongs to. NoxOrigin does not decide that for you and does not file anything on your behalf. What the records can do is hold the fact - money received, dated, allocated to nothing, sitting against a named project and a dated promise - so that the person deciding the period has something to read. The absence of a benchmark for 'how long is too long' is not a gap in this article; it is the point. There is no defensible number for how long an advance may sit unallocated, because the answer is about the deal, not about an average.
Illustrative: four honest destinations for one advance, and what each one claims
Held as an unapplied credit
The payment is recorded, dated, and allocated to nothing. The customer account carries a credit of 40,000.00 in the constructed example. Nothing has been claimed against the customer and nothing has been promised about which invoice it will land on. This is the defensible default, and it is only safe if somebody is looking at the unapplied list, because an unapplied credit that is never reviewed is just a debt with extra steps.
Allocated to a named invoice
Correct when the customer has said which invoice they are paying, or when your terms make application automatic in a stated order. In the constructed example this produces 59,000.00 − 40,000.00 + 35,400.00 = 54,400.00 outstanding, and it also means the deposit has been spent against a document the customer may not have intended to settle.
Held against the project
The advance stays visible against the project it was given for, so that when the milestone is invoiced the person raising it knows the money exists. This is the answer that best matches a deposit against a scope, and it depends on the project being a real record that money can be attached to, not a line in a spreadsheet.
Treated as an overpayment
The wrong answer, and the one a blank field invites. It produces a refund that should not have been sent, and it treats a future obligation as a past one. The tell is a customer account where the credit moves the wrong way, or where somebody proposes returning money that is already earmarked for work.
ConstructedWhat the ledger says about an advance nobody allocated
A constructed deposit, two invoices and a milestone. Every figure below is invented for this article so that the arithmetic can be checked by hand. No deposit default rate, no ageing benchmark, no collection benchmark and no industry average is asserted anywhere in this piece. The 18% GST figure appears only to make an invoice total checkable; it is not a statement about the rate that applies to your business.
The two invoices already exist. The deposit has not been drawn down against either of them.
| Line | Arithmetic | Amount |
|---|---|---|
| INV-4501, dated 2026-03-10, taxable | constructed | 50,000.00 |
| GST on INV-4501 at 18%, illustrative only | 50,000.00 × 0.18 | 9,000.00 |
| INV-4501 total | 50,000.00 + 9,000.00 | 59,000.00 |
| INV-4502, dated 2026-04-21, taxable | constructed | 30,000.00 |
| GST on INV-4502 at 18%, illustrative only | 30,000.00 × 0.18 | 5,400.00 |
| INV-4502 total | 30,000.00 + 5,400.00 | 35,400.00 |
| Billed and outstanding at 2026-05-04 | 59,000.00 + 35,400.00 | 94,400.00 |
| Deposit received 2026-04-02, recorded as a payment, allocated to nothing | constructed | 40,000.00 |
| Milestone work the deposit was given against, not yet invoiced | constructed, taxable | 40,000.00 |
The same customer, read three ways, on 2026-05-04.
| Reading | Arithmetic | Result |
|---|---|---|
| What the receivables list says the customer owes | 94,400.00 billed − 0.00 allocated | 94,400.00 |
| What is actually in the bank and unapplied | 40,000.00 | 40,000.00 |
| Share of the billed total that has already been received | 40,000.00 ÷ 94,400.00 = 0.4237 | 42.4% |
| Days on INV-4501 | 21 remaining days of March + 30 of April + 4 of May | 55 days |
| Days on INV-4502 | 9 remaining days of April + 4 of May | 13 days |
| The ageing picture, as it would be read | one invoice at 55 days, one at 13 days | the oldest invoice looks like the whole problem, and the 40,000.00 in the bank is not in the picture at all |
So the distortion is not that a number is wrong. Every figure in the table is arithmetically correct. The distortion is that 42.4% of the billed total is already in the bank and the list does not know it, which means the list ranks a 55-day invoice above a customer who has paid nearly half of what they have been billed, in cash, in advance.
What happens if somebody guesses instead.
| Line | Arithmetic | Amount |
|---|---|---|
| Whole deposit allocated to INV-4501 | 59,000.00 − 40,000.00 + 35,400.00 | 54,400.00 shown as outstanding |
| Milestone invoice raised in June, taxable | constructed | 40,000.00 |
| GST on that milestone invoice at 18%, illustrative only | 40,000.00 × 0.18 | 7,200.00 |
| Milestone invoice total | 40,000.00 + 7,200.00 | 47,200.00 |
| Outstanding after the milestone invoice lands, with the deposit already spent against the wrong document | 54,400.00 + 47,200.00 | 101,600.00 |
| Cash that will exist by then | 40,000.00 deposit + 0.00 collected against the milestone work | 40,000.00 |
| Gap between what will be demanded and what will be in the bank | 101,600.00 − 40,000.00 | 61,600.00 |
| Of that gap, money the customer has already handed over | 47,200.00 of the 101,600.00 | 46.5% (47,200.00 ÷ 101,600.00 = 0.4646) |
The guess costs nothing to make and creates a demand for 47,200.00 against a customer who already paid it. The remainder, 61,600.00 − 47,200.00 = 14,400.00, is the genuine receivable, and 14,400.00 is also what the customer actually owes, because 94,400.00 billed − 80,000.00 received = 14,400.00. Both numbers are derivable from the constructed example, and both are reachable by arithmetic a reader can redo on a piece of paper.
The reason the guess is so tempting is that it produces a better-looking list, and this is worth dwelling on because the temptation is structural rather than moral. An unapplied credit sitting on an account is uncomfortable. It is money you hold and have not decided about, and a list full of undecided money is a list you cannot act on. Allocating it somewhere - even somewhere obviously wrong - converts a vague unease into a specific number, and a specific number feels like progress. This is the same mechanism that makes people close a row they should have left open, and it is why the correct answer, which is to leave the money unapplied until somebody knows which invoice it belongs to, requires more discipline than the incorrect one.
The cost lands later and lands on a person who did not make the decision. In the constructed example, the milestone invoice arrives in June for 47,200.00, the customer looks at it, remembers paying in April, and asks why they are being invoiced for work they have already paid for. The person answering has to reconstruct a sequence that involved no record connecting the two events, and the most likely reconstruction is that somebody allocated the wrong deposit and nothing was written down at the time. The customer is right, the business is right that it did not receive double payment, and the two positions are reconciled by a correction nobody planned. That correction is the real product of the guess: not the 54,400.00, which was only ever a display, but an afternoon spent with a customer's memory and your own bank statement.
There is a second-order effect that shows up in the reporting rather than the relationship. Money received in advance is not revenue, and revenue is not money. A business that treats an unapplied advance as though it settled an invoice will report lower receivables and higher apparent collection in the same period, and the two errors point in opposite directions, so they do not obviously cancel. The receivables list gets shorter by 40,000.00 in the constructed example - from 94,400.00 to 54,400.00 - which is an improvement of 45.8%, since 40,000.00 ÷ 94,400.00 = 0.4237 and 40,000.00 ÷ 54,400.00 = 0.7353 is the improvement against the smaller base. A collection figure that improves by 73.5% in a month where no invoice was actually collected is not a collection figure, and a reader who has learned to distrust one will distrust all of them.
The remedy is unglamorous and it is a policy rather than a feature. Decide, once, what an unapplied credit means in your business and what has to be true before it can be allocated: an explicit instruction from the customer, a written allocation order in your terms, or a matching document that makes the destination unambiguous. Anything short of that is a guess, and the guess should be a named person's decision on a dated note rather than a default. Everything else in this article is downstream of that sentence.
Illustrative: what an advance record has to carry, compared with an allocated payment
| Question | Advance allocated to nothing | Advance allocated deliberately |
|---|---|---|
| What the customer appears to owe | 94,400.00 in the constructed example, with 40,000.00 already in the bank | A number that reflects cash actually received, with the unapplied portion visible as a credit |
| What happens to a future invoice | It arrives asking for money already received, as 47,200.00 does in the constructed example | It is raised net of the advance, or arrives with the advance already applied to it |
| Who decided the destination | Nobody, and the record does not say so either | A named person, on a date, against a stated instruction or a written order |
| What the ageing list is measuring | Time since invoice, with cash-received advances invisible to it | Time since invoice net of applied customer money, which is a measure of delay |
| What a statement says | A demand for 94,400.00 that a customer will read as a mistake | A position the customer can check against their own record of what they paid |
| What the tax treatment rests on | Cash movement alone, with no document allocating it to any supply | Cash movement plus the document it will be applied to, with the reporting still done by the business and its accountant |
The hard caseThe case with no good answer, and why it still needs a written one
There is a version of this that has no correct answer, and a system that pretends otherwise will make it worse. The customer pays 40,000.00 in advance, three months later changes their mind about the work, and asks for the money back. The refundable amount is not the 40,000.00 that arrived, because the tax on it was never claimed against anything and giving the whole figure back does not necessarily settle what was owed - and this is exactly the point at which tax treatment matters and exactly the point at which software must stop.
What the records can honestly do is hold the inputs. The payment is 40,000.00, dated 2026-04-02, allocated to nothing. No invoice was raised against it, so there is no taxable value to reverse on the invoice side. NoxOrigin does not file GST returns, does not generate e-invoices, does not issue e-way bills, does not record TDS or TCS, does not handle reverse charge, and does not determine place of supply. It also does not hold bank credentials, so the refund leaves through your own bank and the person handling this is a person with a chartered accountant, not a person with a screen. The 18% in the worked examples above exists to make a total checkable and for no other reason; a reader who carried it into their own filing would be making a mistake, and the honest position is that the amount to return is a question for the accountant who knows the treatment, not a field in a billing screen.
The structural point underneath that is the same one that has run through this article. An advance is a claim about the future attached to money that has already moved. Money that has moved is not a fact that needs checking, so the temptation is to treat the whole episode as closed. It is not: the obligation is still open, it is just unallocated, and the four honest destinations for it are all still available - hold it, apply it to an invoice that now exists, draw it against the project if the work is re-scoped as a new quote on the same project, or return it. What is not available is leaving it unexamined, because that is the state the customer wrote the email about.
Illustrative: what to settle before an advance is a record rather than a mystery
- Record the payment the day it arrives, even with nothing to allocate it to. An unrecorded receipt is worse than an unallocated one, because it cannot be found later.
- Attach the advance to the project or the quote it was given against, so the person who later invoices the work knows the money exists.
- Write down the drawdown rule in your own terms: oldest invoice first, specific invoice by the customer's instruction, or against milestones. Pick one and keep it, because inconsistency is what turns a rule into a guess.
- Decide in advance what happens when the instruction is ambiguous. The default should be to hold the money unapplied and ask, not to allocate and apologise.
- Require a named person to approve any allocation made without a matching instruction, and date the note. An approval nobody can see is not an approval.
- Keep unapplied credits on a review list with a date on it. An unapplied credit that is never looked at is indistinguishable from one that has been lost.
- Exclude unapplied credits from collection communications. A customer holding an advance should never receive a demand for money they have already sent.
- Keep the invoice and the payment as separate records, and treat paid as a projection of allocations, so applying an advance visibly reduces the invoice rather than overwriting a status.
- Separate an advance from an overpayment explicitly in your process, because the payment record looks identical and the correct action is the opposite.
- Take the refund question to your chartered accountant rather than deriving it from a screen, because the tax treatment of a supply that was never invoiced is not a software decision and NoxOrigin does not report it for you.
- Do not fill the gap in this article's constructed example with a default-rate figure from outside your own records. The 42.4% and the 46.5% above are derived from the constructed numbers, and your own derivation will be different because your own numbers are.
Money received before there is anything to invoice against is its own failure mode. when a return is never recorded
Frequently asked questions
Is it wrong to leave an advance unallocated?
No. Leaving a payment unapplied is often the most defensible position, because it claims nothing on either side until somebody knows which invoice it belongs to. What is not defensible is leaving it there without an owner and a review date. An unapplied credit that nobody looks at is indistinguishable from money that has gone missing.
How much does an unallocated advance distort the receivables list?
In the constructed example, billed and outstanding is 59,000.00 + 35,400.00 = 94,400.00, and 40,000.00 of that has already been received, so 40,000.00 ÷ 94,400.00 = 42.4% of the billed total is sitting unapplied. Every figure is arithmetically correct and the list is still misleading, because the list is built from allocations and this payment has none. The number is derived from the constructed example and is not a benchmark.
What is the difference between an advance and an overpayment?
An advance is money received before the work was billed; an overpayment is money received after an invoice was settled, or more than the largest open invoice. They look identical in a payment record because both are payments with no allocation, and they require opposite actions - an advance is held or drawn down against future work, an overpayment is returned or applied. Separating them in the process is what stops a deposit being refunded by mistake.
Should a deposit be allocated to the oldest unpaid invoice?
Only if that is a written term of your business and the customer did not say otherwise. Allocating to the oldest invoice in the constructed example produces 59,000.00 − 40,000.00 + 35,400.00 = 54,400.00, and then the milestone invoice for 47,200.00 arrives later and demands money the customer already sent. The rule is not about which invoice is oldest; it is about which document the money was given against, and if that is not knowable, hold the money and ask.
How much of a deposit should be returned if the customer cancels?
That is a question for your chartered accountant, not for a field in a billing screen. The payment amount and the absence of an invoice are facts the records can hold; the tax treatment of a supply that was never invoiced is a reporting decision, and NoxOrigin does not file GST returns, does not generate e-invoices, does not issue e-way bills, does not record TDS or TCS, does not handle reverse charge, and does not determine place of supply. The 18% in the worked examples is there only to make a total checkable.