The fastest way to lose a finance manager's trust in remittance automation is to post a wrong match into Xero. The fastest way to lose their interest is to make them review every right one. Auto-match confidence is the dial that sits between those two failure modes, and choosing where to set it is the single most important configuration decision your team will make.
Most Xero remittance tools surface a confidence score against each matched line. It is the system's own estimate of how sure it is that this remittance line maps to this open Xero invoice. The score is useful, but the real decision is what you do with it. Some teams review everything. Some teams auto-post only at 100 percent confidence and review the rest. Some teams auto-post a wider band and accept the occasional correction. This post walks through how the dial actually works, who should set it where, and how to think about the audit, exception, and culture consequences of each choice.
What an auto-match confidence score actually measures
Confidence is not a single number with a single meaning. Behind the percentage, most matching engines combine three signals: invoice number match (exact, partial, or fuzzy), amount match (exact or within a tolerance), and customer or supplier identity match (does the remittance say it is from the customer whose invoices we are reconciling against). A 100 percent score usually means all three line up cleanly: the remittance reference matches a single open invoice number exactly, the amounts agree to the penny, and the payer identity is unambiguous.
Anything below 100 percent is the system telling you it has found a candidate but is not sure. The most common reasons for a sub-100 score are: the remittance reference is a customer-side PO number rather than your invoice number, the amount is short by a deduction or VAT discrepancy, the payer is paying through a parent account that does not match the entity on your invoice, or the remittance line could plausibly map to two open invoices of similar value. Each of those needs a different response, and that is the point of keeping a review layer for the ambiguous cases.
Three thresholds, three different operating models
Review everything (zero auto-match)
This is where most teams start. Every remittance is parsed, every line is matched, and a human approves the batch before it posts to Xero. It is the safest option and the right one for the first two weeks of any rollout. Reviewing everything gives the team a chance to verify that the system is reading their formats correctly, that customer name normalisation is doing what they expect, and that the audit trail looks the way they want it to. After about ten to twenty live remittances, most teams have seen enough to know whether they trust the high- confidence matches without checking.
Auto-match at 100 percent confidence, review the rest
This is the setting that most high-volume teams end up running. Lines that score 100 percent post straight to Xero without manual intervention. Anything below 100 sits in a review queue where a finance team member confirms the suggested match, adjusts it, or rejects it. For most B2B remittance flows, this means the bulk of the work runs untouched and the finance team's time is spent on the 5 to 15 percent of lines that genuinely need a judgement call. High-volume customers running this setting after onboarding consistently describe it the same way: it takes the manual element out of the process.
Auto-match at a wider band (90 percent and above, for example)
Some teams push the threshold lower. The argument is straightforward: if the system is 95 percent sure, the review usually confirms what it already thought, and the time spent confirming is wasted. The counter-argument is that 95 percent confidence is not 100 percent, and the matches that go wrong in that band tend to go wrong silently. A wider auto-match band is defensible for high-trust, low- complexity formats (a single B2B customer with consistent invoice numbering, for example) but is rarely the right default across a mixed remittance flow.
The decision is not about whether to use automation, it is about where to locate the human review layer. Set it too high and you spend your time on work the system has already done correctly. Set it too low and you spend your time unwinding posted entries that should never have gone in.
How to choose the right threshold for your team
How stable are your customer remittance formats
If you process remittances from a small number of large customers who use consistent layouts (think a labour hire firm invoicing four big civil contractors, or a wholesale supplier shipping to a handful of grocery chains), the system learns those formats quickly and high-confidence matches become reliable inside a few cycles. If your remittance flow includes dozens of one-off customer formats with no clear pattern, the confidence scores will be noisier and a tighter threshold makes sense. Stability of inputs is the strongest predictor of whether an aggressive auto-match setting will work.
How much audit exposure do you carry
NDIS providers, healthcare operators, public-sector contractors, and any business with grant funding sit in a different audit posture than a typical B2B wholesaler. For those teams, the cost of a single wrong match (and the resulting need to reverse and repost a batch payment in Xero) is meaningfully higher because it leaves a visible trail in the ledger. Tighter thresholds, and a clear note on the review log of who approved each batch, matter more. The good news is that the review layer at 100 percent auto-match is already small for these teams: most NDIA remittances, once formats are learned, score cleanly, and the exceptions are usually the same handful of plan-manager edge cases each week.
What does your team's capacity actually look like
This one is rarely said out loud. A finance manager who is comfortable with the review queue and has the time to work through it will set thresholds tighter than a finance manager who is the only person reconciling several hundred remittances a month and needs the system to take most of the work off the table. The threshold should reflect the actual operating reality, not the theoretical ideal. There is no prize for setting a stricter threshold than your team can sustain.
What does the customer mix tell you
If 80 percent of your remittances come from five customers, you can almost certainly auto-match those five formats at 100 percent confidence after the learning period, and keep tighter manual review on the long tail of one-off payers. Most matching engines let you set thresholds per customer or per format, which is the version of this decision most teams should actually be making. A single global threshold is the easy answer, but a per-customer threshold matches how the work actually arrives.
What a healthy review queue looks like
If you have set your threshold correctly, the review queue should not be a bottleneck. Across the teams we have onboarded, a typical healthy queue at 100 percent auto-match runs at somewhere between 5 and 20 percent of total remittance lines. The reviewer's job in that queue is not to confirm matches the system has already made (those have posted), it is to handle the genuinely ambiguous cases: a deduction that needs allocating to a separate GL account, a short payment that should be left unallocated pending a credit note, a remittance line that maps to two plausible invoices of identical value, or a payer identity that the system has not seen before.
A useful health check: if your review queue is consistently above 30 percent of total lines after the first month, the threshold is probably set too aggressively for your data, or your customer name and invoice number normalisation needs tuning. Below 5 percent is also worth a look, because it can mean the system is being too lenient and posting weak matches as confident ones. The right zone is the band where the reviewer's time is spent only on the cases where their judgement actually adds value.
A note on the bookkeeper-as-reviewer question
Bookkeeping practices have a slightly different version of this conversation. Their value to clients is partly the judgement layer: knowing which deductions to post where, which short payments to chase, which credit notes are about to land. Auto-matching the routine 80 percent of lines does not take that work away, it moves the bookkeeper's billable time onto the cases that genuinely need it. For practice owners pricing client engagements, that is a stronger margin position, not a weaker one. The fear that automation replaces the bookkeeper has not borne out in the practices we work with. What it replaces is the part of the bookkeeper's day that was never billable in the first place.
A simple rollout pattern that tends to work
For most teams, the cleanest path is to start at zero auto-match for the first two weeks, move to 100 percent auto-match once the formats have settled, and only consider a wider band after at least three months of clean operation at the 100 percent threshold. That sequence builds trust the right way: the team sees the matches before they post, then sees them post correctly on their own, then considers loosening only when the operating history justifies it. Teams that skip the first two weeks and turn auto-match on from day one are the ones who tend to roll it back later, usually after a single visible mismatch shakes confidence across the whole tool.
Summary
Auto-match confidence is the most important configuration decision in any Xero remittance automation setup, and the right answer is almost never the most aggressive one. Start at zero, move to 100 percent auto-match after two weeks of clean operation, and only widen the band on stable, high-trust customer formats where the cost of a wrong match is recoverable. The goal is not to remove the human review layer, it is to relocate it onto the lines where human judgement actually adds value. For the cost framing of the same decision, see our post on offshore AR teams versus Xero remittance automation, and for what happens when a single customer pays you across hundreds of invoices at once, see the Xero 200-invoice batch payment limit.