MoneyTalkswith SS
BACK TO FCCS LIBRARY
Foundation

Security Architecture – Designing Control, Not Chaos

In FCCS, weak security design does not just expose data — it destroys audit confidence.

FCCS security is not about hiding data.

It is about enforcing accounting discipline across entities, scenarios, and consolidation stages.

When security is designed correctly, it becomes invisible. When it is designed poorly, it becomes the reason auditors stop trusting your numbers.


1. Definition — Architect Level

Security Architecture in FCCS is the framework that controls:

  • Who can see data
  • Who can load and adjust data
  • Who can approve and post journals
  • Who can run consolidation and view group results

This control exists across every major FCCS dimension:

  • Entity
  • Scenario
  • Account
  • Intercompany
  • Movement
  • Data Source

Oracle treats security as a first-class accounting control, not an IT feature.

Architect’s Secret If your FCCS security is weak, your consolidation is not auditable — no matter how perfect your rules are.

2. Real-World Failure Story

SmartSpends Group has:

  • India Controller
  • UK Controller
  • Corporate Consolidation Team

In the initial setup, all controllers are given:

  • Access to all entities
  • Journal posting rights at parent level

One month later:

  • An India controller posts a journal at Group Parent
  • Consolidated numbers change
  • No one knows who caused it
Audit Finding “Insufficient segregation of duties and inadequate access controls.”

The issue was not the journal. The issue was the security architecture.


3. What Proper Security Enables

When security is designed correctly:

  • Controllers work freely — within their entities
  • Parents remain protected — no accidental overrides
  • Audit confidence increases — ownership and eliminations are trusted
  • Close runs faster — fewer investigations and reversals

Strong security reduces questions like:

“Who changed this number?”


4. Where Security Is Applied in Real Projects

  • Data Loads — who can load data to which entities
  • Forms — which POVs users can see and edit
  • Rules — who can execute consolidation logic
  • Journals — who can create, approve, and post
  • Reports — who can see pre-elimination vs post-consolidation data

5. Common Mistakes & Architect Fixes

Mistake — Granting broad access to avoid complaints

Users see everything and can touch everything.

Architect Fix: Security must reflect organizational responsibility, not convenience.

Mistake — No segregation of duties

The same user creates and posts journals.

Architect Fix: Always separate journal creation, approval, and posting.

Mistake — Ignoring scenario-based security

Budget users adjust Actuals.

Architect Fix: Separate Actual, Forecast, and Budget responsibilities.

Final Thought If FCCS numbers are questioned, security — not calculations — is broken.

Architecture Series

Ready to explore more?

View Full Library