When two business entities share a single Oracle Fusion Cloud ERP instance for years — intentionally, as is common in large conglomerates — every data structure reflects that shared reality: ledgers are co-mingled, chart of accounts segments span both entities, cost centers cross legal boundaries, and integrations were never designed to distinguish between them. A corporate spin-off or divestiture does not change those data structures automatically. It creates a hard legal deadline by which every byte of financial data, every integration, and every accounting hierarchy must be cleanly attributable to one entity or the other — retroactively, on a system that was never architected for separation. This toolkit provides the SQL schema, PL/SQL enforcement packages, and architectural patterns developed during a production Fortune 500 energy company spin-off to solve exactly that problem: enforcing data boundaries across 15+ external system integrations and redesigning EDMCS accounting hierarchies to produce legally correct financial statements for a publicly traded entity on day one of separation.
Standard Oracle Fusion Cloud security is designed to control who can see which data. Role-based access control, data access sets, and segment value security all assume that the underlying data model is correct and that separation of concern is a matter of authorization, not architecture.
Corporate spin-offs break this assumption entirely.
When a parent company carves out a subsidiary into an independent publicly traded entity, the ERP data was intentionally designed to be shared. The chart of accounts was built to serve both businesses. Integrations from Salesforce, CPQ tools, Workday, and GL feeders were built to route data into a single Oracle instance without concern for legal entity attribution. EDMCS hierarchies reflect an organizational structure that no longer legally exists as of separation day.
The problem is not access control. The problem is that the data boundary does not exist yet, and it must be imposed retroactively — under SOX scrutiny, under a legal separation timeline, and with zero tolerance for inter-company data violations post go-live.
This toolkit addresses three distinct technical challenges that arise in every large-scale Oracle Fusion spin-off:
-
Integration governance before go-live — Every integration that crosses the new legal boundary must be evaluated, redesigned, and approved before it can operate in the separated environment. Without a structured governance model, teams independently connect systems in ways that violate the boundary.
-
EDMCS accounting hierarchy redesign — Oracle's Enterprise Data Management Cloud Service manages the account hierarchies that drive financial reporting. Pre-built vendor integrations frequently fail when hierarchy structures change mid-separation, producing incorrect segment values that, if undetected, result in materially misstated financial statements.
-
Retroactive data boundary enforcement — Historical transactions must be reviewed and, where necessary, re-attributed to the correct legal entity. This is not a data migration; it is a forensic accounting exercise performed under live system conditions.
The Integration Gatekeeper Model is an architectural governance pattern, not a software feature. It designates a single engineer or small team as the authoritative decision-making body for every integration that crosses the data boundary during a legal separation. No integration between an external system (Salesforce, CPQ, Workday, a GL feeder) and Oracle Fusion Cloud ERP may be designed, built, or deployed without passing through this gatekeeper.
This is necessary because in a separation program involving dozens of workstreams, each team will independently make integration decisions that seem locally correct but are globally catastrophic. A Salesforce integration team will route opportunity data to the wrong ledger. A Workday team will push cost center assignments that cross the legal boundary. A GL feeder from a third-party system will reference account combinations that belong to the parent entity, not the spinoff. Each of these is a SOX violation.
The gatekeeper's role is architectural, not bureaucratic. The gatekeeper:
- Reviews the data domain of every proposed integration (financial, HR, operational, customer)
- Evaluates which boundary side the integration serves (parent entity vs. spinoff entity)
- Identifies data type conflicts — cases where the integration routes data that legitimately belongs to both entities and must be split
- Maintains an audit trail of all integration decisions that can be produced for auditors and regulators
- Provides an escalation path for design disputes between workstream teams
The schema in this toolkit (INTEGRATION_BOUNDARY_REGISTRY, GATEKEEPER_REVIEW_QUEUE) operationalizes this pattern — turning a governance concept into a queryable, auditable data structure.
For a full conceptual treatment, see docs/integration-gatekeeper-model.md.
| Path | Description |
|---|---|
sql/schema/boundary_registry.sql |
DDL for all boundary governance tables, sequences, and indexes |
sql/packages/boundary_enforcement_pkg.sql |
PL/SQL package for integration validation, review submission, gatekeeper approval, and compliance scoring |
sql/packages/edmcs_hierarchy_validator_pkg.sql |
PL/SQL package for detecting shared Chart of Accounts segments and crossover journal lines post-separation |
docs/integration-gatekeeper-model.md |
Conceptual architecture document for the gatekeeper pattern |
docs/edmcs-hierarchy-patterns.md |
Reference guide to common EDMCS hierarchy failure modes during spin-offs |
- Oracle Fusion Cloud ERP with SQL access to GL schema tables
- Database user with CREATE TABLE, CREATE SEQUENCE, CREATE PROCEDURE privileges in your schema
- Familiarity with Oracle Fusion GL table structures (
GL_CODE_COMBINATIONS,GL_LEDGERS,XLA_AE_HEADERS)
-- Connect as your schema owner
@sql/schema/boundary_registry.sql-- Compile package specs first, then bodies
@sql/packages/boundary_enforcement_pkg.sql
@sql/packages/edmcs_hierarchy_validator_pkg.sql-- Register your first integration
INSERT INTO INTEGRATION_BOUNDARY_REGISTRY (
INTEGRATION_ID,
INTEGRATION_NAME,
SOURCE_SYSTEM,
TARGET_SYSTEM,
DATA_DOMAIN,
BOUNDARY_SIDE,
ALLOWED_DATA_TYPES,
EFFECTIVE_DATE,
STATUS,
CREATED_BY,
CREATED_DATE
) VALUES (
'INT-CRM-001',
'Salesforce Opportunity to Oracle AR',
'SALESFORCE',
'ORACLE_FUSION_AR',
'CUSTOMER_REVENUE',
'SPINOFF',
'INVOICE,CUSTOMER_MASTER',
DATE '2025-01-01',
'PENDING_REVIEW',
'SYSTEM',
SYSDATE
);
COMMIT;DECLARE
v_integration_id VARCHAR2(50) := 'INT-CRM-001';
v_requestor VARCHAR2(100) := 'JSMITH';
v_doc_ref VARCHAR2(500) := 'JIRA-SPINOFF-4421: Salesforce AR Integration Design v1.2';
BEGIN
BOUNDARY_ENFORCEMENT_PKG.SUBMIT_FOR_GATEKEEPER_REVIEW(
p_integration_id => v_integration_id,
p_requestor => v_requestor,
p_design_doc_ref => v_doc_ref
);
COMMIT;
DBMS_OUTPUT.PUT_LINE('Integration ' || v_integration_id || ' submitted for review.');
END;
/DECLARE
v_shared_segs SYS_REFCURSOR;
v_violations SYS_REFCURSOR;
BEGIN
EDMCS_HIERARCHY_VALIDATOR_PKG.VALIDATE_ACCOUNT_HIERARCHY_SPLIT(
p_parent_entity_id => 'PARENT_LE_001',
p_spinoff_entity_id => 'SPINOFF_LE_001',
x_shared_segments => v_shared_segs,
x_violations => v_violations
);
-- Process cursors in your reporting layer
END;
/erp-spinoff-data-boundary-toolkit/
├── README.md
├── LICENSE
├── sql/
│ ├── schema/
│ │ └── boundary_registry.sql -- Core DDL
│ └── packages/
│ ├── boundary_enforcement_pkg.sql -- Integration governance PL/SQL
│ └── edmcs_hierarchy_validator_pkg.sql -- EDMCS validation PL/SQL
└── docs/
├── integration-gatekeeper-model.md -- Architectural pattern doc
└── edmcs-hierarchy-patterns.md -- EDMCS failure mode reference
This toolkit is applicable to any Oracle Fusion Cloud ERP separation scenario:
- Corporate spin-offs — A publicly traded parent carving out a subsidiary into an independent company with its own SEC reporting obligations
- Divestitures — Selling a business unit to an acquirer who will operate it on a separate ERP instance; the seller must produce clean, separated historical financials
- Carve-outs — Operational separation of a division that will eventually be spun off or sold, requiring a period of running in a clean-boundary state before legal day one
- Post-merger separations — Unwinding a shared ERP instance after a merger-of-equals fails or a regulatory body mandates divestiture
This toolkit is not appropriate for:
- Standard multi-org security in Oracle Fusion (use Data Access Sets and Segment Value Security)
- Role-based access control problems (use Oracle Identity Governance)
- Standard intercompany elimination (use Oracle Fusion Intercompany)
This toolkit was generalized from a production implementation at a Fortune 500 energy company spin-off. Contributions that extend or improve the pattern are welcome, particularly:
- Additional data domain validation rules in
boundary_enforcement_pkg - Extended EDMCS hierarchy checks for non-standard COA structures
- Integration with Oracle Integration Cloud (OIC) for automated boundary checks at the middleware layer
- Reporting queries for auditor-ready compliance documentation
Please open an issue before submitting a pull request for significant changes.
MIT License. See LICENSE for full terms.
This toolkit is provided as a reference implementation. Production use requires adaptation to your specific Oracle Fusion Cloud configuration, chart of accounts structure, and legal separation requirements. Nothing in this repository constitutes legal, accounting, or SOX compliance advice.