SAP statement of work: what it must contain

An SAP statement of work (SOW) is the contract document that says what the partner will deliver, with what effort, by whom and how it can change. It must cover scope, detailed assumptions and exclusions, effort by phase and role, deliverables with acceptance criteria, named resources and change control.

Most SOWs cover scope well enough. What clients often leave out is detailed assumptions and exclusions, and that is the section that decides what you finally pay.

This article is part of my guide on how to choose an SAP implementation partner. The SOW is the last step of that process, after the SAP partner RFP and the orals. For a worked example of a SOW review before signature, read my case study on ERP contract negotiation.

A good SAP SOW reads like an operating manual for the programme. Anyone on your side should be able to open it and answer three questions: what are we getting, what does it depend on, and what happens when something changes.

These are the sections it needs, and what goes wrong when one is missing:

Section	What it should say	What happens if it is thin
Scope	Processes, modules, company codes, plants, countries and users in scope	Every workshop reopens the question of what was included
Assumptions	The conditions the price depends on, each with a consequence if it proves false	The partner raises change requests you cannot challenge
Exclusions	What the partner will not do, and who does it instead	Work falls between you and the partner, and nobody owns it
Approach and phases	The method, phase plan and quality gates	No agreed point at which a phase is finished
Effort	Estimated effort by phase and role	You cannot tell whether the burn rate is on plan
Deliverables and acceptance	Named documents and outputs, acceptance criteria, sign-off period	Invoices are paid for partial work
Resources	Named key people, roles, allocation and substitution rules	The team you met at the orals is not the team on site
Client responsibilities	What your people must provide, and when	Delays caused on your side become partner change requests
Change control	How a change is raised, assessed, priced and approved	Change requests become a second revenue line
Governance	Steering committee, reporting, escalation	Problems surface late, when they are expensive

Write the scope yourself before you ask for prices, so partners price your scope rather than their own.

This is the section clients often leave out. Without it, the price rests on conditions nobody on your side has read or agreed.

An assumption is a condition the partner has priced on. An exclusion is work the partner has not priced at all. Both need to be specific enough that a third party could check whether they held.

Assumption types to write down

Every assumption needs a consequence. "If this proves false, the change goes through change control with an impact assessment" turns an assumption from decoration into a control.

These are the categories an SAP SOW should cover:

1. Organisational scope. The number of company codes, plants, sales organisations, countries and legal entities the price covers.
2. Process scope. The business processes in scope, named, and the SAP standard processes the partner expects you to adopt.
3. WRICEF volume. The number of workflows, reports, interfaces, conversions, enhancements and forms, by complexity. Budgets get hit in the Explore phase as this list grows, so the baseline count belongs in the contract.
4. Data. The data objects to migrate, the volume of history, the number of mock loads, and who cleanses the data.
5. Integrations. Each interface named, with the system on the other side and who changes that system.
6. Testing. The number of test cycles, who writes the scripts, who executes them and who fixes defects.
7. Client availability. Which of your people are needed, for how much of their time, and how quickly decisions must be made.
8. Environments and licences. Who provides systems, tools and access, and by when.
9. Location and language. Where the team works, onshore and offshore mix, travel, and the languages for documents and training.
10. Training and hypercare. The training model, the number of trainers trained, and the length and exit criteria of hypercare.

The WRICEF baseline matters most to the budget. SAP's own course material describes the Explore phase as a fit-to-standard analysis, where approved delta requirements are added to the product backlog for the Realize phase (SAP Learning). Each approved delta can become new WRICEF effort, so you need the starting count to measure the growth against.

Exclusion types to write down

Exclusions should name who does the work instead. "Excluded" with no owner is a gap waiting to be found during cutover.

These are the usual categories:

1. Data cleansing and enrichment in the legacy systems, often a client task.
2. Changes to third-party and legacy systems on the other side of an interface.
3. Software licences and subscriptions, which sit in your contract with SAP, not in the SOW.
4. Infrastructure and hosting, unless the partner is explicitly running them.
5. End-user training delivery, where the partner only trains your trainers.
6. Organisational change management beyond what is listed.
7. Security, roles and authorisation design, if another party owns it.
8. Performance, penetration and regression testing outside the named cycles.
9. Countries, entities or localisations not in the organisational scope.
10. Post-hypercare application support, which is a separate contract.

Read the two lists side by side with your programme director. Anything that appears in neither list is the place a change request will come from.

The commercial model I recommend for an SAP implementation is time and materials, with the effort quantified. That means the estimated effort by phase and by role is written into the contract, so you can track actual effort against it every month.

Fixed price looks safer to a board. In practice the price is only fixed while every assumption holds, and an SAP programme tests most of them by the end of Explore. My notes on SAP implementation cost cover when a fixed-price phase can still make sense.

This is how the two models compare in the SOW:

