Every match a reconciliation system attempts lands in one of four states, and the audit log’s entire job is to record which state, why, and who was involved if a human had to step in.
| State | What it means |
|---|---|
| Confirmed automatically | Both records agreed within the rule’s tolerance; no human touched it |
| Suggested, pending review | A likely match was found but confidence fell below the auto-confirm threshold |
| Rejected | A suggested match was reviewed and specifically declined |
| Exception | No corresponding record was found at all, or the mismatch exceeded any tolerance |
A transaction matching audit log is distinct from the broader record covered in audit trails in payment reconciliation software, because it operates at the level of this single decision, which is where most silent reconciliation errors actually start. Rexi’s reconciler agent generates this log as a normal output of running the match, not as a separate audit exercise bolted on afterward. Where that matching step sits within the broader workflow is covered in Rexi’s guide to payment reconciliation software.
What decides whether a match needs a human at all
Most matching engines use a confidence score, not a strict yes-or-no comparison. A match scoring above a set threshold, often somewhere around 90 out of 100, gets confirmed automatically. One falling in a middle range gets flagged for review. Anything below that becomes an exception outright. Rexi’s matching agent sets these thresholds per data source rather than applying one blanket rule, because a PSP’s data is typically far more reliable than a manually uploaded CSV from a smaller payment partner, and multi-provider payment reconciliation only works if the confidence bar reflects that difference.
The audit log has to capture which threshold a given match fell under, not just its final disposition. A match that cleared automatically at a 95% confidence score and one that barely squeaked through at 91% carry very different risk profiles, even though both show up identically as “matched” if the log doesn’t record the score itself.
Automation rates look impressive right up until you do the math
Vendors in this space increasingly advertise very high automated match rates. In its own Businesswire announcement, FIS claims its Optimized Reconciliation Service targets at least 98% automated matching rates backed by financial SLAs. Separately, in its own press release, Maxima claims via Businesswire that its platform has processed more than $255 billion in volume across 250 million records with full auditability. Both figures are vendor claims rather than independently verified benchmarks.
Run the arithmetic on 98% automation at meaningful volume and the 2% remainder is still tens of thousands of matches a month that needed a tolerance rule, a manual review, or a forced override. That remainder is where audit risk concentrates, and it is exactly what a transaction matching log has to capture in enough detail to reconstruct later, not wave away as a rounding error.
What a forced match actually needs on the record
A preparer sometimes recognizes that two records represent the same transaction despite a formatting difference, a truncated reference, or an unexpected prefix, and overrides the system to force the match. When that happens, the log needs the justification, not just the fact that an override occurred. A force-matched transaction with no recorded reason is functionally identical to an unexplained one, it just looks tidier in the dashboard.
Rexi’s matching agent requires a reason code on every manual override before it will post, which is what keeps the resulting log usable for a reviewer who wasn’t in the room when the call was made. This matters more in payments than almost anywhere else in reconciliation, since payment reconciliation audit trails cross more systems and formats than most other transaction types, which means more overrides happen and more of them need documentation.
Timing tolerance is a rule, not a courtesy
Matching rules rarely demand an exact hit. Most engines apply a percentage or date tolerance so that legitimate variance, a payment settling a day later than expected, doesn’t get flagged as a break. Timing differences in payment reconciliation are one of the most common reasons that tolerance exists in the first place, and the audit log needs to record which window a match fell within, not just that it cleared. A tolerance set too loosely can quietly absorb real discrepancies, and if the log only records the final match rather than the tolerance applied, there’s no way to later tell whether a run of matches passed because they were genuinely correct or because the rule let them through.
Rules change too, and that needs its own history
Matching rules are not static, and a change to one can silently alter outcomes for every transaction that passes through it afterward. In its own Businesswire release on irAuthor Web, InRule positions this directly: governance for decision logic in regulated industries requires version control, audit trails, and rule traceability as a baseline expectation, not an optional add-on.
This is a separate requirement from logging individual match events. A team can have a complete log of every match decision and still have no record of when the rule governing those decisions last changed, by whom, or why. Rexi treats a rule change as its own logged event, distinct from the transactions matched under it, so a shift in match behavior can always be traced back to the specific change that caused it.
From an unmatched record to a closed exception
Anything that lands in the exception state needs its own resolution path, and that path is where the matching log connects to broader reconciliation governance. According to The Paypers, one governance framework for finance AI describes a three-way match exception on a large invoice being either resolved automatically with a recorded decision trail, based on pre-configured policy, or escalated with a structured recommendation depending on the threshold the finance team has set.
Exception audit trails in reconciliation pick up exactly where the matching log leaves off, capturing how the exception was investigated and closed. The two records have to reference each other: the matching log shows why a transaction became an exception, and the exception trail shows what happened after.
Regulators increasingly expect this by default
The SEC’s concept release on the Consolidated Audit Trail is reviewing the scope and sufficiency of audit trails used across U.S. securities markets, reflecting how central transaction-level traceability has become to market oversight generally. Separately, Nacha’s new risk management rules require non-consumer ACH originators to implement risk-based processes to identify entries suspected of being unauthorized or authorized under false pretenses, with those controls reviewed and updated at least annually, as part of a broader shift toward continuous, evidence-based compliance rather than point-in-time review.
PYMNTS frames the shift plainly: as B2B payments move toward real time, enterprises need systems that enforce segregation of duties and generate immutable audit trails without slowing operations down. A matching log that exists informally, in a spreadsheet comment or a Slack thread, does not meet that bar anymore.
What SOC 2 auditors actually pull from this log
An auditor sampling transactions for SOC 2 evidence in payment reconciliation workflows needs to trace each sampled transaction back to the specific rule version and reviewer responsible for its disposition. That’s only possible if the matching log is append-only, tied to a rule version, and searchable by transaction rather than buried inside a batch report. Rexi’s matching log is built to be pulled at the transaction level for exactly this reason, so a sample request doesn’t turn into a reconstruction project every time an auditor picks a handful of records to check.
Frequently Asked Questions
What is a transaction matching audit log?
A transaction matching audit log records how each reconciliation match was decided. It shows whether a transaction was confirmed automatically, suggested for review, rejected, or moved into an exception state. A useful log records the rule, confidence score or threshold, tolerance, source records, timestamp, and any human reviewer involved so the match can be explained later.
What match states should a reconciliation system log?
A reconciliation system should log at least four match states: confirmed automatically, suggested and pending review, rejected, and exception. Confirmed matches show records agreed within the rule. Suggested matches need human review. Rejected matches show a reviewer declined the proposed link. Exceptions show no counterpart was found or the mismatch exceeded the allowed tolerance.
How does a system decide whether a match needs human review?
Most systems use rules, tolerances, and confidence thresholds. A high-confidence match above the auto-confirm threshold can be accepted automatically. A middle-confidence match may be routed to a reviewer. A low-confidence or out-of-tolerance record becomes an exception. The audit log should preserve the threshold and rule version used, because different configurations can produce different outcomes.
What should be recorded for a forced match?
A forced match should record who overrode the system, which records were linked, the reason for the override, the evidence reviewed, and whether approval was required. The log should not simply say that a manual match occurred. It should explain why the preparer believed the records represented the same transaction despite formatting differences, truncated references, timing gaps, or other mismatch signals.
Why should rule changes have their own audit history?
Rule changes need their own history because they can affect every future match result. Changing a date tolerance, amount threshold, confidence score, or provider-specific mapping can silently alter how transactions are classified. The audit trail should show who changed the rule, what changed, when it took effect, who approved it, and whether prior transactions were reprocessed.
How do transaction matching logs support SOC 2 evidence?
Transaction matching logs support SOC 2 evidence by connecting sampled transactions to the rule, tolerance, reviewer, and approval path that produced the final status. They help show that matching decisions were authorized, explainable, and consistently applied. For SOC 2 review, the log is strongest when it links automated decisions, manual overrides, exception handling, and rule changes in one traceable record.
