How to Write a Statement of Work for a SAP Integration Project

A SAP integration project can fail commercially long before an interface fails technically. The warning signs often sit inside the statement of work: a vague interface count, unclear ownership, loose acceptance language, missing source-system duties, or a fixed price built on assumptions nobody wrote down. Those gaps become expensive once design has started and each side has a different view of what the original price covered.

A strong SAP integration statement of work turns the integration plan into a contract that can be managed. It names the systems and interfaces in scope. It states what the partner must deliver, what the customer must provide, how each integration will be tested, and what evidence is needed for acceptance. It also explains how scope changes, access delays, security reviews, and production support affect cost and schedule.

This guide focuses on the parts of the SOW that matter during delivery. It is written for SAP Integration Suite projects that connect SAP S/4HANA, SAP ERP, SAP cloud applications, non-SAP systems, APIs, files, events, or partner networks. The same structure also works for migration projects where existing PI or PO interfaces are being rebuilt or moved.

TL;DR

·        Build the SOW from an agreed interface inventory rather than a single interface count.

·        Define each integration by source target business purpose direction pattern volume and criticality.

·        Turn requirements into measurable acceptance conditions before development starts.

·        State which side owns credentials certificates firewall changes endpoint readiness and test data.

·        Set the architecture rules for APIs events files mappings retries logging and error handling.

·        Define testing cutover monitoring hypercare and handoff as priced deliverables.

·        Tie fixed price to written assumptions and use a clear change process when an assumption changes.

What The SOW Must Accomplish

The SAP integration statement of work should answer one practical question: what does each side have to do for an integration to move from approved design to accepted production service? A contract that only says the supplier will “design, build, and test integrations” leaves too much room for later disagreement. The SAP integration statement of work needs enough detail for a project manager to identify an obligation, assign an owner, and decide whether the work is complete.

Start by separating the project objective from the delivery obligations. The objective might be to connect SAP S/4HANA with a warehouse platform, CRM, bank, tax service, or data platform. The obligations are more specific. They cover interface discovery, design decisions, build artifacts, security setup, testing, deployment, monitoring, documentation, and handoff. SAP describes Integration Suite as supporting cloud, on-premise, and hybrid scenarios across application, API, event, and B2B integration. The Integration Suite overview is useful when checking which platform capabilities actually apply to the project, because the SOW should name only the services and patterns the team expects to use.

A useful SAP integration SOW also distinguishes deliverables from activities. “Attend design workshops” is an activity. “Approved interface design for IF-017 with source mapping, security method, error path, and acceptance criteria” is a deliverable. Activities explain effort. Deliverables explain what the customer receives.

The contract should also make uncertainty visible. Integration work often starts before every endpoint, payload, or volume figure is known. That is manageable if the SAP integration requirements list the unknowns, the person who must resolve them, and the commercial rule that applies if the answer changes the estimate. Hidden uncertainty is what later becomes a surprise change request.

Start With The Integration Landscape And Project Objective

Write the opening SAP integration scope from the business process outward. Name the business event that starts the flow, the systems that take part, and the result the process needs. “Integrate Salesforce with SAP” is too broad. “Create customer records approved in Salesforce in SAP S/4HANA within 5 minutes and return the SAP business partner number” gives the team a process boundary it can design and test.

The SAP integration project should also state the landscape in plain terms. List the SAP products, non-SAP applications, middleware, network zones, environments, and external parties that matter to the work. Record which systems are cloud, on-premise, or partner-managed. If the project spans several business units or countries, state which ones are in the first release and which are excluded.

Architecture work becomes easier when the SOW names the integration styles the company permits. SAP’s advisory methodology starts by assessing integration domains, styles, and use-case patterns before technology mapping. Use that idea to write the SAP integration scope. Define where process integration, data integration, APIs, events, or B2B exchange apply instead of allowing every workstream to choose its own pattern during build.

