In a finance ERP program, you can survive a few late decisions and a few build defects. You cannot survive weak data, weak controls, and unproven reporting. Those three areas determine whether the ERP becomes the financial backbone of the enterprise or just a place to post entries after teams “true up” numbers elsewhere.
This chapter defines readiness in practical terms: what must be true before you cut over, run the first close, and publish results with confidence. Data readiness is not “migration completed.” It is ownership, quality thresholds, and reconciliations that work repeatedly. Controlled readiness is not “roles created.” It is enforceable segregation of duties, auditable workflow, and evidence that stands up to scrutiny. Reporting readiness is not “dashboards built.” It is certified output that ties to the ledger and can be explained under pressure. Compliance readiness is not “tax reviewed.” It is translation of obligations into configuration and test cases that pass the first audit after go-live.
The guiding idea is simple: treat data, controls, reporting, and compliance as first-class workstreams with measurable gates. “We’ll finish it later” usually means the final weeks, when late discoveries turn into manual workarounds that then live for years. Measure readiness weekly; treat evidence as always nonnegotiable.
11.1 Data Strategy and Ownership Model
Finance ERP data is a portfolio of domains created by different teams, used by different processes, and audited in different ways. The program’s job is to make that portfolio governable.
Data strategy: the set of decisions that define which domains are in scope, what “good” looks like for each domain, where each domain is authoritative, and how quality is monitored and improved after go-live. A practical data strategy does not chase perfection in Release 1. It targets the domains that drive postings, controls, and reporting, and it creates ownership that lasts beyond the project team.
Start by separating data into three categories that behave differently. Master data: relatively stable objects that transactions reference, such as suppliers, customers, bank accounts, assets, projects, cost centers, and intercompany partners. Transactional data: the daily records created by operations—orders, invoices, payments, receipts, journals, and subledger documents. Reference data: code sets and rules that standardize behavior, such as tax codes, payment terms, reason codes, tolerance groups, and currency rates.
Most problems that “feel like configuration” are master data problems. Duplicate suppliers create duplicate payments and broken matching. Mis-parented customers distort collections and reporting. Misaligned cost objects create endless mapping work. That is why master data ownership and change control are controllership topics, not IT housekeeping.
Define an ownership model by domain and make it operational. Data owner: the business leader accountable for definitions, quality rules, and policy decisions. Data steward: the operational role responsible for day-to-day maintenance, monitoring, and issue resolution. Data custodian: the technical role responsible for platform configuration, integrations, and security controls that protect data. Each domain must have one accountable owner, even when multiple functions contribute attributes.
Next, declare authority. System of record: the system that is authoritative for an object’s definition and lifecycle. The ERP can be the system of record for finance domains, or you may consume from procurement, CRM, or an MDM platform. Either way, authority must be explicit and synchronization must be designed with reconciliation in mind. If three systems each hold a “version” of the same supplier and none is authoritative, the close will inherit the problem.
Define quality standards that can be tested. Use five measurable dimensions and set thresholds by domain. Completeness: required fields populated. Accuracy: values validated and correct. Uniqueness: duplicates prevented. Consistency: values align across systems and hierarchies. Timeliness: updates occur within defined service levels and effective dates. Agree which dimensions matter most for each domain and publish them as rules, not aspirations.
Ownership also needs lifecycle workflows. Define how master data is created, changed, and retired, including service levels and evidence requirements for sensitive changes. For example, supplier creation may be centralized with duplicate checks, while bank detail changes require additional verification and enhanced logging. If lifecycle workflows are unclear, teams will create records “wherever they can,” and data quality will degrade quickly after go-live.
Finally, establish a data council with decision rights, a cadence, and a single backlog. The data council approves new values and hierarchy changes, resolves conflicts between processes, and owns the data quality dashboard. Without a forum like this, data decisions fragment and teams build “local” definitions that later surface as reporting discrepancies.
- Domain definition template: purpose, owner/steward, system of record, mandatory fields and validations, duplicate prevention, change approvals and effective dating, and the quality metrics that will be monitored.
A data strategy with real ownership is not bureaucracy. It is the foundation for conversion success, interface stability, and reporting trust.
11.2 Data Cleansing and Migration Readiness
Migration is where the data strategy meets reality. Many programs treat migration as a technical event: extract, transform, load. That mindset produces messy go-lives because it ignores the real objective: repeatable conversion with reconciliation evidence and no reliance on last-minute heroics.
Migration readiness: the state in which conversion scope, data ownership, mappings, conversion processes, and reconciliations are mature enough that cutover is predictable. Readiness is earned through mock conversions and proven tie-outs, not through a completed mapping spreadsheet.
Define conversion scope as a set of conversion objects. Conversion object: a distinct dataset loaded into the new system with defined extraction logic, transformation rules, load approach, and reconciliation method. Typical objects include COA and hierarchies, suppliers and customers, open AP and AR items, open orders, fixed assets, bank balances, and historical balances for comparatives. Be explicit about what will not be converted and how history will be accessed for audit, customer service, and analytics.
Begin with profiling and targeted cleansing sprints. Data profiling: analysis that identifies duplicates, missing mandatory fields, invalid values, inconsistent hierarchies, and out-of-policy records. Use profiling results to drive time-boxed cleansing actions owned by data owners. Waiting until the final weeks to “clean data” is how programs end up loading defects and then fixing them through manual journals and workarounds in production.
Mapping must be governed like design. Account mapping is only one part. You also map entities, cost objects, products, projects, and tax codes. Mapping governance: version control, approvals, and impact assessment on reporting and interfaces. If mappings change late, reconciliations break and reporting comparisons fail.
Run multiple mock conversions with explicit objectives and thresholds. Early mocks prove extraction and transformation logic. Middle mocks prove completeness and reconciliation for critical objects. Late mocks simulate cutover sequencing and timing. Every mock should produce a scorecard: success rates, reconciliation results, defect trends, and open issues with owners and due dates.
Reconciliation must be engineered and repeatable. Conversion reconciliation: the evidence that loaded data matches the source according to defined rules. Use control totals (counts and amounts), balance tie-outs (subledger to GL), and sampling for high-risk objects such as bank accounts, supplier bank details, and customer credit attributes. Define what differences are acceptable due to cutover windows and how they will be captured and resolved.
Open items deserve special focus because errors immediately disrupt payments, collections, and customer trust. Define how partial payments, credit memos, disputes, and payments in transit are represented. Then test those scenarios in a mock conversion with realistic data and with the downstream processes that depend on them: payment runs, dunning, cash application, and reconciliations.
Design the cutover window explicitly. Most migrations require a blackout period for certain processes, plus a method for capturing “delta” transactions that occur after extraction but before go-live. Define how those deltas are posted (interface replay, manual controlled journals, or a final mini-load) and prove the approach in a rehearsal. The goal is to avoid a Day 1 surprise where operations continued transacting while the conversion team assumed everything was frozen.
Build the cutover conversion runbook from rehearsal evidence. Include sequencing, owners, duration estimates, reconciliation steps, and decision rights. Define go/no-go criteria tied to conversion evidence so cutover decisions are not based on optimism. If conversion results do not meet thresholds, the program should have a predefined response: additional cleansing sprints, a revised cutover window, or scope deferrals.
- Migration readiness checklist: conversion objects and owners defined, profiling completed, cleansing sprints executed, mapping artifacts version-controlled, at least two successful mock conversions with reconciliations, open-item scenarios tested end to end, cutover runbook rehearsed, and go/no-go criteria based on evidence.
The key shift is to treat data defects like product defects: tracked, triaged, assigned, and closed with proof. When you do that, “data miracles” stop being part of the plan.
11.3 Finance Controls, Audit, and Segregation of Duties
A finance ERP implementation changes the control environment: access, approvals, evidence, and audit traceability. Controlled readiness must be embedded in design and testing, not bolted on during the final weeks.
Controls readiness: the state in which key controls are defined, embedded in configuration and operating procedures, tested with retained evidence, and accepted by internal audit (and external auditors where relevant). Controls readiness spans preventive controls (access and workflow), detective controls (monitoring and reviews), and the routines that keep controls effective after go-live.
Start by mapping key controls to process steps and system mechanisms. A control is not real until you can answer three questions: what behavior does it enforce, how does the system enforce or evidence it, and who reviews exceptions? For example, a vendor bank change control may require maker-checker workflow, a separate verification step, and review of change logs. A journal approval control may require approval routing by threshold, attachment standards, and periodic monitoring of manual journal types.
Segregation of duties must be designed, not only reported. Segregation of duties: separation of responsibilities so no single person can initiate and complete a high-risk transaction without oversight. High-risk conflicts typically involve supplier master maintenance, invoice entry and approval, payment creation and release, customer credits and refunds, manual journal posting, and configuration changes. Define the SoD rules that matter most in your risk environment and then design roles, workflow, and compensating controls accordingly.
Role design should begin with responsibilities. Grant the minimum permissions required, and avoid broad “super user” roles for convenience. Where perfect separation is impractical, define compensating controls that are realistic and provable, such as secondary approvals, centralized review reports, or monitoring of high-risk activity with documented evidence. Compensating controls that no one has time to perform are not controls.
Access lifecycle controls are often overlooked. Access provisioning: controlled granting and modification of access with approvals and evidence. Access recertification: periodic review of user access by accountable managers, with timely removal. If provisioning and recertification are weak, the ERP becomes a persistent audit finding regardless of how well workflows are designed.
Include configuration control as part of the audit story. Many control failures occur not in transactions but in rule changes: posting logic, approval thresholds, or tolerance settings changed without review. Define who can change configuration, how changes are approved, how they are tested, and how change logs are retained. Treat key configuration like policy: controlled, reviewable, and explainable.
Privileged access deserves separate governance because it can override controls. Define how administrators receive elevated access, how long it lasts, and how activity is logged and reviewed. Emergency access should be time-bound and subject to after-action review.
Controls must be tested as part of business testing and close rehearsal. Test SoD restrictions by attempting conflicting actions using role-based users. Test workflow approvals through threshold crossings, delegation, and escalation. Test audit trail by tracing from a financial statement line to journals, to source documents, to approvals, and to supporting evidence. Test period controls by closing periods, attempting late postings, and validating the approved reopening process.
Controls also require operational monitoring routines so they do not degrade after the project team leaves. Define which exception reports are reviewed daily (failed approvals, blocked payments, unmatched interfaces), weekly (aged invoice holds, changes to sensitive master data, unusual manual journals), and monthly or quarterly (user access recertifications, SoD analysis, privileged access reviews). Each routine needs an owner, a review method, and an evidence standard that is lightweight enough to sustain. If monitoring is too heavy, it will be skipped; if it is too informal, it will not satisfy audit. Treat these routines as part of the future-state close and compliance calendar, and include them in training and handover.
- Controls readiness checklist: key controls mapped to system and procedure, SoD rules defined and built into roles, provisioning and recertification designed with evidence, privileged access governed and logged, workflow approvals operable with delegation, evidence standards defined for journals and master data changes, and audit stakeholders sign off based on test evidence.
Controls are sustainable only when ownership is clear after go-live. Define who maintains roles, who reviews SoD conflicts, who owns exception monitoring, and how control changes are approved and tested.
11.4 Statutory, Tax, and Compliance Requirements Translation
Compliance is rarely a single requirement. It is a set of obligations that vary by legal entity, jurisdiction, industry, and transaction type. Programs run into trouble when compliance stays in policy language and is never translated into configuration, data attributes, and test cases.
Requirements translation: converting statutory, tax, and compliance obligations into explicit design decisions, configuration requirements, data fields, workflow controls, report outputs, and test evidence with stakeholder sign-off. Translation is the bridge from “we must comply” to “we can prove compliance on Day 1.”
Start with an entity-and-obligations inventory: statutory statements required, local GAAP needs, filing calendars, and any special disclosure or audit requirements. Confirm how multiple accounting bases will be supported (parallel ledgers, reporting layers, or controlled adjustments) and how differences will be reconciled and evidenced.
Tax design must be end-to-end. For indirect tax, define determination rules and the upstream attributes required (ship-to, bill-to, registration, product category), plus exception handling and audit trail. For withholding, define supplier attributes, posting logic, and reporting outputs. For direct tax, define what data must be captured for provision and compliance even if calculation occurs outside the ERP.
Digital obligations are increasingly material: e-invoicing, real-time reporting, and mandated formats. Whether handled inside the ERP or through third parties, design for traceability. Store acknowledgements and rejection statuses, link them to accounting entries, and define how errors are resolved without creating duplicate postings.
Translate requirements into testable scenarios. For statutory reporting, define which trial balances, disclosures, and local packs must be produced from Day 1, and test them using converted data and period-end processing. For tax, test edge cases that trigger errors: exemptions, cross-border transactions, rate changes, credit memos, and partial payments. For compliance workflows, test approval and evidence paths, not just postings. Stakeholder sign-off should be based on test evidence, not on design documents.
Do not forget privacy and retention constraints. Test data may require masking, and historical data retained outside the ERP must meet retention periods, access controls, and audit retrieval needs. These requirements affect environment strategy, archiving design, and cost.
A practical control is a traceability matrix that links each material obligation to the process step, configuration, data attribute, report, and test case that proves it. Keep it focused on material requirements so it remains usable throughout delivery.
- Compliance translation checklist: obligations inventoried by entity, accounting-basis approach defined, tax rules and required attributes designed with exception handling, digital reporting obligations mapped with traceability, statutory reporting approach defined with governed mappings, retention and privacy requirements addressed, and stakeholders sign off based on test evidence.
Incorporate compliance timing into the close calendar and go-live plan. If the first close includes a filing deadline, treat it as a program risk and plan additional rehearsal and support.
11.5 Reporting Strategy and Close/Management Reporting Readiness
Reporting is where the organization experiences the ERP program. Leaders and finance teams will judge success by whether numbers are available quickly, tie out reliably, and can be explained without a shadow spreadsheet layer.
Reporting strategy: the decisions that define where reporting lives (ERP versus consolidation, EPM, or BI), which sources are authoritative, how metrics are defined, and how outputs are certified and changed over time. A strong strategy prevents the common post–go-live failure mode where users stop trusting reports and rebuild truth manually.
Start with Day 1 reporting. Define the minimum set of reports required to run and close: trial balance, key subledger reports, interface control totals, statutory outputs, and management close packs. Assign report owners and acceptance criteria, including tie-outs to the ledger and drill-down expectations. Defer nice-to-haves; do not risk close readiness for dashboards that can be built after stabilization.
Separate reporting types and apply appropriate governance. Operational reporting: work management views such as queues, holds, and exception aging. Financial reporting:Management reporting:
Make the report inventory practical. For each Day 1 report, specify purpose, audience, frequency, authoritative source, key dimensions, and acceptance criteria. This keeps discussions grounded in what must be true at close and prevents a late discovery that a “critical report” was assumed but never built or never tied out. It also helps you distinguish reports that must be certified from reports that are exploratory.
Reporting readiness depends on the data model and hierarchies. Ensure that hierarchies are governed with effective dates and coordinated releases across ERP, consolidation, and BI layers. Late hierarchy changes are a top cause of “the report doesn’t match the ledger” issues. Ensure conversion includes the hierarchies and attributes required to generate Day 1 reports without manual mapping.
If you use a data platform or BI layer, define refresh timing and certification. Close data freeze: a defined dataset and timestamp that represents final close results for reporting, aligned to period lock and sign-off. Without a freeze, dashboards drift as late postings occur, and trust erodes. Establish routine tie-outs between ERP balances and reporting layers each close, with owned remediation of differences.
Certified reporting requires change control. Define which reports are certified, who signs off, and what evidence is retained. Implement versioning and testing for changes to certified reports and KPI definitions. Informal changes are how multiple versions of truth proliferate.
Management reporting also needs definition governance. If KPIs are calculated in multiple tools, implement a shared semantic layer or, at minimum, a documented calculation standard and a controlled change process. Keep KPI definitions aligned across actuals, plan, and forecast so forecast-to-actual analysis is meaningful and not a debate about formulas.
Prove readiness through rehearsal close. Require the team to run the close calendar and produce the close pack and management reports using the new reporting architecture. Validate tie-outs, drill-down, and variance explanation. If explanation depends on offline calculations, identify whether the root cause is missing dimensions, missing data quality, or missing reporting definitions, and fix the foundation rather than adding spreadsheets back into the process.
- Reporting readiness checklist: Day 1 report inventory with owners, reporting types defined, hierarchies governed with effective dates, authoritative sources declared, close data freeze tied to period lock, routine tie-outs to reporting layers, certified report sign-off and change control, rehearsal close producing close packs with drill-down, and KPI definitions governed across ERP/EPM/BI.
When data, controls, compliance, and reporting readiness are treated as core work, go-live becomes a controlled transition instead of a leap of faith. Issues will still arise, but they will be manageable because ownership is clear and evidence is available.
