The Short Payment Nobody Agreed To
A customer pays less than the invoice and nobody recorded why, so the shortfall becomes an argument at the next invoice. What has to be attached to a part payment for it to be a fact, and why a discount approved at the counter and a shortfall nobody approved are different things.
A customer pays an invoice and pays less than the invoice asked for. Nothing about the payment is unusual: money arrived, it was recorded, and someone allocated it against the invoice. The invoice is now short. And nobody has written down why, because at the counter the person taking the money was not the person who raised the invoice and was not the person who would chase it.
The shortfall then does what shortfalls do. It sits on an invoice. It appears in an outstanding figure. Six weeks later somebody opens a new invoice for the same customer and the customer says, correctly, that they already paid that. Or worse, the customer says nothing, pays the new invoice in full, and your records now show the old invoice partly unpaid and the new one settled, with the money on the wrong side of the argument.
This article is about the difference between a short payment that is a fact and a short payment that is an anomaly. It is not about recovering the money. It is about what has to be attached to a part payment at the moment it is recorded, so that the reason is still attached in six months.
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. Where a treatment matters, the question belongs to your own chartered accountant. What a billing system owes you is a record good enough for that accountant to work from.
A shortfall is a subtraction, and a subtraction has no opinion about why
The invoice asked for a total. The allocations recorded against it sum to less. The difference is the shortfall, and like the overpayment in [one invoice, two payments that were meant to be one](/blog/recording-a-payment-twice-idempotency), it is arithmetic and nothing more. It carries no reason, no fault, and no instruction about what happens next.
The reason lives somewhere else entirely: in a conversation at a counter, in a note on a paper docket, in a message the person who took the payment read once and acted on. That is the whole problem. The arithmetic is durable; the reason is a rumour with a half-life of about a week.
It is worth being clear that the invoice carries no paid flag, so 'short' is not a state the invoice is stuck in. It is a projection: allocated total against invoice total, recomputed whenever asked. Nothing is waiting to become paid. The invoice will read as short on every query until allocations change, and if someone later records a credit note or a discount against it, the projection changes for a reason that has to be findable somewhere other than the total.
Three shortfalls that look identical in a payment list
Illustrative: three reasons a payment is smaller than its invoice, and why they are not variations
An agreed discount
Somebody with authority agreed to reduce the price, and the customer paid the reduced figure. If the reduction was a discount on the invoice, the invoice itself should carry it and the payment should match the invoice. A payment that is short because the discount was never put on the invoice is not an agreed discount; it is a missing document.
A part payment with a promise
The customer paid what they could and said the rest would follow. This is the ordinary case and it is fine, provided the remaining figure, the promised date, and the person who recorded the promise are on the record. What makes it a fact rather than an anomaly is the promise with a date on it.
A shortfall nobody approved
The customer paid less and nobody decided anything. This is the dangerous one, because it looks exactly like the middle case until the promised date passes, and then it is not a part payment at all. It is an unpaid invoice with a small false promise attached to it.
These three are not the same size of problem, and the middle one is the only one that is ordinary. Treating all three as 'part payment' is what makes the third one survive. A collection queue that counts every shortfall as a live part payment will keep showing the third case as healthy, current and being worked, right up until the month it is simply old.
The fix is not a reminder to be careful. It is a distinction the record has to make: a payment is short, and separately, something was decided about why. Those are two facts. When only the first is captured, the second is reconstructed from memory at the worst possible moment.
The mechanics of prioritising what gets chased, once the distinction exists, are in [the collection call you have to make](/blog/the-collection-call-you-have-to-make), and the point of that article is the same one: the queue should be decided by a written rule rather than by whoever shouts loudest.
Illustrative: the same payment, read under three different attributions
| What is attached to the payment | What the invoice is doing six weeks later | What the next conversation is about |
|---|---|---|
| Nothing. Amount and date only. | Reading as short, ageing quietly, treated as if it were a part payment | Whether the customer is in good faith, and who made a decision nobody recorded |
| A part payment with a promised date and the name of the person who recorded it | Reading as short, but with a live date attached that a queue can order by | A date. The customer said when, someone wrote it down, and now somebody can check. |
| An approval: who agreed to reduce, up to what limit, when, and against which invoice | Reading as settled against an approved reduction, if the reduction was put on the invoice as a discount | Nothing to argue about, provided the reduction exists as a document on the invoice |
A discount approved at the counter is not the same thing as a discount nobody approved
This is the sharpest edge in the whole subject, so it is worth separating carefully. A discount is a change to what the invoice asks for. It is a field on a document: an amount, a reason, a limit, an approver, a date. It exists before the payment and it survives the payment. Applied properly, the customer pays the reduced invoice in full, the invoice reads as settled, and nobody has to remember anything.
A short payment with no approval is not a discount. It is a customer who paid less. The business has, in effect, absorbed the difference without deciding to, and the record of the decision is a silence.
The reason to care is not primarily financial; it is that the two situations point in opposite directions when the arguments start. The approved discount is a closed question: the price was agreed, the invoice says so, the payment matches. The unapproved shortfall is an open question: the customer says the invoice was Rs 20,000, you say it was Rs 23,600, and the arithmetic on the invoice is the only witness either of you can call.
Approval with a threshold is a control rather than a courtesy, and it is worth setting a limit rather than leaving the decision to whoever is nearest the till. The mechanics of threshold approvals and recorded supervisor overrides are described at /approval-workflow-software-small-business, and the reason they matter here is specific: without a recorded approver and a recorded limit, the review of a discount has nothing to review.
A worked example, constructed so you can check the arithmetic
Everything in this section is constructed. No real business, customer, invoice or frequency is implied. The 18% figure appears here, and everywhere else in this article, for one reason only: so the totals can be checked by hand in ten seconds. It is a prop for arithmetic, not a claim about any slab, threshold or classification.
One 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 customer transfers Rs 20,000 and says the rest will follow. The payment is recorded and allocated against the invoice. Allocations against the invoice now sum to 20,000. The invoice total is 23,600. The shortfall is 23,600 minus 20,000, which is Rs 3,600.
Here is the trap, and it is worth naming because it is exactly the kind of coincidence that gets a person into an argument. The shortfall is Rs 3,600. The tax on the invoice is also Rs 3,600. A reader who glances at the two figures will very reasonably assume that the tax has not been paid, and that the taxable part has been paid in full. That is a coincidence of this constructed example and nothing more. In a different example the shortfall would be a round number chosen for a reason entirely unrelated to tax, and the same reader would draw the same conclusion and be wrong in a different way.
The arithmetic that actually settles the question is the line-level one. Taxable value 20,000, tax 3,600, total 23,600, paid 20,000, short 3,600. Which component is outstanding is a question for the customer, the invoice, and your own chartered accountant, and a system that cannot show the components cannot help anyone answer it. Which is a small argument for keeping tax as a field on a line of an invoice rather than a lump on a total, and for treating the outstanding figure as a subtraction rather than as a stored number.
The obvious next number to print is the share of the invoice left unpaid after the part payment. This article deliberately does not print it. A share of one invoice in one constructed example is not a collection rate, and printing it invites the reader to believe that a shortfall of this size is ordinary or acceptable. Nothing in the arithmetic supports either claim.
What has to be attached to a part payment for it to be a fact
Five things, none of them clever, all of them record-keeping rather than automation. Together they are the difference between a part payment and an unexplained gap.
The amount received and the date, obviously, because everything else is measured against them. The external reference from the bank or provider, so the payment can be matched to a settlement line later rather than trusted. The allocation, naming the invoice it was pointed at and the person who pointed it. The reason, in the business's own words rather than a code nobody remembers, attached at the moment of recording. And the decision, where there is one: who approved a reduction, up to what limit, on what date, or, in the part-payment case, the date the remainder is promised.
Where none of that exists, the honest description of the record is that money arrived and nobody recorded why. That is not a data quality complaint about the software. It is the accurate description of what a counter interaction looks like when nobody was given the authority, or the reminder, to record the reason at the time.
If any of these is a no, the shortfall is an anomaly rather than a fact
- Can you name the person who decided the payment was short, rather than inferring it from the total?
- Is the promised date for the remainder on the record, with the name of the person who recorded the promise?
- If a reduction was agreed, does the invoice itself carry it as a discount, with an approver and a limit, rather than the payment being quietly smaller?
- Can you separate the taxable component of the shortfall from the tax component by looking at the invoice lines?
- Does your collection view distinguish a part payment with a live promise from a shortfall with no promise attached?
- Is the record exportable to your chartered accountant without anybody re-keying the payments?
Where the line falls
The software records the payment, the allocation, the reason a person typed, the approval where one was required, and the promised date where one was given. Outstanding on an invoice is a projection of allocations and nothing else, so it can never be silently wrong in the way a stored flag can. Payments, promises and outstanding by age, grouped by client, are the views a collection queue is actually built from, and they are described at /invoice-payment-tracking-software.
What it does not do is chase, and it does not decide. There is no dunning sequence, no auto-debit, no card on file and no payment gateway integration, so nothing contacts a customer on a schedule and nothing collects without a person sending money. There is no write-off automation either: writing off a shortfall is a decision somebody makes and records, and the effect of that decision on your figures is a separate conversation, covered in writing off a debt and what it does to your numbers.
Approvals are a control, not a courtesy, and where a reduction was applied at the counter it belongs on the invoice as a discount with an approver rather than in the size of a payment. There is no timesheet record and no payroll module anywhere in this product, so nobody's hours are involved in deciding whether a payment was correct; there is no contract editor and no e-signature, and a change to what is being billed is a new quote on the same project rather than an edit to an agreed document. Expenses live in Nox-Billings only; purchasing and stock movement live in Commerce. If the reason for a shortfall is a disputed scope or a disputed quantity, the reconstruction that settles it is usually a scope argument rather than an accounting one, and the sibling article on that is when the customer disputes the invoice.
A shortfall is one direction of the mismatch; the other is money received in excess. the credit balance nobody expected
Frequently asked questions
What is the difference between a part payment and a short payment with no reason attached?
A part payment is a decision: money was received, the remainder is known, and a date was promised and recorded with the name of the person who recorded it. A short payment with no reason is a gap: money was received and nobody wrote down why. Both display identically in a payment list, which is why the distinction has to be stored rather than inferred.
A customer paid less because we agreed a discount. Where does the discount go?
On the invoice, as a discount, with the amount, the reason, an approver and a limit. A discount is a change to what the invoice asks for, so it belongs on the document and it exists before the payment. A payment that is merely smaller than the invoice is not a discount, however well understood it was at the counter, because nothing on the record says the price was agreed.
Should an invoice carry a paid flag?
No. An invoice is a request for money and a payment is money that arrived, so they are two records. What an invoice looks like is a projection of the allocations recorded against it, recomputed whenever it is asked for. A stored paid flag cannot survive one payment touching four invoices, two payments touching one invoice, or a payment that arrived before the invoice did.
Does the system chase the shortfall for us?
No. There is no dunning sequence, no auto-debit, no card on file and no payment gateway integration, and no write-off automation. A person sends the money and a person records it; a person decides what a shortfall means and a person decides when to chase it. The system holds the records, the promised dates and the ageing, so the queue is ordered by what is written down rather than by who remembers.
The shortfall equals the tax on the invoice. Does that mean the tax is unpaid?
It might, and it might not, and no system can tell you from the total alone. In a constructed example the two figures can coincide by accident. The question is answered at line level, by looking at the taxable component, the tax component and the payment against each other, and where the answer has any tax consequence at all it belongs to your own chartered accountant.