What to Check in an ERP Statement of Work. Clarify deliverables, responsibilities and acceptance criteria.
Review an ERP statement of work by asking how each promised deliverable will be accepted in practice. Identify the input it depends on, the person doing the work, the observable result, and the person authorized to judge that result. Then test whether the surrounding responsibilities make delivery possible.
This turns a broad promise such as “complete data migration” into a set of questions that procurement, finance, the project team, and operating managers can answer together. The review is particularly useful before commercial approval, when assumptions can still be exposed and compared.
The worksheet in this article supports operational due diligence. Qualified legal and commercial reviewers should assess contractual wording, enforceability, remedies, liability, payment obligations, and other legal or financial consequences in the relevant context.
Read from the acceptance event backward
Choose a significant deliverable and imagine the review meeting at which someone will be asked to accept it. What would they inspect? Which business outcome would the evidence establish? What would prevent acceptance?
For a migrated opening receivables balance, a successful file load is only one event. The business may also need evidence that the intended population was extracted, transformation rules were approved, exceptions were resolved or accepted, and balances were reconciled at the required level of detail.
Work backward from that evidence to the tasks and inputs needed to produce it. Some may belong to the delivery team, some to the organization, and some to a third party. A statement that assigns the load does not automatically assign the extraction, correction, review, or reconciliation.
Apply the same reasoning to configuration, interfaces, reports, training, and support transition. The relevant question is what the agreed scope needs to establish, rather than whether a document with the expected title has been submitted.
Complete a responsibility and acceptance worksheet
Create a separate record for each material work package. Use the following fields during review:
- Deliverable and business use: What will exist, and who will use it? ______
- Scope boundary: Which entities, locations, processes, objects, and versions are included? ______
- Inputs: What data, decisions, access, environments, and availability are required? ______
- Input owner and readiness evidence: Who provides each input, and how will adequacy be checked? ______
- Delivery owner: Who produces and coordinates the output? ______
- Dependencies: Which other work must finish, and what happens if it does not? ______
- Acceptance evidence: Which scenarios, reconciliations, records, or observations demonstrate completion? ______
- Acceptance reviewer: Who has the expertise, availability, and authority to judge the evidence? ______
- Exceptions: Which limitations may remain, who can accept them, and where are they recorded? ______
- Support transfer: Who receives the result, and what knowledge or access must transfer? ______
- Exclusions and assumptions: What is not provided, and which estimates depend on it? ______
- Change route: How will a changed need or failed assumption be evaluated and approved? ______
Use the worksheet as a discussion aid. It does not amend the agreement by itself. Relevant clarifications need to be reflected through the authorized contractual and project-governance processes.
Find the work hiding inside a client responsibility
A phrase such as “the client supplies approved data” can imply substantial work. The organization may need to identify the source, decide which records belong in scope, correct inconsistencies, approve mappings, obtain access, and produce a repeatable extract.
Ask the responsible department to describe how it will satisfy that obligation. Confirm the people, skills, operating time, and review authority required. An assumption does not become feasible because it appears in a signed schedule.
Examine the delivery team’s responsibilities with the same care. If it will provide migration tooling, determine which transformations, error reports, iterations, and reconciliation outputs are included. Clarify the boundary between fixing a tool defect, correcting source data, and changing a business rule.
The purpose is to prevent a gap between responsibilities. Both parties can satisfy narrow descriptions of their tasks while the business outcome remains incomplete. A named coordinator should own the handoff and make unresolved seams visible, even when different parties perform the underlying work.
A hypothetical opening-balance review
Imagine a company preparing to migrate open customer invoices. Its draft work package says that the delivery team will load the opening receivables data and that finance will provide a clean file.
The operational review reveals several unresolved questions. Does “open” mean unpaid at the extraction time or unpaid at the agreed business cutoff? How will credits and unapplied receipts be treated? Who decides whether disputed items are included? Which reference identifies each record if a corrected load must be repeated?
Finance also needs to establish its reconciliation basis. Depending on the agreed scope, useful evidence might compare record counts and monetary totals by entity and currency, then examine customer-level balances and specified exception categories. Counts alone cannot show that values are correct. A net total alone can conceal offsetting errors.
The resulting work package could identify finance as the owner of population rules and source corrections, the delivery team as the owner of agreed transformation and loading activities, and a designated finance reviewer as the acceptance authority. A project coordinator tracks unresolved exceptions and their impact on the rehearsal schedule.
The team still needs to agree the specific tolerances, required evidence, review period, and consequences of failure through its normal approval processes. The example is a review pattern, not proposed legal wording or a universal accounting rule.
Name four different kinds of ownership
“Responsible” can obscure important distinctions. For each deliverable, identify who will:
Produce it. This includes coordinating contributors and making the output available in the agreed form.
Verify it. A competent reviewer checks that the evidence supports the required outcome. Depending on risk and organizational policy, verification may need appropriate separation from production.
Accept it. An authorized person decides whether the result meets the agreed criteria, whether permitted exceptions are acceptable, or whether further work is required.
Operate it. Someone supports the delivered process after the project team moves on, including routine changes, failures, and access requests.
One person may hold more than one role where appropriate. The important point is that each role has been considered and the arrangement suits the risk. Avoid assigning acceptance to a steering committee without identifying who will review the evidence before the meeting.
For an interface, the operating owner may differ from the person who built it. Ask what monitoring instructions, recovery procedures, configuration records, and support contacts must transfer. “Interface complete” should have an agreed meaning beyond the first successful transaction.
Make acceptance evidence proportionate
Not every deliverable needs the same level of proof. A consequential transaction control deserves deeper examination than a low-risk document-format preference. Select evidence according to the failure consequence and the uncertainty that remains.
Useful acceptance evidence may include:
- Execution of an agreed business scenario, including a material exception
- Reconciliation between defined source and target populations
- Review of role permissions for the scoped activities
- A repeatable build, load, or recovery procedure
- A support operator completing an agreed task using the handover material
- Confirmation that required decisions and unresolved limitations are recorded
Avoid broad claims such as “all testing complete” without identifying what was tested, under which conditions, and how exceptions were handled. Similarly, an acceptance criterion that depends on an unavailable external service needs a dependency decision before it becomes a late surprise.
Evidence has a version. Record the configuration, data set, environment, and procedure used where those details affect the result. A successful test on an earlier design may not support acceptance of a materially changed deliverable.
Compare proposals on the same operating boundary
When comparing statements of work, build a common work-package list and map each proposal to it. Mark each item as included, excluded, assigned to the organization, dependent on another party, or unclear.
Then examine the assumptions behind apparently similar entries. One proposal may include repeated migration rehearsals while another includes only a specified load. One may assume existing interfaces remain unchanged while another includes modifications. One may provide training material while another includes role-based delivery and attendance support.
Do not label a proposal incomplete merely because it uses a different delivery model. Determine who will perform the required work and how it enters the total effort, schedule, and cost assessment. A client-led activity can be entirely reasonable when the organization has the capacity and accountability to perform it.
Keep uncertain estimates visibly uncertain. Procurement should be able to distinguish quoted commitments from internal estimates and unpriced dependencies. Filling every blank with a confident number creates a misleading comparison.
Ask legal and commercial reviewers the consequential questions
Once the operational review is clear, give qualified reviewers the evidence they need. Highlight how acceptance interacts with payment milestones, review periods, disputed defects, delays, and changes in scope.
Ask them to explain the effect of any provisions governing deemed acceptance, use of a deliverable, termination, warranties, limitations, intellectual property, data handling, and dispute resolution where relevant. The operational team should understand what events may trigger consequences, without trying to supply its own legal interpretation.
Include document consistency in the review. A responsibility described one way in the work schedule and another way in a proposal or project plan may need reconciliation. Qualified reviewers should determine the contractual significance and appropriate correction.
Close the review with decisions rather than comments
A document full of unanswered questions is still an open review. Maintain a short issue register with the affected deliverable, exact ambiguity, business consequence, proposed resolution, responsible reviewer, and approval status.
Before approval, confirm that high-consequence ambiguities are resolved or explicitly escalated to the authorized decision maker. Check that client responsibilities are staffed, acceptance reviewers are available, and exclusions have a credible operating plan.
Start with the deliverable whose failure would most disrupt the first release. Work backward from the evidence needed to accept it. That exercise gives the statement of work a practical test: whether the promises, responsibilities, and dependencies can produce a result the business is prepared to use.