ERP SOW Red Flags: The 11 Protective Terms Missing From Most Implementation Contracts

More than a quarter of ERP projects finished over budget and almost a quarter missed their schedule in Panorama Consulting's 2026 ERP Report. I would bet most of the contracts behind those projects read fine. That is the trap. The statement of work is written by people who negotiate these deals every week, for a buyer who signs one a decade, and the dangerous parts are not bad sentences. They are missing paragraphs, and every missing paragraph defaults in the vendor's favor.

Citable stat

Panorama Consulting's 2026 ERP Report, surveying 170 organizations from January 2025 to January 2026, found more than a quarter of ERP projects over budget and almost a quarter over schedule, on a median project timeline of nine months.

The same report names unplanned change orders, delayed vendor deliverables, and unclear ownership between the software vendor and the implementation partner as recurring problems its project recovery team gets called into. Each of those traces back to language that was never in the SOW. Below are the eleven protective terms our SOW Risk Scan checks for, why each goes missing, and what the absence tends to cost. One boundary up front: this is commercial negotiation guidance from a practitioner, not legal advice. What good language looks like is described conceptually here. Review anything you actually sign with your attorney.

What should an ERP statement of work include?

Eleven protective terms, at minimum: a change-order process, acceptance criteria for each deliverable, a defined data migration scope, named integrations, a fee cap or not-to-exceed, milestone-tied payments, training scope, a hypercare period, a responsibility matrix, an assumptions and exclusions section, and termination rights. Most first-draft SOWs are missing several of them, which is why the scan exists. Each absence shifts risk from the vendor, who wrote the document, to the buyer, who pays for it.

Citable stat

As of July 2026, our SOW Risk Scan weights change control, acceptance criteria, and data migration scope at 12 of 100 points each, the three heaviest of the 11 deterministic checks it runs on ERP implementation contracts.

The weights reflect a judgment call about where disputes start, informed by the same recurring problems Panorama's recovery team names. The full list is published on the tool page with nothing hidden, the same way our system scores trace to a public methodology. Here is each check, in the order the scan runs them.

The 11 red flags, in scan order

1. No change-order process

The most expensive omission on the list. When the SOW is silent on how scope changes get priced and approved, every mid-project discovery becomes a quote you have no framework to push back on. The reference case is worth knowing: in the MillerCoors SAP project, a single amendment in October 2014 added $9.6 million to a fixed-price work order of roughly $53 million after a dispute over the quality of blueprint documents. That is what a scope fight costs when there is an amendment framework and lawyers on both sides. With no process in the SOW, you renegotiate from nothing, mid-project, with the vendor holding the schedule. The language you want says no changed work begins without a written change order stating cost and schedule impact, priced from the original rate card, signed by your sponsor. Ask the vendor what the process and pricing is when scope changes mid-project. A vague answer is itself the answer.

2. No acceptance criteria

Without an acceptance test or UAT gate, "done" means whatever the vendor's status report says it means. The failure mode is an argument at go-live, when you have the least room to maneuver and the most money already spent.

Citable stat

MillerCoors sued HCL Technologies in March 2017 for more than $100 million over an SAP implementation that went live in November 2015 with 8 critical and 47 high-severity defects, per the complaint. The case was reported settled in December 2018, terms undisclosed.

Both sides spent nearly two years in litigation arguing, in essence, about what finished work was supposed to look like. Every deliverable needs measurable acceptance criteria, a defined review window for your team, and a stated remedy at the vendor's cost when acceptance fails. Acceptance also needs teeth, which is what check six is for.

3. Unscoped data migration

"Data migration included" without an entity list, history depth, volume estimates, cleansing ownership, and a count of mock conversions is not a scope. It is an invitation. Migration is where ERP budgets die quietly, because the effort scales with how dirty your data is, and nobody knows that number at signature. The questions the scan generates for this flag: exactly which records and how many years of history move, who cleanses them, and how many mock conversion cycles are included before the real one. Cleansing almost always lands on your team. Fine, but the SOW should say so, and say what happens to the price when the data arrives dirtier than the vendor assumed.

4. Silent on integrations

SOWs regularly gesture at "integration support" without naming a single system. Every integration discovered after signature is a change order at whatever price the vendor sets, and connector licensing plus middleware subscriptions have a way of surfacing on invoices nobody budgeted. iPaaS platforms bill annually, forever. The document should name each integration, its direction, who builds it, and who owns connector licensing and maintenance after go-live. If your quote-to-cash runs through Salesforce and your payroll through ADP, those words should appear in the SOW you sign.

5. No fee cap

