The problem this solves

400,000 credit card transactions from the processor against 400,000 GL rows. Four people spend six days pairing them in spreadsheets, and the exceptions still arrive at period end as a wall. Transaction Matching is a high-volume matching engine at transaction level: configurable rules pair items between two or more data sources, auto-match clears 98%, and a human works the 2%. It is the most dramatic before-and-after in the product — one person, half a day — and it is also the module most often scoped by enthusiasm rather than by transaction volume.

It does not manage workflow. It produces matched sets and unmatched exceptions, and the unmatched balance feeds a Reconciliation Compliance reconciliation as its balance. That relationship is the reason to implement both rather than treating them as alternatives.

Audience

Treasury and cash-application teams reconciling bank, card-processor, and intercompany activity. Close managers deciding which three or four accounts genuinely need matching. Consultants who have to answer “why is our auto-match rate stuck at 71%?” with the composition of the exception population rather than another rule.

Two data sources, six rules, three data-quality scenarios

An auto-match rate you can explain, and an exception population you can act on

• KPI row: auto-match rate against the expected range for the scenario, matched/total rows, exceptions to work, and false matches — which must be zero
• Per-rule chart: rows matched by each rule with false matches overlaid, so loosening a rule shows its cost immediately
• Feeds RC: unmatched GL and bank totals, adjustments created for fees, and the net difference that becomes the reconciling item on the cash reconciliation
• Exception population: every unmatched row categorised by root cause with its real fix — and the honest total of how many are rule changes versus data changes

The second engine, deployed second

Most implementations deploy Reconciliation Compliance first across the whole portfolio, then add Transaction Matching for the three or four accounts that genuinely need it — bank, credit card, intercompany, sometimes AR cash application. Building TM first automates four accounts while the remaining 1,796 stay uncontrolled, which is not the finding the auditor raised. Its output lands on the cash reconciliation in UC10 and, through it, in the aging and evidence views of UC12.

Recommended integration points

• Discovery: the question that settles scope — “are they matching individual line items, or explaining a difference between two totals?”
• Daily close: TM loads daily; matching continuously through the month means period end presents a small exception queue rather than 400,000 rows at once
• Rate stuck low: sample 100 exceptions and categorise them — this page is that exercise, automated

The numbers

The honest checklist

• ✓A handful of accounts carry hundreds of thousands of transactions a month that people are pairing by hand — bank, card processor, intercompany, cash application
• ✓There is, or can be, a shared reference between the two systems — or you accept that amount-and-date matching needs an ambiguity guard and a bigger exception queue
• ✓Reconciliation Compliance is already in place to receive the unmatched balance with workflow and evidence
• ✗The reconciliation pain is control and visibility, not volume — TM would be expensive over-engineering
• ✗The two systems share no key and nobody will change the file — no volume of rule writing recovers a rate stuck at 71%

Try it now

The live demo runs the six-rule engine over 1,200 GL rows and their bank counterparts in real time.

Things to try

• Type “Why is the auto-match rate stuck at 71%?”, then tick Normalise references on load, then Bank file now carries the reference — watch ~75% become ~85% become ~96% without writing a single rule
• Choose Amount and date only and enable r6 — the rate jumps from ~12% to ~90%, and the false-match count tells you what the ambiguity guard is protecting
• Untick r1 and r2 on the clean scenario and read the exception table: the rows that should have matched are labelled as such, not lost

The scoping error, concretely

A client says they have a huge reconciliation problem in their intercompany and bank accounts. If that means volume of transactions, they need Transaction Matching and will be disappointed by Reconciliation Compliance alone. If it means no control or visibility over who did what, they need Reconciliation Compliance and Transaction Matching would be expensive over-engineering. Confusing the two engines is the most common scoping error on ARCS projects, and it is usually an expensive one. The discovery question that settles it: “When your team reconciles this account, are they matching individual line items against each other, or explaining a difference between two totals?”

Generate with known truth → run rules in sequence → categorise what is left

App UI — Component breakdown

Core objects and the four rule shapes