The project objective should also define success at a business level. Examples include retiring a legacy middleware runtime, removing manual file handling, meeting a new partner onboarding date, or supporting an S/4HANA cutover. Avoid using a technical output such as “50 interfaces deployed” as the only success measure. An interface can be deployed and still fail to support the business process it was meant to carry.

Add a short list of out-of-scope items after the objective. Common exclusions include source application changes, end-user training, historical data conversion, new master-data governance, third-party license purchases, or interfaces listed for a later release. Clear exclusions keep the SAP integration statement of work from becoming a catch-all contract for every system that touches SAP.

Define The SAP Integration Scope Interface By Interface

An interface inventory is the commercial backbone of the SAP integration SOW. Give each interface a stable ID and record enough information to estimate it. At minimum, include source, target, business purpose, direction, trigger or schedule, integration pattern, expected message volume, data sensitivity, and criticality. Add the current technology when the work is a migration.

SAP’s Integration Assessment capability distinguishes a business solution request from the technical interface request. The Integration Assessment model can help structure discovery because it records integration requirements and technology proposals at the interface level. Even if the project doesn’t use that tool, the same separation is useful in the SOW: the business need explains why the flow exists, while the interface record explains what must be built.

Use an interface status field as well. Mark each item confirmed, provisional, discovery required, or excluded. That one field can prevent pricing confusion. If a fixed price covers 40 confirmed interfaces and another 12 are still provisional, the contract should say how provisional items are priced once discovery is complete.

Do not price all interfaces as equal units unless they are genuinely similar. A simple scheduled file transfer and a high-volume synchronous API with transformation, throttling, OAuth, retries, and external-party testing do not carry the same effort. The SAP integration scope should include a sizing method or complexity band if the commercial model relies on interface counts.

The inventory should also identify dependencies. A supplier may be unable to build an interface until the customer provides a target endpoint, sample payload, VPN route, certificate, or non-SAP developer. Write those dependencies beside the affected interface instead of leaving them in meeting notes.

Turn SAP Integration Requirements Into Testable Outcomes

Requirements belong in the SOW when they affect price, design, or acceptance. The SAP integration requirements should state what the integration must do under normal conditions and what it must do when something goes wrong. That includes processing rules, mapping rules, validation, duplicate handling, retries, error routing, data retention, and audit needs where relevant.

SAP Cloud ALM lets teams capture requirements, approve them, assign roles, and create work from them. The requirements guidance is useful here because it treats requirements as business expectations that need to be realized and approved. The contract doesn’t need to reproduce every user story, but it should state which approved repository becomes the source of truth once detailed design starts.

Write requirements so they can be tested. “Interface must be fast” has no acceptance value. “The API must return an accepted request or defined error response within 3 seconds for 95% of calls under the agreed test load” is measurable. If there is no verified performance need, do not invent one. Record the requirement as pending and make performance testing a discovery or design task.

The same rule applies to reliability. If the business can tolerate a 30-minute delay, state it. If every failed message must be retried 3 times before entering an error queue, state that only after the architecture team approves it. Contract language should reflect the actual operating requirement rather than generic middleware habits.

Each requirement should have an owner and acceptance path. Business owners accept business behavior. Security teams accept security controls. Integration architects accept design rules. Operations teams may accept monitoring and support readiness. A SAP integration project becomes difficult to close when one person is expected to approve work outside their authority.

Use the requirements register to control later changes. If a requirement is added after baseline approval, the partner should assess its effect on design, build, testing, and schedule. The change process can then use evidence instead of arguing over whether the item was “obvious” from the original scope.

Set Architecture And Integration Pattern Guardrails

The SAP integration statement of work should define architecture rules without trying to become a full technical design. State the approved integration platforms, patterns, and decision authorities. That gives developers boundaries while leaving room for detailed design after discovery.

For API work, define whether SAP Integration Suite API Management is in scope and who owns API design standards. SAP states that its API Management capability supports API design, security, traffic management, lifecycle governance, and monitoring. If the project needs those controls, put the related artifacts in the deliverables instead of assuming they appear because an API is being built.

