The problem this solves

The trial balance is the ledger’s statement of itself: every account, its debits, its credits, and the proof that the two sides agree. It is also the thing that leaves the ERP and becomes the EPM load, which makes two questions matter more than any others. Is it complete — not merely balanced? And can any number on it be traced back to the journal line that created it?

Balanced and complete are different properties, and conflating them is how a period gets closed on a ledger that is missing activity. Unposted journals are excluded from the trial balance by design; the totals still tie perfectly, and the report looks finished. The close checklist exists to make that distinction impossible to miss, and the drill-back exists so that when a downstream EPM number looks wrong, the answer is two clicks away rather than a support ticket.

Audience

Close managers deciding whether a period can be closed. GL accountants investigating a balance. EPM teams who need to know whether the number they loaded was the final one — and auditors who will ask to see the journal behind a balance.

Posted journal lines, and nothing else

Period status is derived from the position of the period: FY26 August is Open, everything before it Closed, everything after Never Opened, and FY25 mostly Permanently Closed.

Three views, one ledger

• Entity trial balance with Dr/Cr per account, a totals row, the Dr = Cr proof, net income, and the unposted count
• Drill-back — click any row and see every journal line behind it with its batch, source and status
• Tie-out table comparing each P&L account’s GL balance to the FP&A income statement, with the difference column
• Group trial balance across 44 companies with a balance-sheet-versus-P&L chart
• Close checklist — five gates, a plain verdict, and the companies blocking it with their excluded dollars

The handover point between ERP and EPM

This is where the general ledger stops and the EPM estate begins. Journals (UC17) creates what this aggregates; Chart of Accounts (UC16) defines the combinations it aggregates by. Downstream, this trial balance is what FP&A (UC2) reports, what FCCS (UC7–9) translates and consolidates, and what ARCS (UC10) reconciles. The tie-out table proves that relationship rather than asserting it.

Recommended integration points

• Close stand-up: the checklist and the named blocking companies, every morning of the close
• EPM load validation: compare the group trial balance to what actually arrived in EPM — the completeness check ARCS (UC12) performs from the other side
• Audit fieldwork: pick a balance, drill to the journal lines, read the source — that is the walkthrough

The numbers

The honest checklist

• ✓Your close has ever proceeded with unposted journals outstanding, because nobody had the number in front of them
• ✓EPM numbers get questioned and the answer requires someone to go and look in the ERP
• ✓You want to show, not assert, that the EPM figures come from the general ledger
• ✗You need the full close task list — accruals, revaluation, allocations, roll-forward. These are five GL-integrity gates, not a close calendar
• ✗Your reporting is done directly in the ERP with no EPM layer — the tie-out has nothing to prove

Try it now

The live demo builds a trial balance for any company, the whole group, or the close checklist across all 44.

Things to try

• Scroll to the tie-out table and read the difference column — every P&L account is zero. That is the GL reproducing the FP&A income statement exactly, and it is enforced by a test rather than by hope
• Click the Store Revenue row and read the drill-back: the AR batch, its source, its status, and the code combination on each line
• Type “Can we close the period?” — four gates pass, one fails, and the blocking companies are named with the dollars that would be missing

Balanced is not complete

A trial balance that balances proves one thing: that the journals which were posted were double entries. It proves nothing at all about whether the right journals were posted. Exclude a $12,500 accrual because it is still awaiting approval and the trial balance balances exactly as before — the totals just happen to be smaller, and there is nothing on the face of the report to say so.

This is why the close checklist matters more than the balance check, and why the KPI row states the excluded value in dollars rather than a count. It is also why the same number is used in three places on the page — the KPI, the gate, and the offender list — rather than recomputed differently in each, which is how reports quietly start disagreeing with themselves.

One aggregation, three views

App UI — component breakdown

Sum the posted lines, keep the excluded ones visible

genTrialBalance(entityId, year, period) {
  batches = genJournalBatches(entityId, year, period)
  for each batch:
    if status !== 'Posted':
      unpostedCount++, unpostedValue += Σ debit      // counted, then excluded
      continue
    for each line: rows[account].debit += line.debit, .credit += line.credit
  return { rows, totalDebit, totalCredit, balanced, netIncome, unpostedCount, unpostedValue }
}

The includeUnposted option exists and is used in one place only — a unit test asserting that including them changes the totals, which is the proof that exclusion is actually happening rather than the unposted batch simply being empty. Net income is derived from the P&L rows rather than stored, so it cannot disagree with the accounts above it.

The group trial balance is the same function run across all 44 companies and summed by natural account. It balances because each company balances — and the test asserts both, because a roll-up that balanced while a component did not would mean two errors cancelling, which is worse than one error.

The capability EPM users ask for first

When a number in an EPM report looks wrong, the question is always the same: what is behind it? In a real estate that means drilling from the EPM cell to the GL balance, from the balance to the journal lines, and from the line to the subledger transaction. This demo implements the middle step, which is the one that most often has no answer.

drillToJournalLines(entityId, year, period, account) →
  [{ batchId, source, category, status, co, cc, acct, prod, ic, fut, debit, credit }]

