Integration is where fixed-price implementation projects quietly lose their margin. The platform work is usually estimated with care, line by line, while the integrations appear as a single entry along the lines of “Integrate with ERP, 80 hours.” By the time anyone discovers that the ERP has no API for the objects that matter, the hours have been spent and the go-live date has not moved.
A good integration statement of work prevents that outcome. It need not be long, but it must make the unknowns visible, give each of them an owner, and define what “done” means in terms both parties can test. This article sets out what such a document should contain.
Want the template itself? Download our free integration SOW template, which contains every section described below, ready to fill in.
Why integrations are hard to scope
Integration effort depends on facts that the selling team rarely knows when the proposal is written: whether the other system offers a usable API for the specific objects required, who owns that system and how quickly they respond, how clean the data is and how much of it exists, how failures are handled today, if they are handled at all, and whether test environments with realistic data are available.
None of these uncertainties is a reason to avoid quoting. They are, however, reasons to write the statement of work so that its assumptions are explicit and the price is visibly tied to them.
The seven sections an integration SOW needs
1. An interface inventory
The foundation is a table listing every integration in scope, one row for each, with its source, target, objects, direction, trigger (real-time, event-driven or scheduled), expected volume and, where known, mechanism. Anything not listed in the table is out of scope. In my experience this single table prevents more disputes than any contractual clause.
2. Systems of record
For each object, the SOW should state which system owns it and, for two-way flows, which system owns each field. If the document is silent on this, the build team makes the decision quietly, and the client discovers 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. Because the owners of third-party systems are often not party to the SOW at all, the client should be named as responsible for securing their cooperation.
4. Acceptance criteria that include reconciliation
“The integration is working” is not a testable statement. Better criteria require that records created in the source appear 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 its defined behavior, whether a retry, an alert or an entry in an exception report.
5. Failure behavior
The SOW should state what happens when the other system is unavailable, when a record is rejected, and when the same message arrives twice, and it should name the retry approach, the dead-letter handling, the alerting and the people who receive the alerts. This is also the place to specify idempotency, because duplicates in financial or order data are expensive to unwind.
6. Data migration, if any, as its own item
Migration is not an integration and should never be hidden inside one. It deserves its own scope, covering the objects involved, their volumes, the number of rehearsals, the validation reporting and the person who signs off the migrated data.
7. Assumptions and change triggers
Finally, the SOW should list the assumptions on which the price depends, written so that if one proves false, everyone recognizes the consequence as 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 will not exceed 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 scope can genuinely be fixed, because 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, fixed-pricing 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 that produces the interface inventory and tests the assumptions, and then to fix the price of the build against what the discovery found. It is fairer to both parties than a single heroic estimate.
Red flags in an integration scope
Several warning signs suggest that an integration scope is not ready to be signed. The most common is a single line for “integrations” with an hours estimate and no inventory behind it. Others include 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 absence of an assumptions section is perhaps the most telling of all, since it means every assumption has quietly become the delivery team’s risk.
Illustrative scenario: rescoping before signature
This scenario is a composite. It is representative of the scoping work we do with partners, but it does not describe a specific client, and nothing in it is a reported result.
A Salesforce partner is about to sign a fixed-price implementation that includes “integration with ERP and billing” as a single line item. Before signing, the partner asks for a review of the integration scope.
A two-day review produces an interface inventory of eleven flows rather than the three the proposal assumed, two of which depend on an ERP module whose API the client has not licensed. The partner restructures the SOW accordingly. The Salesforce build remains at a fixed price, a short integration discovery is added, and the integration build is priced as a scoped work package against the confirmed inventory, with acceptance criteria that include reconciliation.
A good outcome is one in which the licensing gap is found before signature rather than in the fourth month of the project, and the client sees a partner who understood the hard part of its own engagement.
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 beneath other firms’ client relationships, and scoping is often the point at which partners first bring us in. We can review an integration scope before it is 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 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.