The problem this solves

Budget vs actual variance analysis is one of the highest-frequency reporting tasks in any FP&A function. A regional CFO needs to know, at any point in the quarter: which entities are running ahead of plan, which are behind, and by how much across the income statement. Building that view from Oracle EPM Planning data today means either maintaining a static Oracle Analytics dashboard (expensive to build, slow to update) or extracting data to Excel and building pivot charts manually (hours of work per period).

The Planning Analytics Dashboard answers those variance questions through a natural language query, rendered as an interactive KPI dashboard with eight chart types. The same question that would take an OAC dashboard developer two days to configure takes this demo 4 seconds to generate.

Audience

Regional CFOs, finance business partners, and management reporting teams who need fast BvA analysis across entities, regions, and periods. EPM architects exploring whether to add an analytics layer above an existing EPM Planning deployment before committing to Oracle Analytics Cloud licences.

Natural language dashboard queries

Input is a plain-text analytics question. The NLQ parser extracts the analysis intent and translates it into a dashboard configuration:

An interactive KPI dashboard

The output is a live, interactive analytics dashboard rendered in the browser:

• 4 KPI cards: Total Revenue, Budget vs Actual variance ($ and %), Net Margin %, and a primary period metric — each with trend direction arrow
• Regional breakdown table: 4 regions × Plan + Actual + Variance columns, colour-coded variance cells
• Main chart: one of 8 chart types based on query intent or user selection
• Entity ranking table: all 44 entities ranked by revenue, colour-coded by region

All chart types are selectable via chip buttons after initial render — the user can switch from bar to waterfall to combo without re-querying.

In your EPM reporting stack

The Planning Analytics Dashboard sits above EPM Planning data and below a full enterprise BI layer. It is designed for the read-heavy, high-frequency analytical questions that don't justify Oracle Analytics Cloud build time but are too complex for ad-hoc SmartView grids.

• Monthly business review: CFO views regional BvA waterfall for the closed month before the deck is published
• In-meeting analysis: Finance business partner answers a variance question on the spot without leaving the meeting room to "pull the data"
• Period-end close triage: Controller checks which entities are furthest from plan before deciding where to focus close investigations
• Executive self-service: C-suite executives ask revenue questions in plain language without training on any EPM or BI tool

The numbers

The honest checklist

• ✓You need fast BvA variance analysis across regions/entities without Oracle Analytics Cloud build time
• ✓Your executives ask ad-hoc EPM questions in meetings that currently require an analyst to "pull the data later"
• ✓You have EPM Planning with a consistent revenue and income statement data model
• ✓You want 8 chart types selectable dynamically — not a fixed dashboard layout
• ✗You need row-level drill-through to transaction data — this dashboard operates at EPM member level, not GL detail
• ✗You need pixel-perfect print-ready dashboards — the output is browser-rendered, not PDF-optimised
• ✗You need multi-user concurrent sessions with user-level entitlement — the demo is single-tenant on the cookie gate

Try it now

The live demo renders all 8 chart types against pre-loaded EPM demo data with a real DeepSeek LLM call for query intent parsing.

Sample queries to try

• "APAC FY26 revenue trend line chart"
• "Compare plan vs actual EMEA waterfall"
• "Rank all entities by revenue"
• "Revenue and margin combo chart FY26"

The cost of a dashboard

A typical Oracle Analytics Cloud dashboard project for EPM data takes 4–8 weeks and costs $40K–$80K in consulting time. It produces a fixed set of visualisations that answer the questions the project team predicted — not the questions executives actually ask in the next quarter.

The NLQ analytics approach is not a replacement for enterprise BI — it is an answer to the question that comes before the enterprise BI project: "Is EPM analytics useful enough to our executives to justify the investment?" The Planning Analytics Dashboard lets you prove that in 4 hours of setup time and ~$9/month in LLM costs, using pre-loaded demo data, before you commit to the full OAC project.

Intent-to-dashboard pipeline

App UI — Dashboard component layout

What each KPI card shows and why

Each card shows a direction arrow (↑ green / ↓ red) based on the sign convention: revenue and margin variance up is favourable, so ↑ is green. For cost accounts the sign is inverted — cost variance up is unfavourable. The current demo uses revenue sign convention throughout.

How each of the 8 chart types is built

All 8 chart types share a single <canvas> element. Switching type destroys the existing Chart.js instance and creates a new one with the same data — no re-query to the LLM or data layer.

Analytics intent extraction

The analytics prompt is more intent-focused than the FP&A prompt. Instead of extracting dimension values, it extracts the analytical question type and maps it to a chart type:

// Analytics output schema
{
  "chartType": "bar"|"line"|"doughnut"|"radar"
              |"waterfall"|"stacked"|"ranking"|"combo",
  "metric": "revenue"|"margin"|"variance"|"growth",
  "entity": "TotalEntity"|"NA"|"EMEA"|"APAC"|"LAD"|<specific>,
  "scenarios": ["Plan","Actual"],
  "year": "FY26",
  "periods": ["Q1","Q2","Q3","Q4"],
  "groupBy": "region"|"entity"|"period"|"productType"
}

Chart type inference rules (few-shot examples)

• "trend", "over time", "quarterly" → line
• "waterfall", "bridge", "variance breakdown" → waterfall
• "rank", "ranking", "all entities", "top/bottom" → ranking
• "mix", "share", "breakdown by type" → doughnut or stacked
• "combo", "dual axis", "revenue and margin" → combo
• "profile", "radar", "multi-metric" → radar
• Default (comparison, regional, BvA) → bar

Cost per dashboard render

Cost model — At-scale projections

OAC Oracle Analytics Cloud estimates use published list prices for the Analytics Cloud Enterprise edition. NLQ analytics does not replace OAC for complex multi-subject-area reporting, drill-through, or pixel-perfect formatted output — it competes with OAC for the high-frequency, low-complexity BvA questions that are 80% of what executive users actually ask.

Key files

The waterfall chart implementation

Waterfall charts in Chart.js require floating bars — each bar is defined by [start, end] rather than a single value. The plan baseline is a solid bar; each regional variance is a floating bar above or below it; the final actual total is a different colour. The transparent "base" bars that position each variance column are rendered first with backgroundColor:'transparent' and borderWidth:0.

Tech stack — Every tool in this build

Known attack surfaces

Guardrails — What prevents bad dashboards

• Chart type validation: Only the 8 known types are allowed. LLM attempting a novel chart type falls back to bar.
• KPI null guard: If revenue data for the selected entity/period/scenario is zero or missing, KPI cards show "—" rather than $0 or a division-by-zero margin.
• Waterfall balance check: If the sum of regional variances doesn't equal total BvA variance within a rounding threshold, a notice is shown — the chart is still rendered but flagged as approximate.
• Ranking minimum: Ranking chart requires at least 4 entities. If the entity selection resolves to fewer, the chart type falls back to bar.
• Out-of-scope guard: Non-analytics questions (FP&A statements, SmartView grids) return the scoped error message with sample analytics queries.

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: Planning User with access to the Financials cube.

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: Planning access permissions on Entity — and, critically, applied before aggregation rather than after.
• 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 Planning Analytics

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 Planning Analytics 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 Planning Analytics

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