The ERP product, implementation partner, scope envelope and executive sponsor are assumed to be approved before this checklist begins. Product selection, vendor scoring and the question of whether the company needs an ERP remain outside this page.
The implementation record now has to prove that finance processes, data, controls and operating ownership are ready to move from design into production. A completed task is not enough: each gate needs a named accountable owner, inspectable evidence and an exit condition that the steering committee can accept or block.
Quick answer
Weak phase gates allow unresolved design, data, access and balance defects to reach production, where they can disrupt close, reporting and control operation.
Decision: Approve, condition or block each ERP implementation phase based on named ownership, inspectable evidence and defined exit criteria.
Key takeaways
- Keep one design authority and one controlled decision record from mobilization through handover.
- Freeze process, chart-of-accounts, master-data, integration and access designs before test conclusions are accepted.
- Do not release production transactions until opening balances, migrated open items and subledgers reconcile at the approved level.
- End hypercare only after the first close, support model, recurring controls and operating records have named owners.
How to use this ERP implementation checklist
Copy the phase tables into the project control register. Keep one row per gate, replace the empty box with PASS, CONDITIONAL or BLOCKED, and add local columns for due date, evidence link, decision date and approver. A conditional pass needs a bounded exception, an accountable owner, a due date and a stated effect on later gates. It is not a substitute for evidence.
Set local thresholds before execution starts. The company must decide what counts as material, which defects block go-live, how much reconciliation variance is acceptable, how long the cutover window lasts and who may sign each gate. This checklist does not invent those approvals.
Use the finance technology stack reference architecture to confirm authoritative systems and application boundaries. Use the finance systems integration map when an interface row needs field authority, message state, retry, control-total or reconciliation detail.
ERP implementation checklist by phase
Phase 0: Mobilize and govern
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Confirm the approved implementation mandate, in-scope entities, modules, deployment waves, partner scope and exclusions. | Executive sponsor | Signed mandate, approved scope baseline, contract statement of work and dependency list. | Every workstream can trace its work to an approved scope item; exclusions and later-wave items are recorded. |
| ☐ Create the steering committee charter, meeting cadence, escalation route and decision rights for scope, budget, design, risk and go-live. | Executive sponsor | Governance charter, committee membership, authority matrix and calendar. | The steering committee can approve, condition, defer or block each phase and named deputies cover absences. |
| ☐ Establish one design authority for cross-process, accounting, data, integration and security decisions. | Finance transformation director | Design-authority charter, membership, quorum, decision categories and escalation rules. | No workstream can approve a cross-domain design outside the authority; unresolved decisions have an owner and due date. |
| ☐ Open a controlled decision, risk, issue, assumption and dependency log. | Program director | Versioned logs with owner, impact, target date, decision evidence and closure status. | All material open items are visible to phase approvers and no blocking item is hidden in team notes or email. |
| ☐ Assign accountable business owners for every process, data domain, interface, role set, control, report and cutover activity. | Program director | RACI or ownership register with named primary and deputy owners. | Every checklist row and deliverable has one accountable owner; shared accountability is replaced by a named decision owner. |
| ☐ Define environment, configuration, code, release and change-control rules before build starts. | IT program lead | Environment plan, configuration register, version-control policy, release path and emergency-change procedure. | Builds move through approved environments with traceable versions, segregation between build and approval, and rollback evidence. |
Phase 1: Process and finance design
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Build the end-to-end process catalog, including variants, exceptions, handoffs, volumes, cutoffs and accountable process owners. | Business process lead | Approved process inventory and process maps for all in-scope scenarios. | Every configured requirement and test scenario maps to an approved process outcome and owner. |
| ☐ Run fit-to-standard reviews and document each justified configuration, extension, manual control or retained external step. | Design authority chair | Fit-to-standard decisions, gap log, rationale, cost and support impact. | Each departure from standard has a business owner, approved rationale, control treatment and support path. |
| ☐ Map accounting policies and transaction events to subledger, posting, recognition, allocation and period-control rules. | Group controller | Policy-to-configuration matrix and accounting event catalog. | The controller approves how each material event reaches the ledger and how exceptions are identified and corrected. |
| ☐ Approve legal entities, ledgers, fiscal calendars, currencies, chart of accounts, dimensions, hierarchies and reporting mappings. | Group controller | Signed finance design workbook, sample reports and account/dimension governance rules. | The design supports statutory, management and consolidation reporting without relying on uncontrolled remapping. |
| ☐ Design subledger-to-ledger relationships, posting profiles, intercompany, consolidation, close tasks and reporting outputs. | Record-to-report owner | Posting matrix, close design, consolidation rules, report catalog and reconciliation map. | Every material subledger and adjustment route has an approved posting rule, reconciliation owner and close evidence. |
| ☐ Define preventive, detective, automated and manual controls, including approvals, tolerances, evidence retention and exception ownership. | Internal controls lead | Risk-control matrix linked to configuration, roles, reports and test cases. | Each in-scope control has an owner, frequency, evidence source, failure response and acceptance test. |
| ☐ Freeze the baseline design and place later changes under impact assessment and design-authority approval. | Design authority chair | Approved blueprint, signed design pack, open-deviation list and change log. | Build starts from one controlled baseline; open deviations are nonblocking, owned, dated and visible to testers. |
Phase 2: Master data, integrations and access
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Define master-data domains, authoritative systems, stewards, creation and change approvals, required attributes and duplicate rules. | Data governance lead | Master-data governance matrix and data dictionary. | Every governed object has one authoritative owner, approved lifecycle states and a controlled correction route. |
| ☐ Profile source data and approve cleansing, deduplication, enrichment, archival and rejection rules. | Data migration lead | Profiling results, defect inventory, remediation plan and quality thresholds. | Data owners accept the measured quality or approve a bounded remediation plan before rehearsal loads. |
| ☐ Create the complete interface inventory with direction, frequency, volumes, authoritative fields, dependencies and business owner. | Integration architect | Signed interface catalog and context diagram. | No production handoff is missing from the catalog, and each interface has both technical and business ownership. |
| ☐ Define interface contracts, identifiers, control totals, acknowledgements, timeouts, retries, duplicate prevention, suspense and reconciliation. | Integration architect | Versioned interface specifications and failure-state matrix. | Each interface can prove completeness, detect duplicates or omissions, recover safely and route exceptions to a named owner. |
| ☐ Approve nonfunctional requirements for performance, batch windows, availability, recovery, retention, monitoring and capacity. | Enterprise architect | Nonfunctional requirement set with measurable thresholds and test method. | Thresholds are measurable, tied to business cutoffs and included in performance and operational-readiness tests. |
| ☐ Design the role catalog, least-privilege access, approval limits, segregation-of-duties rules, service accounts and privileged roles. | Information security lead | Role-to-process matrix, conflict rules, privileged-account inventory and risk treatments. | Each role maps to approved tasks; incompatible access is prevented or covered by a formally accepted control. |
| ☐ Define joiner, mover, leaver, emergency access and periodic recertification procedures. | Identity and access owner | Provisioning workflow, approval evidence, recertification schedule and emergency-access review procedure. | Access changes are timely, independently approved, logged and reviewable before production credentials are issued. |
Phase 3: Build and migration rehearsal
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Trace configuration, extensions, workflows, reports and controls to the approved process and design records. | Solution architect | Configuration register and bidirectional traceability matrix. | Every build item has an approved source requirement, owner, test case and release version. |
| ☐ Approve migration scope for master data, historical detail, open transactions, balances, documents and retained legacy access. | Group controller | Migration-scope matrix by object, period, entity and disposition. | Finance, audit, legal and operational needs are covered without moving unsupported or unnecessary data. |
| ☐ Sign off source-to-target mappings, transformation logic, defaults, crosswalks and ownership of rejected records. | Data owners | Mapping workbook, transformation specifications and signed sample conversions. | Business owners can explain and approve how each material field and balance changes from source to target. |
| ☐ Build repeatable extract, transform, load, reject, restart and reconciliation procedures. | Data migration lead | Versioned migration runbook, scripts, control totals, reject reports and restart evidence. | A failed load can be stopped, corrected and rerun without unexplained duplicates, omissions or manual edits. |
| ☐ Run progressive mock migrations using production-scale volumes and time the end-to-end cycle. | Data migration lead | Mock-load results, timing log, quality report, defects and signed reconciliation pack. | The load fits the cutover window and meets approved record, value, quality and reconciliation thresholds. |
| ☐ Create role-based operating procedures, training materials and support articles from the controlled build. | Change and training lead | Approved procedures, training environment, attendance and competency evidence. | Users assigned to critical roles can perform normal and exception scenarios before user acceptance testing. |
Phase 4: Test, reconcile and accept
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Approve one test strategy covering unit, functional, process, system integration, end-to-end, performance, security, migration, UAT and regression tests. | Test manager | Test strategy, cycle plan, entry and exit criteria, environment plan and defect workflow. | All required test types have owners, representative data, scheduled cycles and measurable exit criteria. |
| ☐ Control test environments, versions, interfaces, roles and migrated data so results represent the release candidate. | Test manager | Environment baseline, release manifest, data-load certificate and access list. | Test results identify the exact build, data set, interfaces and roles used; material variance from production is disclosed. |
| ☐ Execute end-to-end finance scenarios across procure-to-pay, order-to-cash, record-to-report, assets, inventory, cash and intercompany. | Finance process owners | Scenario scripts, expected accounting, execution evidence, defects and owner sign-offs. | All in-scope normal, exception and period-end scenarios produce approved operational and accounting outcomes. |
| ☐ Test interfaces for late, missing, duplicate, partial, out-of-order and rejected messages, plus controlled restart and replay. | Integration service owner | Failure-injection results, monitoring alerts, suspense records, replay evidence and reconciliations. | Failures are detected within the approved window, do not create duplicate finance events and reach a named resolver. |
| ☐ Test role access, approval limits, segregation conflicts, privileged actions, service accounts and access removal. | Information security lead | Security test results, conflict report, remediation evidence and residual-risk approvals. | Users can perform assigned duties but cannot perform incompatible or unapproved actions; residual conflicts are formally controlled. |
| ☐ Reconcile migrated record counts and values, control totals, trial balances, open items and subledgers to the source. | Group controller | Signed source-to-target reconciliation pack by entity, currency, account and data object. | No unexplained difference remains; approved differences have documented cause, amount, owner and resolution date. |
| ☐ Test financial statements, management reports, tax outputs, consolidations, close controls and audit evidence against approved expectations. | Financial reporting lead | Report validation pack, close test, control evidence and comparison to source outputs. | Finance owners sign off completeness, calculation logic, drill-through, timing and control evidence. |
| ☐ Run UAT with trained business users in the integrated release-candidate environment using migrated data. | Business process owners | UAT scripts, tester roster, results, defects, retests and signed acceptance. | Business owners accept the process outcomes and operating readiness; implementers do not sign on their behalf. |
| ☐ Apply the approved defect threshold, regression scope and risk-acceptance process after every material fix. | Test manager | Defect dashboard, severity rationale, regression results and signed exceptions. | No defect breaches the local go-live threshold; accepted residual defects have workarounds, owners, dates and business approval. |
| ☐ Complete a mock close and full mock cutover, including migration, access, interfaces, jobs, reconciliations and support handoffs. | Cutover manager | Timed rehearsal log, mock-close pack, variance analysis and corrective-action list. | The complete sequence fits the window, financial results reconcile and every failed rehearsal step is corrected or explicitly blocked. |
Phase 5: Cutover, opening balances and go-live
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Approve a sequenced cutover runbook with task owner, predecessor, duration, evidence, checkpoint, communication and rollback rule. | Cutover manager | Versioned runbook, command structure, contact list, go/no-go times and rollback decision tree. | Every critical step has one owner and verifier; dependencies fit the window and rollback remains feasible until the stated point. |
| ☐ Define legacy freeze, in-flight transaction handling, final extracts, delta loads and restart rules. | Business operations lead | Freeze notice, cutoff rules, transaction inventory, delta-load plan and approvals. | No transaction can be silently lost, duplicated or posted in both systems during the transition. |
| ☐ Confirm production capacity, licenses, jobs, interfaces, monitoring, backups, recovery, support coverage and authorized access. | IT operations owner | Production-readiness certificate, monitoring evidence, backup test, access list and support roster. | The production environment matches the approved release and can be operated, monitored, recovered and supported from day one. |
| ☐ Load final master data, open transactions and opening balances by legal entity, currency, account and subledger. | Data migration lead | Final migration log, control totals, reject report and load certificate. | All approved objects load once, rejected items are resolved or formally held, and the final population matches the cutover scope. |
| ☐ Reconcile the legacy trial balance to ERP opening balances and each subledger to the general ledger before releasing transactions. | Group controller | Signed opening-balance bridge, subledger reconciliations, bank and inventory checks, and exception log. | Finance signs off zero unexplained variance at the approved level; any accepted timing item is bounded, owned and dated. |
| ☐ Assemble the go/no-go pack and record all sign-offs, conditions, unresolved risks, workarounds and rollback status. | Executive sponsor | Gate pack covering scope, tests, balances, access, cutover, support, risks and approvals. | The authorized forum records GO, CONDITIONAL GO or NO-GO; every condition has an owner, deadline and monitoring action. |
| ☐ Execute production cutover, release access and complete first-transaction, posting, interface and control smoke tests. | Cutover manager | Executed runbook, production release record, smoke-test evidence and incident log. | Critical transactions post correctly, interfaces acknowledge, controls operate and any blocker triggers the agreed stop or rollback action. |
Phase 6: Hypercare
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Operate one command center for business, finance, data, integration, security and vendor incidents. | Program director | Hypercare roster, severity rules, triage queue, escalation path, daily meeting record and service metrics. | Every incident has an owner and target; blockers receive immediate executive visibility and duplicate queues are eliminated. |
| ☐ Issue a daily financial-integrity pack covering failed postings, interface exceptions, suspense, duplicates, unposted items and reconciliation breaks. | Group controller | Daily integrity dashboard, reconciliations, exception aging and resolution evidence. | Finance can show that production activity remains complete, accurate and reconciled while volumes rise. |
| ☐ Review emergency access, privileged changes, production fixes and configuration moves each day. | Information security lead | Emergency-access log, change approvals, deployment evidence and retrospective review. | No unreviewed privileged action or emergency change remains open beyond the locally approved review window. |
| ☐ Complete the first operational close using the new system and record every manual workaround and control exception. | Record-to-report owner | First-close calendar, reconciliations, control evidence, issues, close duration and remediation plan. | The close produces accepted statements and reconciliations; residual workarounds are owned, controlled and scheduled for removal. |
Phase 7: Ownership transfer
| Checklist item | Accountable owner | Evidence required | Exit condition |
|---|---|---|---|
| ☐ Activate the level-one, level-two and level-three support model, vendor escalation routes, service levels and on-call coverage. | ERP service owner | Support operating model, queue ownership, service-level targets, vendor contacts and coverage calendar. | Operational teams can receive, diagnose, route and resolve incidents without relying on unnamed project resources. |
| ☐ Transfer runbooks, configuration records, data lineage, interface specifications, access procedures, control evidence and training content. | Finance systems owner | Controlled knowledge repository, document inventory, owner acceptance and access permissions. | Business-as-usual owners accept current, usable records and can locate the evidence needed to operate and audit the service. |
| ☐ Convert residual defects, enhancements, data remediation and control actions into a funded backlog. | Business product owner | Prioritized backlog with value, risk, owner, target release, dependency and acceptance test. | No project item disappears at closure; each accepted item has a funded route, accountable owner and review date. |
| ☐ Confirm recurring ownership for reconciliations, access recertification, change review, job monitoring, master data, close and reporting. | Group controller | Business-as-usual control calendar, owner attestations and escalation matrix. | Every recurring finance and access control has a trained owner, deputy, frequency, evidence location and failure route. |
| ☐ Approve hypercare exit and transfer decision rights from the project to the service and process owners. | Executive sponsor | Trend metrics, open-risk pack, first-close acceptance, support readiness and signed handover. | Stability meets the locally defined period and thresholds; no blocking balance, access or control issue remains; ownership transfer is recorded. |
Evidence rules behind the exit gates
Design, data and ownership
This phase structure is Finance Circuit analysis, not a vendor methodology. It draws on Microsoft’s process-focused implementation lifecycle, which links process outcomes to design, build, test, training and cutover, and its project-governance guidance, which treats configuration, data, testing, integration and training as governed project areas. The practical consequence is that the process catalog, design authority and decision log must stay connected. A design decision that cannot be traced into configuration, test evidence and operating ownership is still open.
Microsoft’s configuration and migration data guidance separates configuration data from migrated business data and assigns distinct responsibilities to data stewards, analysts and migration developers. The checklist therefore requires named ownership, mapping approval, repeatable loads, reject handling and business reconciliation rather than treating migration as a technical copy.
The chart of accounts is also a design gate, not a late configuration task. Microsoft’s chart-of-accounts planning guidance ties the account structure and dimensions to legal-entity and reporting requirements. Finance should approve the chart, dimensions, hierarchies, posting rules and reporting mappings as one controlled design.
Testing, balances and go-live
The test-strategy checklist distinguishes functional, process, end-to-end, performance, user acceptance and regression testing and calls for increasingly realistic migrated data. This is why UAT appears after integrated process testing and migration rehearsal, and why business process owners rather than the build team sign acceptance.
Microsoft’s go-live readiness checklist connects completed test cycles, cutover migration, external dependencies, training, support and monitoring to the go-live decision. Its cutover process separates strategy, detailed planning, rehearsal, production execution and transition to support. The gate pack should therefore show how every readiness claim was tested and who accepted it.
For finance, record counts alone do not prove a successful migration. Microsoft’s posting and reconciliation practices call for a mock period close, subledger-to-ledger reconciliation and a mock cutover of balances and open transactions before new transactions begin. The opening-balance bridge and subledger reconciliations are production-release evidence, not post-go-live cleanup.
Access controls and audit evidence
NIST SP 800-53 provides control families for account management, least privilege, separation of duties, audit records and configuration change. GAO FISCAM provides a framework for assessing information-system controls in a financial-audit context. Neither source supplies a universal private-company ERP role design. They support the checklist’s requirement for approved access, independent review, retained evidence and locally tailored control ownership.
Non-negotiable finance stop conditions
- Do not pass a phase with an unowned material decision, risk, interface, data domain, control or balance difference.
- Do not treat a signed design document as proof that the configured process or control works.
- Do not issue production access until roles, approval limits, segregation conflicts and emergency procedures have been tested and approved.
- Do not accept migration from record counts alone when the data carries value, accounting status or open-item consequences.
- Do not approve go-live without a practiced cutover, signed opening-balance bridge, support coverage and a feasible stop or rollback rule.
- Do not close hypercare while recurring controls, support queues, runbooks, open defects or first-close issues lack business-as-usual ownership.
What this checklist does not cover
ERP evaluation owns product selection: requirements, finalist scoring, demonstrations, vendor viability, implementation-partner evaluation and the approval recommendation. This page begins after that decision and governs implementation acceptance. Budget and resourcing for each phase should come from the five-year ERP cost model rather than the subscription quote.
It also does not prescribe vendor-specific configuration, project duration, staffing ratios, jurisdiction-specific tax treatment, accounting policy or legal requirements. The accountable finance, security, audit, tax and legal owners must adapt the rows, thresholds and evidence to the company’s entities, processes, risk model and system design.
