Versapay's research found that 91% of finance technology leaders say their organization still receives checks, which is the first clue to why cash application stays slow at companies that have otherwise moved their payments to electronic methods. A finance team applying cash works from two facts that should fit together and frequently do not: a deposit landed in the bank, and somewhere there are open invoices it was meant to settle. The connection between them is the remittance advice, the document that says which invoices a payment covers and for how much. Versapay's research describes how that remittance detail is frequently decoupled from the payment itself, particularly for electronic methods such as ACH, EFT, and virtual cards. The money arrives by one route and its explanation by another, and the entire difficulty of cash application follows from that separation.
Why the work exists at all
The matching rule itself is not hard. A payment of $14,200 that exactly clears three invoices of $4,000, $6,000, and $4,200 is a problem a clerk solves in seconds, and software solves it faster. What makes the work slow is that the clerk often does not know, at the moment the cash arrives, which three invoices those are. When remittance is decoupled from payment, the analyst reconstructs the link by hand, opening the bank file, searching the customer's open ledger, checking email for a remittance attachment, and sometimes calling the customer to ask what a wire was for. Most of the labor goes into assembling the evidence rather than into running the arithmetic once that evidence is complete.
That structural cause tells you where redesign pays off. A team that buys better matching logic but still retrieves remittance from five separate channels has improved the cheap half of the process. The expensive half is the capture and standardization that has to happen before any matching rule can run.
What the redesigned workflow does step by step
The first step is capturing remittance from every channel a customer might use. Some send a PDF with the check, some email a spreadsheet, some attach nothing to an ACH and post the detail to a buyer portal a person has to log into. An agent watches all of those inputs, the lockbox image file, the shared AR inbox, the EDI 820 feed, the portals, and pulls the remittance regardless of where it landed.
The second step is extraction and standardization. A remittance might list invoice 100481, while the same invoice appears in the bank reference as PO-100481 and in the customer's portal as their own internal document number. The agent reads each format, normalizes the identifiers to the seller's invoice numbers, and produces one structured record per payment: which invoices, which amounts, which deductions claimed.
The third step is matching at the line-item level. Rather than asking only whether a payment total equals an invoice total, the agent works invoice by invoice, so it can handle a payment that covers eleven invoices in full and one in part. The recurring hard cases are partial payments, combined payments spanning several invoices, and cryptic customer references that do not align to invoice numbers. The Hackett Group's 2025 Digital World Class Matrix on cash application software found a median auto-match rate of 70% among end users, with a third exceeding 80%, figures worth reading as a description of what the mechanism clears rather than a promise of a result.
The fourth step is posting the clean majority. Where the remittance reconciles to open invoices within tolerance, the agent writes the cash application back to the receivables ledger. Many sub-ledgers expose no usable interface for this, which is its own problem we treat separately in writing back into a system with no usable API.
What stays with a person
The fifth step routes the residue. After capture, normalization, and line-item matching, what remains is the genuine exception set: a short pay where the customer remitted less than the invoice with no stated reason, a deduction claimed for a discount or a damaged shipment, a payment that matches no open invoice, an overpayment. The agent should not retry these as if they were data-handling failures, because each one is a commercial decision.
The analyst keeps those decisions. Whether a $340 freight deduction is valid, whether a short pay reflects a pricing dispute the sales team already conceded, whether an unexplained remainder should be written off or chased, these require knowledge of the customer relationship and the authority to concede revenue. At this boundary the agent presents each exception with the invoice, the remittance as received, and the prior deduction history attached, so the person decides rather than spends time gathering the file first. We draw the same division on the other side of the ledger in a redesigned collections process, where the agent reconstructs the account and a human makes the concession.
Where this sits in order-to-cash
Cash application is the closing step of the order-to-cash cycle, and its delay shows up in two places operators track. APQC's order-to-cash benchmarks measure the cycle in days from order to applied cash, and unapplied cash inflates days-sales-outstanding because a payment that has arrived but not been matched still reads as an open receivable. A redesign that shrinks the unapplied pile therefore improves a reported metric without collecting a single additional dollar, since the dollars were already in the bank. It also feeds the close: cash applied cleanly during the month is cash the controller is not reconciling at month-end, which connects this work to rebuilding the month-end close.
The counter-thesis
A reasonable objection is that the whole problem disappears at the source. If a company could compel structured remittance with every payment, mandate the EDI 820, refuse ACHs without addenda, push every customer onto a portal, there would be little to reconstruct and the matching would be trivial. That holds in principle, and it is the right thing to pursue wherever a seller has the bargaining power to set payment terms. Most sellers do not have it. The customer with the largest balance is usually the one least willing to change how it pays, and a policy that bounces a real payment for missing remittance is rarely one a CFO will sign. The redesign described here assumes the seller cannot dictate the customer's behavior, which is why it invests in capturing and normalizing whatever arrives rather than in a standard nobody can enforce. Where enforcement is genuinely available it is the cheaper fix and a seller should take it; where it is not, the decoupled remittance is the condition a team has to design around.
Common questions
- Why is cash application slow even after we moved most customers to electronic payments?
- The difficulty comes from the remittance advice, the document that says which invoices a payment covers and for how much, arriving apart from the money itself. Versapay's research describes this detail as frequently decoupled from the payment, particularly for electronic methods such as ACH, EFT, and virtual cards, and 91% of finance technology leaders say their organization still receives checks. When the explanation and the deposit travel by separate routes, an analyst has to reconstruct the link by hand, and most of the labor goes into assembling that evidence rather than running the arithmetic. So moving to electronic payments does not fix the slowness on its own if the remittance is still scattered across channels.
- Which cash application decisions does a redesigned workflow still leave to a person?
- The agent handles capture from every channel, normalization of identifiers to the seller's invoice numbers, line-item matching, and posting the clean majority back to the receivables ledger. What stays with the analyst is the genuine exception set: a short pay with no stated reason, a deduction claimed for a discount or a damaged shipment, a payment matching no open invoice, or an overpayment. Each of these is a commercial decision that requires knowledge of the customer relationship and the authority to concede revenue. The agent presents each exception with the invoice, the remittance as received, and the prior deduction history attached, so the person decides rather than gathering the file first.
- Can we just require structured remittance from every customer instead of building a matching workflow?
- Compelling structured remittance with every payment, such as mandating the EDI 820 or refusing ACHs without addenda, would make the matching trivial and is the right thing to pursue wherever a seller has the bargaining power to set payment terms. The trouble is that most sellers do not have that power, and the customer with the largest balance is usually the one least willing to change how it pays. A policy that bounces a real payment for missing remittance is rarely one a CFO will sign. Where enforcement is genuinely available it is the cheaper fix and a seller should take it, but where it is not, a team has to design around the remittance that actually arrives by capturing and normalizing it.