Applying Cash: Essential Facts and why it’s so Important

A payment can land in your bank account and still do nothing for your business. Until someone works out which customer sent it and which invoices it covers, that money sits in a suspense account, the invoices stay open, and the customer looks overdue on a balance they’ve already paid. If you multiply that by a few thousand payments a month? You have a problem that most accounts receivable teams have to deal with.

Cash application is the magic step that just closes that gap. It rarely gets attention at board level, and it almost never gets investment until it breaks. But it decides how fast cash becomes usable, how accurate your DSO figure is, and whether your credit team spends its week chasing customers who don’t actually owe anything.

Cash application is matching incoming customer payments to the correct customer account and the correct open invoices. Then post that result to the ERP, so accounts receivable reflects reality.

In practice it involves four things:

When all four steps happen cleanly? The payment is applied the same day it arrives. When any one of them breaks, the item becomes an exception. Exceptions are where the hours go.

It sits directly on the cash conversion cycle. Cash that has arrived but hasn’t been applied is invisible to everyone who needs to act on it, so the effects spread well beyond the AR team.

Your DSO is wrong until the cash is applied. Payments received but unallocated still show as receivables. Finance leaders then make decisions on a receivables number that overstates what’s actually outstanding.

Credit holds trigger on customers who have paid. An unapplied payment leaves the invoice open, the account over its limit, and the order blocked. Sales gets the call, not finance.

Collectors chase the wrong accounts. Time spent following up on paid invoices is time not spent on genuinely overdue balances, and it damages the customer relationship in the process.

Disputes get worse with age. Short pays and deductions buried in unapplied cash aren’t investigated while the paperwork is still fresh. By the time anyone looks, the reason code is a guess and the money is written off.

Month-end close waits on it. If you have unapplied cash sitting in suspense, it has to be cleared or explained before the books close. This pushes work into the exact week that the team has least capacity.

The process looks simple on paper. The difficulty comes from the fact that almost nothing about incoming payments is standardised.

Remittance data arrives separately from the money, or not at all. Electronic payments frequently carry no remittance information. The detail turns up in an email, a PDF, a spreadsheet, or a customer portal that someone has to log into and download. Exide Technologies described exactly this before automating: electronic payments with no remittance data, and significant time spent gathering the information from elsewhere.

Every bank and country has a different format. Portwest was running 19 bank accounts across 5 divisions with no standard format between countries or banks. Statements were downloaded by hand, run through macros to identify payers, then keyed into the ERP. Formica hit the same wall across Europe with 56 bank accounts and disparate processes in every region.

Customers don’t pay by invoice. They pay in lump sums covering dozens of invoices, take unearned discounts, deduct for freight or damages, and reference their own purchase order numbers rather than yours. Each of those turns a one-to-one match into a judgement call.

Volume multiplies everything. Portwest was processing around 16,000 payments a month. At that scale, a process that takes three hours per remittance simply cannot be completed in a working day, and the backlog compounds.

The result is predictable. Portwest’s manual cash allocation was consuming roughly 30 hours of work per day, with more than 2,000 unallocated items sitting across Europe and Latin America at any given moment.

The benchmark that matters is the auto-match rate: the percentage of incoming payments applied to invoices with no human involvement. A high rate means the team only touches genuine exceptions.

Real figures from finance teams that automated the process:

The pattern across all of them is the same. The volume didn’t drop. The manual handling did.

Most teams don’t need a bigger AR department. They need fewer items reaching a person in the first place.

Measure your current auto-match rate before anything else. Do you know what percentage of payments apply without a human touching them? If not, then you can’t tell whether the problem is remittance capture, matching logic or ERP posting.

Bring remittance data in automatically, in whatever format it arrives. Bank files, lockbox images, EDI files, emailed PDFs, Excel attachments, and customer portals all need to feed the same process. OCR handles the image-based ones. The goal is that nobody should be retyping remittance detail.

Standardise across every bank and entity. One process for all accounts beats a bespoke method per bank. It also means an acquisition or a new region doesn’t create a new workflow to maintain.

Handle deductions inside the same process. Creating deductions with reason codes directly from remittance data keeps short pays moving toward resolution instead of parking them in unapplied cash.

Automate the ERP posting, not just the matching. A match that still requires manual entry into the ERP has only moved the work, not removed it.

Put the recovered time into exceptions and collections. The real return isn’t the hours saved. It’s what a trained AR person does with those hours once they’re not keying in payments.

What’s the difference between cash application and bank reconciliation?
Cash application – customer payments are matched to open invoices in AR. Bank reconciliation – bank statement transactions are matched to entries in the GL. Both processes use much of the same source data, which is why teams often automate both together (using tools like Cashbook).

What is unapplied cash?
This is where money received into the bank has not been matched to a customer or invoice. It sits in a suspense or on-account balance. It overstates receivables and has to be cleared before month-end close.

How high can an auto-match rate realistically go?
It depends on payment mix and remittance quality, but teams with clean bank integration and automated remittance capture regularly run between 90% and 97% customer identification, with invoice-level automation in a similar range where remittance detail is available.

Does automation replace the AR team?
It changes what they do. MTD Products automated 80% of its deductions allocation and moved from eight people to six, while increasing repaid deductions by more than 40%. The remaining team works exceptions and recovery rather than data entry.

Applying cash is a small step with disproportionate influence. It determines when revenue becomes available cash, whether your receivables figure can be trusted, and whether your credit and collections teams are working real problems or phantom ones.

The teams that have fixed it didn’t do it by hiring. They removed the manual handling from payment identification, remittance capture, invoice matching, and ERP posting, and kept people for the exceptions that genuinely need judgement.

If unapplied cash, manual allocation, or a slow month-end close sounds familiar, it’s worth seeing what a high auto-match rate looks like against your own bank files. Request a Cashbook demo to see how teams like Portwest, Exide, and Formica automated their cash application process.