How automated AR tools handle partial payments and short pays

Automated AR tools handle partial payments and short pays by posting the cash that arrived and then deciding what the gap is. A partial payment is cash against the open balance. A short pay is cash below the invoice. A deduction is a short pay with a reason. A rules-based matcher posts the clean cash and queues the gap. An agent codes the gap as a discount, a deduction, or an amount still to collect, and routes it.

Leaving the gap uncoded is how the money disappears. The bank shows the payment. The invoice looks handled. The remainder sits in the aging until someone notices, often after the customer has stopped answering.

Three gaps that look the same on a bank line

An invoice for 10,000 can land as 9,400 for three different reasons, and each one needs a different next step.

• Partial payment. The customer sent 9,400 against the balance and still owes 600, with no claim attached. Apply 9,400. Keep 600 open. Collect the 600.
• Short pay with a deduction. The remittance names a reason: damaged goods, a shortage, a promotion, freight. Apply 9,400. Code the 600. Validate the claim. Clear it if it is valid, or recover it if it is not.
• Discount or error. The customer took 2% after the discount window, missed a line, or deducted a bank fee. Apply what arrived. Decide whether the difference is allowed. Chase it if it is not.

People use "short payment" and "partial payment" interchangeably. The short payment page defines the term. The operational difference is whether a reason came with the cash.

What rules-based tools do

Rules-based cash application is good at the clean case: the amount matches an open invoice, the reference matches, and the payment posts with no one touching it.

Partials and short pays break the rule. The amount does not match, so the payment falls into an exception queue. A person then has to read the remittance, decide what the gap is, code it, and tell collections to stop chasing the part that was paid. Until that happens, two failures are common. Collections chases an invoice the customer already paid in part. Or the unpaid remainder is never worked, because the invoice no longer looks overdue enough to matter.

That queue is the product for a team that wants every short pay approved by a person before it posts. It is a poor product for a book where hundreds of small gaps arrive every week.

What should happen to the remainder

The cash that arrived should post the day it arrives. The open amount should stay visible, with a reason.

1. Match the payment to the invoice, even when the amount is short.
2. Read the remittance. The reason is usually there.
3. Code the gap: deduction, dispute, discount, or still owed.
4. If it is a valid deduction, clear it with the credit memo so it stops cluttering the aging.
5. If it is still owed, or the deduction is invalid, keep only that remainder in collections or disputes.

Speed matters more than the size of the gap. A 600 deduction worked in the first week is recoverable. The same 600 found at month-end usually is not.

When Rex fits, and when it does not

Rex is the AI operations partner for order-to-cash. On a short pay, agents match the cash, read the remittance, code the gap, and either clear a valid deduction or keep the remainder in collections or disputes. Your team and a Rex finance expert approve the cases that need a judgment, such as a contested price.

Rex fits when partials and short pays are too many to research by hand, and when a paid invoice is still being chased because cash application and collections do not share a ledger.

Rex does not fit a controller who wants every short pay held for human approval before anything posts. A queue tool is the honest buy. The comparison of those tools is best cash application software. How matching works beyond the short-pay case is in automating cash application.

The cash application page is the job: remittance matching, short-pay detection, and exception routing.