A time-and-materials SOW with no cap, no not-to-exceed, and no notice requirement is an open checkbook with your signature on it. "Estimate" is not a cap, and vendors know the difference even when buyers read it as one. The base you are protecting is large.

Citable stat

Our NetSuite pricing research budgets implementation services at 1 to 2 times annual software cost as of July 2026, with partner-led mid-market projects typically running $50,000 to $150,000 before change orders.

Overruns compound off numbers that size, and the pattern holds across partner-delivered suites, whether the logo on page one is NetSuite, Dynamics, Acumatica, or Intacct. Our NetSuite pricing page breaks the full cost structure down. What good looks like: either a fixed fee per phase, or time and materials with a not-to-exceed and required written notice before it is crossed. The notice matters as much as the number: it forces the conversation while you can still act on it.

6. Payments untethered from milestones

Calendar billing pays the vendor whether the project advances or not. If the schedule is monthly installments, then by the time UAT slips you may have paid out most of the contract, and your negotiating position went out the door with the cash. Tie payments to accepted milestones, using acceptance as defined in check two, and hold a meaningful final payment until the system survives its first weeks in production. Vendors resist this less than buyers expect. Confident ones have less reason to.

7. Training left out

Missing training scope bites twice. First it makes the quote look pleasantly light against competitors who scoped it honestly. Then it comes back as either a post-signature invoice or a go-live where nobody can process a purchase order. Our NetSuite profile lists training and change management cut when budgets tighten among the most common implementation risks, and names the result: low adoption and shadow spreadsheets despite a technically successful go-live. Pin down how many hours are included, for which roles, delivered when, and whether train-the-trainer material transfers to you so the knowledge survives staff turnover. Fuzzy phrases like "user enablement activities" deserve a follow-up question in writing.

8. No hypercare period

The defect discovered on day two after go-live is either covered by a warranty and hypercare period or billed at full consulting rates. SOWs that skip the term default to the second option. Stabilization is when your team is weakest and most dependent, which makes it the most profitable phase for a vendor with no support obligation. Get the post-go-live support window defined: what is included, for how long, at what response times, and at what rate once the window closes.

9. No responsibility matrix

Every implementation estimate assumes client staffing the vendor rarely writes down. When your controller cannot give the project, say, twenty hours a week, the delay becomes your fault contractually, and it becomes the vendor's justification for the next change order. A responsibility matrix, RACI or plainer, puts the assumption on paper: the activities that are yours, the named roles you must provide. Decision turnaround times belong there too, because a slow yes from your side is the vendor's favorite delay explanation. You want to see what you owe before signature, because you will be held to it after.

10. No assumptions or exclusions section

Everything unstated becomes a change order. A short SOW with no out-of-scope section reads as generous and is the opposite: undefined. Ask for the exclusions list and for the specific assumptions that void the estimate if they turn out untrue: entity counts, transaction volumes, customization limits. Vendors sometimes treat this section as bad-news real estate best kept off the page. You want the bad news in writing while it is still negotiable.

11. No termination rights

Nobody signs an ERP contract planning to quit, yet some projects should stop, and mid-flight audits recommend exactly that. Without termination language you are negotiating your exit from a failing project with no defined rights and sunk costs mounting weekly. Conceptually: termination for convenience with a notice period, payment owed for accepted work only, and your data returned in usable form. This is also the clause where attorney review earns its fee most directly, because the interaction with the master agreement is where drafting gets technical.

How do you check an ERP SOW before signing?

Check it against the 11 protective terms above before signature, while every line is still negotiable, reading for what is absent rather than what is wrong. Our free SOW Risk Scan automates the first pass: paste the SOW text and it runs all 11 checks, returns a 0 to 100 risk score, and lists the exact questions to send the vendor. Then take the flags to your attorney.

Two honest caveats about the scan, because a referee that oversells is not a referee. A flag means the language was not found in the text you pasted; it may live in a master agreement or an exhibit you did not include. And presence is not quality. A change-control clause can exist and still be weak, which is precisely what attorney review is for. The scan catches the cheap, common failure: the term is not there at all. Your document is pattern-matched by deterministic rules on our server, never sent to an AI model, and the raw text is purged after 30 days.

If you are a few weeks from signature, run the scan tonight and put the flagged questions in front of the vendor tomorrow. The result is a risk summary that forwards cleanly to a CFO who has not read the SOW and needs a reason to slow the signature down, or to speed it up. And if you are still choosing the system rather than negotiating the contract, start with the free assessment instead. It scores 16 systems against your actual footprint, with the reasoning shown.