Reference fields are rarely formatted identically in two systems (INV-00123 vs 123), so normalisation belongs on load. In this build tmNormalizeRef() strips non-digits and leading zeros, and it is a toggle separate from the rules because that separation is the point: a transformation on load fixes a whole category of exceptions that no matching rule can.

Start tight, measure, loosen deliberately

r1  amount ==, ref ==, date ==           // measure the rate first
r2  amount ==, ref ==, |date| <= 3       // settlement window
r3  sum(bank rows w/ same ref) == amount // one deposit, several receipts
r4  sum(GL rows w/ payee+date) == bank   // batch payment
r5  |amount diff| <= max($5, 0.5%)       // fees / FX → adjustment
r6  amount ==, |date| <= 3, no ref       // ONLY if exactly one candidate each way

Tolerances matter as much as the attributes: an amount tolerance for small FX or fee differences, a date tolerance for a settlement window of one to three days, and normalisation of references. The build pattern that works: start with a tight one-to-one rule, measure the match rate, then add progressively looser rules for what remains — checking each addition does not produce false matches. Loosening too fast produces confident wrong answers, which are worse than an exception queue because nobody finds them.

Because bank rows are generated from GL rows, this build can check every match against the true pairing and report falseMatches per rule. The amount-and-date-only rule (r6) is where that matters: without a reference, two $250.00 payments three days apart are indistinguishable, so r6 only fires when exactly one candidate exists on each side. That guard is why the amount-and-date scenario reaches ~90% with a false-match count you can read off the chart rather than discover at audit.

Where a rate is stuck low, the cause is upstream

Do not write more rules against an undiagnosed exception population. Sample 100 unmatched items and categorise why each failed — the page does that for every row:

Only two of those six are rule changes. A rate around 71% is characteristic of a missing or unusable reference key, and no volume of rule writing recovers it. The consultant move is to return with the composition of the exception population, what rules can fix, and the one file change that takes them from 71% to 95% — which is exactly the sequence the two toggles on the page reproduce. Unlike Reconciliation Compliance’s monthly rhythm, TM loads daily; pushing clients toward daily loads changes the close more than any amount of rule tuning.

Two fields, and one of them is a boolean

Matching’s NLQ schema is {intent, scenario, normalize, confidence}. There is no entity, no period, no amount — nothing about the transactions themselves reaches the model, which is the right boundary for bank data. The scenario is a 3-value enum (clean / amountdate / poorref) and normalize is a nullable boolean that only flips when the user says something like “fix the key” or “normalise references”. The few-shot examples include the question a client actually asks — “why is the auto-match rate stuck at 71%?” — and map it to the poor-reference scenario with normalisation off, so the page opens on the problem before the fix.

Cost model — Cost per query

The cheapest query in the ARCS module — a 3-value enum and a boolean. The matching engine runs six rules over ~2,400 rows client-side in well under a second; production ARCS runs the same idea over millions of rows in its own engine.

Key files

Why ARCS is a separate data file from FCCS

They answer different questions and are separately licensed products. ARCS proves each balance is real; FCCS combines them into group results — assurance, then aggregation. Keeping epm-arcs-data.js separate mirrors that: it consumes the FCCS balance sheet for its GL balances but adds its own objects (profiles, formats, reconciliations, match types, rules) and never writes back. The deterministic FNV-1a hash (arcsRand) means every reconciliation and every bank row is reproducible on any machine, which is what makes the trap scenarios teachable.

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents bad control math

• Rules run most-restrictive-first, in a fixed order: TM_RULES is an ordered array; a row consumed by r1 is never available to r6
• Every GL row is matched or in exactly one exception category — unit-tested for all three scenarios, so nothing falls through the accounting
• Reference normalisation is a load-time transformation, not a rule: it is a separate toggle from the six rules on purpose, because that distinction is the lesson
• Tolerances create adjustments, not silent matches: r5 records the fee difference as an adjustment amount so the GL can be corrected rather than left wrong

Who is asking, and what are they allowed to see?

