How to Build a Cash Application Workflow

Quick Summary

• Design the identifiers first. What a payment carries when it arrives sets the ceiling on everything downstream
• Virtual account numbers per customer solve identification permanently, and most banks offer them
• Build remittance capture around the channels your customers use, not the one you wish they used
• Matching rules run as a ladder from strongest signal to weakest, with an explicit stopping point
• Tolerances need two thresholds, an absolute amount and a percentage, or a rule built for small invoices gets applied to large ones
• Exception queues get routed by cause and owned by a named person, with an age target
• The close checklist is what stops unapplied cash becoming a permanent balance
• You're building an information system, not a data-entry job.

Start with what the payment carries

Every design decision downstream depends on how much you can tell about a payment the moment it arrives.

So the first job is improving the signal, before you choose software or write a single matching rule.

Virtual account numbers

For most teams, the biggest single win is giving each customer their own virtual bank account number, sometimes called a VBAN.

It works simply enough. Your bank issues a unique account number per customer, all feeding into your main account. When money arrives at that number, you know who sent it before you've looked at anything else.

That doesn't tell you which invoices they're paying, so it isn't a complete answer. It does remove the "who is this from" problem permanently, and that's a fair share of your exceptions. That's especially valuable when customers pay through parent entities or subsidiaries whose names don't match your records.

Ask your bank what they offer. It varies, and the pricing is usually modest against the analyst time you'll save.

References that survive the trip

Bank reference fields are short and get truncated without telling anyone. A reference that works in your system can arrive unusable.

Keep what you ask customers to quote short and stable. An invoice number alone beats "Invoice 4471 for Acme Corp professional services March." Put it on the invoice in the same place every time, and use the label your customer's AP system uses.

Make the easy path the paid path

Every payment method you offer has a different match rate. The best ones are where the customer tells you what they're paying at the moment they pay.

A payment link or portal captures the invoice reference automatically, because the customer picks the invoice and then pays it. Payment orchestration is the wider version of this decision. There's nothing to match afterward.

Pushing volume toward those channels is a cash application decision as much as a payments one. It's usually cheaper too. AFP's survey puts the median cost of an ACH payment at 26 to 50 cents, against $2.01 to $4 for issuing a check.

For a view of the tooling that manages payment mix, see our roundup of payment orchestration software.

Design remittance capture around how customers behave

The temptation is to design one remittance channel and ask everyone to use it. That fails, because your largest customers won't change their process for you.

Build for the channels your customers use:

• A dedicated remittance email address, parsed automatically, for the majority who email a PDF or a spreadsheet
• EDI 820 consumption, for the large customers who can send it
• Scheduled portal pulls, for customers who post remittance to Coupa, Ariba, or their own system
• Bank file remittance, from a BAI2 or ISO 20022 feed, wherever your bank can carry it
• An ask-the-customer path, for everything that arrives with nothing attached

That last channel is the one teams skip, and it needs designing like the others. Decide who asks, how quickly, and in what tone. A same-day request attached to a thank-you gets answered. A generic chaser three weeks later often doesn't.

For customers who mandate a portal, getting the invoice in correctly is upstream of all of this. Our guide to submitting invoices through the Coupa supplier portal covers that end.

Write the matching rules as a ladder

Your matching logic should be an explicit, ordered sequence, whether it lives in software or in an analyst's head. Ordered means the strongest signal gets tried first, and a match found at a high rung never gets overridden by a lower one.

A workable default order:

• Payment carries a valid open invoice reference
• A parsed remittance file specifies the invoices
• Amount exactly equals one open invoice for that customer
• Amount exactly equals a combination of open invoices for that customer
• Amount equals an invoice plus or minus a known fee, credit, or discount
• Everything else routes to exceptions

The important design decision is where step 6 starts. Some tools will keep guessing well past this point, scoring probabilities and applying the best one. That's the setting to look at closely on any system you evaluate, because it's where silent errors come from.

Setting tolerances properly

A tolerance is the difference your system absorbs without asking anyone. Two numbers work better than one:

• An absolute cap, which might be $25, covering bank charges and rounding
• A percentage cap, which might be 0.5%, so the absolute cap can't be applied to a very large invoice

Both have to pass. A $25 difference on a $600 invoice clears. The same $25 on a $200 invoice doesn't, because 12.5% is a deduction rather than a rounding difference.

Whatever the tolerance absorbs goes to a variance account, and somebody reviews that account quarterly. A tolerance nobody reviews is a slow, invisible write-off.

Rules for the payment types that never match cleanly

Some payment types will fail an exact-amount rule every time, and each needs a standing rule rather than daily handling:

• Card payments arrive net of processing fees
• Cross-border payments arrive net of correspondent bank charges and FX movement
• Customers on early-payment discount terms pay a fixed percentage less
• Customers who net credit notes pay the invoice minus a credit you issued

Handle each one with a rule, and you'll watch the pointless exceptions drop off noticeably.

Route exceptions by cause and give them owners

An exception queue sorted only by date and amount clears slowly, because different exceptions need completely different work.

Route by cause instead:

Two rules make this work.

Every queue has a named owner. A queue owned by "the team" is owned by nobody, and it's the one that grows.

Every queue has an age target, and the age gets reported. Report the age of the oldest item in it, not the number of items sitting there. A queue of forty items where the oldest is three days old is healthy. A queue of eight where the oldest is from last quarter isn't.

Build the deduction track separately

Short payments shouldn't sit in the same queue as unmatched payments, because the work is different and the skills are different.

The track needs four pieces:

• A reason code list that reflects your actual business, kept short enough that people use it accurately
• A validity decision owner, usually someone who can approve a write-off up to a threshold without escalating
• A documentation standard, so an invalid deduction gets challenged with the proof of delivery or the price list attached
• A recovery path, naming who files the claim with the customer and who follows it up

Set a threshold, and anything under it gets written off without investigation. Chasing a $40 unauthorized deduction costs more in analyst time than it recovers, and it irritates a customer over nothing.

For tooling in this area, see our roundup of dispute management software.

Segment where effort is worth spending

Not every account justifies the same handling, and what matters here is different from what collections look at.

Worth segmenting on:

• Payment volume, since a customer sending 200 payments a month justifies solving their remittance format properly
• Exception rate, because a customer generating exceptions on most payments is a fixable problem, whatever their size
• Payment method, as card and cross-border payers need standing rules
• Deduction behavior, since a customer who routinely short-pays needs a different relationship from one who doesn't
• Portal and EDI capability, which tells you where automation is available and unused

The highest-return segment is usually high volume combined with high exception rate. That's a small number of customers generating a large share of your manual work, and each one is a single conversation away from being fixed.

The close checklist

Cash application shows up in the close, and a short standing checklist keeps it from becoming a scramble:

• Every payment received in the period is either applied or explicitly sitting in unapplied with a reason
• The unapplied balance is aged, with anything over your threshold explained
• Bank deposits tie to cash applied plus unapplied
• The tolerance and variance accounts have been reviewed
• Open deductions are coded and aged, with a validity decision made on anything past its target
• The AR subledger agrees with the general ledger control account

The unapplied balance is the one to watch over time. A number that grows every month means your matching isn't keeping up with your volume, whatever the daily queue looks like.

Build it once, run it every day

Designing this is a few days of work. Running it by hand is forever.

Lunos runs the workflow you design. It pulls bank and payment data, parses remittance from your inbox, and applies your matching hierarchy. It asks payers about anything ambiguous, then posts clean entries back to your ERP.

Book a demo to see it configured against your own payment mix.