How to Match a Partial Payment to an Invoice

Match a partial payment by working out why the gap exists before you post anything, then applying the cash to the named invoice and giving the shortfall its own disposition. Monk is an AI-native invoice-to-cash platform that runs invoicing, cash application, collections and disputes as one system, so a payment, the invoice it belongs to and the reason for the difference stay attached to each other instead of living in three places. A customer pays £8,240.00 against an invoice for £8,500.00. The £260.00 gap is a deduction, a dispute, a short ship, an early settlement discount taken, a bank charge, or a keying error at one end or the other. Each of those has a different owner, a different accounting entry and a different collections consequence. The one treatment that is always wrong is deciding nothing and leaving the cash unapplied.

The situation repeats every week. A remittance advice arrives by email, a BAI2 file lands from the lockbox with a payment record and no addenda, or an ACH credit turns up with an EDI 823 wrapper naming one invoice and paying less than its face value. Your ledger has the invoice open at £8,500.00. Your bank statement has £8,240.00. Somebody has to decide today what the difference is and who owns it, and that decision determines whether the account reads as current next month or as a ninety day problem nobody can reconstruct.

Why is leaving a partial payment unapplied the worst option?

Because unapplied cash hides both the invoice and the payment from everyone who needs to see them.

The invoice stays open at full face value, so aging carries £8,500.00 as outstanding when the true exposure is £260.00, and that number rolls into 31 to 60 days and then 61 to 90 without anyone touching it. Meanwhile the £8,240.00 sits in a suspense or on-account balance where treasury sees cash but cannot tell you whose it is. Both halves of the transaction are now wrong in opposite directions.

Collections is the second casualty. A collector opening this account sees a fully overdue invoice and chases £8,500.00 from a customer who paid twelve days ago. The customer replies with a bank confirmation, the collector apologises, and the account goes quiet for a fortnight. You have spent a contact and some credibility.

The third cost is decay. On the day the cash lands, the reason for the gap is usually recoverable in ten minutes because the delivery note is fresh. Sixty days later the same question takes an afternoon and often ends in a write-off, and the reason code that would have told you this customer short pays freight on every third order never gets created.

How do you tell which of the six causes created the gap?

Start with the arithmetic of the gap itself, because most causes leave a recognisable signature in the number.

An early settlement discount is a clean percentage of the invoice net or gross. If your terms are 2/10 net 30 and the gap is exactly two per cent, the only question left is whether the payment landed inside the window. A bank charge is a small, oddly specific amount that repeats on the same corridor, and the SWIFT MT103 tells you: field 71A carrying SHA or BEN means charges came out of the principal in transit. A short ship or price variance ties to a line, so quantity times unit price reproduces the gap exactly.

A formal deduction usually announces itself. An EDI 820 remittance carries adjustment segments with reason codes, a lockbox EDI 823 file may pass those through, and a retailer's CSV remittance normally has a reason column reading freight allowance or damaged goods. A dispute leaves no signature: the number is arbitrary, the remittance says nothing, and an email thread from three weeks ago was never linked to the invoice. A keying error shows as a transposition, a decimal shift, or an amount matching a different invoice.

Should you apply at invoice level or at line level?

Apply at invoice level by default, and move to line level when the shortfall attaches to an identifiable line that a credit will later have to reference.

Most ledgers apply cash at the invoice header, and for most partial payments that is the right resolution. If the £260.00 is a bank charge, no line caused it, and header-level application is faster and easier to reverse.

Line level earns its cost in three situations. The first is a quantity or price dispute, where the credit memo needs to name the SKU so the commercial team can see which product generates deductions. The second is anything with a tax consequence, because a credit against the wrong line produces the wrong VAT or sales tax reversal. The third is contract billing where lines carry different revenue recognition, and applying a shortfall to the header quietly distorts recognised revenue across two performance obligations.

A practical rule holds up: if you can name the line that caused the gap, apply against that line, and otherwise apply at the header with the reason code on the invoice. The failure mode is arbitrary allocation, where a collector spreads £260.00 pro rata across eleven lines because the system demanded it, leaving eleven fractional balances corresponding to nothing.

When do you raise a credit memo and when do you leave a residual?

Raise a credit memo when the shortfall is agreed and permanent, and leave a residual when you still intend to collect it.

A credit memo is a document. It closes the invoice, removes it from aging, carries a reason code, posts to a contra revenue or deduction account you can report on, and gives the customer something to file. Use it for verified short ships, agreed price corrections and approved trade allowances. The discipline that makes credits useful is the reason code: SHIP-SHORT, PRICE-VAR, FREIGHT-ALW, DMG-GOODS. Without codes you have a pile of credits and no way to tell operations which of them recur.

A residual keeps a small open item on the invoice and the collections clock running. It suits an unearned discount you plan to claw back, a deduction behind an unresolved proof of delivery, and any shortfall the customer has not justified. Being a live claim, it needs an owner, a review date and a line on the customer statement.

Two guardrails stop this degenerating. Set a de minimis write-off tolerance, say the lower of £50.00 or half a per cent of the invoice, and post anything inside it to a named account with a code so the volume stays visible. Then age residuals monthly and force a decision at ninety days: collect, credit or write off. The pattern that ruins a ledger is the rolling residual, where a two year old account carries forty open items no collector will work.

How does the aging report lie when you get this wrong?

It reports the whole invoice as overdue when only the shortfall is, and it reports genuine disputes as ordinary delinquency.

Handled properly, £8,500.00 leaves the ledger, £170.00 stays open in the current bucket, and the account reads as a good payer with a discount claim to settle. Handled by doing nothing, the full £8,500.00 ages through the buckets and by day 75 sits on the escalation list beside customers who have paid nothing. Collector time follows the largest overdue numbers, so one mishandled partial payment pulls attention from accounts that need it.

