Short Pays and Deductions: How to Handle Partial Invoice Payments

A customer owes you $4,000. A payment lands for $3,820. There is no email, no explanation, no reason code on the remittance. Just $180 missing.

That is a short pay, and what happens next in most finance teams is nothing. Somebody notices, decides that $180 is not worth an hour of digging through proofs of delivery, and writes it off. The invoice closes. Everybody moves on.

Do that four hundred times a year and you have written off $72,000 without ever making a decision about it.

Short pays are the quietest leak in accounts receivable. There is no angry customer, no overdue notice, no escalation. There is just a small gap that nobody has time to investigate, repeated until it stops being small.

What a short pay actually is

A short pay, or short payment, is a payment for less than the invoiced amount. The missing portion is a deduction.

Some deductions are legitimate and expected. Others are errors. A meaningful share are simply customers taking money they are not entitled to because they have learned nobody checks.

The usual causes:

Deduction type	What the customer is claiming	How often it is valid
Early payment discount	They paid within terms and took the 2%	Often invalid, taken outside the window
Shortage	They received fewer units than billed	Verifiable against proof of delivery
Damage	Goods arrived unusable	Usually valid if documented promptly
Pricing discrepancy	The unit price differs from the agreement	Verifiable against the signed price list
Freight or handling	They dispute an added charge	Depends on terms, often genuinely ambiguous
Promotional allowance	A rebate or co-op deal applies	Valid if the promotion exists and applies here
Unexplained	Nothing stated	Unverifiable, needs a query

The single most common invalid deduction is the early payment discount taken late. A customer with 2/10 net 30 terms pays on day 26 and still deducts the 2%. It is small, it is defensible sounding, and almost nobody challenges it.

Why short pays are more dangerous than disputes

It seems backwards, but a customer who calls to dispute an invoice is doing you a favor.

A dispute is a conversation. Someone has told you they are unhappy, explained why, and given you the chance to resolve it. It creates urgency and an obvious owner.

A short pay is a decision already made. The customer took the deduction, paid the balance, and moved on. There is no message to reply to and no meeting to attend. The remaining balance sits in your aging report looking like a rounding error.

This is why short pays escape normal collections process. Your team is looking at the aging report for invoices that are wholly unpaid and severely overdue. An invoice that is 95% paid does not read as a problem, so it never surfaces. It ages quietly until someone runs a cleanup and writes off everything under a threshold.

The rule: a partial payment is an open balance, not a closed invoice

Everything downstream depends on getting this right in your ledger and in whatever system runs your follow-ups.

A $4,000 invoice paid at $3,820 is not paid. It has an open balance of $180. It should:

• Continue to appear in aging, at the correct age
• Continue to accrue days outstanding
• Remain eligible for follow-up
• Carry a reason code explaining the gap

The failure mode is a system that marks an invoice closed once any payment is applied against it. That makes the deduction invisible, which makes it uncollectable, which makes it a write off by default rather than by decision.

Note the one important exception. In construction, an invoice paid at 90% against a 10% contractual holdback is not a short pay. That is a full payment net of retainage, and chasing it will damage a good customer relationship. The distinction matters enough that we wrote about it separately in how AR automation handles construction retainage and holdback.

A workable deduction process

You do not need a dedicated deduction management platform to handle this. You need a repeatable sequence and someone who owns it.

1. Detect the gap automatically

The moment a payment is applied for less than the invoice total, the difference should be flagged. Not at month end, not during a quarterly cleanup. At application.

This is the step most teams skip, and it is the reason deductions become invisible. If detection depends on a person noticing, detection will be inconsistent.

2. Assign a reason code

Every deduction gets categorized using the list above, or your own version of it. Unexplained is a valid code, and it should be the trigger for an immediate query rather than a research project.

Reason codes matter for two things. In the moment, they tell you what evidence you need. Over time, they tell you which customers deduct habitually and which deduction types you keep losing, which is the information you need to fix the underlying problem.

3. Set a materiality threshold, and make it a policy

Here is where teams get it wrong. They do not set a threshold at all, which means the decision gets made ad hoc by whoever is looking at the account, which usually means "write it off."

Pick a number. Below it, auto write off and move on. Above it, research is mandatory. The point is not the specific figure, it is that the write off becomes a stated policy with a number attached rather than an accumulation of individual surrenders.

Then look at the aggregate every quarter. If deductions under your threshold total $60,000 a year, your threshold is wrong.

4. Query unexplained deductions immediately

An unexplained deduction is the easiest one to challenge, because the customer has to produce a reason before any conversation about validity can happen. Often there is no reason, and the balance is paid on the next run.

The query needs to go out within days, not months. A deduction queried at 90 days invites the response that it is too late to research, which is exactly the outcome the delay was heading toward anyway.

5. Chase valid open deductions like any other receivable

Once you have determined a deduction is invalid and the customer owes the money, it goes back into the normal follow-up sequence. It is an overdue balance. It gets reminders, escalation, and channel switching like anything else.

This is where automation earns its place. The deduction balance stays in the aging view, keeps aging, and keeps generating follow-ups without anybody remembering to do it manually.

Across our customer base, automating follow-ups recovers an average of 15 hours per week. One Yonovo customer brought DSO from 65 days down to 41.

What automation can and cannot do here

Be clear about the boundary, because vendors tend to blur it.

Automation handles well:

• Tracking the remaining balance instead of closing the invoice
• Keeping deductions visible in aging with correct age
• Continuing the reminder sequence on the open amount
• Holding the full communication history so a follow-up references the actual dispute
• Surfacing customers whose deduction behavior is a pattern rather than an incident

Automation should not attempt:

• Deciding whether a shortage claim is legitimate
• Matching a proof of delivery against a claimed quantity
• Judging whether a pricing agreement covers a given SKU
• Choosing when to concede a deduction to protect a relationship

Those are judgment calls with commercial consequences, and they belong to your team. The role of the system is to make sure the decision gets made deliberately rather than by silence.

At Yonovo we surface partial payments and disputes in a single AR inbox with a drafted reply waiting for review. The draft carries the invoice context, so the person handling it starts from the facts rather than from a blank message. They still decide.

Fixing the upstream causes

Deduction management is a symptom. If the same deduction type keeps recurring, the fix is not better chasing.

Repeated shortage claims usually point to a warehouse or fulfillment issue, or to a customer whose receiving process is sloppy. Either way, the reason codes tell you which.

Repeated pricing deductions mean your invoicing is not reflecting the agreed price list, or the customer's records disagree with yours. That is a five minute reconciliation that prevents dozens of future deductions.

Repeated early payment discounts taken late are almost always a customer testing whether you check. Challenging the first two usually stops it permanently.

Unexplained deductions from one customer are a pattern worth escalating to the account owner. It is a commercial conversation, not an AR one.

The reason codes are what make this visible. Without them you have a pile of write offs and no idea which problem to solve.

Where to start

If short pays are currently invisible in your process, the first move is not a new system. It is a report.

Pull every invoice from the last twelve months where the applied payment was less than the invoiced amount. Total the gaps. Group them by customer.

Most teams doing this for the first time find a number considerably larger than they expected, concentrated in a handful of accounts. That number is your business case, and the concentration tells you exactly where to start.

From there, the operational work is the same as any other collections problem: consistent detection, consistent follow-up, and a system that does not forget. For the broader mechanics, how to stop chasing late payments covers automated sequences, and what is the best way to track unpaid invoices covers keeping open balances visible.

If you want to see how partial balances behave in an automated sequence, book a demo and bring an aging report with a few short paid invoices in it.