Every returned line carries its batch, its source and its status, so the answer to “where did this come from” is not just “a journal” but “the AR batch that posted August’s customer invoices, and here is its status.” The drill panel deliberately shows the full six-segment combination too, because the reason a balance is unexpected is frequently a cost centre or product that should not have been used — which loops straight back to the cross-validation rules in UC16.

Five gates, and the proof that the ledger feeds EPM

The checklist runs across all 44 companies and names the blockers with their excluded dollars, because “13 unposted batches” is an abstraction and “NYC Flagship, $12,500 excluded” is an action.

The tie-out

tieOutToEPM(entityId, year, period) →
  per P&L account: { glNet, epmValue, diff, ties }
  // glNet   = the GL trial balance, sign-corrected for the account's natural side
  // epmValue = genIS(entityId, year, 'Actual')[period]['A_' + account] × 1000
  // asserted in CI across 5 entities × 3 periods — every account, every time

This is the strongest claim the module makes and the one most worth testing rather than asserting. The GL was built by posting journals whose amounts come from genIS(); the trial balance sums those journals; so the trial balance must reproduce genIS() exactly. It does, to the dollar, and CI fails if it ever stops. That is the honest version of “ERP feeds EPM” — not a diagram with an arrow on it, but a number you can check.

A view enum is the whole trick

The trial balance schema is {intent, entity, year, period, view, confidence}, and view does the heavy lifting: entity, group, or close. The few-shot examples teach it that “can we close the period?” and “period close checklist” both mean close, that “consolidated” and “all companies” mean group, and that naming an entity implies entity. One field turns three quite different screens into one natural-language surface, which is the pattern worth reusing whenever a page has modes rather than filters.

Cost model — cost per query

The close checklist is the heaviest computation in the module — it builds every company’s trial balance for the period — and still completes in well under a second client-side. Production reads it from the ERP.

Key files

Why the ledger is generated from genIS(), not beside it

The tempting shortcut is to generate plausible journals independently and let the trial balance be roughly right. That would have broken the one claim this module exists to make. Instead every journal line amount is driven by genIS(), so the posted trial balance reproduces the FP&A income statement to the dollar — asserted by unit test across multiple entities and periods. It is the same discipline the FCCS module applies when it constructs a local balance sheet that balances before translation: if the synthetic data does not tie, the demo teaches the wrong lesson.

Tech stack — every tool in this build

Known attack surfaces

Guardrails — what prevents bad ledger math

• Debits equal credits for every company: asserted across all 44 entities, and again on the group roll-up — an out-of-balance trial balance is not a display bug, it is a broken ledger
• Unposted is excluded, explicitly and visibly: the same fact drives the KPI, the close gate and the offender list, so it cannot be reported inconsistently in two places
• Period status is derived, not stored: periodStatus() computes Never Opened / Open / Closed / Permanently Closed from the period’s position relative to the current one, so the calendar cannot contradict itself
• The tie-out is a test, not a claim: the page shows it, and CI enforces it — the strongest guardrail in the module

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 ERP Cloud (Fusion) 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 ERP Cloud (Fusion) does not replace your directory — it trusts it. Fusion 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 ERP 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                    →  ERP role / entitlement
──────────────────────────────────────────────────────────────────
FIN-EPM-Analysts                  →  General Accountant (inquiry)
FIN-EPM-Controllers-EMEA          →  General Accounting Manager + EMEA data scope
FIN-EPM-Admins                    →  Financial Application Admin
──────────────────────────────────────────────────────────────────
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: General Accountant or General Accounting Manager for the group view; opening and closing periods is a separate privilege this tool never needs.

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: Data access sets scoped to ledgers and balancing segment values — the group trial balance requires access to every ledger in it, which is a much smaller population than it sounds.
• 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 Fusion security console, 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 Trial Balance & Period Close

9.8 · Security configuration checklist

• ✓Oracle ERP Cloud (Fusion) 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 Trial Balance & Period Close 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 window onto the general ledger does not change a financial-reporting control, but the GL is the most SOX-relevant system in the estate and this 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 segment-value 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.
• Chart of accounts drift: a scheduled job refreshes segment value sets and the cross-validation rule list into Layer 2 grounding with change detection, so a new cost centre or company appears in the approved lists without a code release — and an unmapped one is surfaced rather than silently accepted.
• 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.
• Close-window load: GL queries spike hard in the first five working days. Size for the close, not the average, and cache the chart of accounts aggressively — it barely changes.
• 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; ERP API outage → cached metadata with a stale banner; guardrail spike → review logs for injection attempts.

10.7 · What changes for Trial Balance & Period Close

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 ERP roles, ledgers and data-access sets; cookie gate removed
• ✓Read-only ERP integration user per environment, credential in a vault, rotation scheduled, no posting privilege
• ✓Prompts, segment value sets, 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
• ✓Chart-of-accounts refresh job scheduled with change detection for new and unmapped values
• ✓SLOs sized for the close window, cost caps, and the incident runbook agreed with platform operations