The Credit Balance Nobody Expected
Money held on account against future invoices is real money and a real liability, and the easiest number in a billing system to be wrong about. What a customer balance has to mean, and why a credit balance and an unapplied payment are not the same record.
A customer overpays on purpose, or pays ahead of an invoice that has not been raised yet, and the business keeps the money. Now there is a number on the customer record that has no invoice behind it, and it is the easiest number in a billing system to be wrong about, because it looks like a small thing and it is not.
The reason it is hard is structural. An outstanding invoice is an amount with a counterparty who has already agreed to it. Money held on account is an amount where the counterparty has agreed to nothing yet: not the price, not the quantity, not the tax treatment, not even the month. It is the most honest number a business can hold and the one most likely to be quietly absorbed into something else.
There is a second number that looks identical on screen and is not the same thing at all: an unapplied payment. An unapplied payment is money that has arrived and has not been pointed at anything yet. A credit balance is money that has been decided to be held. One is an open question; the other is a decision. Collapsing them is how a business ends up unable to say, months later, whether it decided to hold the money or simply forgot to apply it.
This article is about what a customer balance has to mean for it to be a fact rather than a residue, and why those two records have to stay separate. This is not tax advice and it is not accounting advice. NoxOrigin does not file GST returns or any other statutory return, does not generate or submit returns, is not a tax authority, and is not certified. Whether held money is a liability in your books, and how it should be shown, is a question for your own chartered accountant.
A balance is an amount with no document behind it
Every other number in a billing system has a document. Invoiced value is the sum of invoice totals. Tax recorded is the sum of tax lines. Collected is the sum of allocations. Outstanding is invoice totals minus allocations. All of them can be recomputed from records you could print out.
A credit balance has no such document. It is a payment, minus the allocations that have consumed it, with nothing on the other side of the subtraction because nothing has been invoiced yet. That is not a flaw in the arithmetic. It is a faithful description of what the money is: an amount the business holds that the customer has not yet decided what it is for.
Because there is no document, the balance cannot be audited the way the others can. It cannot be checked against a stack of invoices, because there are no invoices for it. It can only be defended by pointing at the record of the decision: the payment, the allocations that have drawn it down, the reason each allocation was made, and the person who made it. If any of those four is missing, the balance is a number that came from somewhere and cannot say where.
A credit balance and an unapplied payment are not the same record
Both show as money the customer has given you that is not sitting against an invoice. They are produced by entirely different acts.
An unapplied payment comes first. Money arrives, it is recorded, and nobody has decided where it goes. It is a queue item. Its defining property is that the next action is a decision, and the decision is usually asking the customer, because a payment with no advice and no obvious target has an owner problem before it has an arithmetic problem.
A credit balance comes second, and it only comes at all if somebody decided. Holding money on account against future invoices is a decision: the customer agreed it, or the business accepted it, and either way the decision was made. The defining property of a credit balance is that the next action is not a decision. It is an event: the next invoice, when it is raised, draws against it.
The practical consequence of collapsing them is that the queue disappears. If unapplied money and held money are the same field, then every payment nobody got round to allocating becomes a credit the business is quietly holding, and the list of things a person is supposed to be chasing is suddenly empty. Nobody notices for months, because the total looks identical either way. Only the difference between a number you decided and a number you forgot is invisible, and that is exactly the difference you need.
Illustrative: the same money, before and after somebody decided
| The state | What the customer record says | What happens next, and who moves |
|---|---|---|
| Unapplied payment, no decision taken | Money received, not yet pointed at any invoice | A person has to find out what it was for. The queue item is a question to the customer, and somebody is accountable for asking it. |
| Credit balance, decision taken and recorded | Money held on account against future invoices, with the decision dated and attributed | Nothing to ask. The next invoice draws against it by agreement, and the draw-down is a record like any other allocation. |
| Both stored in one field, as the constructed example below shows | One number, and no way to tell which of the two it is | Nothing. That is the failure. The queue empties silently and the figure never moves again. |
A worked example, constructed so you can check the arithmetic
Everything in this section is constructed. No real business, customer, invoice or rate is implied, and no proportion, ageing figure or benchmark of any kind is being claimed. The 18% figure appears here, and everywhere else in this article, for one reason only: so that each total can be checked by hand in ten seconds. It is a prop for arithmetic, not a claim about any slab, threshold or classification.
A customer pays Rs 56,640 in advance, before anything has been invoiced for the period. The payment is recorded. Because no invoice exists to allocate it against, the payment is unapplied, and the customer record shows 56,640 received and nothing allocated.
Later, an invoice is raised. The taxable value is Rs 20,000. Tax at 18% is Rs 3,600, checked as 20,000 multiplied by 0.18. The invoice total is Rs 23,600. A person allocates 23,600 of the unapplied payment against it. Allocations against the payment now sum to 23,600. The payment is 56,640. What remains against that payment is 56,640 minus 23,600, which is Rs 33,040.
Now the decision that has to be written down. Is the 33,040 held on account against future invoices, or is it money that arrived for something else and has not been identified? Those are the two states from the previous section, they hold the same figure, and they require different people to do different things. In the first, the business holds 33,040 that it will expect to be offset against invoices not yet raised. In the second, the business holds the same 33,040 that nobody has asked about, and there is a customer who thinks they have paid.
Continue the example under the first state, because the second is just a queue item with a respectable-looking number attached. A second invoice is raised. The taxable value is Rs 30,000. Tax at 18% is Rs 5,400, checked as 30,000 multiplied by 0.18. The invoice total is Rs 35,400. The balance is 33,040. The invoice is not fully covered: 35,400 minus 33,040 is Rs 1,360 outstanding. The held money was applied in full and the customer still owes 1,360, and a system that displayed the balance as a positive number against the customer without showing the draw-down would have made it look like 33,040 was still there.
The obvious next number to print is 33,040 divided by 56,640, which is the share of the advance still held, and it comes to a tidy enough figure to look authoritative. This article deliberately does not print it. A share of one constructed advance tells the reader nothing about their own customers, and the number would only be doing rhetorical work rather than arithmetic work. What the arithmetic establishes is narrower and more useful: a held balance is a subtraction of allocations from a payment, it changes every time an allocation is recorded, and it is therefore a live figure rather than a static one.
What a customer balance has to mean before it is a fact
Five conditions, none of them clever, all of them about meaning rather than about storage.
It has to be a subtraction and not a stored figure, so that it cannot drift out of step with the allocations that produced it. It has to name what it is: money held against future invoices, on this customer, decided on this date, by this person. It has to be separable from unapplied money, so the queue of things a person is meant to chase stays visible. It has to show its own history, because a balance that appeared from nowhere at a month-end close is indistinguishable from a mistake. And it has to be a liability in the reader's understanding, not revenue, not a discount, not a free credit to be quietly netted against next quarter's invoices without anyone deciding to.
That last one is where the business risk sits, and it is worth being blunt about it. Money held on account is money you owe. Not a debt you can write off because the customer has not invoiced yet, not income because the cash is in the bank, and not a courtesy that can be quietly consumed by the next invoice because applying it feels like tidying up. The distinction is between an amount that was agreed to be held and an amount that was spent, and only a person can agree to the first.
If any of these is a no, the balance is a residue rather than a fact
- Can you produce the payment a balance came from, the allocations that have drawn it down, and the reason for each?
- Is unapplied money listed separately from held money, with a named owner for the unapplied list?
- Does the balance show a decision: who decided to hold the money, when, and against what future purpose?
- Is the balance recomputed from allocations, so re-allocating a payment updates it and every view that reads it?
- Can you see when a balance was last drawn against, and by which invoice?
- Is the balance treated in your own books as money owed to the customer rather than as income? That question is for your chartered accountant, not for the software.
Where the line falls
The software records the payment, records each allocation against a named invoice with a named author, and recomputes what remains of the payment from those allocations. Because an invoice carries no paid flag and no stored balance is the source of truth, a customer position is a projection: the sum of payments received, minus the sum of allocations, split by invoice. That is what makes a balance explainable, and it is the same mechanism that makes an overpayment explainable and a shortfall explainable. The distinctions between those three states are the subject of one invoice, two payments that were meant to be one and the short payment nobody agreed to.
Where money goes back out is a separate record with its own reason. A credit note is a document; a refund is money leaving; the payment behind it is a third record. The mechanics are in refund, credit note, and the payment behind it, and holding money rather than returning it is simply another of the decisions a person records rather than a mode the system selects.
What the system does not do here is decide, contact anybody, or file anything. There is no auto-debit, no card on file and no payment gateway integration, so a refund or a further payment is a person moving money. There is no dunning sequence and no write-off automation, so a held balance is never quietly cleared by a system deciding it is stale; writing off money held on account is a decision somebody makes and records. Duplicate detection flags candidates and a person reviews them, and nothing merges automatically, because a merge that combined two payments would destroy the evidence of which money was held and which was applied. Merge policy is a setup decision. Shift close and day-end reconciliation are assisted-setup maturity rather than self-serve switches, so the month-end comparison of what you hold against what you have recorded is something a person performs, with the setup done alongside you; the harder version of that comparison, where the drawer, the ledger and the bank are three different numbers, is in the cash count is not the bank balance.
None of this is tax advice and none of it is accounting advice. NoxOrigin does not file GST returns or any other statutory return, does not generate or submit returns, is not a tax authority and is not certified. Whether a held amount is shown as a liability, and what it is called in your books, is your chartered accountant's determination.
Frequently asked questions
What is the difference between a credit balance and an unapplied payment?
An unapplied payment is money that arrived and has not been pointed at anything; the next action is a decision, usually to ask the customer what it was for. A credit balance is money somebody decided to hold on account; the next action is not a decision but the next invoice drawing against it. They hold the same figure and require different people to do different things, which is why they should be stored as different states rather than as one number.
Is money held on account revenue?
That is a question for your own chartered accountant, and it is one of the clearest examples of a question software should not answer. What the billing system owes you is the record: the payment, the allocations drawn against it, the decision to hold the remainder, the person who took it and the date. How that amount is presented in your accounts is a determination for your accountant.
Can the system apply a held balance to the next invoice automatically?
No. There is no auto-matching engine, no rules-based allocation, and no write-off automation. Applying held money to an invoice is a decision a person makes, and the allocation is recorded against their name. The reason is the same as for unadvised payments: a stored balance that moves itself stops being a decision and becomes an accumulation.
Does the system chase or refund anything by itself?
No. There is no dunning sequence, no auto-debit, no card on file and no payment gateway integration. A refund is a payment leaving, recorded with its own reason, and both people and money are involved by choice. Where a refund follows a credit note, the three records involved are described in [refund, credit note, and the payment behind it](/blog/refund-credit-note-and-the-payment-behind-it).
Why does a customer balance need to be a subtraction rather than a stored number?
Because every allocation recorded against the payment changes it, and a stored figure can only be updated by whoever remembers to update it. When the balance is a projection, re-allocating a payment updates the balance and every view that reads it at the same moment, and the figure can be reconstructed from the records at any point in the future rather than trusted.