I get asked for our auto-match rate on most sales calls, and so does everyone else in this category. It is the most quoted number in cash application software. It is also the one I would trust least on a comparison grid, including ours, unless somebody says what it counts.
So here is the honest answer to what a good rate looks like. I cannot give you a market benchmark, because I have not seen a dataset that would support one, and I am sceptical of anyone who quotes you one. Two vendors can report 85% and 92% while counting different populations of payments against open invoices, treating different events as a match, and stopping at different points in the process. The gap between those two figures tells you nothing until you know what sits underneath each.
I work at Monk and we quote a rate of our own, so I will put ours in here with what it counts.
What population is the rate measured against?
Ask a vendor what the denominator is and you will get one of about four answers.
Some measure against every payment received in the period. That is the hardest version and the closest to what a finance team experiences on a Monday.
Some measure only against payments that arrived with remittance information, which removes the receipts that are hardest to match in the first place.
Some exclude payments under a value threshold, on the grounds that a $40 receipt is noise. Small receipts are usually the ones with no reference attached, and somebody still has to clear them.
And some measure only against customers who have been fully configured in the system, which makes the rate a statement about the configured accounts rather than about your ledger.
The arithmetic is worth doing. Take a book where 60% of receipts arrive with usable remittance data: a vendor matching 90% of those can report 90% and be telling the truth, while the same software on the same book produces 54% measured against every receipt.
What counts as a match?
Identifying which customer sent a payment is real work, and on a large book with similar company names it can be the hard part. It does not finish the job. A $47,000 wire identified as coming from Acme, but not allocated across the four invoices it covers, still sits in a queue until someone opens the account and decides. Some vendors count that as matched. Others count it only once the cash is posted against specific invoice numbers, which is the version that clears the aging report.
Partial payments divide the field the same way. When a customer pays $10,000 against a $12,000 invoice, one product marks the invoice matched and leaves a $2,000 residual open. Another holds the payment as an exception until the residual is coded as a short pay, a deduction or an approved credit. The first reports a higher rate, the second leaves you with a cleaner ledger, and both are describing identical performance.
There is also the question of who pressed the button. Plenty of systems propose a match with a confidence score and wait for a person to accept it. That saves real time and I would not talk anyone out of buying it. Counting those accepted suggestions inside a rate labelled automatic makes a supervised process look unsupervised, and a buyer who reads the higher number as nobody-touched-it has budgeted for the wrong headcount.
First pass, or after the queue is worked?
A first-pass rate tells you what happens when the bank file lands: how much posts on its own, and how much arrives on a specialist’s desk. A rate measured after the exception queue has been worked, rules rerun and month-end closed will always be higher, because human effort has been folded into a number labelled automatic. Both are legitimate to publish. They answer different questions, and they are not comparable to each other.
The variable people miss is count against value. Match rates can be counted by number of payments or by value of cash, and on most B2B books those two diverge. Small receipts tend to be single-invoice and straightforward. Large receipts tend to be consolidated payments from big customers, covering twenty invoices with deductions across half of them. A business can post 90% of its receipts automatically and still have most of its money unapplied on Friday. Ask for both figures and expect the value one to be lower.
Our own number
Monk’s cash application matches 80% of payments automatically, and 95% once suggested matching rules are enabled.
Those are two different measures. The 80% is before any customer-specific configuration. The 95% includes matches produced by rules a customer has set up around their own payment patterns, which is a real result and a separate thing to quote. Anyone evaluating us should put the questions below to us as well, and we will answer them.
Five questions to ask
What population is this measured against, as a count of payments over a period? If the answer contains the words eligible, supported or configured, ask what sits outside those words and how many payments that was last month.
Does a match mean posted to invoice level, or identified to a customer? Then ask what happens to the ones that stop at customer level, and who does that work.
How are partial payments and short pays treated? A vendor counting an invoice matched while a residual stays open is measuring something different from one that does not. Both should be able to say which they do.
Is this first pass, or after the exception queue is worked? Ask for the first-pass figure specifically. That is the one that tells you how many people you need.
What is the same rate by value rather than by count? A vendor who has never calculated it will say so, and that answer is more useful than a fast number.
Three things worth measuring in your own business
Once the software is running, the only rate that matters is the one your own book produces.
Track your first-pass match rate on all receipts, by count and by value, with no exclusions for missing remittance or small amounts. It will come in below any figure you saw in a demo. It is also the one that moves in step with your team’s workload.
Track your unapplied cash balance and its age. A balance that clears in two days is a rhythm. The same balance sitting for three weeks is cash you have collected and not recognised, and it is usually concentrated in a handful of large accounts your team can name without looking.
Track days from receipt to posted, as a median and at the ninetieth percentile. The median tells you the normal case and the ninetieth tells you where the disputes and write-offs are coming from.
Why this is worth an afternoon
Unapplied cash inflates DSO while the money is sitting in the bank. The receipt has landed, the invoice stays open in the aging, and the ratio counts it as outstanding for every day it takes to allocate. Allianz Research, looking at roughly 45,000 listed companies across 35 countries, put the global average DSO at 62 days of turnover at the end of 2024, up more than two days over the year. In some businesses a meaningful share of that is money that arrived on time.
The practical consequence is what I would flag to anyone running AR. A team watching DSO climb will read it as a collections failure and respond with more chasing, tighter terms, another collector. If the cash is arriving on time and then sitting for a week or more before it posts, none of that helps, and a quarter goes into working a receivables problem that is a matching problem. Before you reprice anyone’s credit terms, check how long the money has already been in the bank.
An auto-match rate is a useful signal once you know what it counts. Ask the five questions above of every vendor you are considering, ours included, and then go and measure your own three. The second set is the one you will still be using in a year.
Author bio
Kendall Warson leads growth at Monk, an AI-native invoice-to-cash platform that submits invoices into corporate AP portals, runs collections and applies incoming cash on top of a company’s existing ERP.
Source table
| # | Claim | Source | Status |
|---|---|---|---|
| 1 | “One says 85%. Another says 92%.” | Illustrative, not attributed to any named vendor | Illustrative. Do not let an editor attach vendor names. |
| 2 | 60% of receipts with remittance, 90% of those matched, equals 54% on all receipts | Arithmetic in the text: 0.60 x 0.90 = 0.54 | Verified by calculation |
| 3 | “$47,000 wire from Acme”, “$10,000 against a $12,000 invoice”, “$40 receipt” | Constructed examples | Illustrative. Acme is a placeholder, not a customer |
| 4 | Monk matches 80% of payments automatically, 95% once suggested matching rules are enabled | Monk canonical stats sheet | Verified. Approved wording used |
| 5 | Global average DSO 62 days of turnover at end-2024, up more than two days, across roughly 45,000 firms in 35 countries | Allianz Research, “Cash back to shareholders or cash stuck to finance customers?”, 18 June 2025 | Verified against the primary PDF. https://www.allianz.com/content/dam/onemarketing/azcom/Allianz_com/economic-research/publications/specials/en/2025/june/2025-06-18-DSO.pdf Note the allianz-trade.com landing page still shows the April 2024 edition with the older 59-day figure |
| 6 | Bio description of Monk | Monk canonical description | Verified. No market-position claim, no competitor reference |
Outside statistics used: one. Cap is two.
Swaps held in reserve
| Held back | Reason |
|---|---|
| The denominator behind Monk’s 80% (all payments received, counted by payment, match meaning posted to invoice level) | Not a published figure and unverified. If product confirms, add it to the “Our own number” section. It is the stronger version, since the piece argues undefined rates are useless |
| 40% average reduction in DSO | Correct wording is “40% average reduction in DSO”. Never “40%+”, “more than 40%” or “over 40%”. Not used here because the piece is about measurement rather than outcomes |
| 92% of enterprise invoices require portal submission, 600+ portals | Belongs to the portal argument, not this one |
| 37% cash on hand month one rising to 2.4x over the first quarter | Reads as a product pitch in a contributed piece |
| Federal Reserve trade receivables total, $9,822,834m Q1 2026, US only | Verified but a macro total does not advance a definitional argument |
