Integration is where fixed-price implementation projects quietly lose their margin. The platform work is usually estimated carefully, line by line, and then the integrations show up as a single entry – something like “Integrate with ERP, 80 hours.” By the time anyone finds out that the ERP has no API for the objects that matter, the hours are gone, and the go-live date hasn’t moved an inch.
A good integration statement of work prevents that. It doesn’t need to be long, but it does need to make the unknowns visible, give each of them an owner, and define what “done” means in terms both parties can actually test. In this article, I’ll go through what that document should contain.
Want the template itself? Download our free integration SOW template, which has every section described below, ready to fill in.
Why integrations are hard to scope
How much effort an integration takes depends on facts the selling team rarely has when the proposal is written: whether the other system has a usable API for the specific objects you need, who owns that system and how quickly they reply, how clean the data is and how much of it there is, how failures are handled today (if they’re handled at all), and whether there are test environments with realistic data in them.
None of these uncertainties is a reason to avoid quoting. They are, though, good reasons to write the statement of work so that its assumptions are spelled out, and the price is visibly tied to them.
The seven sections an integration SOW needs
1. An interface inventory
Everything rests on a table that lists every integration in scope, one row each, with its source, target, objects, direction, trigger (real-time, event-driven or scheduled), expected volume and, where it’s known, mechanism. Anything that isn’t in the table is out of scope. In my experience, this one table prevents more disputes than any clause a lawyer could write.
2. Systems of record
For each object, the SOW should say which system owns it – and, for two-way flows, which system owns each field. If the document says nothing about this, the build team makes the decision quietly, and the client finds out about it during user acceptance testing.
3. Responsibilities for each side of the interface
The SOW should record who provides API access, credentials, documentation and test environments for each external system, who builds each side of each interface, who tests it, and who supports it after go-live. The owners of third-party systems often aren’t party to the SOW at all, so the client should be named as the one responsible for getting their cooperation.
4. Acceptance criteria that include reconciliation
“The integration is working” isn’t something anyone can test. Better criteria say that records created in the source show up in the target within an agreed time, that totals such as record counts and financial amounts reconcile between the systems over a test period, and that each defined error condition produces the behavior defined for it – a retry, an alert or an entry in an exception report.
5. Failure behavior
The SOW should say what happens when the other system is down, when a record is rejected, and when the same message arrives twice. It should name the retry approach, the dead-letter handling, the alerting and the people who get the alerts. This is also where idempotency belongs, because duplicates in financial or order data are expensive to unwind.
6. Data migration, if any, as its own item
A migration is a different piece of work from an integration, and it should never be tucked inside one. It deserves its own scope, which covers the objects involved, their volumes, the number of rehearsals, the validation reporting and the person who signs off on the migrated data.
7. Assumptions and change triggers
Finally, the SOW should list the assumptions the price depends on, written so that if one turns out to be false, everyone can see that the consequence is a change. Typical assumptions are that the ERP exposes documented APIs for customers, items and orders; that test environments with representative data will be available by an agreed date; that peak volume won’t go above an agreed number of records per hour; and that the owners of third-party systems will answer technical questions within an agreed number of business days.
Fixed price or time and materials?
Where the scope really can be fixed – the integration is well defined, the APIs are documented and the acceptance criteria are clear – a fixed price is reasonable, and clients generally prefer it. Where the work is heavy with discovery, putting a fixed price on the unknown mostly moves the risk into contingency, and someone pays for that contingency either way.
A practical middle path is to fix the price of a short discovery, which produces the interface inventory and tests the assumptions, and then to fix the price of the build against what the discovery found. To be honest, it’s fairer to both parties than any single heroic estimate.
Red flags in an integration scope
There are a few warning signs that an integration scope isn’t ready to be signed. The most common is a single line for “integrations” with an hours estimate and no inventory behind it. Others are silence about who provides access to third-party systems, acceptance criteria that mention neither reconciliation nor error handling, and data migration folded into an integration line. The missing assumptions section is probably the most telling of all, because it means every assumption has quietly become the delivery team’s risk.
A client example: rescoping before signature
A Salesforce partner we work with was about to sign a fixed-price Service Cloud program for a distribution client, and the draft SOW covered the integration in a single line: “Integrate with ERP and billing.” Before signing, the partner asked us to review it. Over two days we ran two focused workshops with the client’s finance, service operations and ERP administrators and the partner’s solution architect, and the inventory came to eleven flows – customer master, asset registration, entitlement checks, orders, invoices, credit status, warranty claims, returns and several status updates.
Two of those flows depended on an ERP service-management module the client hadn’t licensed. Nobody owned warranty eligibility, and the draft said nothing about volumes, latency, error handling or acceptance tests. So we gave each flow a source and target, a trigger, a system of record, a mapping owner, an expected volume, its failure and replay behavior, and an acceptance criterion, with tests for failed and amended transactions alongside the successful ones.
The partner then restructured the SOW. The six flows that were ready went into a fixed-price first phase, three became conditional on decisions and source-data readiness, and the two module-dependent flows were excluded until the licensing question was settled, with a short discovery work order covering final mapping and estimates. The licensing gap surfaced before signature, the partner wasn’t left carrying unpriced change requests, and the client had a clear list of what go-live actually included.
Related reading
- White-label subcontracting for integration work
- Rescuing an ERP or Salesforce project
- Integration reconciliation reports: proving two systems agree
Working with eProxim
eProxim works underneath other firms’ client relationships, and scoping is often when partners first bring us in. We can review an integration scope before it’s signed, run a bounded discovery, or take on the integration build as a fixed-scope work package with acceptance criteria – under your brand, if you’d prefer.
About to sign a project with integrations in it? See how white-label delivery works, read the partner FAQ, or start a partner conversation.