The problem this solves

A group's consolidated revenue is not the sum of every entity's revenue — some of that revenue is one entity selling to another entity in the same group, and from the outside investor's perspective nothing left the building. Distribution Network billing every store for transferred inventory, Corporate HQ charging every store a management fee, Corporate lending working capital to a joint venture — none of it is a transaction with the outside world, and none of it belongs in the consolidated income statement or balance sheet.

Miss an elimination and the group's reported revenue, expenses, receivables, and payables are all inflated by the same amount on both sides — a error that is easy to miss precisely because the income statement still "balances" (revenue and its offsetting expense both went up together) even though the whole thing is fictional at the consolidated level.

Audience

Consolidation accountants who run the elimination process each close. Controllers designing the intercompany transaction policy — which entities can bill which, at what markup. FP&A teams who need to understand why "consolidated revenue" is smaller than the sum of the entity-level numbers they see in the FP&A module.

A transaction type and a period

Matching pairs, a journal, and a break detector

• Matching pairs table: seller's IC revenue lined up against every buyer's IC expense — for a clean transaction type these sum to exactly the same total
• Elimination journal: a debit-the-revenue / credit-the-expense entry rendered in the same format a consolidation accountant would recognize, with a visible balance check
• Reconciliation-break simulator: a toggle that introduces a deliberate $18 mismatch on one loan pair and shows the guardrail catching it — the elimination journal visibly fails to balance and names the specific pair

After translation, before the group total is final

Eliminations run on translated (USD) balances, after Currency Translation and before Ownership & NCI is applied to whatever remains — this is the middle step of a three-step consolidation sequence this module's three use cases walk through in order.

Recommended integration points

• Close checklist: IC matching runs as a scheduled task before the elimination journal posts, with any break routed back to the entities involved for correction
• Transfer pricing review: Tax and Treasury periodically confirm the 15% DC markup and 2% management fee are still defensible arm's-length rates
• New entity onboarding: when a new store opens, it is automatically added to the Corporate Management Fee and DC Transfer buyer population — nothing has to be configured by hand

The numbers

The honest checklist

• ✓Entities in your group trade with each other — inventory transfers, management fees, royalties, intercompany loans
• ✓You need a systematic matching step before elimination, not a manual spreadsheet reconciliation each close
• ✓You want a break in an intercompany pair surfaced explicitly rather than eliminated anyway with a rounding plug
• ✗Your entities never transact with each other — there is nothing to eliminate
• ✗You need complex multi-tier eliminations (Entity A sells to B, B sells to C, all intercompany) — this demo models direct pairs only, not elimination chains

Try it now

The live demo runs all three transaction types entirely client-side.

Things to try

• Type "Show DC to store transfer eliminations" into the NLQ bar and watch it select the right transaction type
• Switch between the three transaction types and watch the elimination journal always balance — because it's built from the same source amount on both sides
• Select Intercompany Loan Interest, then click Introduce an IC mismatch — watch the Riyadh loan pair break and the journal flag it

Why "it nets to zero" is the whole test

An intercompany transaction, correctly recorded, is symmetric by construction — the seller's revenue line and the buyer's expense line are the same number, recorded on two different sets of books. That symmetry is both why elimination is possible (Dr the revenue, Cr the expense, done) and why a mismatch is a red flag rather than a rounding issue: if the two sides of a genuinely intercompany transaction don't match, one side recorded it wrong, translated it at a different rate, or recorded it in a different period — and that has to be found and fixed, not plugged.

Transaction generator → matching → journal

App UI — Component breakdown

Three retail-specific intercompany flows

DC → Store Inventory Transfer: the Distribution Network isn't a store — it doesn't sell to customers — but it does "sell" transferred inventory to every store and digital fulfillment entity at a markup over merchandise cost. That markup (15% here) is itself a transfer-pricing policy decision, and it generates real intercompany revenue and cost that must eliminate before the group's true external COGS is known.

Corporate Management Fee: every operating entity pays Corporate HQ 2% of revenue for shared brand, systems, and management services. This is one of the most common intercompany flows in any multi-entity retailer and one of the easiest to get wrong at scale — 42 buyer entities means 42 individually small amounts that are easy to miss in aggregate if the elimination isn't automated.

Intercompany Loan Interest: Corporate HQ funded the formation of the three minority-owned JV/equity entities (the same three modeled in Ownership & NCI) with intercompany loans. The interest income at HQ and interest expense at the borrower should match exactly every period — and because loan interest is a fixed, easily-verified number, it's the natural place this kit demonstrates what a genuine mismatch looks like.

Match first, eliminate second

// The core elimination test, applied to every IC pair
if (Math.abs(sellerAmount - buyerAmount) < tolerance) {
  // safe to eliminate: Dr seller revenue, Cr buyer expense, done
} else {
  // reconciliation break — do NOT eliminate; the difference
  // must be investigated and resolved first
}

This is deliberately the entire algorithm. Real FCCS applications add currency handling (an IC pair recorded in two different functional currencies can show a "difference" that's actually a translation timing effect, not a real break) and multi-period matching (a transaction recorded in one entity this month and the other next month), but the underlying test — do the two sides of this pair agree — is unchanged.

What the mismatch simulator actually demonstrates

The demo's Riyadh loan, when the mismatch toggle is on, shows the lender booking $720 of interest income and the borrower booking $702 of interest expense — an $18 gap. genICLoanInterest(introduceMismatch) injects this on exactly one pair so the other two loans keep matching perfectly, which matters pedagogically: a real reconciliation process is mostly clean pairs with the occasional break, not a wall of red.

The general lesson generalizes past this one use case, and echoes the All_ member trap in the Workforce module: a system that lets a mismatch resolve itself silently is worse than one that has no automated matching at all, because it creates false confidence. The right behaviour is always to surface the break with enough detail (which pair, which entities, how much) that a human can fix the root cause.

Cost per query

The LLM resolves one enum (txType: which of the three transaction types) plus year/scenario — it never touches a dollar amount. Matching, the balance check, and the journal entry are all client-side arithmetic against genICTransactions() / genICLoanInterest(), so the financial correctness of an elimination never depends on the LLM getting a number right.

Cost model — At-scale projections

LLM cost scales with query volume, not transaction volume — roughly $0.0002 whether the resolved transaction type covers 3 buyers or 42. Matching and journal generation itself is driven by transaction volume in a real system (more IC pairs means more matching comparisons), but at any retail-chain scale this remains trivial compute. The real cost driver in production is the process discipline around who is authorized to create intercompany transactions and how quickly a flagged break gets resolved before close.

Key files

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents bad eliminations

• Explicit match tolerance: Math.abs(lenderInterest - borrowerInterest) < 0.01 — anything outside a cent of rounding is a break, not silently accepted
• Break-specific messaging: the alert names the exact pair, both booked amounts, and the dollar difference — never a generic "reconciliation failed"
• Journal never fakes balance: the Dr/Cr entry always reflects the actual booked amounts on both sides, even when they disagree, so the imbalance is visible in the entry itself
• Buyer population derived, not maintained: new entities are automatically in scope for elimination, removing the "we forgot to add the new store to the elimination template" failure mode

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: FCCS User with intercompany access on both sides of the pair.

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: FCCS data access by Entity — and intercompany is the awkward case, because a matching view is inherently two entities at once.
• 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 IC Eliminations

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 IC Eliminations 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 IC Eliminations

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