A NetSuite Statement of Work with Usable Acceptance Criteria
A NetSuite implementation statement of work should let the buyer and delivery team answer the same question: what evidence will show that the agreed work is complete? Broad labels such as finance setup, migration and training are insufficient unless the document explains their boundaries, required inputs and acceptance method.
Use the statement of work as an operating agreement for the project. Commercial and legal advisers should review the final contract, including liability, intellectual property and termination terms. The guidance below concerns practical delivery scope and evidence; it is not a substitute for that review.
Describe outcomes at a testable level
Begin with the entities, locations, processes and systems in scope. State which business activities must work at launch and which are deferred. Then connect each deliverable to an outcome the business can demonstrate.
For example, “accounts payable configured” could require approved supplier records, the agreed bill and credit process, role-based approval behavior and accepted reconciliation reports. The precise contents depend on the design. The point is to prevent one side treating a configured screen as completion while the other expects an entire operating process.
For multi-entity work, specify which parts of the common design apply to every entity and which need local adaptation. Oracle's OneWorld setup guidance identifies hierarchy and related setup dependencies. The statement of work should allocate who supplies and approves those inputs rather than leave them implicit.
Define scope units that reflect effort
Count meaningful units. An integration should list data flows, directions, event timing, supported exceptions and ownership at both ends. “One connector” could cover several materially different processes. A report should identify its purpose, population, filters, output and reviewer, not only a name.
For migration, state record categories, history periods, source systems, cleansing responsibilities and rehearsal cycles. Specify whether attachments and legacy audit retrieval are included. Record assumptions about source identifiers and relationships because missing keys can change the work required.
Training scope should name audiences, tasks, delivery format, practice environment and materials. State whether administrator knowledge transfer and new-starter procedures are included. A fixed number of classroom hours is a quantity measure; it does not describe what users should be able to do afterward.
Pair supplier obligations with client inputs
Create one responsibility row for each deliverable: supplier activity, client input, input due date, reviewer and escalation owner. This makes delay consequences discussable before they occur.
Data cleansing is a useful example. The provider may supply rules and import templates while the client decides which customer is authoritative and approves accounting mappings. If both sides assume the other owns those decisions, the migration can stall even while each believes it has completed its contracted work.
Set realistic review windows that account for business calendars. Include a method for identifying a missing input and agreeing its effect on the schedule. Avoid wording that conceals unresolved scope by treating every unanswered question as automatic client acceptance.
Write acceptance criteria before delivery
An acceptance criterion should contain a scenario, expected result, evidence and authorized reviewer. Keep it specific enough to test while allowing the implementation team appropriate flexibility in the solution.
A useful criterion might require a controller to reconcile the agreed migrated open-payables population to the approved source cutoff and accept documented differences. It should specify the report basis and relevant currency or entity detail. “Data migrated accurately” provides much less guidance when a disagreement appears.
Use a traceability register connecting requirements, design decisions, delivered configuration and acceptance tests. Where a design change occurs, update the linked criterion before testing. Keep the earlier version so the project can explain how scope evolved.
Agree defect and change treatment
Define a defect as a departure from an agreed requirement or approved design, subject to the contract's precise terms. Define a change request as a proposed alteration to that baseline. Real cases can be ambiguous, so provide an escalation process rather than assume the label is always obvious.
State how defects are prioritized, corrected and retested. For issues accepted temporarily, require a business owner, workable control and follow-up treatment. A final signoff should not make unresolved operational consequences disappear from the project record.
Change proposals should show options, cost, timing and dependencies before approval. Clarify whether assessment itself is chargeable and who may authorize it. This avoids surprise invoices for investigating an idea that the sponsor ultimately rejects.
Specify environments and handover
Identify the environments needed for build, migration rehearsal and business testing, with responsibility for access and refresh coordination. Oracle distinguishes development and sandbox account purposes; the contract should reflect the account types actually available to the project.
Define the handover package: approved design, configuration inventory, custom code and ownership where applicable, interface documentation, mappings, test evidence, operating procedures and unresolved issues. Confirm where it will be stored and which rights the customer receives under the agreement.
Separate launch support from ongoing support. Specify coverage hours, duration, incident route and exclusions. Make clear whether a response commitment means acknowledgement, diagnosis or resolution. These are different service expectations.
Hypothetical acceptance wording
A buyer requests migration of open customer invoices. A practical deliverable description identifies the approved source cutoff, included invoice and credit categories, mapping owner and agreed rehearsal cycles.
Its acceptance record requires matching document references and open amounts, reconciliation by customer and relevant currency, a tie to the receivables control account and controller approval of exceptions. The description also explains how balances created by those transactions interact with the wider opening-ledger load.
This gives both parties a shared test without pretending a universal import recipe applies to every account. The actual wording should be adapted and reviewed before it becomes contractual.
Before signing
Read the statement of work alongside the proposal, design assumptions and commercial schedule. Confirm that quantities and exclusions agree across documents. Resolve conflicts in writing and identify the controlling version.
A usable statement of work reduces uncertainty by defining work, inputs and evidence. Bring your highest-risk scenarios into the scope discussion early, then make sure the final agreement describes how they will be accepted.