Transaction matching compares records across ledgers, bank statements, subledgers, and intercompany books to confirm they agree. Comparison is largely solved by software. The unresolved remainder, the items that survive the first pass, is where most manual effort still sits.
The last four days of the month look similar at most multi-entity companies. Someone exports a bank file, someone else pulls a subledger, and both land in a spreadsheet a former colleague built two years ago. Most lines tie on the first pass, and what is left becomes a list to work through by hand.
Transaction matching software has been sold against that list for years, and it does the first part well. Comparing large populations of records and flagging what agrees is a settled engineering problem, available from every major vendor in the category. What no comparison engine resolves is what happens to the residue, which is where the calendar actually goes.
That gap explains why teams buy a matching tool and still staff the same number of people for the same number of days. The comparison finishes in minutes. Resolution, documentation, and posting stay with the team, and that load grows with volume while the software's contribution holds flat.
What a first pass actually compares
A matching routine takes two or more populations of records and looks for the pairs, groups, and offsets that represent the same economic event. That can mean bank lines set beside cash postings, purchase orders tested against receipts and invoices, or a balance in one legal entity compared with its mirror in another.
Volume is what makes the job hard, since every additional subsidiary, bank account, and payment method multiplies a population that has to tie across systems never designed to agree.
The comparison step is arithmetic, and the judgment it hands back is what consumes the month.
The four match types and where each one breaks
Records arrive from the ERP, the bank, the payment processor, and whatever subledgers hold the detail. Matching logic then works across four relationships, and the difficulty rises sharply from the first to the last.
- One-to-one is the simple case, where a record has exactly one counterpart, such as a wire that clears one invoice at the stated amount.
- One-to-many covers a lone record answered by several, such as a deposit split across two subsidiaries, or one payment settling a batch of invoices net of a deduction.
- Many-to-one is the mirror of that, where several records resolve against a single item, such as three partial shipments billed on one invoice.
- Many-to-many is the hard case, where groups on both sides balance only in aggregate, which is common in intercompany activity and in inventory movement. Tools that were built on configurable rules tend to be strong on the first relationship and progressively weaker across the other three.
Bundled remittances and aggregate intercompany positions are one-to-many and many-to-many by nature, which is exactly why they stay manual in most systems.
Why the remainder costs more than the match
What survives the first pass is rarely random. It clusters around timing differences, currency movement between the two sides, partial settlements, misclassified postings, duplicates, and items booked correctly in one system and never mirrored in the other.
Each one requires a person to determine the cause, choose treatment, write the support, and post the result. That sequence is the reason a matching project can succeed in the comparison and leave headcount untouched.
Related post: How to Scale Finance Operations Without Adding Headcount: Data-Driven Insights from 50 Million Transactions
Matching and reconciliation are two different jobs
The two terms get used interchangeably, and the distinction decides what a team should be evaluating. Matching operates at the transaction level and answers whether individual records correspond. Reconciliation operates at the balance level and answers whether a general ledger figure is supported and defensible, which requires an explanation for every difference and a documented conclusion.
A tool can therefore report a strong match percentage while the underlying balance remains unexplained. The unmatched population is precisely the population that has to be explained before anyone signs off, so the balance-level question inherits everything the transaction-level pass declined to settle.
Matching is one step inside reconciliation, which is why a match score on its own says little about whether the month can finish on time.
Explore more on this topic: Automated Reconciliation: Why RPA Falls Short at Scale and How APM Agents Finish the Job
Where rules-based matching stops scaling
Configurable rules encode the patterns that were visible when someone wrote them. A new acquisition arrives with its own chart of accounts, a new processor settles on a different cycle, a new market introduces a second currency, and the rule set that worked last quarter starts producing false positives. Maintaining that logic becomes a recurring assignment for the most experienced person on the team.
The deeper limit is what happens at the end of the routine. Rules-based tooling routes an unresolved item into a queue and notifies a human, which relocates the work without completing it. A tool that hands back a shorter list has improved the sorting while the labor stays where it was.
You might also like: APM vs. RPA vs. AI Copilots: What Each One Can Actually Execute in the Accounting Close
How Nominal executes transaction matching across systems
Nominal performs the accounting work that traditional close software leaves with the team, and the part after the comparison is where that difference shows. A matching agent reads each population directly from the system that holds it, works across all four relationships including the many-to-many cases that defeat static rules, and then carries on into the part that normally comes back to a person.
What a matching agent produces
Evaluation comes first, so the cause of an unresolved item is identified as a timing difference, a currency movement, a partial settlement, or a posting error. A treatment permitted by policy is then chosen and executed, and what comes out is a finished accounting artifact: the reconciliation, its supporting workpaper, the journal entry, and the sign-off. Anything outside policy is escalated with the evidence already assembled, so the judgment is all that remains for a controller to make.
How the sequence hands off
Because these run in order, the output of one becomes the input of the next. Matching passes its results into resolution, resolution passes cleared balances forward into sign-off and elimination, and each handoff carries its documentation with it. Every action runs under human review and approval, a standing condition of how the sequence operates.
The measure worth applying to any matching tool is how much accounting it finishes without returning the item to a person.
Nominal is not an ERP, and it does not replace one. It reads from and writes back to the general ledger a team already uses, and Deployed Finance Engineers configure the agents around that team's existing policies, thresholds, and materiality conventions.
Common Challenges in Traditional Matching Processes
Certain matching populations are difficult in ways that a general comparison engine handles poorly, and they are the ones that grow fastest as a company adds entities and markets.
1. Intercompany matching
Two subsidiaries record the same transfer on separate dates, in unlike currencies, under charts of accounts that were never harmonized. Neither side is wrong, and the gap still has to be explained and eliminated before consolidation.
Much of this population is many-to-many, since one funding movement can offset a group of charges recorded over several weeks, and the number of possible pairings grows faster than the number of legal entities. Nominal treats explaining and eliminating intercompany balances as one continuous piece of work.
2. Inventory matching
Goods received, invoices approved, and quantities counted rarely align on the same day, so the three-way comparison across purchase order, receipt, and invoice produces steady exceptions even in a well-run operation. Partial receipts against a single order make this a one-to-many problem by default, and landed cost allocations and in-transit units add a layer that quantity logic alone cannot settle.
The same pattern surfaces in inventory reconciliation at period end, where the count has to be defended and not simply reported.
3. AR/AP Matching
Customer remittances arrive short, bundled, or without reference data, and a single payment can clear eleven invoices net of a credit memo and a bank fee. That is a one-to-many case with a difference attached, so applying it correctly means reading the remittance advice, testing combinations, and deciding how to treat the shortfall.
Payables carry the mirror version on the vendor side, where one check covers several approved bills and a short payment has to be explained before anyone releases the next run.
Each of these three fails for a reason of its own, which is why a single rule set never covers all three.
How continuous matching changes the month-end
Batch comparison run in the final days of a period concentrates every unresolved item into the narrowest part of the calendar. Running the same comparison continuously spreads that population across thirty days, so an item surfaces near the date it occurred, when the person who can explain it still remembers the context.
The effect on audit preparation follows from the same shift. When documentation is produced at the moment each item is settled, support exists weeks before an auditor asks for it, and the person who wrote the explanation is still available to stand behind it.
A period that closes on schedule is usually a period where nothing waited for the last four days.
What becomes possible when the remainder shrinks
The value of transaction matching was never in the percentage of lines that tie automatically, since that number has been high for years while month-end stayed long. The number worth tracking is how much of the unresolved population reaches a posted, documented, reviewed conclusion without a person assembling it. When that figure moves, senior accountants stop spending the last week of every month on assembly and start spending it on review, variance explanation, and the analysis their titles imply.
Growth then stops arriving as a hiring conversation. A company can add three subsidiaries, a new market, and a second payment processor without adding the people that volume would otherwise require. Continuous, agentic reconciliation becomes how the year runs.
Ready to see what your matching population looks like when the exceptions finish themselves? Book a demo to walk through a live matching population with Nominal.
About the writer