Point of comparison	Fixed price	Time and materials with quantified effort
What the contract fixes	The price, while the assumptions hold	The rates, and the estimated effort by phase and role
Where the risk sits	The partner prices it in as contingency	With you, but visible every month
When scope moves	Every change becomes a negotiation	Effort moves, and you see it against the estimate
What you can track	Milestones and change requests	Actual effort against plan, by phase and role
What protects you	Tight assumptions and exclusions	Tight assumptions, exclusions and effort reporting

Quantified effort turns time and materials from an open cheque into a controlled budget. Ask for the estimate as a table of phases against roles, in person days, and make monthly reporting against that table a contract obligation.

Do not let the rates hide in the effort. Check the role mix against market rates using my guide to resource allocation planning for SAP projects.

A plan heavy on senior days early and junior days later is common. The reverse needs an explanation.

A deliverable is a named output with a definition of done. "Design support" is not a deliverable. A signed solution design document for record to report, reviewed against agreed criteria, is.

Tie acceptance to quality gates

SAP Activate runs in six phases: Discover, Prepare, Explore, Realize, Deploy and Run. SAP describes formal quality gates after each phase, which check that the phase deliverables are complete before the project moves on (SAP Learning).

Use those gates in the SOW. List the deliverables due at each gate, the acceptance criteria and the number of days you have to review. Tie payment to accepted deliverables, not to the calendar.

Someone on your side has to be able to judge those documents. This is one of the three points where I recommend bringing in an independent consultant: during contracting, for the design, and for assessing the partner's deliverables. My article on SAP partner versus independent consultant explains how the two roles work together.

Name the people, and check them

Weak quality in the proposed resources is one of the two things that make me walk away from a bid. The other is a partner that cannot explain the architecture and the plan.

The SOW should name the solution architect, the programme manager and each functional and technical lead. Write in their allocation, a right for you to interview replacements, and your approval for every substitution. The case study on ERP contract negotiation shows the named resource clause in practice.

Check certifications rather than taking a CV at its word. SAP issues certification badges through Credly, which supports real-time verification (SAP Learning). Under SAP's stay certified process, a certification lapses if the holder misses the mandatory assessment (SAP Learning).

This clause matters more than it looks. I have changed a partner during a programme, and the trigger was that the partner could not provide quality resources. My guide to changing an SAP partner mid-project covers what to secure before you get there.

Change control is where a thin SOW gets expensive. If the assumptions are vague, almost anything can be argued to be a change.

A workable change control section needs these elements:

1. A trigger. A change exists only when an assumption fails, an exclusion is brought into scope or you ask for something new.
2. An impact assessment. Scope, effort by role, timeline and cost, in writing, before work starts.
3. A rate card. Changes are priced at contract rates, with no premium for urgency unless agreed.
4. An approval level. Who on your side can approve changes up to which value, with the CFO above a set threshold.
5. A log. Every change, approved or rejected, reported to the steering committee with the running total.
6. A link to the baseline. New WRICEF objects are measured against the count in the assumptions.

The partner will raise legitimate changes. SAP programmes find things nobody knew at contract signature. The aim is that each change is visible, priced and approved before anyone spends the money.

Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start. The SOW is where that planning becomes binding, and time spent on it is cheap next to disputed change requests.

The concrete next step: take the SOW you have in front of you and list every assumption and exclusion on one page. Next to each, write what happens if it proves wrong and who pays. If you cannot fill that column in, the SOW is not ready to sign.

If you want an independent read of an SAP statement of work before signature, I help clients with this during contracting. You can contact me here.

What should an SAP statement of work include?

Scope, detailed assumptions, exclusions, approach and phases, estimated effort by phase and role, deliverables with acceptance criteria, named resources, client responsibilities, change control and governance. The part most often left thin is the assumptions and exclusions, and that is the part that decides the final cost.

What is the difference between assumptions and exclusions in an SAP SOW?

An assumption is a condition the partner priced on, such as the number of company codes or WRICEF objects. An exclusion is work the partner has not priced at all, such as legacy data cleansing. Each assumption should say what happens if it proves false, and each exclusion should name who does the work instead.

Is fixed price or time and materials better for an SAP implementation?

I recommend time and materials with the effort quantified: the estimated effort by phase and role written into the contract and tracked monthly. A fixed price only holds while every assumption holds, and an SAP programme tests most assumptions during the Explore phase.

How do you define acceptance criteria for SAP deliverables?

Name each deliverable, describe what complete looks like, and set a review period for your team. Tie them to the SAP Activate quality gates at the end of each phase, and release payment only when the deliverable is accepted.

Should the SAP SOW name the consultants?

Yes, for the key roles: solution architect, programme manager and the functional and technical leads. Add their allocation, your right to interview replacements and your approval for any substitution. Verify certifications through the SAP badges on Credly rather than relying on the CV.

Who should write the SAP statement of work?

The partner drafts it, but the scope and assumptions should come from you. Write your scope before you go to market, and have someone independent of the partner review the assumptions, exclusions and deliverables before signature.