The demo answers neither question — it has a cookie gate and no notion of a user. In production these are the two questions everything else rests on, and they have different answers: authentication is who you are, authorization is what you may see. Corporate SSO settles the first. Only Oracle EPM Cloud can settle the second, and the single most important rule in this section is that this application must never become the place where that decision is made.

9.1 · The identity chain, end to end

9.2 · Federating the corporate identity provider

Oracle EPM Cloud does not replace your directory — it trusts it. The EPM Cloud identity domain is federated with the corporate IdP so authentication happens where it already happens, under policies security has already written.

For the browser application itself, use OIDC Authorization Code flow with PKCE. Not the implicit flow, which is deprecated and leaks tokens through the URL, and never a resource-owner password grant — a finance tool should not be capable of handling a password at all.

9.3 · From group membership to EPM roles

Roles are granted to groups, never to individuals, and the groups come from the directory. That one discipline is what makes joiner/mover/leaver work without anyone having to remember this application exists.

Entra ID group                    →  EPM role / entitlement
──────────────────────────────────────────────────────────────────
FIN-EPM-Analysts                  →  Planning User
FIN-EPM-Controllers-EMEA          →  Power User + EMEA data scope
FIN-EPM-Admins                    →  Service Administrator
──────────────────────────────────────────────────────────────────
Provisioned by SCIM. Remove the user from the group and the
entitlement disappears on the next sync — including here.

For this use case the relevant native entitlement is: ARCS User with access to the relevant match types.

9.4 · The architectural decision: who enforces?

This is the choice that determines whether the deployment is defensible. Both patterns appear in the diagram above; the difference is where the security boundary actually sits.

The shortcut to refuse. Pattern B built with a Service Administrator account and no filtering at all is the most common way this gets delivered, because it works perfectly in UAT — testers are usually over-entitled, so nobody notices that everyone can see everything. It fails at the first access review, and by then it is in production with real users depending on it.

9.5 · Data-level security is the part that matters

Role membership decides whether a user can open the application. It does not decide which rows they get back, and confusing the two is the most expensive mistake available here.

• For this use case: Match-type level access in ARCS; bank and processor sources are usually restricted to treasury and cash application.
• Apply it before aggregation, not after. Filtering a total that has already been computed across entities the user cannot see still leaks the total.
• The NLQ layer needs its own check. Layer 4 already validates that the resolved point of view uses approved members; production adds a second test — that the resolved POV sits inside this user’s scope — and it runs before the data call, not after. A natural-language interface is very good at asking for things politely; the authorization check must not care how the question was phrased.
• Fail closed. If entitlements cannot be resolved, return nothing and say so. An empty result is a support ticket; a permissive default is an incident.

9.6 · Provisioning, sessions and the leaver problem

• SCIM provisioning from Entra or Okta into the EPM Cloud identity domain (OCI IAM, formerly IDCS), covering joiner, mover and leaver. The mover is the case people forget — somebody changing region should lose the old scope, not accumulate both.
• No local user store. If this application keeps its own copy of who may do what, a leaver keeps access until somebody remembers to update it. Nobody ever does.
• Short-lived access tokens with refresh-token rotation; align session timeout with the data classification rather than with convenience.
• MFA and Conditional Access at the IdP — not reimplemented here. Device compliance and location policy come free with federation.
• Quarterly recertification of both the groups that grant access and the service account’s own entitlements, evidenced and signed.
• Break-glass access is a named, monitored, time-boxed account — never a shared credential in a password manager.

9.7 · What this means for Transaction Matching

9.8 · Security configuration checklist

• ✓Oracle EPM Cloud federated with the corporate IdP over SAML 2.0 or OIDC; the cookie gate removed entirely
• ✓Browser app uses OIDC Authorization Code + PKCE — no implicit flow, no password grant
• ✓MFA and Conditional Access enforced at the IdP, not reimplemented in the application
• ✓Roles granted to directory groups, never to individuals; SCIM covers joiner, mover and leaver
• ✓Enforcement pattern chosen deliberately — Pattern A where the API supports it, or Pattern B with filtering centralised and tested
• ✓Data-level security applied before aggregation, and the resolved POV checked against the user’s scope before the data call
• ✓No local user table and no local role table anywhere in the application
• ✓Every query logged against the real end user, even when a service account makes the call
• ✓Authorization failures fail closed and are logged as security events rather than swallowed
• ✓Quarterly recertification of access groups and of the service account’s own entitlements

