A chart of accounts change never touches a transaction. Nobody posts a journal, and no balance is entered. Yet after the change, a cost center rolls into a different line of the income statement, an account moves from one reporting group to another, and the consolidated number the board reads is different. That is why auditors treat the dimensions, hierarchies, and mappings in your EPM applications as part of the control environment, and why the question "who approved this change?" is now one of the most common requests in a SOX walkthrough.
This guide is written for the controller, the CFO's finance systems lead, and the internal audit partner who has to answer that question. It lays out eight controls that auditors typically test for EPM metadata changes, a walkthrough script you can rehearse, the evidence to keep for every change, and an honest comparison of three ways to produce that evidence: tickets and spreadsheets, native platform workflow, and a governed hub. One disclosure up front: EPMware, our product, is a master data governance platform, and it appears in the third option. The first two are legitimate answers for some organizations, and we say when.
This is a control design guide, not audit advice. What counts as sufficient depends on your scope, your risk assessment, and your external auditor.
SOX section 404 requires management to assess internal control over financial reporting, and the external auditor to attest to it. Within that, IT general controls (ITGCs) are the controls over the systems that financial reporting depends on. They are commonly grouped into four areas: access to programs and data, program changes, program development, and computer operations.
EPM metadata sits in the program change and access areas. The members, hierarchies, properties, and mappings in Oracle EPM Cloud, OneStream, or any consolidation platform determine how reported numbers are aggregated, translated, eliminated, and presented. A change that moves an account under a different parent can alter a reported subtotal without altering a single posted amount. If the application supports in-scope accounts or disclosures, a metadata change is a change to the system that produces them, and it needs the same evidence of authorization, testing, and controlled deployment as any other production change.
Auditors also rely on the automated controls inside these platforms, such as consolidation rules and validations. PCAOB's standard for auditing internal control (AS 2201) notes that automated controls are generally lower risk when the relevant ITGCs are effective. In plain terms, weak control over metadata changes weakens the case for trusting everything built on top of the metadata.
The table below is a practical control set. Your own control library will use different names and numbering, and your auditor may combine or split some of these. The right-hand column is the part that matters on audit day: the evidence you can hand over for a sampled change.
Eight controls, eight pieces of evidence: what an auditor asks for on a sampled EPM metadata change.
| Control | What the auditor wants to see | Evidence to keep |
|---|---|---|
| 1. Change authorization | A documented request with a business reason, approved by an authorized finance owner before the change is made | Request record with requester, date, rationale, approver, and approval timestamp |
| 2. Impact assessment and validation | Evidence the change was checked for what it could break: invalid parents, orphaned members, account type conflicts, mappings that would no longer resolve | Validation results attached to the same request |
| 3. Testing and business sign-off | For structural changes that could alter reported output, testing outside production and a finance sign-off | Test results, before and after comparisons, sign-off |
| 4. Separation of duties | The person who requests, the person who approves, and the person who deploys are not the same individual for a given change | Request record showing three identities, plus role assignments |
| 5. Controlled deployment | Production changes made only through an authorized path, with direct edits prevented or detected | Deployment record tied to the approved request, list of privileged users |
| 6. Completeness of the change population | Assurance that the list of changes handed to the auditor is the full list, reconciled to approved requests | Reconciliation of production changes to requests, with exceptions investigated |
| 7. Emergency changes | A defined fast path, with the reason recorded and approval obtained after the fact within a stated window | Emergency flag, reason, retroactive approval |
| 8. Access review | A periodic review of who can edit metadata and who can approve, with removals actioned | Signed review, removal tickets, role assignment reports |
Controls 4 and 6 deserve extra attention, because both are about connecting records, not just creating them. An approval that exists in an email thread satisfies control 1 only if someone can prove it belongs to the change that was deployed. A change log satisfies control 6 only if it can be matched, line by line, to approvals. The next two sections cover how to demonstrate each.
Most finance teams do not lack evidence. They have too many places for it. In a typical spreadsheet-and-email process, the request arrives as an email or a form, the proposed hierarchy lives in a workbook with a version number in its filename, the approval is a reply or a chat message, the ticket sits in an IT service tool, the deployment happens through an import or an automation script, the platform keeps its own audit log, and test screenshots sit on a shared drive. Each piece is real. None of them points to the others.
The same change, two evidence trails: scattered across seven places, or linked in one record.
That works until a sample is drawn. Then someone spends days assembling a package for each sampled change, and the package is only as credible as the person's memory of which email belongs to which deployment. The goal of a good control design is not more evidence. It is evidence that is linked at the moment it is created, so that the package for any change can be produced without a person reconstructing it.
The honest answer has three parts: the approval itself, the link from approval to deployment, and the completeness of the population.
The approval itself. A record showing who approved, in what role, when, and what exactly they approved. "Approved the change" is weaker than approval of a specific, versioned request, because a later edit to a workbook can silently change what was approved. The approver also needs to be someone with authority for that dimension, which is why mature teams define an owner for each hierarchy.
The link to deployment. The auditor will sample a change from the system, not from your approval folder. They start from what is in production and ask to see how it got there. That means every production change needs to trace back to exactly one approved request, and the version deployed has to be the version approved. Where deployment is a manual import of a file, the file itself becomes evidence and needs to be retained and matched.
The population. Before sampling, the auditor needs a list of all changes in the period, and a reason to trust that the list is complete. This is the information the auditor relies on, and it is where many teams stumble. The test is a reconciliation: take every change recorded in the production system for the period, match each to an approved request, and investigate anything that does not match. A production change with no request on file is the single most damaging exception, because it suggests the control can be bypassed.
The completeness test: every change in production has to match an approved request.
Platform audit logs help with the second half of this. Oracle EPM Cloud, for example, provides audit reports covering application activity, role assignments, group assignments, and application access, including who performed an action and when. The Application Audit Report also records old and new values for properties. Check what your own platform records for metadata objects specifically, because coverage varies by platform and by the object type. Even where the log is excellent, it tells you what changed and who changed it. It does not by itself tell you why, who approved it, or what testing preceded it. Those facts live in the request, which is why the log and the request must be reconcilable.
A walkthrough is how an auditor tests whether a control is designed the way you describe it. Under PCAOB AS 2201, a walkthrough follows a single transaction from origination through the company's processes and systems into the financial records, using the same documents and systems that personnel use, and it typically combines inquiry, observation, inspection of documents, and reperformance. The standard also ranks these procedures by the strength of evidence they produce and says inquiry alone is not enough to conclude a control is effective. Translated to metadata: the auditor will not accept a description of your process. They will want to watch it, or see it, for a real change.
Rehearse with a recent change that mattered, such as a new legal entity, a restructured account group, or a mapping update after an acquisition. Then walk it through seven questions.
Seven questions to rehearse before an auditor traces a metadata change.
If you can answer all seven from records that existed before the auditor asked, the walkthrough is short. If you cannot, you have found your gaps while there is still time to fix them.
Findings on metadata changes follow a small number of patterns. Each has a direct fix, and most are about linking records, not adding steps.
| Common finding | Why it happens | Fix |
|---|---|---|
| Change in production with no approved request | Direct edits by administrators, or a request that was closed before the work | Route all changes through one path, reconcile production changes to requests each period |
| Approver and implementer are the same person | Small team, or the approver role was never separated from administration | Enforce the separation in the workflow, not in a policy document |
| Approval after the change | Approval requested retroactively to clear a backlog | Make deployment impossible before approval, and track emergency changes separately |
| Incomplete change population | The list is built by hand from several sources | Generate the population from the system of record and reconcile it |
| Evidence cannot be tied to the deployed version | Workbooks edited after approval | Version the request and deploy the approved version, not a file |
| Access reviews missing or stale | Review depends on someone remembering | Schedule the review and keep the sign-off with the role report |
| Same change applied differently across systems | One change keyed separately into the ERP, EPM, and warehouse | Deploy from one approved version to every target |
The last row deserves emphasis. When one hierarchy change has to be made in an ERP, two EPM applications, and a data warehouse, the work is done several times, and each repetition is a chance for a gap in the trail or a difference in the result.
There are three common designs. None is wrong in every case, and the right one depends on how many systems a change touches and how often changes occur.
Option 1: Tickets, spreadsheets, and native audit logs. The request is a ticket in your IT service tool, the proposed structure is a workbook, and the platform audit log supplies the record of what changed.
Benefits: no new software, a ticketing system your auditors already know, and a defensible control when change volume is low and a single platform is involved. Downsides: the link between ticket and deployed change is maintained by people, population reconciliation is manual, nothing validates the content of the change before approval, and a change touching several systems needs several tickets or one ticket with manual follow-through. Fits best when: one EPM platform, a modest number of changes per period, and a team disciplined enough to reconcile every period.
Option 2: The native workflow in each platform. Platforms provide their own request and approval features within their scope. OneStream's Application Control Manager, for example, provides multi-level approval for change requests inside OneStream, and Oracle's own data management product provides request workflows for the Oracle applications it connects to.
Benefits: approvals and changes are linked inside the platform, the controls are built by the vendor, and there is nothing extra to integrate. Downsides: the boundary of each tool is the boundary of its evidence. A change that starts in an ERP and lands in several systems has a trail in each, and the reconciliation across them is manual again. Fits best when: the governance boundary genuinely stops at one platform.
Option 3: A governed hub upstream of every system. One request, validated against the rules for every target, approved once with separation of duties enforced, and deployed to all targets from the same version. The audit trail for each target is the same trail, because there was one change.
Benefits: the evidence is linked when it is created, the population is generated from one system, and the same version identifier appears in every target. Downsides: it is another system to implement, and the hub is itself in SOX scope, so it needs its own access, change, and operations controls and an auditor who understands it. It earns its cost when changes span several systems or occur often. It does not make sense for a single-platform shop with a handful of changes a quarter. Fits best when: multiple ERPs or EPM applications, a data warehouse that must match, high change volume, or repeat audit findings on cross-system consistency.
A useful question for your own situation: how many systems does a typical hierarchy change touch, and how many people key it? If the answer is one and one, Option 1 or 2 is probably enough. If it is five and three, the evidence problem multiplies with every target.
Get the answers in writing. Most painful findings come from an unstated assumption, not a missing control.
For any sampled change, the package should contain, or be able to generate on demand:
If a package can be produced for any sampled change in minutes, the process is auditable. If it takes days, the process may be sound but the evidence is not.
EPMware is a finance-owned master data governance platform. In the third design above, it is the hub: a single request is validated, routed for approval with separation of duties, and deployed to the connected systems, including Oracle EPM, Hyperion, OneStream, SAP, Oracle Fusion, Workday, and Databricks, with the audit trail produced by the workflow itself. If you want to see the control matrix in this guide mapped against your own landscape and your own audit findings, that is a useful conversation to have before the next cycle begins, not during it.
Keep a record of the approval that names the approver, their role, the timestamp, and the specific versioned request they approved, then show that the deployed change matches that version. Auditors usually sample from production, so you also need a reconciliation that matches every production change in the period to an approved request. A change in production with no request on file is the most serious exception.
They are the program change and access controls applied to dimensions, hierarchies, properties, and mappings: authorization before the change, validation and testing, separation of duties between requester, approver, and deployer, controlled deployment, reconciliation of production changes to approved requests, a defined emergency path, and periodic access review. Each needs evidence that can be tied to the specific change.
Choose a recent significant change and trace it from request to deployment in the same systems your team uses every day. Be ready to show the request, validation, approval, who deployed and that they were a different person, the version in each target system, and how an unapproved direct edit would be detected. Under PCAOB AS 2201, inquiry alone does not establish that a control works, so be ready to show records rather than describe the process.
Most findings come from unlinked records: production changes with no request, approvals that cannot be tied to the deployed version, incomplete change lists, and separation of duties that exists in policy but not in the workflow. Route every change through one path, enforce separation of duties in the tool, version what is approved and deploy that version, and generate the change population from the system of record.
Yes, wherever the metadata affects reported results. Auditors commonly test that the person who requests a change, the person who approves it, and the person who deploys it are not the same individual for that change. It is most reliable when the workflow enforces it, because a policy that relies on people to self-police is hard to evidence.
When changes are infrequent, only one platform is involved, and the team reconciles production changes to tickets every period. It becomes harder to defend when one change must be applied in several systems, because the linkage between the ticket, the approval, and each deployment is maintained by hand.
Sources: PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements. Oracle, Available Audit Reports.