An ERP implementation statement of work (SOW) converts a sales proposal into an executable agreement about what will be delivered, by whom, when, under which assumptions and how completion will be accepted. If the SOW describes activities but not measurable outputs, the buyer may struggle to control scope, assess progress or challenge incomplete work.
This guide explains the commercial and delivery topics an enterprise buyer should review. It is not legal advice or a substitute for contract review. ERP agreements should be checked by legal, procurement, finance and technical stakeholders in the relevant jurisdiction.
1. Connect the SOW to business outcomes
Start with the business objectives and processes the project is intended to support. “Configure accounts payable” is an activity; “route supplier invoices through defined approvals and post approved invoices to the general ledger with an agreed audit trail” is closer to an outcome that can be tested.
State the intended business scope, entities, locations, user groups, modules, process areas, deployment waves and target operating model. The SOW should align with the approved proposal, requirements, solution design and commercial schedule. Identify which document takes precedence if terms conflict.
2. Define in-scope and out-of-scope work
List included work by workstream and phase. Typical workstreams include discovery, solution design, configuration, extensions, integrations, data migration, reporting, testing, training, cutover and support transition. For each, define the expected activities and outputs.
List exclusions with equal care. Examples may include historical data beyond an agreed period, integrations not named in the scope, new legal entities, custom reports beyond a stated allowance, additional locations, process redesign outside selected areas or post-go-live enhancements. Avoid vague phrases such as “standard reports” unless standard is defined.
3. Specify deliverables and acceptance criteria
A deliverable is a work product or completed capability that the customer can review. It should have an owner, format, due date, review period and acceptance method. “Complete design” is difficult to verify; “approved process design document covering the listed business processes, decisions, gaps and configuration assumptions” is more specific.
| Deliverable | Example acceptance evidence |
|---|---|
| Project plan | Milestones, dependencies, owners, critical path and governance agreed |
| Solution design | In-scope processes, fit gaps, integrations, roles and design decisions reviewed and approved |
| Configured solution | Demonstrated against agreed scenarios and configuration records supplied |
| Integration package | Interface specification, error handling, security and agreed test results delivered |
| Data migration | Mapping, cleansing rules, migration results and reconciliation signed off |
| Test evidence | Test scripts, results, defect status and exit criteria documented |
| Training and handover | Materials, attendance, administrator training and support documentation provided |
| Cutover package | Sequenced tasks, owners, rollback conditions and go/no-go criteria approved |
Define how the customer reviews each deliverable, how defects are classified, how rejected work is corrected and when resubmission is due. Avoid acceptance language that automatically treats silence as approval without a fair review process and explicit safeguards.
4. Make responsibilities and dependencies explicit
ERP delivery is a joint effort. The partner may own configuration and technical delivery, while the customer owns business decisions, data accuracy, process owners, timely approvals and user availability. Put these responsibilities into a RACI or equivalent matrix.
For each customer dependency, state the required input, accountable role, due date and consequence of delay. Examples include access to legacy systems, data extracts, subject-matter experts, security decisions, third-party credentials and approval of design documents. The partner should also identify its dependencies and provide notice when a risk threatens the schedule.
5. Identify named roles and resource commitments
Ask for named project leadership and key specialist roles, their expected allocation and the phases in which they are required. Clarify who can approve design decisions, manage issues, lead data migration, own integrations and coordinate testing. Define how key personnel can be replaced, what notice is required and how knowledge transfer will be handled.
Do not assume that the people who presented the proposal will deliver the project. Validate the proposed team, subcontractors, location model, time-zone coverage and escalation contacts.
6. Tie milestones and payments to verifiable progress
Build a milestone schedule around meaningful deliverables and decision gates, not simply elapsed time. For each milestone, state the output, acceptance criteria, customer review period, dependencies and payment trigger. Make sure the schedule includes time for review, correction and retesting.
Review advance payments, non-refundable fees, expenses, travel, taxes, rate cards, capped time-and-materials work and assumptions about customer delays. The lowest headline fee may not represent the lowest exposure if significant services are excluded or change requests are priced without controls.
7. Establish a workable change-control process
Changes are normal in ERP projects. The objective is not to prevent all change but to make its impact visible before work proceeds. Require a written change request describing the business reason, scope change, alternatives, cost, schedule, resources, dependencies, risk and effect on acceptance criteria.
Specify who can request a change, who estimates it, who approves it and whether work may begin before approval. Set thresholds for steering committee approval. Keep a change log linked to the baseline scope and project plan. Verbal instructions and informal meeting notes should not silently expand the contractual scope.
8. Cover data, integrations and customisation
Data migration should identify source systems, entities, history, cleansing responsibility, mapping, trial loads, reconciliation, cutover loads and retention. Define what constitutes a successful migration, including record counts and financial or operational balance checks where relevant.
For integrations, list each interface, source and target, direction, frequency, data owner, authentication method, error handling, monitoring and test responsibility. Avoid broad language such as “integrate with existing systems” without an interface inventory.
For customisations and third-party products, clarify specifications, ownership of deliverables, licence responsibility, support model, upgrade compatibility and documentation. Ask how design changes will be assessed for future maintenance cost.
9. Define testing, go-live and warranty responsibilities
State the test phases, entry and exit criteria, defect severity definitions, responsibilities and sign-off authority. Include system integration testing, user acceptance, performance and security testing where relevant. Specify whether the partner must correct defects before a milestone is accepted and how retesting is handled.
Go-live provisions should identify readiness criteria, cutover ownership, rollback decisions, support coverage and the conditions for a no-go decision. Define any warranty or defect-correction period, what it covers, exclusions, response expectations and the process for distinguishing defects from new requirements.
10. Plan post-go-live support and exit
Specify hypercare duration, support hours, ticket channels, severity levels, response and resolution targets, escalation path, reporting and transition to steady-state support. Clarify whether support is provided by the implementation partner, software publisher or another service provider—and where responsibilities change hands.
Include knowledge transfer, administrator training, configuration documentation, integration runbooks, credentials handover and access removal. Address data export, transition assistance, subcontractor obligations and access to project artefacts if the relationship ends.
Questions to ask before signing
- Can each deliverable be objectively reviewed and accepted?
- Are assumptions, exclusions and customer dependencies complete?
- Are named key resources and replacement rules clear?
- Are milestone payments tied to verifiable outputs?
- Can change requests be assessed before cost or schedule is committed?
- Are data, integration, customisation and testing responsibilities assigned?
- Are go-live, warranty, hypercare and support transition defined?
- Are ownership, data access, confidentiality and exit arrangements addressed?
Bottom line
A useful ERP SOW protects both parties by making expectations explicit. It defines business outcomes, scope boundaries, deliverables, acceptance criteria, responsibilities, assumptions, change control and post-go-live obligations. If a key commitment cannot be measured, assigned or traced to a deliverable, resolve it before signing rather than relying on goodwill during delivery.
For additional project readiness context, review Microsoft’s Dynamics 365 go-live preparation guidance. The Government Finance Officers Association also publishes ERP procurement and contract-management resources relevant to public-sector buyers.
