How to Reduce Time Spent on Cash Application

You reduce the time spent on cash application by removing the searching rather than by matching faster: route every remittance advice to one address, ask your bank for a file that carries payment detail instead of a summary, fix the invoice number so it survives being retyped, and give payment matching a fixed order of rules so nobody decides from scratch which invoice a payment belongs to. Monk runs this as one invoice-to-cash system, so remittance capture, payment matching, posting and collections work from a single accounts receivable record. Teams losing days a month here are rarely slow at matching. They are slow at finding the remittance that makes matching possible, which is a cheaper problem to fix.

The situation is usually recognisable. One person opens the bank portal on Tuesday morning, downloads yesterday's credits, then spends two hours in a shared inbox and four buyer portals looking for the advices that explain them. By the time each advice is found, opened, read and rekeyed, the posting takes seconds. This guide walks the day in order and gives the fixes in the order a team can apply them. For the underlying process, see what cash application is.

Where do the hours go in a manual cash application and remittance process?

Almost all of the time goes into finding and reading remittance, and almost none into the posting itself.

Walk a normal day in order. It opens with pulling the bank file or the lockbox report, which means logging into every account that receives customer money: the operating account, the lockbox, the merchant settlement account and any foreign currency account, each with its own login, export format and idea of what yesterday means.

Then the hunt. Remittance for those credits sits in the shared inbox, in individual mailboxes because a customer replied to whoever chased them last, inside Coupa or Ariba where the buyer posted a payment schedule, and in the lockbox file as a scanned stub. Some arrived days before the money, some arrives days after, some never arrives.

Reading is the next block. An advice comes as a PDF with a table in it, and the person opens it, reads twenty invoice lines and types them into the ledger. Rekeying is where transposition errors enter, and the ledger search follows, one invoice number at a time, with extra guesswork whenever the customer quoted a purchase order. The judgment calls come last: splitting a lump sum across invoices that add up, and classifying a short pay as a deduction, a dispute or a keying error. Posting is quick. Then the residue, everything that did not match, which is where the afternoon goes.

How long should cash application take from bank file to posted invoice?

Every payment that lands on Monday should be posted on Monday, and the effort behind that should be a slice of one morning rather than a whole one.

Two clocks matter and teams often track neither. The elapsed clock runs from bank value date to the moment the invoice shows as paid, and it is the number collections feels, because anything unposted looks overdue and gets chased. The effort clock counts person hours a week, and it is the number the controller feels. A team can post same day while burning most of a person on it.

The healthy shape is a large first pass that clears the bulk of the day's receipts without a human decision, followed by a short worked queue of real exceptions. A small first pass points upstream, to capture and identifiers, and a queue that never empties points at ownership. Batching receipts into a weekly posting run is the most expensive habit here, because it hides the aging report from the people using it.

Which upstream fixes cost nothing and remove the most hours?

The cheapest hours to recover are the ones spent looking for remittance a customer would happily have sent somewhere findable.

None of the changes below need budget, procurement or a project plan. They change where information arrives and what it looks like when it does, which is where the manual effort is created.

Publish one remittance address. Create a single monitored mailbox such as remittance@yourcompany.com, put it on the invoice template, in the payment instructions and in the signature of everyone in credit control, and forward the mailboxes remittance lands in today. One address means one search, and it survives the AR clerk leaving.

Fix the invoice number format. Use a short fixed-length number with no characters that get confused when retyped, keep it identical on the PDF, the portal submission and the statement, and never let a credit note share a series with an invoice. A number that survives rekeying removes a lookup from every payment that quotes it.

Ask large payers for a file. Email the accounts payable contact at each high volume customer and ask for a remittance file in a consistent layout, a CSV or an EDI 820, sent to the remittance address on the day they release the payment run. Large payers usually have this available and have never been asked.

Ask customers to quote invoices. Add a line to the invoice and the payment terms asking the payer to put the invoice number in the payment reference field, and repeat the request to the AP contact of any customer who sends a purchase order number instead. A PO can cover many invoices, so it turns a match into an investigation.

Map payer names to customer accounts. Build a table of the payer names your bank shows, including trading names, subsidiaries and the truncated versions the rail produces, and hold it beside the customer master. Many unidentifiable wires are a known customer paying under a name nobody has recorded.

What should you ask your bank for?

Ask the bank for structured detail rather than a statement, because a summary line forces a search a data file answers.

Bank format changes take a few weeks and a conversation with your relationship manager, and they remove more manual reading than anything else here. Name the format you want when you ask.

