Cash application process and best practices for AR teams

The cash application process is how an AR team turns incoming payments into closed receivables. It takes each payment, matches it to the open invoices it pays, codes any difference, and posts the result to the ledger. Done well, it keeps the aging report honest and DSO accurate. Done badly, it leaves cash sitting unapplied and collectors chasing invoices customers already paid.

This guide walks through the standard workflow, explains why unapplied cash piles up, and gives the practices that move more payments through without a person touching them.

What is cash application in AR

Cash application is the step that matches an incoming customer payment to the specific open invoices it clears. Every payment has two parts: the funds, and the remittance that explains what the funds are for. The job is to line those up against the open receivables, mark the right invoices paid, and post the cash.

Until that happens, the invoices still show as open. The aging report is wrong, DSO is overstated, and the cash is in the bank but invisible on the ledger. Cash application sits at the end of the order-to-cash cycle, so any error there ripples backward into collections and reporting.

The standard cash application workflow

Most teams run some version of these six steps:

1. Receive the payment. Funds arrive by ACH, wire, check, card, or lockbox. The deposit shows on the bank statement.
2. Gather the remittance. The detail explaining the payment arrives as an email, a portal upload, an EDI 820, or a lockbox file. Often it comes separately from the funds.
3. Identify the customer. Tie the payment to a customer account, sometimes from the bank reference alone, sometimes from the remittance.
4. Match to open invoices. Work through invoice numbers first, then PO numbers, then amounts, then payment history, narrowing the payment to the invoices it most likely clears.
5. Resolve differences. Code short pays, deductions, and overpayments. Route disputes to the right owner.
6. Post and reconcile. Mark the invoices paid, post the cash to the ledger, and confirm the applied total ties to the bank deposit.

The clean case takes seconds. A customer pays one invoice in full, references the invoice number, and the amount matches. The headache is everything else.

Why unapplied cash piles up

Unapplied cash is money in the bank that the system cannot tie to specific invoices. It builds up for a few predictable reasons:

• Remittance arrives separately, late, or never. The funds land Monday and the email listing what they cover arrives Thursday, so the payment waits.
• One payment covers many invoices. A single ACH clears a dozen invoices, and if the total does not tie out cleanly, the whole batch stalls.
• Identifiers do not match. The remittance lists the customer's PO numbers instead of your invoice numbers, so the matching engine cannot find the link.
• Amounts do not reconcile. A short pay or deduction buried in a batch means the payment does not equal the invoice total, so it gets parked.

Parked cash is expensive. It overstates DSO, triggers dunning to customers who already paid, and forces a manual scramble at month-end. The longer a payment sits unapplied, the harder it is to reconstruct what it was for.

Best practices for faster, cleaner matching

A few habits move the bulk of payments through automatically.

Standardize remittance capture. Push customers toward consistent formats and a single channel where you can. The more predictable the remittance, the more the matching engine can read intent instead of guessing it.

Match on a hierarchy, not just invoice number. Configure matching to fall back from invoice number to PO number to amount to customer history. Most payments that "cannot be matched" actually can, on a secondary identifier.

Pair late remittance with parked funds automatically. Hold unapplied deposits in a way that lets new remittance attach to them when it arrives, rather than starting the search over each time.

Set tolerances for small differences. Decide in advance how to treat a few dollars of variance, so trivial rounding or fee differences do not block an otherwise clean match.

Work exceptions daily, not at month-end. Unapplied cash compounds. A short daily pass keeps the queue small and the trail fresh while customers still remember the payment.

For the deeper mechanics of how matching, short pays, and remittance interact, see what is cash application.

Handling remittance and short-pay exceptions

Exceptions are where the time goes, so handle them with a clear rule per pattern.

For a short pay, decide fast whether it is an approved discount, a partial payment against the full balance, or an unexplained gap. Code the reason, keep the invoice open for the remainder, and let collections keep working the balance.

For a deduction, code it to the right reason: pricing dispute, damaged goods, a promotional allowance. Route valid ones for credit and invalid ones for recovery so they do not sit and age. Tight deduction coding feeds straight into a clean payment reconciliation at period end.

For separated remittance, hold the funds as cash on account and attach the detail the moment it arrives, rather than forcing the customer to be re-contacted.

Measuring cash application performance

Track three things and you will know how the process is really running.

• Straight-through (auto-match) rate. The share of payments matched and posted with no human touch. This is the headline number.
• Unapplied cash balance and age. How much money is parked and how long it has been parked. Falling balances mean the exception queue is under control.
• Time to apply. How long from funds landing to invoices marked paid. Shorter means DSO reflects reality sooner.

A worked example: if you receive 1,000 payments a month and 600 apply automatically, your auto-match rate is 60 percent and 400 payments need hands. Push the rate to 90 percent and you cut the manual queue from 400 to 100, a 75 percent reduction in touch work without adding people.

How Rex runs cash application end to end

Most cash application stays manual because the exceptions resist rules. Rex closes that gap by reasoning through each payment the way an experienced analyst would, continuously across the whole ledger. It reads remittance from any format, pairs a remittance email with a batch payment that arrived days earlier, splits a lump sum across invoices, codes the short pay or deduction, and posts the result. The clean payments never needed a person, and now most of the messy ones do not either.

What Rex does not resolve on its own, it escalates with the context already gathered, so an operator decides instead of investigating from scratch. The unapplied cash queue shrinks, DSO reflects what customers actually owe, and the team stops keying in matches.

See how Rex keeps cash application running so your aging report tells the truth.