The NetSuite partner questions that matter most before you sign a statement of work are about people, boundaries and proof: who exactly will do the work, what is in and out of scope, how each deliverable will be accepted, who moves the data, how changes are priced, what support looks like after go-live and what you get back if you leave. If the SOW can't answer those in writing, it isn't ready to sign.
By the time a SOW arrives, you have usually chosen the partner. That's when buyers relax, and it's the point where the most expensive misunderstandings get locked in. Read it as the document you will be arguing from in month five.
Ask who will actually do the work
Ask for the named solution architect, project manager and lead consultants, with the share of their time on your project. Ask whether any work is subcontracted or delivered by an offshore team, and where. Then ask what happens if a named person leaves: how much notice you get, whether you can approve the replacement and who pays for their ramp-up.
Meet the people before signing. The sales team that ran the demo may not be the team that delivers. Our post on choosing a NetSuite partner using delivery evidence explains how to check their track record.
Ask where the scope boundary sits
Every SOW has a scope list. Fewer have a clear list of exclusions. Ask the partner to write down what is out: integrations not named, reports beyond a stated number, subsidiaries not live on day one, historical transactions, sandbox refresh work, training beyond a stated number of sessions.
Then check the assumptions. Phrases like "standard functionality", "client to provide" and "up to" hide a lot of cost. Ask what "standard" means for each process, and what happens if it turns out not to fit.
Ask about your obligations as well. A SOW usually lists what the client must provide: decision-makers available within a set number of days, test users, data extracts, access to third-party systems. Check each one against your team's real capacity during the project months, including any audit or peak season. If your controller can't spend two days a week in design workshops in March, say so now and agree a plan that works.
Ask how each deliverable will be accepted
"UAT sign-off" isn't an acceptance criterion. For each major deliverable, ask what test proves it works and who runs the test. Good criteria are specific: the first month-end close completed in NetSuite with the trial balance agreed to the old system, or 200 sample orders flowing from Shopify with tax and payment matching.
Ask what happens when a test fails, how many cycles are included and how defects are prioritized. If payment milestones are tied to acceptance, make sure the criteria are the ones in the SOW.
Ask who moves and validates the data
Data migration causes more overruns than almost anything else. Ask the partner to define exactly which objects they migrate, how many test loads are included, who cleans the data and who signs off the reconciliation. Ask whether open transactions, history and attachments are in scope.
Most SOWs make the client responsible for data quality. That's fair, as long as you know the format, the deadlines and the rework cost if a load fails.
Ask how change requests are priced
Changes will happen. Ask how a change request is raised, estimated and approved, and how long the partner takes to price one. Ask whether a change that saves effort reduces the fee, or only changes that add effort count.
Look at the rate card attached to the SOW and check that it applies to changes. If the project is fixed-fee, ask what counts as a change and what is the partner's own risk. Our explanation of outcome-based NetSuite pricing shows one way to draw that line.
Ask about hypercare, support and exit
Ask how long hypercare lasts, what response times apply and what happens to defects found after it ends. Ask whether ongoing support is a separate agreement, and get the proposal for it before you sign the implementation, so the costs are visible together.
Then ask about exit. You should own your configuration, scripts and documentation, with the source handed over on request. If you ever need to change providers, the steps in how to switch NetSuite partners in the US are much easier when the SOW already says what is handed back.
A hypothetical SOW review
A hypothetical Colorado medical device distributor receives a US$310,000 fixed-fee SOW. Its controller and IT lead review it against the questions above. All details are illustrative.
| Clause | As drafted | Question raised | Revised |
|---|---|---|---|
| Team | "Experienced consultants" | Who, and how much of their time? | Named architect at 50%, lead consultant at 100% |
| Integrations | "Standard EDI integration" | Which trading partners and documents? | 4 trading partners, 850, 856 and 810 documents |
| Data | "Client to provide clean data" | Format, loads and sign-off? | Templates, 3 test loads, joint reconciliation sign-off |
| Acceptance | "UAT sign-off" | What test proves it? | First close reconciled; 300 EDI orders processed end to end |
| Changes | Rate card attached | Do savings reduce fees? | Change log with both additions and reductions |
| Exit | Not mentioned | What is handed back? | Source, documentation and credentials on request |
The revised SOW costs US$318,000 because two trading partners were added. The controller judges that the clearer acceptance criteria are worth more than the difference. Your review will raise different clauses. The questions apply in the same order.
Check the budget behind the SOW
A SOW is one line in a larger budget. Licenses, internal staff, integrations, data work and support all sit around it. Compare the SOW with a full budget before signing. Our guides to NetSuite implementation cost in the US and NetSuite implementation cost and the scope behind your budget set out what belongs in it.
Check the payment schedule against delivery too. Milestones paid on calendar dates, or on the start of a phase, move risk to you. Milestones paid on accepted deliverables keep both sides focused on the same finish line.
Use the NetSuite partner questions checklist
Before signing, confirm the SOW answers each of these in writing:
- Who are the named team members, and what share of time does each give?
- Is subcontracted or offshore work disclosed?
- Are exclusions listed as clearly as inclusions?
- Does each major deliverable have a specific acceptance test?
- Are data objects, test loads and sign-off defined?
- Is the change process written, including reductions?
- Are hypercare terms and the support proposal attached?
- Does the SOW say what is handed back on exit?
Our NetSuite implementation work starts from an agreed result and acceptance criteria, and our page for US companies on NetSuite describes how we scope projects. For selection advice, read How to Choose a NetSuite Implementation Partner.
Related reading: How to Choose a NetSuite Partner Using Delivery Evidence
Frequently asked questions
What should a NetSuite SOW include?
Named team, scope and exclusions, acceptance criteria, data responsibilities, change control, hypercare terms and what is handed back on exit.
Should a NetSuite SOW be fixed-fee or time and materials?
Either can work. Fixed-fee needs a clear change definition. Time and materials needs estimates, caps and regular burn reporting.
Who is responsible for data quality?
Usually the client. The SOW should still define formats, test loads, deadlines and sign-off.
Can we negotiate a partner's standard SOW?
Yes. Most partners expect questions and revisions. Clear terms protect both sides.
What is a reasonable hypercare period?
It depends on complexity and the close cycle. Make sure it covers at least one full month-end close after go-live.