For event-driven flows, state when asynchronous events are allowed and what delivery behavior is expected. SAP describes SAP Event Mesh as a way for applications to communicate through asynchronous events across SAP and non-SAP sources. The SOW should still define event ownership, topic or queue naming, replay expectations, dead-letter handling, and which team investigates missed or duplicated events.

Define the policy for reusable content too. If the partner can use SAP-delivered integration packages or existing company artifacts, state how those assets will be assessed before custom build starts. Reuse can reduce work, but only if the content fits the actual source and target versions and the team records any changes made to it.

The SAP integration statement of work should identify architecture approvals that can block development. Examples include a new public API, a new outbound internet route, use of a new adapter, or an exception to an internal integration standard. State who approves those choices and how long the customer has to respond. That turns architecture review from an informal dependency into a managed project condition.

Define Deliverables And Acceptance Criteria

Every major work package needs an output and an acceptance rule. A SAP integration SOW can group interfaces into design, build, test, and deployment deliverables, but each group should still point back to the interface IDs in scope. This keeps billing tied to identifiable work.

A design deliverable might include the approved interface design, field mapping, security method, error handling, monitoring plan, and dependency list. A build deliverable might include the deployed integration artifact, configuration documentation, unit-test evidence, code or artifact repository update, and peer-review result. Production acceptance can require successful end-to-end testing plus completion of the agreed operations handoff.

Use measurable acceptance language. Current US federal guidance for performance work statements says work should be described in terms of required results and assessed against measurable standards where practical. The performance work rules are written for government buying, but the contract principle translates well to SAP services: define the result that must exist and the evidence used to accept it.

Set the review window. If the customer has 5 business days to review a design, state when the clock starts, what happens when feedback is incomplete, and whether rejected work must identify the unmet acceptance condition. Avoid automatic acceptance clauses that can approve a complex deliverable merely because a reviewer was unavailable.

Payment milestones should follow accepted deliverables when the commercial model allows it. If a milestone is tied to “Realize phase complete,” define what complete means for this project. Milestone names borrowed from a method are too broad unless the contract lists the included outputs.

The SAP integration statement of work should also define how partial acceptance works. A release may contain 20 interfaces when 18 are ready and 2 are blocked by a third party. The contract should explain whether the 18 can be accepted independently or whether the whole group stays open. This matters for billing and for keeping unrelated work from being held hostage by one dependency.

Assign Roles And Customer Dependencies

Integration delivery is shared work. The SAP integration statement of work should name the responsibilities of the partner and the customer with enough detail to prevent handoff gaps. A RACI can help, but the written duties matter more than the matrix itself.

The partner may own interface design, configuration, mapping, development, technical testing, deployment support, and documentation. The customer may own business requirements, source-system changes, identity approvals, network routes, certificates, test data, user acceptance, and production change authorization. Those are examples only. Use the split that matches the project.

Make customer dependencies time-bound where they affect the schedule. If the partner needs test credentials 10 business days before system integration testing, say so. If a non-SAP vendor must expose an API before build can finish, identify that dependency and the escalation path. The SAP integration project schedule should not assume that every external team can respond immediately.

Roles should also cover decision rights. Name who can approve an interface design, accept a requirement change, authorize a production deployment, and approve paid scope. The person who asks the partner to do extra work may not be the person who can commit budget. The SAP integration SOW should separate those authorities.

Include staffing assumptions if they affect the price. If the partner promises a named architect at 50% allocation or on-site cutover support, write it down. If the customer must provide a full-time integration lead or 2 hours per week from each application owner, make that visible too. A project can miss dates because the customer did not provide promised subject-matter experts just as easily as it can miss dates because the supplier understaffed the build.

Cover Environments Access And Security

The SAP integration statement of work needs a security workstream when the integration team will handle credentials, certificates, sensitive payloads, or privileged access. State which environments are included and who provisions access to each one. Development, test, quality, pre-production, and production may have different approval paths.

