Cash Application

Cash application is the process of matching a customer's payment to the specific invoice or invoices it is meant to pay, so accounts receivable shows what the customer actually still owes rather than what was billed. A customer pays $14,200. The cash application process has to answer which open invoices that $14,200 covers, and the answer isn't always obvious, because the payment and the remittance advice explaining it rarely travel together.

That gap is the entire job. A deposit lands in the bank with a reference number that means nothing on its own. The remittance advice, the document or data that says which invoices the payment covers, might arrive by email as a PDF, sit in a spreadsheet, live inside a customer's own payment portal, or never arrive at all. Cash application is the work of reconstructing that link: pulling the deposit detail, finding whatever remittance exists, and applying the payment against the correct open invoice or invoices in the subledger.

How the cash application process actually matches a payment

A clean payment, full amount, one invoice, a clear reference number, applies itself in seconds. Most of the cash application workload isn't that case. The harder matches that actually eat a week:

• One payment, many invoices. A single ACH deposit covering eleven open invoices, with no obvious way to split it until the remittance is found and read.
• No remittance at all. A check or wire with a reference number that doesn't map to anything, where the only path is matching on amount, customer history, and which combination of open invoices adds up.
• A payment processor in the middle. An invoice sent through one system paid through another, so the deposit that lands in the bank has already been stripped of the context that would make it obvious.
• A short pay. The customer sends less than the invoice says, because of a dispute, a deduction, or a pricing disagreement, and the gap has to be named and routed rather than silently absorbed.

Cash application software that only handles the clean, fully remitted payment is handling the easy half. The harder half, the one-to-many match, the missing remittance, the short pay, is where the actual hours go, and it's also where most of what gets marketed as "cash application" quietly stops.

Unapplied cash: what cash application can't resolve

Whatever a payment can't be matched to becomes unapplied cash (glossary entry planned), a credit sitting in accounts receivable with no invoice attached to it. Unapplied cash isn't a failure state. It's the honest output of a cash application process that refuses to guess: a payment either matches with enough confidence to apply, or it waits as a named, visible exception until someone with more context resolves it.

The risk is what happens to unapplied cash that doesn't get named clearly. Treated loosely, it behaves like a suspense account: a parking spot that grows quietly because nobody owns clearing it. The fix is the same discipline that applies to any reconciling item: age it, name an owner, and treat anything open for more than a cycle or two as a problem rather than a line item.

Why cash application and the accounts receivable aging have to agree

Cash application output feeds directly into the accounts receivable aging, and the two have to tell the same story. A payment applied in the subledger but not reflected in the aging, or unapplied cash sitting as a credit nobody can see from the aging report, is one of the most common reasons an aging doesn't tie to the general ledger control account at close. Clean cash application isn't just a collections convenience. It's a precondition for an aging a reviewer can actually trust.

Cash application vs. collections

The two get bundled under "accounts receivable automation" constantly, and they're different jobs. Cash application decides what a customer has already paid and against what. Collections decides what to do about what a customer hasn't paid yet, chasing, reminding, escalating. Getting cash application right first matters because collections built on a wrong or stale aging chases customers for invoices they already paid, which is a fast way to make a collections process look worse than it is.

What most cash application software actually does

Matching a clean, fully remitted payment to a single invoice is a solved problem, and most AR platforms and most cash application software do it well. That part of cash application is commoditized: the rules-based match on amount and invoice number is table stakes, not a differentiator, across nearly every tool on the market.

What separates tools is what happens to the payment that doesn't match cleanly. A one-to-many payment with no remittance, a short pay with no stated reason, a deposit that arrived through a bank portal with no API and no export: the software that stops at "unapplied, needs review" has handed back the exact hours a controller was trying to remove. The decision layer, reasoning through the ambiguous case rather than just flagging it, is where cash application tools still mostly leave the work to a person.

Related terms: Accounts Receivable Aging, Suspense Account, Reconciling Item, Bank Reconciliation

Related skill: Cash Application

Go deeper: Accounts Receivable Automation

Pulling deposit detail from a bank portal, finding the remittance wherever it landed, and matching it against open invoices is exactly the kind of cash application work that scales with payment volume, not with judgment, until it doesn't. Adopt's agents apply cash the same way: pull the deposit, find the remittance in whatever format it arrived, match against open invoices on amount, reference, and customer history, and name what can't be matched instead of guessing it into the ledger. Nothing reaches a customer, and nothing posts, without a reviewer's sign-off. Sign up free.