The auto-match rate, held still and per rule
Auto match is why Transaction Matching pays for itself, and the rate is its health number. The app shows today; the useful report shows the trend per match type and per rule, because that is what turns a slipping number into a fixable cause.
Note: Transaction Matching is the half of ARCS, Oracle's reconciliation module, that pairs transactions between systems automatically, bank lines to ledger entries for example. The match rate is the share it pairs without a human, and it is the module's health number.
One question this page answers: our match rate fell, which rule, and since when? The whole module is mapped on the Account Reconciliation index.
◆ The rate, footed, three match types, one June, every row summing to its load.
The rate is confirmed automatic matches over transactions loaded. The app shows the ingredients on the Match Metrics dashboard and in the daily statistics by reconciliation type, unmatched, suggested, and confirmed per import date. What it does not do is hold the rate still over months, per rule, so a slipping rule shows up as a trend instead of an anecdote.
| Match type | Loaded | Confirmed | Suggested | Unmatched | Rate |
|---|---|---|---|---|---|
| Bank operating | 18,240 | 17,905 | 120 | 215 | 98.2% |
| AR lockbox | 4,610 | 4,388 | 98 | 124 | 95.2% |
| IC settlements | 1,768 | 1,618 | 75 | 75 | 91.5% |
| June total | 24,618 | 23,911 | 293 | 414 | 97.1% |
Every row foots: confirmed plus suggested plus unmatched equals loaded, and the columns sum to the totals. The 414 unmatched is the same 414 the aging page buckets; one sample world, one set of numbers.
◆ Making a drop diagnosable, the rule-naming habit, the per-rule trend, and the scheduled run.
A rate is only useful if a drop is diagnosable. That starts with a naming habit practitioners wrote down years ago: encode the rule number, match status, cardinality, and matched attributes in each rule's name. Then the per-rule counts read like a diagnosis. When IC settlements slips from 95 to 91.5, the per-rule trend says whether a tolerance got tight, a source changed its date format, or a new entity started settling in a currency no rule covers. The run itself schedules cleanly, runAutomatch from EPM Automate after each load, and the counts land in the star with the load date, which is what makes the trend a query.
The problem: The match rate fell and nobody can say which rule or since when.
What we build: Per-rule match counts land nightly with their load dates.
What you get: A drop arrives with a rule name and a start date attached.
- auto match
- Rules pair transactions across sources without a human. The engine of TM.
- confirmed
- Matched by rule, no review needed. The numerator.
- suggested
- The engine proposes, a human decides. Not in the rate.
- per-rule trend
- Rate by rule by month. Where a drop stops being a feeling.