Short pay invoice: how to spot, record and follow up

A short pay is a payment for less than the open amount of an invoice. On a remittance you spot it by comparing the amount paid on each line with what the invoice still shows open: the difference is the short-pay, and the reason, if printed, tells you what to do next.

This page covers how to find short-pays, what to record, and how Remit Reader flags them. What a customer is entitled to deduct depends on your terms and contract, so this is not advice on that question.

How do you spot a short-pay?

Compare each line's amount paid with the open amount for that invoice. If paid is less, the difference is the short-pay. Do this per invoice, not per payment, because a total that looks right can hide one short line offset by an overpay on another.

In the free run's sample, invoice 104517 is open for $512.80 and the customer paid $455.20 with a $57.60 deduction and the note "Damaged on delivery - 2 cs romaine". The two figures add back to the open amount.

What should you record about a short-pay?

Four things: the invoice, the difference, the customer's stated reason, and the payment it came in on. Remit Reader carries all four into the application file: the short_pay_amount and deduction_reason columns sit beside the invoice number and the payment reference.

Keep the reason as the customer printed it. Do not summarize it.

What does Remit Reader do with one?

It lists the line as a short-pay with the difference and any reason printed on the remittance, and it applies the amount actually paid. It then waits for your decision. It does not write anything off and does not tell the customer anything.

Because you review each line before export, you can correct the reason or the amount first.

How is a short-pay different from an overpay or an invoice not found?

An overpay is a line that pays more than the open amount. An invoice not found is a line whose number matches nothing open. An already-paid line points at an invoice that is not open. Each gets its own status, and the lines that need a person go in a second file, not in the application CSV.

That separation matters because a short-pay and a mistyped invoice number look similar on a total but need different follow-up.

What do you do next?

That is your policy: dispute it, accept the deduction, issue a credit, or ask for proof of damage. The software only makes sure the short-pay is visible when the payment is applied.

Continue with what a remittance should contain, the cash application process and cash application automation.

What is a good routine for short-pays each day?

Work them in one pass at the end of the batch, not as they appear. After you approve a batch, filter the application file on the short-pay column. Each row already carries the customer, the payment reference, the invoice and the stated reason, so the follow-up email or call can be written from the row without reopening the PDF.

Sort by amount so the large ones are chased first. For a recurring reason from the same customer, such as damage claims, note the pattern, because it changes the conversation.

Where does the number come from?

Remit Reader shows it as the open amount minus the amount applied, taken from your uploaded open-invoice export, so the figure is only as current as that export. If a credit memo posted since you pulled the export, refresh it first.

The sample shows the point: the customer's line reads 455.20 against 512.80 open, with 57.60 printed as a deduction. Check that paid plus deduction equals the open amount, and if it does not, there is a second difference to explain.

What if the customer pays an invoice twice or too much?

That is an overpay, the opposite case. The line is classified separately, the excess is shown in the unapplied_amount column, and it stays visible so it can be refunded or held as credit under your policy. Remit Reader does not decide which.

Seeing both cases in one file is the point: short-pays and overpays on the same remittance often partly offset each other, and the total alone hides it.

FAQ

Is a short pay the same as a deduction?

Often a short-pay is caused by a deduction the customer took, and the remittance may name it. The two figures can be the same amount; the file records both.

What if the customer prints no reason?

The line is still flagged as a short-pay with the difference. The reason column stays empty for you to fill.

Does it handle partial payments?

A line that pays less than the open amount is classified as a short-pay with the difference shown, and you decide whether it is a partial payment or a deduction.