From demo to a governed enterprise deployment

Everything above runs on synthetic data, a public LLM API key, a cookie gate, and no audit trail — deliberately, so the mechanics are inspectable. Taking Transaction Matching to production is not a rewrite; the 4-layer pipeline and the data-layer contract survive intact. It is a controlled-change program across six workstreams: architecture, LLM platform, security, SOX/audit, environment promotion, and operations. This section is the checklist we run with clients.

10.1 · Production reference architecture

10.2 · Choosing the LLM platform

The demo’s DeepSeek call is a placeholder for a single adapter, callLLM(system, user), behind Layer 3. Swapping the provider changes one function and zero business logic. Pick the platform the organisation already governs — the security and procurement review is the long pole, not the integration.

Put a model gateway in front of whichever you choose (Azure API Management, OCI API Gateway, Kong AI Gateway, LiteLLM, or Portkey): it owns key custody, per-team spend caps, routing and fallback between models, prompt/response logging, and lets you retire a deprecated model without touching the application.

10.3 · Security controls

10.4 · SOX, audit, and model-risk controls

A read-only NLQ layer does not change a financial-reporting control, but it is an interface to a SOX-relevant system and lands squarely in ITGC scope. Treat prompts, schemas, and eval sets as code — that single decision satisfies most of what an auditor will ask for.

10.5 · Dev → Test → Prod promotion

• Promoted artifacts: application build, prompt templates (versioned), approved-member schema snapshot, eval set, infrastructure config (IaC) — all from the same Git tag.
• Pipeline: branch → PR review → CI (tests + evals) → deploy to Test → UAT sign-off → CAB → deploy to Prod → smoke test. Hosting can stay on Cloudflare Pages/Workers or move to OCI Functions + API Gateway or the org’s standard platform — the code does not care.
• Configuration: per-environment secrets and endpoints injected at deploy; the same build runs in every environment.
• Metadata sync: a scheduled job refreshes dimension metadata into Layer 2 grounding with change detection, so a new entity or account appears in the approved lists without a code release.
• Rollback: previous build and previous prompt version retained; rollback is a redeploy, and because prompts are versioned it also reverts a prompt regression.

10.6 · Operating it

• SLOs: p95 latency, availability of the read path (the deterministic fallback keeps it alive when the LLM is down — already built), fallback rate as a quality signal, eval pass rate per release.
• Cost governance: per-user and per-team token budgets at the gateway; alert on anomalies; the unit-cost model earlier in this kit is the baseline.
• Model lifecycle: providers retire models on a schedule — re-run the eval suite on the successor before switching, and record the switch as a change.
• Incident runbook: LLM outage → fallback parser; EPM API outage → cached metadata with a stale banner; guardrail spike → review logs for injection attempts.

10.7 · What changes for Transaction Matching

10.8 · Production readiness checklist

• ✓LLM platform selected from the governed list, DPA / zero-retention terms on file, gateway in front of it
• ✓SSO integrated; authorisation derived from EPM security groups; cookie gate removed
• ✓Read-only EPM service account per pod, credential in a vault, rotation scheduled
• ✓Prompts, schema, and eval set version-controlled and under change management
• ✓Append-only audit log wired to the SIEM with the agreed retention
• ✓Golden-query eval suite passing in CI; results archived as release evidence
• ✓Dev / Test / Prod pipeline with gates, IaC, and a rehearsed rollback
• ✓Model-risk register entry and owner named; first re-validation date set
• ✓Metadata refresh job scheduled with change detection
• ✓SLOs, cost caps, and the incident runbook agreed with platform operations