For years, Odoo’s bank reconciliation system included a quiet convenience: a built-in 3% tolerance threshold that automatically matched bank transactions to invoices even when the amounts didn’t perfectly align. The logic was practical — merchant processing fees shave a percentage off payments, rounding differences create small gaps, and currency conversions introduce minor fluctuations. Rather than forcing accountants to manually reconcile every $0.37 discrepancy, the system absorbed them. That tolerance has now been removed entirely.
What the Tolerance Actually Did
The bank reconciliation engine works by running through a sequence of matching rules against each incoming bank transaction. It starts with exact matches — same amount, same partner, clean hit. When exact matching fails, the system moves down the priority chain to progressively fuzzier criteria.
The tolerance match sat in that chain as a fallback: if a transaction amount was within 3% of an open invoice, the system would propose the match and let the accountant confirm it. A separate currency tolerance applied the same 3% buffer when transactions arrived in a different currency than the invoice, accounting for exchange rate drift between the invoice date and the payment date.

Why Remove It
Tolerance matching sounds helpful in theory, but in practice it creates a category of problems that accountants discover at the worst possible time — during audits and month-end close. A 3% tolerance on a $10,000 invoice means the system will happily match a $9,700 bank deposit and call it done. The $300 difference might be a legitimate processing fee, or it might be a partial payment, a pricing error, or a customer who sent the wrong amount. The system can’t tell the difference, and when it guesses wrong, the error compounds silently until someone notices the balance sheet doesn’t tie out.
Currency tolerance had a similar issue. Exchange rates between the invoice date and payment date rarely drift 3% in established currency pairs, but for emerging market currencies or longer payment terms, a 3% swing could represent a material amount that belongs in a realized gains or losses account rather than being absorbed into the original receivable.
What Remains in the Matching Chain
With tolerance matching gone, the reconciliation engine still runs through several automated steps before asking for human input. Exact amount matches still fire first. Discounted matches — where a customer takes an early payment discount within the configured terms — still work, because those are rule-based with explicit discount percentages and deadlines rather than fuzzy tolerances. And the amount-in-label matcher still scans transaction descriptions for embedded amounts that might reference a specific invoice.

What’s gone is specifically the “close enough” matching that treated any amount within 3% as a likely hit. Accountants who relied on this behavior will now see those transactions land in the manual reconciliation queue, where they can create explicit write-off entries, assign discrepancies to fee accounts, or investigate the actual reason for the difference.
The Real Impact Depends on Your Payment Mix
Businesses that primarily receive wire transfers and ACH payments probably won’t notice this change much. Those payment methods tend to arrive at exact amounts, and when they don’t, the difference is usually obvious and intentional.
The businesses that will feel this are those processing high volumes of credit card payments through gateways that deduct fees before settlement. When Stripe deposits $97 against a $100 invoice, that $3 difference previously matched automatically. Now it won’t. The solution isn’t to wish the tolerance back — it’s to set up a reconciliation model that explicitly routes the fee portion to a payment processing expense account. This produces cleaner books than the tolerance approach ever did, because the fees are tracked as actual expenses rather than silently absorbed into revenue.
A Broader Shift Toward Precision
This change fits a pattern visible across Odoo’s recent accounting updates. The platform has been tightening its financial controls — requiring analytic distributions on write-offs during reconciliation, enforcing stricter VAT ID validation, adding explicit currency handling in reporting. Each change adds a small amount of friction in exchange for significantly cleaner data.
The tolerance removal is the same philosophy applied to the most fundamental accounting operation: matching what the bank says to what your books say. The two should agree, and when they don’t, the system should surface the discrepancy rather than paper over it. It’s a less convenient default, but it’s the correct one for any business that takes its financial controls seriously.