Transaction Matching Audit Logs: What They Should Record

A transaction matching audit log is the record of how a reconciliation system decided that records belong together. It should answer a straightforward question: why did this payment, settlement, bank entry, or ledger posting receive this outcome?

The answer should not be a single status. “Matched” does not tell a reviewer whether the result came from an exact ID match, a date tolerance, a high-confidence suggestion, or a manual override. The log needs the source records, the matching policy, the values used, the time of the decision, and any person involved in changing it.

Record the state of the decision

An attempted match can be confirmed automatically, proposed for review, rejected by a reviewer, or left as an exception. Those states carry different meanings. A confirmed match may satisfy an approved rule. A suggestion may need a person to decide whether the evidence is sufficient. A rejection indicates that the system proposed a relationship that a reviewer did not accept. An exception means there is no defensible link yet.

Keeping those states separate avoids a common reporting problem. A team may say that most records are matched while missing the fact that a growing share are being force-matched or accepted under a widening tolerance. The audit log makes those differences visible.

Preserve the inputs and the rule

For a processor settlement, the relevant inputs may include the internal payment ID, provider reference, gross amount, fee amount, currency, and settlement date. For a bank credit, the payout ID, destination account, net amount, and value date may matter more. The log should preserve the fields that actually influenced the result, alongside the version of the matching rule.

Finextra’s analysis of payment-data fragmentation explains why that context matters. If sources use different identifiers or report on different schedules, a match cannot be understood from the final outcome alone.

Tolerances should be visible and governed

Date and amount tolerances are often necessary. A payment may settle later than expected, or a known fee may create a small difference between the gross transaction and the bank deposit. These policies need to be explicit because they change the result of the match.

The audit log should identify the tolerance that applied. A finance team can then see whether a record cleared because it was an exact match or because it fell within a permitted range. Timing differences in payment reconciliation are expected, but the system still needs to show the window that justified the decision.

Manual overrides need a complete explanation

Some manual matches are legitimate. An analyst may have evidence that a truncated bank reference and a processor payout represent the same event. The record should say who made that decision, which records were linked, why, what evidence was reviewed, and whether approval was required.

This protects the analyst as much as the business. A later reviewer can see the reasoning instead of treating every manual match as an unexplained change. It also exposes patterns. If the team repeatedly needs to override the same source relationship, the source mapping or matching policy probably needs attention.

Rule history is part of the control environment

A transaction log explains a result. Rule history explains why similar records started receiving a different result on a later date. The system should retain who changed a rule, what changed, why it changed, when it became effective, and who approved it.

Rexi keeps that decision context across reconciliation and investigation. When a record cannot be matched, the case can move into an exception workflow without losing the source evidence or the history of the matching attempt. Exception audit trails then capture the work needed to resolve it.

Logs should be easy to retrieve when a question arrives

An audit log is only useful if a team can find a decision without building a new report. Users should be able to search by payment ID, payout reference, source, date, rule version, owner, and final state. A control or finance reviewer can then trace one selected transaction through the matching result and, if needed, into the exception case that followed.

Searchability is also useful for operations. A manager can look for a cluster of rejected suggestions or manual overrides tied to one provider and investigate the mapping before the problem creates a larger backlog. The log becomes part of the team’s monitoring process, rather than a record that is opened only during audit preparation.

Frequently Asked Questions