For API exposure, specify the expected authentication and policy controls after the security team confirms them. SAP’s API security guidance lists options such as OAuth, API keys, SAML, access control, threat protection, and traffic policies. The SOW should assign responsibility for configuring the chosen controls and for getting the required client registrations or identity-provider changes completed.

Certificate ownership deserves its own line. SAP documents the tenant keystore as the place where customer-owned key pairs and X.509 certificates can be managed for Cloud Integration. The keystore management guide makes the ownership distinction clear. In the contract, state who requests certificates, who imports them, who monitors expiry, and who rotates them after go-live.

Apply least-privilege thinking to project access. NIST’s cloud access model explains identity-based authorization for cloud-native applications and multi-cloud environments. The practical SOW question is simpler: which roles need access to which resources, for how long, and who removes that access when a consultant leaves the project?

The SAP integration requirements should also cover sensitive data in logs and traces. If payload logging is restricted, say so. If production message content may be viewed only during an approved incident, define the control. These requirements affect how developers debug and how operations teams investigate failures, so they should be known before build standards are set.

Define Build Standards And Transport Process

The SOW should state what quality checks apply before an integration artifact can move to the next environment. That can include naming rules, error handling, security review, peer review, documentation, transport packaging, or use of an approved repository. Keep the list tied to standards that your organization actually enforces.

SAP’s Integration Solution Advisory Methodology recommends adding integration-specific checks to existing quality practices. Its integration quality guidance covers quality considerations across requirements, design, implementation, testing, go-live, and operations. A project SOW can turn those internal rules into a required quality gate for each interface or release.

Define who moves artifacts between environments. Some companies let the implementation partner deploy to development and test while internal operations control production. Others allow a managed-service team to handle all transports under change approval. The contract should match the actual control model and include the lead time for each approval.

Versioning and rollback need clear ownership. The team should know where the approved artifact is stored, how configuration differences are recorded, and what happens if a deployment has to be reversed. Avoid putting detailed command-level procedures in the main SOW. Reference a release or transport standard if one already exists and make compliance with it part of acceptance.

The SAP integration scope should also state whether common frameworks count as project deliverables. A partner may build shared logging, reusable exception handling, or a standard API policy set for several interfaces. If the customer expects ownership of those artifacts after the project, identify them as deliverables instead of allowing them to remain undocumented partner accelerators.

Set Testing Defect And Performance Rules

Testing should prove the business flow works across all systems in scope. The SAP integration statement of work needs to define the test levels, who prepares the cases, who provides test data, who executes each test, and what makes a cycle pass.

SAP Cloud ALM supports manual and automated test cases and can link test cases to requirements or user stories. The test preparation guidance gives a useful traceability model for an SAP integration project because it connects the original need to test evidence. Even if another test tool is used, require that every critical interface requirement can be traced to an executed test.

Define defect severity before testing starts. A severity 1 defect should have a business-impact meaning, not merely a label. State which severities block exit from system integration testing or user acceptance. If lower-severity defects can remain open at go-live, require an approved waiver and a target fix date.

Performance testing belongs in scope only when there is a real performance requirement and a test environment that can support it. Record the expected volume, concurrency, payload size, and response or processing target where these are known. Also state which connected systems must participate. An integration runtime cannot prove end-to-end performance if the target system is a stub with no realistic behavior.

The SAP integration requirements should include negative tests where failure handling matters. Test invalid credentials, malformed payloads, unavailable endpoints, duplicate events, and retry behavior when those conditions can occur in production. The exact cases depend on the interface. The SOW should require them based on risk instead of forcing the same test pack on every flow.

Write Cutover Monitoring And Support Obligations

Cutover is a deliverable, not a calendar date. The SAP integration SOW should describe the tasks that move interfaces from test to production and the checks that prove the release is working. Include transport sequencing, endpoint changes, credential activation, scheduler changes, queue or topic setup, smoke tests, and business validation where they apply.

