The problem this solves

A client reporting 99% on-time completion may still have a serious control failure. Completion measures that the process ran, not that the balances are right. What an auditor tests instead: aged reconciling items (a reconciliation can complete while carrying six-month-old unexplained differences), the denominator (99% of what? accounts never set up as profiles are invisible), rubber-stamp review (140 approvals in eleven minutes with no comments), segregation of duties, and supporting evidence (marked complete with no bank statement attached — the assertion exists, the proof does not).

Any mature reconciliation function is measured on aging, not on completion percentage. Build the aging report in phase one — it is the report that changes client behaviour. This use case is that report, plus the four others that reveal actual health.

Audience

Close managers who need portfolio status, bottlenecks, and completeness. Controllers who asked to review everything and should be given the dashboard instead of the queue. Internal audit and external auditors who want the evidence package and the exceptions, not the completion chart.

Every reconciliation in the period, aggregated

The compliance dashboard an auditor would actually use

• Six KPIs, completion first and labelled a vanity metric: items aged over 90 days, aggregate unexplained difference, auto-reconciled share, late count, closed-without-evidence count
• Aging chart: open reconciling items by bucket — the single most important view in ARCS
• Status by risk tier: where the close actually stands, for the accounts that matter
• Reviewer behaviour: approvals, rejections, average time, rejection rate, and the rubber-stamp flag
• Completeness check: loaded total vs trial balance, the gap, and the profiles that loaded $0 and auto-passed
• Threshold trap: aggregate permitted difference for a flat $10K rule versus percentage-plus-cap by tier, against group materiality

The portfolio view on top of UC10 and UC11

Reconciliation Compliance shows one reconciliation with its evidence; this page shows all of them and the patterns only the portfolio reveals — the reviewer who never rejects, the cluster of $0 auto-passes, the flat threshold that adds up to twice materiality. Transaction Matching’s unmatched balance arrives here through the cash reconciliations it feeds. Together the three are the ARCS module: assurance at transaction level, at balance level, and across the portfolio.

Recommended integration points

• Close-manager stand-up: aging and late counts by tier, every morning of the close
• Quarterly control review: reviewer table and completeness check as standing agenda items
• Audit fieldwork: the evidence package is a by-product of the work — two to three weeks of manual assembly a year that this replaces often funds the project

The numbers

The honest checklist

• ✓Your reconciliation KPI is completion percentage and audit findings keep arriving anyway
• ✓Nobody can say what the current aging of reconciling items is — which is itself the finding
• ✓A controller wants to approve everything, and you need to offer oversight instead of a queue
• ✗Reconciliations are not yet in a system that timestamps preparer and reviewer actions — there is nothing to measure until UC10 exists
• ✗The organisation is not ready for individual performance to become visible; this dashboard needs an executive sponsor, not just training

Try it now

The live demo aggregates every reconciliation in the chosen month and recomputes all six panels.

Things to try

• Type “Which reviewer is rubber-stamping?” and read the reviewer table: 38 approvals, 8 seconds each, 0% rejections. Then compare the Group Controller’s 89 approvals at nine minutes each
• Change the flat threshold to $5,000 and watch the aggregate permitted difference still exceed group materiality — the arithmetic, not the number, is the problem
• Filter to High risk and look at the aging chart — the 180+ bucket is where the planted suspense items live

Three audiences, three surfaces

This use case serves the second and third. ARCS ships seeded reports and dashboards, supports custom report definitions, and can burst on a schedule; anything more sophisticated pushes data to Oracle BI or a warehouse — scope that explicitly rather than discovering it in UAT. Design guidance mirrors FCCS: a small set of parameterised reports rather than forty static ones, and the aging report built early.

Every reconciliation → aggregate → the five signals

App UI — Component breakdown

Completion percentage is the vanity metric

• Aging of reconciling items — buckets at 30/60/90/180+ days. The single most important view in ARCS. An old unresolved item means an error nobody chased, a fraud, or a process that quietly broke.
• Unexplained difference by account and in aggregate — catches the threshold-aggregation problem.
• Late completion trend — is the process improving or drifting.
• Auto-reconciliation rate — efficiency, and a check that it is not creeping into material accounts.
• Rejection rate by reviewer — a reviewer with a 0% rejection rate over a year is not reviewing.
• Preparer workload distribution — finds the one person carrying 300 reconciliations.

The build orders the KPI row in that spirit: completion is shown, because clients will ask for it, but it is greyed and labelled, and the five signals that reveal actual health sit beside it. Aging is computed from item ages rather than reconciliation status on purpose — a reconciliation can be Closed and still carry a 200-day item, and that item counts.

A silent failure wearing the costume of success

