Version control in Oracle EPM refers to the application’s ability to maintain distinct, labelled copies of planning data at different stages of the review and approval cycle. In Oracle PBCS and EPBCS, versions are defined dimension members — “Working,” “Draft,” “Submitted,” “Approved,” “Adjusted Approved” — and each version holds a separate copy of the data at that stage of the process. The finance team prepares the plan in the Working version, submits it as a Submitted version when ready for review, the finance director reviews and makes adjustments in the Adjusted Approved version, and the final Approved version is the locked baseline against which actual performance is reported.
Why Version Control Matters in a Multi-Entity Planning Process
In a GCC group budget cycle where the CFO is collecting budget submissions from finance teams in Riyadh, Dubai, Abu Dhabi, Cairo, and Doha, the question of which submission is current for each entity is a real operational problem. Without structured version management, the answer is “check your email for the most recent file from each subsidiary” — and email is an unreliable version management system at the best of times. Oracle EPM’s version structure means the finance director can look at the Working version for each entity and see whether it reflects the post-review adjustments or the original submission — without maintaining a file log or an email thread.
How Version Management Supports the Audit Trail
Version control in Oracle EPM also provides the audit trail that finance governance and external auditors require. If the approved budget for a Saudi entity shows a 10% increase in capital expenditure from the submitted version, the EPM version structure preserves both the original submission and the approved figure — along with the journal adjustments or business rule calculations that moved from one to the other. When the external auditor asks how the final capital budget was derived from the initial submission, the answer is in the EPM version history, not in a series of emails and spreadsheet revisions.
What Good Version Design Looks Like
Version structures in Oracle EPM should reflect the actual approval stages in the organisation’s planning governance — no more and no fewer versions than the process genuinely requires. An organisation with a three-stage review process (entity submission, business unit review, group finance approval) needs three review versions. An organisation that configures eight versions because “more flexibility is better” creates a version management problem — users do not know which version represents the current state for their purpose, and the finance team spends time explaining the version structure rather than reviewing the plan.
Where Version Management Fails
The most common version management failure is users working in the approved version rather than the working version — either because the version selection in the form’s point of view is not clearly labelled, or because training did not adequately distinguish the purpose of each version. When users accidentally overwrite approved data by submitting inputs to the wrong version, the recovery requires an IT intervention to restore from a backup — a disruptive and time-consuming process during an active planning cycle.
How Loop Wise Solutions Designs for This
We design version structures from the client’s actual approval governance before configuring the EPM application — producing a version map that shows the name of each version, who can read and write to it, at what point in the planning cycle it is used, and what happens when a user attempts to write to a locked or read-only version. Version design is reviewed and approved by the finance leadership before implementation, and the user training is built around the version structure so that every user understands which version to use for their role in the process.
