FCCS supports two journal types that serve opposite architectural purposes. Consolidation Journals post adjustments directly within FCCS and stay there — they affect consolidated results but never flow back to ERP. Enterprise Journals are different: FCCS controls the creation and approval process, but the actual posting goes to the ERP General Ledger. From there, the data reloads into FCCS through the normal Data Integration pipeline — just like any other GL data.
The critical architectural distinction: Consolidation Journals write to
FCCS_Journal Input — a data source permanently protected from Data Integration
loads. Enterprise Journals write to the ERP GL and then land in
FCCS_Managed Data on the next DI load cycle. FCCS does not keep Enterprise
Journal data separately in its consolidation cube.
FCCS owns the process, not the posting destination. Enterprise Journals solve a governance and close-control problem: finance teams identify adjustments needed during consolidation review, and rather than phoning the ERP team, they create, approve, and push those adjustments through a controlled workflow in FCCS — which then posts to the ERP GL and flows back in on the next load. One journal framework across ERP + EPM, rather than fragmented processes and reconciliation headaches.
Adjustments made directly within FCCS that affect consolidated results but do not flow back to ERP. Used for consolidation-specific entries: reclassifications, eliminations, top-side adjustments, and group-level statutory entries.
FCCS_Journal Input — a separate data source permanently protected from DI Replace-mode loads.FCCS owns the process (creation, approval, validation, posting control) but the data destination is the ERP General Ledger. After posting, the data reloads into FCCS_Managed Data via the normal DI pipeline. FCCS does not store Enterprise Journal data separately in its consolidation cube.
FCCS_Managed Data on the next DI run — like any other GL source data.Both journal types have approval workflows inside FCCS. The critical difference is the
data destination. Consolidation Journals stay in FCCS forever in
FCCS_Journal Input. Enterprise Journals are posted to the ERP GL — FCCS
is the governance and control interface, not the data store. After an Enterprise Journal
posts to ERP, the only way it appears in FCCS is via the next DI load from the GL.
Process
Ledger (GL)
into FCCS
Consolidation
After an Enterprise Journal posts to ERP, there is a window before the next DI load where the adjustment is in ERP but not yet in FCCS — unlike a Consolidation Journal, which is instantly visible on post to FCCS_Journal Input.
Three EJ posting methods (Oracle documented): ① Direct connector to Oracle Cloud Financials (pre-built, automated); ② Enterprise Journals APIs for direct posting to other ERP systems; ③ File-based via EPM Automate exportEJJournals command for any ERP. The method is configured per Target definition — not all posting is automatic or real-time.
When an approver rejects an Enterprise Journal, it does not disappear. It is returned to the submitter with the approver's rejection comments attached. The journal returns to Working status. The submitter corrects and resubmits. The approval clock resets — the approver sees it as a fresh submission. This loop is fully audited: every rejection event is timestamped in the journal history.
When the consolidation engine reads an entity's data, it aggregates both
data sources together. The P&L and Balance Sheet visible in reports is
FCCS_Managed Data + FCCS_Journal Input combined.
FCCS_Journal Input holds Consolidation Journal data only.
Enterprise Journal data, after reloading from the ERP GL, appears in
FCCS_Managed Data alongside regular trial balance figures — it is not
separately identifiable by data source after the DI reload.
Posting any Consolidation Journal to an entity that is currently at OK (Consolidated) immediately moves that entity back to Impacted. The system has detected that the data has changed since the last consolidation run. The consolidated figures stored at the parent level no longer reflect the posted journal.
Wrong Scenario POV posts successfully but silently to the wrong data slice. FCCS does not cross-check the journal's Scenario against any expected value. The journal appears as Posted. Consolidation reruns cleanly. The adjustment is simply missing from Actual and present (incorrectly) in Budget. Discovery typically happens during review when the analyst notices Actual is still unbalanced. The fix: unpost the wrong journal, correct the Scenario header, repost, rerun consolidation for both affected Scenarios.
| Feature | Enterprise Journals | Consolidation Journals |
|---|---|---|
| Purpose | Governance of journal creation, approval, and posting to ERP | Adjustments within FCCS for consolidation reporting |
| Where Created | FCCS (via Enterprise Journals module) | FCCS (within the consolidation cube) |
| Where Posted | ERP General Ledger | FCCS Consolidation Cube |
| Governance Role of FCCS | Controls who, when, what, and how journals are posted | Controls how adjustments affect consolidated results |
| Storage in FCCS | Not stored in cube; posted to ERP and reloaded as GL data into FCCS_Managed Data |
Stored directly in FCCS cube via FCCS_Journal Input |
| Audit Trail | Full workflow, approvals, and audit trail in FCCS + ERP | Audit trail within FCCS journal module |
| Impact on Consolidation | Indirect — via GL load post-ERP (DI reload required) | Direct — impacts consolidation results immediately on post |
| Use Case | ERP-aligned journal governance during close | Top-side adjustments, reclassifications, IC eliminations |
| Situation | Journal Type | Reason | GlobalMerge Example |
|---|---|---|---|
| Routine reclassification, same amount, same entity, repeats monthly | Consolidation Journal | Consolidation-layer only, low risk, optional approval sufficient — stays in FCCS_Journal Input | BritEdge monthly depreciation reclassification |
| Cross-entity elimination that does not recur systematically | Consolidation Journal | Consolidation-layer adjustment — stays in FCCS, does not need to flow back to ERP | DeutschWerk → BritEdge unrealised profit Q1 |
| FCCS-identified adjustment that must also appear in the ERP GL ledger of record | Enterprise Journal | ERP and FCCS must stay aligned — FCCS governs the process, ERP GL receives the posting | Late audit adjustment that auditors also need reflected in Oracle ERP Cloud |
| Material one-off statutory adjustment, SOX environment, consolidation layer only | Consolidation Journal | Stays in FCCS_Journal Input. For SOX, use documented approval workflow on Consolidation Journal | GlobalMerge group goodwill impairment entry (consolidation-only) |
| Period-end accrual that auto-reverses next period | Consolidation Journal (auto-reverse) | Auto-reverse feature eliminates manual reversal risk | AsiaLink intercompany management fee accrual |
| Systematic elimination — same entities, fixed margin, every period | Consolidation Rule (Hall 5) | Pattern is too systematic for a journal; rule is the right tool | Hypothetical: if DeutschWerk margin were fixed and never judged |
| Equity method investment pickup (30% NovaTech) | Neither — system process | Equity Pick-up is a Stage 1 locked system process in the engine | NovaTech equity value calculated automatically in Stage 1 |
In GlobalMerge's close calendar, periods are locked on Day 5 after the CFO signs off. Occasionally a late adjustment — an external auditor finding, a corrected allocation — arrives after lock. The procedure is governed and sequential:
- 01 Assess materiality first. Before unlocking, Finance Controller determines whether the adjustment is material enough to warrant reopening a locked period. Immaterial amounts are often deferred to the next period.
- 02 Admin unlocks the period via Approvals → Period Status. The entity-period combination is moved from Locked to a reopened state. Document the reason for unlock in the system.
- 03 Post the late journal — Consolidation Journal if the adjustment stays within FCCS; Enterprise Journal if it must also be reflected in the ERP GL (e.g. auditor-required entries). For auditor adjustments, Enterprise Journal with the auditor communication attached is appropriate.
- 04 Entity status is now Impacted following the journal post. Run Consolidation for the affected entity and all parent entities up to GlobalMerge.
- 05 Verify consolidated figures in the parent. Confirm the adjustment flows correctly through Proportionalization (DeutschWerk at 80%) and any IC eliminations.
- 06 Re-lock the period via Home → Approvals → Change Status → Lock. Note: re-locking requires the entity to be at OK status — consolidation must be complete before locking. Document the re-lock with reference to the late journal. The full cycle is audited.
DeutschWerk uses Full Consolidation (PCON = 100%). When a late journal is posted and Consolidation reruns, 100% of the journal amount flows into GlobalMerge's consolidated P&L — not 80%. The 20% NCI is calculated separately as an elimination entry based on POWN%. For a €100,000 journal: the gross consolidated line shows €100,000; the NCI elimination removes €20,000; the net controlling interest impact is €80,000. The Finance Controller must communicate these three numbers to the CFO — journal amount, gross consolidated line, and net controlling interest figure are all different.
GlobalMerge runs a 5-working-day close cycle. Journals run Days 1–4 concurrently
with Data Integration loads, protected in their own data source lane. This concurrency
is only possible because FCCS_Journal Input and FCCS_Managed Data
are separate — reloading DeutschWerk's trial balance on Day 2 never disturbs the
Day 1 intercompany journals already posted.
DeutschWerk sold components to BritEdge during Q1. At period end, BritEdge holds
€30,000 of unrealised profit in closing inventory (DeutschWerk's 25%
margin on €120,000 of unsold components). The Finance Controller has confirmed this
is a Q1-specific situation requiring a Consolidation Journal — not a systematic rule.
This adjustment stays entirely within FCCS (FCCS_Journal Input); it is a
consolidation-layer elimination that does not need to flow back to the ERP GL.
The journal must eliminate the unrealised profit from consolidated inventory and
retained earnings.
FCCS sandbox · GlobalMerge Corp application · Actual / Q1 / FY2025 · DeutschWerk and BritEdge both at Consolidated status (2) before the lab begins · You have Journal Administrator role · Finance Controller user available for approval step · Inventory schedule PDF ready for attachment.
- 01 Navigate to Journals → New Journal. Set Type = Consolidation Journal. Set Status will show Working — the journal does not exist until saved.
- 02 Set the header POV: Scenario = Actual · Year = FY2025 · Period = Q1 · Entity = BritEdge. Double-check Scenario — selecting Budget here would post silently to the wrong slice with no error.
- 03 Enter a clear description: "Q1 FY2025 — Unrealised profit elimination on DeutschWerk components in BritEdge closing inventory. Gross margin 25% on €120k unsold stock."
- 04
Enter the journal lines as shown in the entry mockup below. Ensure
ICP_DeutschWerkis tagged on the Inventory line to identify the intercompany source. - 05 Click Validate. FCCS checks: (a) Dr = Cr balance if Balance Type = Balanced (unbalanced journals are also supported when the Unbalanced Journals feature is enabled), (b) all dimension members are valid, (c) journal is not posted to a locked period.
- 01
Attach the inventory schedule before submitting. Navigate to the Attachments tab on the journal. Upload
BritEdge_Inventory_Schedule_Q1_FY2025.pdf. This attachment is mandatory — the Submit button remains greyed out without it in Enterprise Journal configuration. - 02 Click Submit. The journal status moves from Validated to Submitted. The designated approver (Finance Controller) receives a task notification.
- 03 Switch to the Finance Controller user. Navigate to Journals → Pending Approval. Open the submitted journal. Review the lines, description, and attached inventory schedule.
- 04 Click Approve. Add an approval comment: "Confirmed against Q1 inventory schedule. Unsold DeutschWerk components at 25% margin rate." Status moves to Approved.
- 05
Click Post. The Consolidation Journal writes to
FCCS_Journal Input. Status moves to Posted. (Note: this is correct for Consolidation Journals — unlike Enterprise Journals which post to the ERP GL.) Confirm the post timestamp appears in the journal history. - 06 Check entity status immediately after posting. Navigate to Consolidation → System Check. BritEdge should now show Impacted — confirming the journal post has invalidated the previously consolidated figures.
BritEdge moving to Impacted is the expected and correct outcome. It is not an error — it is FCCS confirming that the consolidated figures stored at the GlobalMerge parent level no longer include the €30,000 elimination. The system is telling you: run Consolidation to incorporate this change.
- 01 From Consolidation → Consolidate, select BritEdge · Actual · Q1 · FY2025. Run Consolidation. Wait for completion.
- 02 System Check: BritEdge should return to OK (Consolidated). Also check GlobalMerge parent — it should also show Consolidated, incorporating the elimination.
- 03
Open a data form for BritEdge, Actual, Q1. Filter by Data Source =
FCCS_Journal Input. Confirm the Inventory Cr 30,000 and RetainedEarnings Dr 30,000 appear in this data source partition. - 04
Filter the same form by Data Source =
FCCS_Managed Data. Confirm the trial balance data is unchanged — the journal did not touch the DI load data. - 05
DI reload test: Re-run the BritEdge data load rule (Replace mode). After the reload completes, check
FCCS_Journal Inputagain. Confirm the journal is still present and intact — Replace mode did not clear it.
BritEdge at OK (Consolidated) · GlobalMerge consolidated FCCS_Inventory reduced by the GBP-equivalent of €30,000 at the Q1 closing rate · FCCS_Managed Data unchanged by the journal · FCCS_Journal Input unchanged by the DI reload · Full audit trail in the journal history showing Create → Validate → Submit → Approve → Post with timestamps and named approver.
Journals are a reliable exam topic area. Questions focus on the distinction between Consolidation Journals and Enterprise Journals, the Enterprise Journal workflow and status model, the data source separation principle, entity status after posting, the locked period procedure, and the silent wrong-Scenario trap. Expect scenario-based questions with plausible wrong answers.
FCCS_Journal Input
and trial balance data into FCCS_Managed Data. Data Integration Replace mode
clears and reloads FCCS_Managed Data only. It has no access to and no effect on
FCCS_Journal Input. Approved Consolidation Journals are fully protected from all DI load operations.
Note: Enterprise Journal data, by contrast, lands in FCCS_Managed Data after reloading from the ERP GL — it is subject to Replace-mode clears on the next DI run.
FCCS_Journal Input
and produce updated consolidated results.