Request BAI2 or EDI 820 files. Ask your bank for a structured daily file rather than a PDF statement or a CSV of totals, and confirm it carries the payment reference and addenda fields in full. A structured file reads straight into a matching routine, which removes the rekeying step.

Turn on lockbox remittance imaging. Ask your lockbox provider to capture and transmit the image of the remittance stub alongside the payment record, with data capture of the invoice numbers where the service offers it. A lockbox that reports amounts and dates but not the paper leaves the hardest half of the job on your desk.

Ask for full ACH addenda pass-through. Confirm with the bank that addenda records arrive complete rather than stripped or shortened, and ask corporate customers to use the CTX format, which carries invoice level detail inside the payment itself. Addenda that survive the journey turn an unidentified credit into a match with no human involvement.

Reduce the number of receiving accounts. Count the accounts customer money can land in, close or repurpose the ones that exist for historical reasons, and set each remaining feed to arrive before the daily posting run. Fewer accounts means fewer logins and one predictable start time.

What matching order removes the most manual searching?

Match on the strongest identifier available, then fall back in a fixed sequence, and write that sequence down so every person and every rule applies it the same way.

Most manual searching happens because there is no agreed order, so each payment gets whatever approach the person thinks of first. A written cascade turns matching into a decision tree that can be delegated, measured and later automated. The mechanics of reading an advice against open items sit in the guide to remittance matching.

Match on the payment reference first. Take the reference, addenda or advice line, extract anything shaped like an invoice number, and test it against open items before any other rule runs. It is the only identifier the customer has given you, so it wins whenever it is valid.

Match exact amount to one invoice. Where no usable reference exists, look for a single open invoice for that customer whose value equals the payment, inside the value date window the terms make plausible. An exact amount against one open item is a safe match and clears most small, regular payers.

Test combinations that sum exactly. For a lump sum, search for the set of open invoices that adds up to the amount received, preferring the oldest consistent set. When two combinations both fit, the payment belongs in the exception queue rather than being guessed at.

Fall back to customer and age. If no invoice level match survives, identify the payer from the bank name, the account details and the alias table, then present that customer's open items by age for a person to allocate. Identifying the customer is most of the work, and it turns a mystery into a two minute decision.

Set tolerances for rounding and currency. Agree a small fixed tolerance for rounding differences and a separate treatment for foreign exchange variance and bank charges, record both in writing, and let anything inside them clear to the agreed difference account. Tolerances held in one person's head give different answers on different days.

Allocating one payment across many invoices has its own rules, set out in the guide to applying a lump sum across multiple invoices.

How should the exception queue be sized and time-boxed?

Treat the exceptions as a queue with a size, an owner and a closing time, rather than a pile that grows quietly at the bottom of a spreadsheet.

The exception queue is where the remaining hours live once capture and matching are fixed, and it behaves badly when invisible. Sizing it turns an unbounded worry into a workload you can staff, and time-boxing stops one wire absorbing an afternoon.

Size the queue before working it. Each morning, count the unmatched items, total their value and group them by reason: no remittance, remittance with no invoice match, short pay, overpayment, unknown payer. The grouping says whether today is a capture problem or a matching problem before anyone opens a case.

Time-box the queue to one sitting. Give the queue a fixed daily window, work the highest value items first, and stop when the window closes rather than when the queue empties. Anything unresolved carries a note saying what was already tried, so the next attempt does not repeat the same search.

Escalate large unknowns to an owner. Set a value above which an unidentified receipt goes the same day to the account owner in sales or customer success, carrying the payer name, amount, value date and a deadline. Whoever knows the customer identifies a payer faster than whoever knows the ledger.

Leave small residuals to a sweep. Hold low value unmatched amounts and rounding residuals in a named unapplied cash account, and clear them in a weekly or monthly sweep under a written write-off policy. Working every small residual the day it appears costs more attention than the amounts justify.

Two exception types are common enough to have their own procedures: a wire with no remittance information and a partial payment against a single invoice.

How do you measure whether the changes saved time?

Measure four numbers weekly, record them before you change anything, and compare like weeks rather than impressions.

Improvements here are easy to feel and hard to prove, which is how good changes get reversed and bad ones survive. Take a baseline for a fortnight before touching anything, and write the definitions down, since a metric that quietly shifts meaning is worse than none.

Read the four together. A first pass rate climbing while the unapplied balance climbs too usually means the easy payments are automated and the hard ones abandoned, and hours falling while days to post rise means the work is deferred rather than removed.

What stays manual even after all of it?

A residue always remains, and planning for it beats hoping it disappears.

