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.
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.
Create a separate record for each material work package. Use the following fields during review:
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.
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.
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.
“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.
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:
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.
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.
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.
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.