The problem this solves

Not every entity in a group is wholly owned. Local foreign-ownership rules in several retail markets — Mexico, Saudi Arabia, and others — require a local partner to hold a minority stake before a foreign retailer can operate there at all, and some international expansion happens through minority equity stakes rather than acquisitions. Consolidating these entities correctly means answering two questions for each one: does the parent control it, and if so, how much of its results belong to outside shareholders rather than the parent?

Get the method wrong — full-consolidate an entity that should be equity-method, or forget to carve out NCI on one that should be full-consolidated — and the group's reported revenue, assets, and net income are all misstated, not by a rounding amount but by the entire uncontrolled or unconsolidated entity.

Audience

Consolidation accountants and controllers who set the group's ownership structure and consolidation method by entity. Corporate development and M&A teams evaluating new market entry structures (wholly owned vs joint venture vs minority stake). FP&A teams who need to understand why "consolidated net income" is smaller than the sum of every entity's reported net income.

Three entities, three ownership structures

Every other entity in the cube defaults to 100% ownership, Full consolidation, and zero NCI.

Parent share, NCI share, and one equity-method line

• Ownership cards: one per non-wholly-owned entity, showing the ownership %, the method badge, and the plain-language reason for that structure
• Stacked chart: for the two Full-consolidated entities, Parent Share vs NCI Share of net income, side by side
• Consolidation detail table: subsidiary revenue and net income (100%, before any ownership adjustment) next to what actually lands in the consolidated result

The last step of the consolidation sequence

Ownership and NCI apply after Currency Translation (so the math runs on USD-denominated results) and after Intercompany Eliminations (so IC transactions with the JV/investee entities are already netted out) — the third and final step this module's three use cases walk through in sequence.

Recommended integration points

• New market entry: before signing a JV agreement, model both the 70%-Full and a hypothetical 40%-Equity structure to see the NCI/equity-pickup impact on consolidated net income before the deal terms are final
• Board reporting: distinguishing "Net Income Attributable to Parent" (what shareholders actually care about) from "Consolidated Net Income" (which still includes 100% of Full-consolidated subsidiaries, NCI and all)
• Local-partner renegotiation: if Mexico City's local-partner stake changes from 30% to 20%, this is exactly the calculation that needs to re-run

The numbers

The honest checklist

• ✓Any entity in your group is less than 100% owned — a JV, a strategic stake, or a local-partner requirement
• ✓You need to distinguish "consolidated net income" from "net income attributable to the parent" in board or investor reporting
• ✓You're modeling a new market-entry structure and need to see the consolidation impact of different ownership percentages before signing
• ✗Every entity in your group is wholly owned — there is no NCI or equity method to calculate
• ✗You need the Proportional or Cost consolidation methods modeled explicitly — this demo implements Full and Equity only, the two methods this retailer's three minority structures actually use

Try it now

The live demo computes NCI and equity-pickup for all three entities in real time.

Things to try

• Type "Show NCI for FY26" into the NLQ bar and compare Mexico City (70% Full) against Bogotá (40% Equity) — notice Bogotá contributes only one small line to consolidated income, while Mexico City contributes its full revenue and assets plus an NCI carve-out
• Switch scenario to Actual and watch every NCI and parent-share figure recompute from the underlying entity P&L

Control is a legal test, not an ownership percentage

The accounting question is not "how much of this entity do we own" — it's "do we control it." Ownership above 50% is a strong presumption of control and typically drives Full consolidation. Ownership in the 20–50% range typically indicates significant influence without control, which drives the Equity method. But these are presumptions, not mechanical thresholds — a 45% stake with contractual board control still consolidates fully, and a 55% stake subject to substantive minority protective rights might not. This demo models the common case (ownership percentage determines the method) because that is the right level of fidelity for illustrating the consolidation math; a production system's method assignment is a judgment call documented per entity, not a formula.

Ownership lookup → method branch → NCI/equity math

App UI — Component breakdown

Full vs Equity — what actually differs

The demo deliberately shows both methods side by side on entities with genuinely different structures (Mexico City and Riyadh are both foreign-ownership-driven JVs at Full+NCI; Bogotá is a strategic minority stake at Equity) so the contrast is visible in the same screen rather than described in the abstract.

Why the two numbers can diverge

Ownership percentage is an economic-interest measure — how much of the entity's value belongs to the parent. Consolidation percentage (or "control") is a legal/governance measure — whether the parent's financial statements should include the entity's results at all, and at what proportion. In the common case these move together (own more than half, you control it), which is why this demo's OWNERSHIP table uses ownership percentage as the practical driver of method. But the two can separate: contractual voting rights, board composition, and protective rights for minority shareholders can all shift where control actually sits independent of the raw ownership percentage.

This matters operationally because the method decision, once made, has to be revisited whenever the governance arrangement changes — a JV agreement renegotiation, a shareholder rights amendment — not just when the ownership percentage itself changes.

Two NCI lines, not one

// Full consolidation NCI — computed on two different bases
nciNI     = subsidiaryNetIncome × (1 - ownershipPct)   // income statement
nciEquity = subsidiaryTotalEquity × (1 - ownershipPct) // balance sheet

nciNI is the minority shareholders' share of this period's net income — it appears below consolidated net income, splitting it into "Net Income Attributable to Parent" and "Net Income Attributable to Non-Controlling Interests." nciEquity is the minority shareholders' share of the subsidiary's cumulative equity — it appears as a separate line within total equity on the consolidated balance sheet, distinct from the parent's own retained earnings and common stock. These are two different bases (one period's flow, one point-in-time stock) computed the same way, and conflating them — showing only one NCI number instead of both — is a common simplification error worth calling out explicitly.

Cost per query

Ownership has the cheapest query of the nine use cases — there's no entity to resolve, only year and scenario, since all three non-wholly-owned entities always render together. The value is in modeling Full-vs-Equity consolidation correctly, not in retrieval, and the LLM's job here is correspondingly small.

Cost model — At-scale projections

LLM cost is flat per query at roughly $0.0002, regardless of how many non-wholly-owned entities the group has — the query only resolves year and scenario, and every non-wholly-owned entity renders in the same response. NCI and equity-method calculation itself scales linearly with the number of non-wholly-owned entities, which even for a large group is a small fraction of the total entity count — trivial client-side compute at any realistic scale. The real cost driver in production is maintaining the ownership table itself as stakes change through renegotiation, dilution, or buyout.

Key files

Why the same three entities appear in Eliminations too

Mexico City, Bogotá, and Riyadh are the borrowers in the Intercompany Loan Interest transaction type in UC8 — Corporate HQ's formation funding for exactly these three minority structures. That's deliberate cross-linking, not coincidence: a real consolidation process treats ownership structure, intercompany funding, and translation as three views of the same underlying entity relationships, and the demo data is built to make that connection visible rather than modeling each use case with an unrelated cast of entities.

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents bad consolidation math

• Method branch is explicit, not inferred at render time: computeConsolidation() checks the method once and returns a completely different result shape for Equity vs Full — the two paths can't be accidentally blended
• Parent share reconciles to subsidiary NI exactly: parentNI + nciNI === subsidiaryNI by construction for Full-consolidated entities — no rounding drift between the two shares
• Default is always 100% / Full / wholly owned: any entity not explicitly listed in OWNERSHIP is guaranteed to consolidate at 100% with zero NCI, so a missing configuration entry fails safe rather than silently under-consolidating

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; Manage Ownership is typically restricted to a small consolidation group.

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, plus restricted access to the ownership management screens themselves.
• 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 Ownership & NCI

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 Ownership & NCI 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 Ownership & NCI

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