Some customers will keep paying by check with no stub, or by wire with a reference field their treasury system fills with an internal batch code. Others pay from a shared services centre abroad that nets several subsidiaries into one transfer against invoices raised on different entities. Deductions are the other durable category, since a short pay for a damaged delivery or a disputed rate is a commercial question finance cannot close without the sales owner.

Judgement is the honest boundary. Automation reads a document, applies a rule and does arithmetic across open items, and it does not decide whether a customer was entitled to keep what they withheld. Shrink the manual set to items needing a human decision, then staff it deliberately, with a named owner, a working window and an escalation path. A dozen real decisions a day is a manageable job. Two hundred unidentified credits is not.

How does Monk handle this?

Monk runs cash application as part of one invoice-to-cash system, so remittance capture, matching, posting and the collections that follow read from the same accounts receivable record rather than four disconnected tools.

Remittance is ingested from bank files, the AR inbox and buyer portals, including PDF advices and scanned lockbox images, which removes the search and the rekeying that consume most of a manual morning. AI cash application matches 80% of payments automatically, rising to 95% with suggested matching rules, and the rest arrives as a queue with the payer, amount, value date and the reason the match failed attached. Teams save 26 hours a month on receivables work.

Edge cases are treated as the main event rather than an afterthought, since 39% of cash flow slowdown is caused by them. Monk integrates with QuickBooks, NetSuite, Salesforce, HubSpot and Stripe, so posting writes back to the ledger and the aging report stays accurate, and it is SOC 2 Type II compliant with more than $2B in accounts receivable under management. Onboarding takes less than one week. Alaskan Salmon, a variable-weight seafood wholesaler, went live in under a week.

Where should you start?

Spend one week measuring before you change anything, because the fix you need is usually visible after two days of logging.

Ask whoever does the work to keep a log for five days with four columns: the payment, whether remittance was available when it was looked at, where that remittance came from, and roughly how many minutes it took. Sort the log by minutes at the end of the week. If the long items cluster on missing remittance, start with the single remittance address and the request to your largest payers. If they cluster on remittance that arrived but did not match, start with the invoice number format and the written matching cascade. If they cluster on short pays, the time belongs to a deductions process with a named owner.

Run the log again a month after the changes and compare the two sorted lists. To see how Monk captures remittance and posts the matches against your own bank file and ledger, book a demo.

Frequently asked questions

How long should cash application take from payment to posted invoice?

Payments that land on a given business day should be posted that same day, and the effort behind that should be a slice of one morning rather than the whole of it. Track two clocks: elapsed days from bank value date to posted invoice, and person hours a week. A team can post same day while spending most of a person on it, which is a different failure from posting weekly with little effort, so both numbers need to fall before the process has improved.

How much time can you remove without buying software?

A large share of it, because most manual hours go into finding remittance rather than into matching or posting. Publishing one remittance address, fixing the invoice number format so it survives being retyped, asking your largest payers for a consistent remittance file, and recording the payer names your bank shows each remove searching from every payment they touch, and none of those need budget. What they will not fix is deductions and disputes, which need a commercial decision.

Why does remittance arrive after the payment?

Because the payment and the advice travel on separate rails and are usually produced by separate systems. The buyer's treasury releases the payment run through the bank, while the advice comes from the accounts payable system and is emailed or posted to a supplier portal. Nothing synchronizes the two, so an advice can arrive days before or after the money. Asking large payers to send the file to one address on the day they release the run closes most of the gap.

Should you match on the purchase order number if that is all the customer sends?

Use it as a starting point rather than as a match. A purchase order often covers several invoices, so a PO reference names the customer and the contract without saying which open items the payment settles. Narrow it by testing the amount against the open invoices under that PO, and if more than one combination fits, send it to the exception queue instead of guessing.

What is a good first pass match rate?

Your own baseline is the useful benchmark, because the rate depends on how your customers pay and how many send structured remittance. Measure it two ways, matched items as a share of items received and matched value as a share of value received, since a few large payers can flatter one and not the other. Record it weekly for a month before changing anything, then watch the direction of travel.

How big should the exception queue be?

Small enough to be cleared inside a fixed daily window by the person who owns it. Size it each morning by counting unmatched items, totalling their value and grouping them by reason: no remittance, remittance with no invoice match, short pay, overpayment, unknown payer. If the queue cannot be worked inside its window on most days, fix the upstream cause behind the largest group rather than adding hours.

What is the single fastest change to make this week?

Route every remittance advice to one monitored mailbox and forward the addresses it currently arrives at. It takes an afternoon, needs no approval beyond your own team, and removes the repeated search across personal inboxes that sits in front of nearly every payment. Put that address on the invoice template and in the signature of everyone in credit control so it survives the person who set it up.