Transaction Matching Workbench

Overview

The transaction matching workbench pairs individual transactions from the general ledger with corresponding records in a subledger, bank feed, or external file. Matched pairs explain part or all of the reconciliation variance, reducing the number of items the preparer needs to investigate manually.

Matching is rule-driven. You define a ruleset, an ordered list of passes, each with one or more conditions, and the system runs the ruleset against the data every time a reconciliation is opened or refreshed.

Condition types

Each pass in a ruleset contains one or more conditions. A transaction pair must satisfy every condition in a pass to be considered a match. Arvexi supports eight condition types:

EXACT

The values in the two columns must be identical after trimming whitespace and normalising case. Use for reference numbers, invoice IDs, and any field where an exact string match is expected.

CONTAINS

The value in one column must appear as a substring in the other. Useful when one system stores a full description and the other stores only a truncated version. Comparison is case-insensitive.

STARTS_WITH

The value in one column must be a prefix of the value in the other. Common for batch reference numbers where the subledger appends a suffix (e.g., INV-2026- matching INV-2026-0042).

FUZZY (Jaro–Winkler)

Uses the Jaro–Winkler similarity algorithm with a configurable threshold (default 0.90). Designed for vendor names, payee descriptions, and other free-text fields where minor spelling variations are expected. A similarity score of 1.0 means identical strings; the match fires when the score meets or exceeds the threshold.

TOLERANCE_ABSOLUTE

The numeric difference between two amount columns must be less than or equal to a fixed value. Tolerances can be asymmetric: you can set separate thresholds for positive and negative differences. For example, allow the GL amount to exceed the bank amount by up to $2.00 but require an exact match in the opposite direction.

TOLERANCE_PERCENTAGE

The numeric difference between two amount columns must be within a percentage of the reference value. Like absolute tolerance, percentages can be asymmetric. Example: a 1% tolerance on a $10,000 transaction allows a difference of up to $100.

DATE_RANGE

The dates in two columns must fall within a configurable number of calendar days of each other. Supports business calendar mode: when enabled, the system counts only working days (excluding weekends and organisation holidays) instead of calendar days. Business calendar mode is critical for cross-border payments where settlement timing varies by jurisdiction.

REGEX

A regular expression pattern is applied to one column, and the captured group is compared against the other column using exact match. Use when a meaningful identifier is embedded inside a longer string, for example, extracting a check number from a bank narrative like CHK 004821 PAYROLL 03/15.

Match types

Arvexi supports three match cardinalities. The match type is set per pass, not per condition.

One-to-one (1:1)

Each GL transaction matches exactly one subledger transaction. This is the default and most common type. Once a transaction is matched, it is removed from the pool for subsequent passes.

Many-to-one (N:1)

Multiple GL transactions match a single subledger transaction (or vice versa). The system groups GL transactions whose amounts sum to the subledger amount within the configured tolerance. Typical use case: several daily deposits that together equal a single monthly bank credit.

Partial match

A GL transaction is partially matched against a subledger transaction when the amounts differ by more than the tolerance but all non-amount conditions are satisfied. Partial matches create a residual unmatched amount that carries forward to the next pass. They are flagged for preparer review.

Suggested vs. confirmed workflow

Every match produced by the ruleset starts in a Suggested state. Suggested matches appear in the workbench with a dashed border and can be reviewed, accepted, or rejected individually or in bulk.

When a preparer accepts a match, it moves to Confirmed status. Only confirmed matches reduce the reconciliation variance. This two-step workflow ensures that automated matching never closes a variance without human approval.

Arvexi Cortex can suggest matches outside the ruleset by analysing transaction descriptions, amounts, and historical patterns. Cortex-suggested matches follow the same suggested/confirmed workflow and are clearly labelled as AI-generated.

Ruleset approval

Rulesets go through an approval workflow before they run in production. A new or modified ruleset starts in Draft status. A user with the Matching Admin role reviews the rules, runs a dry-run simulation against historical data, and either approves or returns the ruleset with comments.

Only Approved rulesets execute during the normal reconciliation workflow. Draft and rejected rulesets can still be run manually in simulation mode for testing.

Execution pipeline

When the matching engine runs, it follows a five-step pipeline:

Load sources. Pull GL transactions and subledger records for the account and period. Each source is loaded once and held in memory for all passes.
Map columns. Apply the column mapping defined on the ruleset to normalise field names across sources. For example, map the GL's JRNL_AMT and the bank's Transaction Amount to a common amount field.
Run passes. Iterate through each pass in priority order. For each pass, evaluate every unmatched transaction pair against the pass's conditions. Pairs that satisfy all conditions are marked as suggested matches.
Save results. Persist suggested matches to the database in batches of 100 rows. Batching prevents memory pressure on accounts with tens of thousands of transactions.
Return summary. The engine returns a summary object with total matched, total unmatched, match rate, and execution time. This summary is displayed at the top of the workbench.

Performance considerations

The matching engine is optimised for accounts with up to 50,000 transactions per side. For larger volumes, consider splitting the data into multiple matching sources (e.g., by cost centre or transaction type) and running separate rulesets.

Fuzzy matching (Jaro–Winkler) is the most computationally expensive condition type. Placing an EXACT or TOLERANCE condition before a FUZZY condition in the same pass significantly reduces the candidate pool and improves throughput.

Building a ruleset

Navigate to Settings → Transaction Matching and select New Ruleset.
Name the ruleset and assign it to one or more account profiles.
Define the column mappings for your GL and subledger sources.
Add passes in priority order. Each pass specifies a match type and one or more conditions.
Run a dry-run simulation against a completed prior period to validate match rates.
Submit the ruleset for approval. Once approved, it runs automatically on all future reconciliations for the assigned profiles.

Transaction matching workbench