The problem this solves

Support cost centers don't just serve the business — they often serve each other. IT runs the servers Facilities' building-management system depends on; Facilities provides the office space IT's own staff sit in. Allocating IT's cost to stores while ignoring what it owes Facilities (and vice versa) systematically understates both centers' true fully-loaded cost — and worse, which method you use to handle this circularity changes how much of the total ends up "labeled" IT versus Facilities by a material amount, even though the total dollars reaching stores never changes.

This matters whenever cost centers get compared, budgeted, or benchmarked against each other: a support function that looks cheap because a reciprocal relationship went unaccounted for isn't actually cheap — the cost is real, just mislabeled.

Audience

Cost accounting and FP&A teams who own the allocation methodology for internal service/support functions. IT and Facilities finance business partners who need to understand why their fully-loaded cost differs from their direct budget. Anyone deciding which allocation method (Direct, Step-Down, or Reciprocal) their organization should standardize on.

Two cost centers, a mutual service relationship

Both centers' direct-cost bases are sized as a percentage of total company revenue at runtime, matching the same pattern the Allocation Waterfall pools use.

The same total, four different labelings

• KPI row: the selected method's IT→Stores, Facilities→Stores, and combined total
• Stacked bar chart: all four methods compared side by side — visually confirms the total bar height never changes, only the IT/Facilities split within it
• Worked math panel: the actual equations for whichever method is selected, filled in with real numbers — including the simultaneous-equation solve for Reciprocal
• Comparison table: all four methods' numbers in one place, selected method highlighted

The harder case the Allocation Waterfall doesn't cover

Allocation Waterfall (UC13) allocates from cost pools down to entities — a one-directional cascade. This use case handles the case where two cost centers allocate to each other as well as downstream, which the simple waterfall model can't represent. Both feed into the same underlying idea: cost has to land somewhere defensible, and the method used to get it there has to be explainable, not just computable.

Recommended integration points

• Standardizing allocation methodology: before an organization picks Direct, Step-Down, or Reciprocal as its house standard, this shows exactly what's traded off — Direct is simplest but least accurate; Reciprocal is most accurate but requires solving a system every period
• Cross-charge disputes between support functions: when IT and Facilities disagree about whose budget should absorb a shared cost, the Reciprocal method's simultaneous-equation solve is the defensible answer, not a negotiated split
• Benchmarking support function cost: comparing IT's cost-per-store against an industry benchmark only makes sense if the allocation method matches what the benchmark assumes

The numbers

The honest checklist

• ✓Two or more of your support/service cost centers genuinely serve each other, not just downstream business units
• ✓You need to defend a cost-center's fully-loaded cost figure to someone who will ask "why this number and not a different one"
• ✓You're choosing (or reconsidering) which allocation method to standardize on and want to see the actual dollar impact of that choice, not just the theory
• ✗Your cost centers only allocate downstream to final entities, with no service relationship between the centers themselves — that's the simpler case in UC13
• ✗You need more than two reciprocal centers modeled simultaneously — this demo's 2×2 system illustrates the mechanics; production systems with 3+ mutually-reciprocal centers need a full matrix solve, not the closed-form algebra shown here

Try it now

The live demo recomputes all four methods in real time and highlights the one currently selected.

Things to try

• Switch between all four methods and watch the stacked bar chart — the total bar height never moves, only where the IT/Facilities split line falls within it
• Type "Solve the simultaneous equations for reciprocal costing" and read the worked-math panel — check that IT × 0.92 + FAC × 0.88 equals the same total every other method produces

The circularity is the whole problem

A one-directional allocation (pool → entities) is a closed-form calculation with no ambiguity. A reciprocal relationship — IT's true cost depends on Facilities' true cost, which depends on IT's true cost — isn't closed-form unless you either break the circularity by fiat (Direct, Step-Down) or solve it as a system (Reciprocal). This demo exists specifically to make that choice, and its consequences, visible and comparable rather than abstract.

Method branch → four independent calculations

App UI — Component breakdown

What actually differs

Solving the 2×2 system in closed form

IT  = itDirect  + pFac2IT × FAC
FAC = facDirect + pIT2Fac × IT

// substitute FAC into the IT equation:
IT = itDirect + pFac2IT × (facDirect + pIT2Fac × IT)
IT × (1 - pFac2IT × pIT2Fac) = itDirect + pFac2IT × facDirect
IT = (itDirect + pFac2IT × facDirect) / (1 - pFac2IT × pIT2Fac)

FAC = facDirect + pIT2Fac × IT   // back-substitute

With pFac2IT = 0.12 and pIT2Fac = 0.08, the cross-term pFac2IT × pIT2Fac = 0.0096 is small, so the closed-form solve converges to essentially the same answer an iterative "allocate back and forth until it stabilizes" approach would reach — but the closed-form version is exact and instant, with no convergence tolerance to tune. A larger, N-center reciprocal system would need a full matrix solve (Gauss-Jordan or similar) instead of this 2-variable algebra; this demo intentionally keeps to 2 centers so the math stays inspectable in a worked-math panel rather than a matrix inversion nobody can eyeball.

Redistribution, not creation or destruction

Every method starts from the same two direct-cost numbers (itDirect + facDirect) and every method's store-bound total works out to exactly that same sum — verified directly in testing across all four methods for the same year/scenario. This is the single most important sanity check on the whole demo: if a method's total-to-stores ever diverged from the others, that would mean cost was being invented or lost, not just relabeled, which would be a bug, not a legitimate methodology difference. The four methods differ only in which center gets credited with how much of that fixed total — never in the total itself.

A method-selection schema, not an entity-lookup one

Unlike most of the site's other use cases, Reciprocal's NLQ schema — {intent, method, year, scenario, confidence} — has no entity field at all: there's nothing to look up, only a method to select from a fixed enum of 4 values. The few-shot examples and the semantic-fallback keyword matcher both key off phrases like "direct," "step down...IT first," and "reciprocal/simultaneous" rather than any lookup table, since the entire space of valid answers is 4 strings.

Cost model — At-scale projections

LLM cost is flat per query at roughly $0.0002 — the smallest lookup space of any use case on the site (4 fixed method strings). The reciprocal solve itself is O(1) — a closed-form 2-variable algebraic solution, not an iteration — so it stays instant regardless of company size. The real production cost driver would be extending this to N>2 reciprocal centers, which requires a genuine matrix solve rather than this demo's closed-form shortcut.

Key files

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents bad reciprocal math

• Method is an explicit enum, never inferred: exactly 4 valid methodId values, validated against SCHEMA.reciprocalMethods before the calculation runs — an unrecognized method string falls through to the safe default (reciprocal) rather than silently mis-branching
• Every method's output is cross-checked against the same total: the demo computes all four methods every time it renders (not just the selected one), so a regression that broke the total-preservation property would be immediately visible in the comparison table, not hidden behind a single-method view
• pctToOther + pctToStores is enforced to sum to 1.0 for each center in RECIPROCAL_CENTERS — a center that "serves itself" more or less than 100% of its output would silently create or destroy cost

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: PCMCS User; changing the costing method is a model change under change control, not a user action.

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: PCMCS application and POV access, with rule-set maintenance restricted to the cost-accounting owner.
• 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 Reciprocal Costing

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 Reciprocal Costing 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 Reciprocal Costing

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