How to choose tools for automated payment reconciliation.
Most reconciliation projects fail on data, not on software. This is the selection checklist I use before recommending any tool — eight criteria, in the order they actually matter.
Map the money before you shortlist software.
Every failed reconciliation implementation I have seen started with a vendor demo instead of a data map. Before you speak to anyone, write down each source of money movement, the file or API behind it, the currency, and who owns the difference when it does not match. That one page tells you which of the criteria below are dealbreakers for you — and it doubles as the requirements document.
1. Source coverage
List every money movement first: PSPs, acquirers, marketplaces, wallets, bank accounts, card programmes, crypto rails. Confirm the tool ingests each one at transaction level via API — not a manual CSV upload someone has to remember on the 3rd working day.
2. Fee, FX and chargeback handling
Gross versus net settlement is where most implementations fail. Ask exactly how the tool books provider fees, FX differences, reserves, refunds and chargebacks, and whether each posts to its own account automatically.
3. Matching engine transparency
You need rules you can read, version and explain to an auditor: one-to-one, one-to-many, many-to-many, tolerance windows and date offsets. Black-box matching with no audit trail creates an audit finding, not a saving.
4. ERP integration depth
Check the actual integration to NetSuite, SAP, Exact, Xero or whatever you run: does it post summarised journals, sub-ledger detail, or both? Can it reverse and repost? Does it respect your period locks?
5. Exception workflow
The value is not in the 95% that matches, it is in how fast your team clears the rest. Look for ownership, ageing, comments and an escalation path — plus a report showing exception volume trending down over time.
6. Controls and audit evidence
Segregation of duties, immutable logs, approval on manual matches, and an export that satisfies a statutory audit without a week of screenshotting. If you are SOx-scoped, involve internal control before signing.
7. Scale and cost model
Price per transaction looks cheap at current volume. Model it at three times your volume, and check what happens to processing time at month-end when everything runs at once.
8. Time to first clean close
Ask the vendor for a reference customer with a comparable stack and ask them one question: how many closes did it take before the numbers were trusted? That answer predicts your project far better than a feature matrix.
The three questions that separate good tools from demos.
- Show me an unmatched item and every rule that was tried against it.
- Show me the journal this posts to my ERP, at line level, for a settlement with fees, FX and a chargeback.
- Show me the audit export for last month's close.
Any vendor who can answer all three live is worth a pilot. Any vendor who cannot is selling you a dashboard.
Common questions on reconciliation tooling
- Do I need a dedicated reconciliation tool, or is my ERP enough?
- If every settlement lands in one currency from one payment provider, ERP bank rules are usually enough. Once you add a second PSP, marketplace payouts, refunds and chargebacks, or multi-currency settlement, the ERP's one-to-one matching breaks down and a dedicated matching engine — or a well-built data layer feeding the ERP — pays for itself quickly.
- What is the single most important selection criterion?
- Data completeness at source. A tool that cannot ingest the provider's full transaction-level report — including fees, FX, reserves and chargebacks — will always leave a manual remainder, no matter how good its matching rules look in a demo.
- How long does implementation typically take?
- For a scale-up with two or three payment sources, expect 6 to 12 weeks from data mapping to a first clean close on the new process. Most of that time is spent agreeing the chart-of-accounts mapping and the treatment of edge cases, not on the software itself.
- Can AI do the matching?
- AI is genuinely useful for the unmatched remainder — clustering exceptions, suggesting probable matches, explaining variances in plain language. It should not replace deterministic rules for the 95% that match on reference and amount, because auditors need reproducible logic.
- Build or buy?
- Buy when your flows resemble standard e-commerce or SaaS billing. Build a thin internal layer when your settlement logic is a competitive part of your product — marketplaces splitting payouts across sellers are the usual case. Either way, keep the accounting rules outside the code so finance can change them without a release.
Get a second opinion before you sign.
I have run these selections and the implementations that follow. Send me your shortlist and your data map — I'll tell you where it will break.
30 minutes, no obligation. Bring your close timeline and top pain points.
Book a diagnostic call