The cutover plan should identify dependencies between interfaces. A downstream interface may not be testable until a source job is active. A partner connection may have a narrow activation window. A certificate may need to be exchanged before the production endpoint is reachable. Sequence those conditions in the cutover plan and name the owner of each step.

Monitoring also needs a defined outcome. SAP documents central monitoring options for Integration Suite that include message search, alert handling, health information, certificate validity, and integration exceptions. Use the monitoring guidance to decide which operational signals matter, then put the required dashboards, alerts, ownership, and runbooks in the contract.

Hypercare should have a start point and an exit rule. Define coverage hours, the roles that remain available, response expectations by severity, and how open defects are handled at the end of the period. If the implementation partner hands support to another team, include knowledge transfer and a formal acceptance of the handoff.

The end-to-end project record should connect requirements, work, testing, and deployment. SAP’s implementation process guidance describes that flow through requirements, user stories, test cases, and deployment. Your SOW can require equivalent traceability without forcing a specific project tool if the company already uses another one.

Do not leave monitoring ownership until after go-live. The operations team should know which failures trigger alerts, who receives them, and what first-response steps are documented. A working interface with no agreed support model is unfinished delivery.

Price The Work And Control Changes

Pricing only makes sense when the SAP integration scope and assumptions are visible. For fixed-price work, state the number and type of interfaces included, the complexity assumptions, planned workshops, test cycles, cutover support, and customer dependencies that support the price. If one of those assumptions changes, the contract should explain whether the partner absorbs the change or raises a formal request.

For time-and-materials work, list the approved roles and rates and define who can authorize additional effort. Also state how estimates are created for new work and how often forecast-to-complete is updated. The buyer still needs scope control even when every hour is billable.

Change control should be simple enough to use. A change request should state the trigger, affected interface or deliverable, effort, cost, schedule effect, and any new assumption. It should also show what happens if the change is rejected. A change process that takes 3 weeks to approve a 1-day fix can stop the project, so set an approval route that matches the value and urgency of the work.

Avoid vague contingency pools. If the contract includes a block of hours for unknown integration work, define who can consume it and what evidence is required. Otherwise the pool can disappear into ordinary overruns without resolving the uncertainty it was meant to cover.

The SAP integration project should track remaining contingency beside the interface register and change log. That gives the steering team a direct view of how discovery is affecting the commercial plan. It also makes it harder for small additions to accumulate without a decision.

A strong SAP integration statement of work protects both sides. The customer can see what it is buying. The supplier can point to the assumptions and dependencies that supported its estimate. The contract becomes a working project control instead of a document that is opened only when a dispute starts.

Final SOW Review Before Signature

Review the draft as if the project were already 3 months late and both sides disagreed about responsibility. Could a new project manager read the SAP integration statement of work and determine which interfaces were included, who owed the missing endpoint, what evidence was required for acceptance, and how a late requirement should be priced? If not, the document still has gaps.

Run the SAP integration requirements against the interface inventory. Every material requirement should map to an interface, shared platform component, or project-wide rule. Check that the architecture section covers the actual patterns in the inventory. Then confirm that testing and acceptance can prove those requirements were met.

Review the customer obligations with the same care as supplier obligations. Endpoint readiness, network access, credentials, certificates, test data, source-system changes, and business testers can all sit on the critical path. Assign dates or lead times to the dependencies that can stop work.

Check the commercial section last. The price should match the final SAP integration scope rather than an earlier discovery estimate. Provisional interfaces should have a defined treatment. Any named resource, cutover window, test cycle, support period, or documentation package that affected vendor selection should still exist in the signed language.

A useful SAP integration statement of work gives the project a shared definition of done. It won’t remove technical surprises. It will make those surprises easier to classify, price, test, and resolve because the baseline is clear.

FAQs

What Is A SAP Integration Statement Of Work?

A SAP integration statement of work is the project document that defines the integration services a supplier will perform and the results the customer will receive. It should cover scope, interfaces, deliverables, responsibilities, assumptions, acceptance, testing, security, cutover, support, pricing, and change control that apply to the engagement.