Every loaded balance must resolve to a profile, and profiles are keyed on Account ID. If the GL extract’s segment combination does not match exactly, the balance does not land — and the reconciliation sits at zero, which presents as a clean reconciliation rather than a failure. A zero balance with a nil difference auto-passes. It does not error, reject, or appear in an exception queue. This is the ARCS equivalent of unmapped intercompany in FCCS.

// The two defences, both in this build:
// 1. Build profiles from the GL extract, not a hand-maintained list  → genProfiles()
// 2. Every period, compare Σ loaded balance to the trial balance total:
completeness = {
  loadedTotal:       Σ reconciliation.glBalance,       // what landed
  trialBalanceTotal: Σ reconciliation.trueBalance,     // what the GL holds
  gap:               trialBalanceTotal − loadedTotal,  // ≠ 0 ⇒ accounts missing from the universe
  missing:           reconciliations where keyMismatch  // 3 entities × 4 account types
}

Where the failure clusters — here 12 profiles across three EMEA entities — it is structural rather than random: delimiter format, leading zeros stripped by Excel, segment count, or recently changed entity codes. The panel names the entities and account types so the first check is obvious. It also answers the denominator question directly: those 12 are not in the 1% either. They are invisible, which is why completeness of the account universe is tested early and manual processes routinely fail it.

Three findings the portfolio view exists to surface

“Auto-reconcile anything under $10,000”

Four problems. Aggregation: 436 accounts each permitted $10,000 of unexplained difference is $4.36M in total — 2.2× group materiality — and “each was under threshold” is not a defence. Flat thresholds ignore account size: $10,000 is rounding on $2Bn and 83% of a $12,000 petty cash float; use the lesser of a percentage and an absolute cap, tuned by risk tier, which the panel shows landing at 0.35× materiality. Systematic error hides inside “immaterial”: 1,400 accounts all understated in the same direction is one broken interface, not noise. Auto-closing is the wrong response even where the threshold is right: a $9,000 difference persisting twelve months is a problem whatever its size. Better design: auto-close only on a nil difference, and use thresholds to route small differences to lighter review rather than none.

The reviewer who never rejects

ARCS timestamps everything, which is exactly why rubber-stamping becomes visible. The reviewer table computes, from the Approved and Rejected history entries, each reviewer’s decision count, average seconds, and rejection rate; one reviewer in this build approves in 4–12 seconds and rejects nothing, and is flagged when those three facts coincide over thirty or more decisions. The remedy is not a reprimand but a redesign: risk-tier the review so the controller takes only High-risk profiles, use summary profiles so related accounts approve as one, and give them the dashboard rather than the queue. What they usually want is assurance nothing is missed — a completeness and aging view. Oversight and approval are different needs.

Segregation of duties and the audit package

ARCS prevents preparer and reviewer being the same user; it cannot detect that the reviewer reports to the preparer. That assessment is design-time work, done against the org chart, and it belongs on the same quarterly agenda as the reviewer table. The audit evidence package — the reconciliation with balances and items, attached documentation, the full timestamped workflow history, questions and checklist responses, and the period lock — is a by-product of doing the work, not a separate exercise. Clients typically spend two to three weeks a year assembling it manually; that saving alone often funds the project.

The portfolio schema: risk tier, year, month

Aging’s NLQ schema is {intent, risk, year, period, confidence} — the same minimal shape as Ownership and Profitability, because the output is always the whole portfolio and the only things worth resolving are the period and an optional risk-tier filter. The few-shot examples deliberately include questions that name a metric rather than a filter — “which reviewer is rubber-stamping?”, “completeness check against the trial balance” — and map them to the dashboard for the right period, since every metric renders together and the user’s eye goes to the panel they asked about.

Cost model — Cost per query

Year, month, and a 3-value risk enum — the same footprint as Ownership. The portfolio itself is 516 profile evaluations per query, client-side, in tens of milliseconds; production ARCS computes these views on its own dashboards.

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

• Aging is computed from item ages, not from reconciliation status: a closed reconciliation can still carry a 200-day item, and it counts
• The completeness gap reconciles exactly to the planted key mismatches — unit-tested, so the panel cannot show a gap that the profile list does not explain
• Threshold exposure is additive by construction: permitted difference is summed per reconciliation, which is the arithmetic “each was under threshold” forgets
• Reviewer statistics come only from Approved/Rejected history entries — a reviewer with open work is not penalised for the queue they have not reached

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 Power User or the compliance-dashboard entitlement — wider than a preparer, narrower than everyone.

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: Portfolio-wide by nature, which is precisely why it needs its own entitlement rather than inheriting a preparer’s.
• 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 Aging & Audit Evidence

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 Aging & Audit Evidence 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 Aging & Audit Evidence

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