Short answer: transaction matching is pairing each record in one data set with the record or records in another that describe the same money movement, then putting whatever is left in front of a person. Transaction matching software does the pairing with rules (exact amount, reference, date window) and, in AI based tools, with learned judgement for vague references and combinations. The useful test is not the match rate on the demo file but how it handles your messiest month, and whether it shows and explains every match before anything is posted.
What is transaction matching?
Every reconciliation compares two records of the same activity: the bank statement and the ledger, a card statement and the expense claims, a payment provider's payout and the sales behind it. Transaction matching is the step where individual lines are paired up. Reconciliation is the wider job: matching, explaining the differences, posting the adjustments and signing off.
For an accounting firm the common pairs are:
| Side A | Side B | Typical problem |
|---|---|---|
| Bank statement lines | Open invoices and bills | One payment covers several invoices |
| Payment provider payouts (Stripe, PayPal, Adyen) | Sales invoices or orders | One payout bundles dozens of sales minus fees and refunds |
| Card statement | Receipts and supplier bills | Foreign currency amounts that differ slightly |
| Supplier statement | Bills in the ledger | Missing or duplicated invoices |
| Intercompany balances | The other company's books | Timing and currency differences |
If the goal is invoice-level checking rather than bank lines, see invoice reconciliation, which also covers orders and supplier statements.
The four match types
Enterprise reconciliation software uses four standard match types. Oracle's Account Reconciliation documentation lists them as one to one, one to many, many to one and many to many, and the same names appear in most tools.
- One to one. One bank line, one invoice, same amount. The easy majority.
- One to many. One transfer of 2,486.25 pays three invoices. The software must find which open items add up to the payment. We go through this in detail in one payment, many invoices.
- Many to one. Three part payments settle one large invoice.
- Many to many. Two transfers from the same customer together settle four invoices. There is no single anchor record, so only the totals can be compared.
The last three are where manual matching eats time, and where tools differ most.
How rules-based matching works
A rules engine applies a list of conditions in order. Oracle's best-practice guidance is to run the most precise rules first: one to one before one to many or many to one, and those before many to many, with "matches exactly" rules ahead of "matches with tolerance" rules. That order matters. If a loose rule runs first, it can grab a transaction that a stricter rule would have matched correctly.
Three things make up most rules:
Keys. Which fields must agree: amount, counterparty, invoice number in the reference, currency. A "contains" condition lets a structured field, such as an invoice number, be found inside free text like a bank reference.
Tolerances. How far apart two records can be and still match. Oracle describes three kinds: a fixed variance (for example -1 to +3), a percentage of the amount, or a percentage with a cap. Date tolerances work the same way. Its guidance for a 60-day payment term is to look in a narrow window around day 60, such as +60 to +65 days, rather than across the whole 60 days.
Tie-breaks. What happens when two candidates fit. Oracle's engine, for example, picks the transaction loaded first. That is predictable, but it is not judgement, and it is exactly how a 450.00 payment ends up on the wrong customer's 450.00 invoice. A better default is to refuse to choose and flag both.
Where AI based transaction matching helps
Rules only know what you told them. AI based transaction matching adds judgement where rules give up:
- Vague references. "MEDSUPPLY 04/12" and a customer called Med Supply Ltd are the same party, even without an invoice number.
- Combinations. Working out that three of eleven open invoices add up exactly to a payment, without you building a subset rule.
- History. If a client's tenant always pays rent from a personal account on the 3rd, that pattern makes the next match easier.
- Sensible differences. A payment 3.60 short after a card fee is proposed with the difference shown, not rejected outright.
What AI should not do is hide its reasoning or post on its own. Every match should show which records were paired, which fields agreed and what the difference is. For a broader look at matching tools for small firms, including enterprise products like BlackLine, see AI reconciliation software.
A worked example: a bundled payout
An online shop client uses Stripe with automatic payouts. On 3 November the bank shows one credit: STRIPE PAYOUT, +1,932.18. The ledger has 24 separate sales invoices for that period. No single invoice is 1,932.18, so a one-to-one rule finds nothing.
Stripe's payout reconciliation report exists for this case: it lists every payment, refund, dispute and fee included in each automatic payout, and the itemized CSV can be downloaded. Stripe notes that it cannot do this for instant payouts, because you choose their timing and amount, so those you reconcile against your own transaction history.
The itemized report for this payout shows:
| Component | Amount |
|---|---|
| 24 charges (gross) | 2,010.00 |
| 1 refund | -20.00 |
| Stripe fees | -57.82 |
| Net payout | 1,932.18 |
The match is many to many: one bank line on one side, 24 invoices, a refund and a fee line on the other. The steps:
- Match the bank line to the payout total (one to one, exact).
- Match the 24 charges to the 24 sales invoices (one to one each, usually on order or invoice number).
- Match the refund to its credit note.
- Post the 57.82 as payment processing fees, with the report as support.
Done by hand, that is a spreadsheet and half an hour. With matching software that can read the itemized report, it is a review of one proposed group.
How to choose transaction matching software
Test with a real month from a real client, not the vendor's sample.
| Check | How to test it |
|---|---|
| Reads your actual formats | Include a PDF statement from a bank with no feed, and a CSV export |
| One to many and many to many | Include a payment covering three invoices and a bundled payout |
| Tolerances you control | Can you set amount and date tolerances per client or per account? |
| Refuses to guess | Include two open invoices with the same amount and a vague reference |
| Explains each match | Click a match: can you see which fields agreed and the difference? |
| Approval before posting | Nothing should be reconciled or marked paid until someone approves |
| Audit trail | Export who approved what and when |
| Posts back to the books | Are invoices marked paid in the accounting software afterwards? |
Count three numbers at the end: lines matched correctly, lines flagged for review, and lines matched wrongly. The third matters most. A tool that matches 95% but gets 3% wrong costs more review time than one that matches 85% and flags the rest. PDF statements need their own test; see reconciling PDF bank statements without a bank feed.
Where Invoreg fits
Invoreg does transaction matching for bank reconciliation: it reads bank statements, including PDF and scanned ones, matches each payment to the invoices and bills it settles, works out the combination when one payment covers several invoices, and flags uncertain matches with the likely candidates. Nothing is reconciled without approval, matched invoices are marked paid, and all clients sit in one firm-level queue. It is not an intercompany or enterprise high-volume matching platform, and it does not connect to payment providers such as Stripe directly.
The live connector is Zoho Books; for other accounting software we produce an import file it already accepts or build an API connector. See the bank reconciliation page, or bring a messy month to a demo and we will run it live.