Unapplied cash breaks the report from the other side. It reduces true receivables but sits outside the aging buckets, so the aging total no longer reconciles to the AR control account without a bridging line most people stop reading. Any DSO built on that ledger overstates DSO, and any provision driven by bucket percentages over-provides against invoices paid weeks ago.

What does a worked partial payment look like end to end?

Here is the full arithmetic on a single invoice, from the bank credit to the closing balance.

Northgate Supplies Ltd is invoiced £8,500.00 on INV-10442, issued 4 August 2026, terms 2/10 net 30, due 3 September 2026. A wire for £8,240.00 arrives on 18 August with a CSV remittance emailed separately referencing INV-10442 and nothing else. The £260.00 gap turns out to be three separate things.

Two per cent of £8,500.00 is £170.00, and the discount window closed on 14 August, so the settlement discount is unearned. Delivery note DN-77310 shows four cases short at £15.00 each, which is £60.00, and the warehouse confirms the short pick. The remaining £30.00 matches the correspondent charge on the last three wires from this payer, whose MT103 messages carry SHA in field 71A.

Fifteen minutes on the day the cash lands produces a fully applied payment, an invoice balance that reflects reality, a credit memo logistics can see, and three reason codes. If DISC-UNEARNED appears against Northgate every month, that is a terms conversation rather than a collections problem, and you have the evidence to open it.

How does Monk handle this?

Monk treats cash application and the exception behind it as one workflow rather than two queues that hand off to each other.

Monk's AI cash application matches around 80% of incoming payments automatically, rising to 95% once suggested matching rules are in place. Those rules encode what your team already knows: this payer always deducts freight, this lockbox truncates invoice numbers at eight characters, this CSV puts the reference in column D. The payments left over are the ones with a real gap, and they reach a human with the invoice, the remittance, the delivery evidence and the payment history already assembled.

Monk reads the artefacts in the forms they arrive in: BAI2 and EDI 823 lockbox files, EDI 820 remittances, ACH addenda records, PDF remittance advices and the CSV an AP clerk exported by hand. When a shortfall needs a decision, the credit memo, the residual and the reason code sit against the invoice, and the collections side sees the same record, so nobody chases a balance already credited. Monk's measurement is that 39% of cash flow slowdown comes from edge cases.

Monk syncs to QuickBooks, NetSuite, Salesforce, HubSpot and Stripe. Teams running Monk report 26 hours a month saved on receivables work and a 40% average reduction in DSO. Monk is SOC 2 Type II compliant, onboarding takes less than one week, and customers see results in their first month.

Where should you start?

Run a ninety day partial payment audit this week, small enough to finish in one sitting.

Export every payment from the last ninety days where the amount applied did not equal the face value of the invoice it hit, and record the gap, the cause, the treatment and whether a reason code exists. Most teams find the same three things: a few payers behind most of the gaps, many shortfalls with no recorded cause, and tiny residuals open long enough to be worthless.

Then age your unapplied and on-account balance, and give anything older than thirty days a name and a resolution date. Write down a de minimis tolerance if you have none, agree the four or five deduction reason codes you will use, and book a monthly residual review with a hard ninety day decision point.

Once the audit shows where the volume sits, decide what to automate first. To see how matching, the exception queue and the collections view fit together on your own ledger, book a demo.

Frequently Asked Questions

What is a short pay?

A short pay is a payment for less than the invoiced amount, made deliberately by the buyer rather than by mistake. It usually carries a reason such as a freight allowance, a promotional deduction or a quantity claim, and on larger buyers that reason arrives as a code on the remittance advice. The task is to classify and clear each one rather than prevent them all.

Should I post the cash before I know the reason for the gap?

Yes. Post the cash to the invoice the day it arrives and leave the shortfall as a residual with an owner and a review date. Holding the whole payment in suspense keeps both the cash and the invoice misstated, and collections then works from a ledger saying the customer has paid nothing. Applying first and classifying second narrows the open question to the gap alone.

How do I tell an unearned discount from an agreed one?

Compare the payment value date against the discount window in your terms, and the deduction against the exact percentage those terms allow. A customer on 2/10 net 30 who pays on day fourteen and takes two per cent has taken an unearned discount, even if they have done it for years. Recording it under a consistent reason code turns a recurring irritation into a terms negotiation you can evidence.

When should a shortfall be written off automatically?

When it falls inside a documented de minimis tolerance, such as the lower of a fixed amount and a small percentage of the invoice. Automatic write-off should still post to a named account with a reason code so the monthly total stays visible, because a tolerance that hides its volume drifts upwards. Bank charges and rounding differences are the classic cases.

Does a credit memo hurt my revenue reporting?

A credit memo posts to contra revenue or a deduction account, so it reduces net revenue in the period it is raised, which is the correct outcome when the shortfall is genuine. The larger reporting problem runs the other way: shortfalls left as permanent residuals overstate receivables and defer the correction until a bad debt charge.

What does invoice-level application miss that line-level catches?

Invoice-level application records that a gap exists but not which product, service or charge caused it. Line-level application preserves the SKU, the freight line or the tax line, which is needed for quantity disputes, tax reversals and contracts where lines carry different revenue treatment. Use line level where the credit will reference the line and header level everywhere else. Arbitrary pro rata spreading across lines is worse than either.

How long should unapplied cash be allowed to sit?

A workable policy resolves most unapplied cash within five working days and holds nothing beyond thirty days without an owner, a documented reason and a target date. Age the unapplied balance the way you age receivables and review it monthly. Anything crossing sixty days goes to the account owner, because by then the customer is the only remaining source of truth.