Most integration overruns start in the statement of work. The platform work is scoped line by line; the integrations get a single line and an hours estimate. This template gives integration work the structure it needs so it can be priced honestly, built without surprises, and accepted against criteria both sides agreed in advance.
It is written for implementation partners, agencies and ISVs scoping work that connects a platform – Salesforce, NetSuite, SAP, Shopify, ServiceNow or anything else – to the systems around it. Use it as a standalone integration SOW, or paste the sections into your main SOW.
Download the template (Word) – free, no sign-up. Edit it however you like.
This template is a practical starting point, not legal advice. Have your own counsel review contract terms.
How to use this template
- Fill in the interface inventory first. Everything else depends on it. If you cannot complete a row, that interface is not ready to be priced as fixed scope.
- Agree systems of record with the client’s business owners, not only with IT. Finance usually owns more than anyone expects.
- Write acceptance criteria that can be tested, including reconciliation between systems.
- Make every assumption explicit. The assumptions section is where your margin is protected.
- Price discovery separately if more than a couple of interfaces cannot be fully described yet.
Text in [square brackets] is guidance or a placeholder to replace.
The template
1. Purpose and scope summary
[One paragraph: the business outcome the integrations support – for example, “orders closed in Salesforce are created in NetSuite without re-entry, and invoice status is visible to sales within 15 minutes.”]
In scope: the interfaces listed in Section 2 and the data migration described in Section 7 (if any).
Out of scope: any interface, object, field or data source not listed in this SOW. Additional interfaces are handled through change control (Section 12).
2. Interface inventory
| ID | Source system | Target system | Objects / data | Direction | Trigger | Expected volume | Mechanism (if known) |
|---|---|---|---|---|---|---|---|
| INT-01 | [e.g. Salesforce] | [e.g. NetSuite] | [Accounts, orders] | [One-way / two-way] | [Real-time / event / scheduled – frequency] | [Records per day, peak per hour] | [API, middleware, file] |
| INT-02 | |||||||
| INT-03 |
[Add one row per interface. If the same two systems exchange different objects on different schedules, use separate rows.]
3. Systems of record
| Object | System of record | Systems that receive it | Field-level exceptions | Business owner |
|---|---|---|---|---|
| [Customer / account] | [System] | [Systems] | [e.g. credit limit and payment terms owned by ERP] | [Name, role] |
| [Product and price] | ||||
| [Order] | ||||
| [Invoice and payment] |
[For two-way flows, name the owning system for each field that can change on both sides, and the rule that applies when both change.]
4. Responsibilities
| Activity | Client | Delivery partner | Third party / other vendor |
|---|---|---|---|
| Provide API access, credentials and documentation for each system | [R/A/C/I] | ||
| Provide test environments with representative data | |||
| Configure the platform side of each interface | |||
| Build middleware, mappings and transformations | |||
| Obtain cooperation from third-party system owners | |||
| Execute integration and end-to-end testing | |||
| Business acceptance and sign-off | |||
| Production monitoring and support after go-live |
[R = responsible, A = accountable, C = consulted, I = informed. Third-party system owners are often not party to this SOW; name the client as responsible for securing their cooperation and response times.]
5. Acceptance criteria
For each interface in Section 2, acceptance requires:
- Timeliness: records created or changed in the source appear in the target within [time] under expected volume.
- Completeness: for an agreed test period, control totals – record counts and, where applicable, financial amounts – reconcile between source and target, with all differences explained.
- Accuracy: a sample of [number] records per object is checked field by field by the business owner and matches.
- Error handling: each failure condition in Section 6 produces the agreed behavior in testing.
- Documentation: interface specifications, mappings and runbooks are delivered (Section 11).
[Name the test period, the sample size and who signs off.]
6. Failure behavior and non-functional requirements
| Condition | Required behavior | Alert to |
|---|---|---|
| Target system unavailable | [Queue and retry with backoff for up to N hours] | [Role / channel] |
| Record rejected by target | [Log with reason, route to exception queue] | |
| Same message received twice | [Processed once – idempotent by key: e.g. source record ID] | |
| Messages arrive out of order | [Apply latest state / version check] | |
| Mapping not found (e.g. unknown account code) | [Stop record, raise exception, never default silently] |
Non-functional: peak throughput of [N records per hour]; data retention of logs for [N days]; credentials stored in [vault / secret store] and rotated [frequency]; personal data handled per [policy].
7. Data migration (if applicable)
Data migration is scoped separately from the interfaces.
| Object | Source | Approximate volume | History included | Cleansing / dedup rules | Validation method |
|---|---|---|---|---|---|
| [Customers] | [System] | [Count] | [e.g. active plus last 3 years] | [Rules] | [Counts, totals, sample review] |
Rehearsals: [number] full-volume rehearsals before cutover. Sign-off: [business owner] signs off migrated data using the validation report.
8. Assumptions and change triggers
The price and timeline depend on the following assumptions. If an assumption proves false, it is handled as a change (Section 12).
- [System] exposes documented APIs for [objects] in the client’s current license and edition.
- Test environments with representative data are available by [date] and remain available until go-live.
- Peak volume does not exceed [N records per hour] per interface.
- Third-party system owners respond to technical questions within [N] business days.
- Systems of record and field ownership in Section 3 are agreed by [date] and do not change without change control.
- [Add assumptions specific to the engagement.]
9. Environments and access
| Environment | Systems included | Provided by | Available from | Data |
|---|---|---|---|---|
| Development | [Synthetic / masked] | |||
| Test / UAT | [Representative copy] | |||
| Production |
10. Cutover and hypercare
- Cutover plan with sequence, owners and go / no-go criteria agreed by [date].
- Rollback approach documented for each interface before go-live.
- Hypercare period of [N weeks] after go-live, covering [scope], with response targets of [targets].
11. Deliverables
- Interface specifications and field mappings for each interface in Section 2.
- Source code and configuration, delivered to [repository / client].
- Reconciliation report or query for each interface.
- Runbooks: monitoring, common failures and recovery steps.
- Handover walkthrough with [team].
12. Commercials and change control
Pricing model: [Fixed price for interfaces INT-01 to INT-0N / time and materials / fixed-price discovery followed by fixed-price build].
Change control: changes to interfaces, objects, systems of record, volumes or assumptions are raised in writing, assessed for impact on price and timeline within [N] business days, and approved by [roles] before work begins.
Checklist before you sign
- Every interface has its own row in the inventory, and nothing is described only as “integrations”.
- Systems of record are agreed with the business, not assumed.
- Someone is named as responsible for access to every third-party system.
- Acceptance criteria include reconciliation and error handling, not just “the integration works”.
- Duplicate and failure handling is specified for anything that carries money or orders.
- Data migration has its own section, rehearsals and sign-off.
- Every assumption the price depends on is written down.
Related reading
- How to scope integration work in a statement of work – the reasoning behind each section of this template.
- Integration reconciliation reports: proving two systems agree
- Idempotent webhooks: duplicates, retries and out-of-order events
- White-label subcontracting for integration work
Want a second pair of eyes on a scope?
eProxim reviews integration scopes for partners before they are signed, runs bounded discovery, and takes integration builds as fixed-scope work packages with acceptance criteria – under your brand if you prefer. Start a partner conversation.