What Should Be Included In A SAP Integration SOW?

A SAP integration SOW should include the project objective, interface inventory, in-scope systems, exclusions, requirements, architecture rules, deliverables, roles, customer dependencies, environment responsibilities, testing, acceptance criteria, cutover, support, pricing, and the process for handling changes. Add schedules for detailed interface or rate information when the main document would become too dense.

How Detailed Should The Interface Inventory Be?

Record enough detail to estimate and test each interface. A useful entry includes a stable ID, source and target, business purpose, direction, trigger, pattern, volume where known, security needs, criticality, status, and key dependencies. Migration projects should also record the existing technology and any known custom behavior.

Should Every Interface Have Separate Acceptance Criteria?

Each interface needs acceptance conditions that reflect its requirements, but they can inherit common criteria from a project standard. For example, all interfaces may require unit-test evidence and monitoring documentation while a critical API also has its own performance and security checks. The SOW should make the inheritance clear.

How Should SAP Integration Requirements Be Written?

Write SAP integration requirements as observable outcomes. State the expected data or process result and include measurable conditions when the business has a real threshold. Also cover failure behavior where it matters. Avoid adjectives such as fast or secure unless the document defines what those words mean in a testable way.

Who Should Own Source-System Changes?

The owner depends on the project model. The customer often owns changes in systems it controls while the integration partner owns Integration Suite artifacts. Another vendor may own a third-party system. The SOW should assign each source and target change explicitly and include the dependency in the schedule.

How Should Security Be Covered In The SOW?

Define who owns identity setup, credentials, certificates, network access, API policies, sensitive-data handling, privileged access, and access removal. The SOW should point to existing company security standards where possible. Project-specific duties still need named owners and acceptance evidence.

Should Monitoring Be A Project Deliverable?

Yes when the project is expected to hand over a supportable production service. Define the alerts, dashboards, runbooks, ownership, and access required by the operations team. The exact monitoring design can be completed during build, but the obligation to deliver it should already exist in the contract.

How Should Testing Be Split Between Partner And Customer?

The partner commonly owns technical and unit testing for its artifacts while both sides support end-to-end testing. Business owners usually lead user acceptance because they can judge process outcomes. The SOW should state who writes test cases, supplies data, executes each cycle, fixes defects, and signs off results.

What Makes A Good Acceptance Criterion?

A good criterion describes an observable result and the evidence used to approve it. It should be specific enough that 2 project managers can reach the same conclusion from the test result or deliverable. Acceptance also needs an owner and a reasonable review period.

How Should Fixed-Price Integration Work Handle Unknown Interfaces?

Separate confirmed interfaces from provisional work. Price the confirmed scope and define a sizing or change method for items that still need discovery. If provisional work is included in a contingency amount, state how the amount can be used and who approves consumption.

When Should A Change Request Be Required?

Require one when approved scope, requirements, assumptions, dependencies, or delivery conditions change enough to affect effort, cost, or schedule. Small clarifications that fit the original requirement shouldn’t automatically become paid changes. The SOW should define the threshold and approval route.

What Should Hypercare Include?

Define the period, support hours, responsible roles, severity handling, response expectations, daily or weekly reporting where needed, and exit criteria. Also state what happens to unresolved project defects when hypercare ends and which team owns them after transition.

Who Owns Integration Documentation After Go-Live?

The SOW should grant the customer the documentation and project artifacts it needs to operate the integrations, subject to the contract’s intellectual-property terms. Typical handoff items include interface designs, mappings, configuration notes, support runbooks, monitoring information, and deployment records.

How Do You Know The SAP Integration SOW Is Ready To Sign?

It is ready when the interface scope can be identified, material requirements can be tested, responsibilities are assigned, acceptance is measurable, dependencies are visible, and the pricing model matches the written assumptions. The project team should also be able to explain how a new requirement or blocked dependency would be handled without inventing a process after kickoff.