# ERP Implementation Statement of Work Template

> Source: https://netray.co/tools/erp-implementation-statement-of-work-template-africa
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A fill-in statement of work for an ERP implementation or migration, covering scope, deliverables, responsibilities, milestones and acceptance.

## Category

erp-migration

## Region

Africa

## Audience

- ERP project manager
- Operations director
- Procurement

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Customer name

**Key:** customer

**Type:** text

**Default:** Karoo Precision Engineering (Pty) Ltd

#### Implementation partner

**Key:** partner

**Type:** text

**Default:** Example ERP Consulting

#### ERP product and version

**Key:** system

**Type:** text

**Default:** SYSPRO 8 on premise

#### Modules in scope

**Key:** modules

**Type:** textarea

**Default:** Inventory, Purchasing, Sales Orders, Work in Progress, Bill of Materials, General Ledger, Accounts Receivable, Accounts Payable

#### Sites and legal entities

**Key:** sites

**Type:** text

**Default:** One factory in Gauteng, one legal entity

#### Planned start date

**Key:** start

**Type:** date

**Default:** 2026-11-02

#### Planned go live date

**Key:** golive

**Type:** date

**Default:** 2027-04-01

#### Fee basis

**Key:** fee

**Type:** select

**Options:**

- Fixed fee per phase
- Time and materials with cap
- Time and materials

**Default:** Fixed fee per phase

#### Currency

**Key:** currency

**Type:** text

**Default:** ZAR

**Blocks:**

#### 1. Parties and purpose

**Body:** This Statement of Work is between {{customer}} (the Customer) and {{partner}} (the Partner) for implementation of {{system}} at {{sites}}.

It describes the work, the deliverables, who does what, the timeline and how the Customer accepts the result.

#### 2. Scope of work

**Body:** Modules in scope: {{modules}}.

Included: business process workshops, system configuration, data migration of agreed objects, report and document set up, integration as listed in section 4, user training, cutover support and a post go live support period.

Excluded unless added by change control: custom programming not listed here, hardware, third party licences, historic transaction migration beyond the agreed cutoff.

#### 3. Phases and milestones

**Table:**

**Columns:**

- Phase
- Key deliverable
- Target date

**Rows:**

**0:** Discovery and design

**1:** Signed process design and gap list

**2:** Month 1

**0:** Build and configure

**1:** Configured test company

**2:** Months 2 to 3

**0:** Data migration and testing

**1:** Reconciled test loads and signed test scripts

**2:** Months 3 to 4

**0:** Training and cutover

**1:** Trained users and cutover plan

**2:** Month 5

**0:** Go live and support

**1:** Go live on {{golive}} and stabilisation

**2:** Weeks 1 to 6 after go live

#### 4. Integrations and reports

**Table:**

**Columns:**

- Item
- Description
- Owner

**Rows:**

**0:** Integration 1

**0:** Integration 2

**0:** Custom report 1

**0:** Custom document 1

#### 5. Responsibilities

**Body:** The Partner provides project management, consultants, configuration, migration tooling, test support and training material.

The Customer provides a project sponsor, a business owner for each process area, timely decisions, clean source data, test participation and user attendance at training.

Project start is planned for {{start}} and depends on the Customer meeting its responsibilities.

#### 6. Fees and payment

**Body:** Fee basis: {{fee}}. Currency: {{currency}}. Travel and expenses are charged as agreed in writing. Invoices are issued on completion of milestones or monthly, as set out in the commercial schedule. Amounts exclude VAT unless stated.

#### 7. Acceptance and change control

**Body:** Each deliverable is accepted when it meets the acceptance criteria agreed in writing, or after the review period if the Customer raises no documented defect. Changes to scope, schedule or fees require a written change request approved by both parties before work starts.

#### 8. Risks and assumptions

**Body:** Assumptions: data is available in agreed formats, key users have time allocated, and the infrastructure is ready by the date agreed.

Risks to be managed: data quality, user availability, scope growth and late decisions.

#### Approval

**Signatures:**

- Customer sponsor
- Partner engagement lead
- Customer project manager

**Notes:** This template is a starting point, not legal advice. Have your attorney review the final contract terms, liability, intellectual property, data protection and termination clauses before signing.

## Content

**Intro:** An ERP project without a clear statement of work becomes a series of arguments about what was included. This template gives you the sections a good SOW needs, filled with your names, modules and dates, ready to export to Word or PDF.

**Sections:**

#### How to use it

**Body:** Fill in the customer, partner, product, modules and dates in the form. The document builds itself with the standard sections: scope, phases, integrations, responsibilities, fees, acceptance and risks. Then edit the exported file to add detail specific to your project. Use the integrations table to list every interface and custom report by name, because these are where scope usually grows.

#### What a strong SOW contains

**Body:** It states what is included and, just as important, what is excluded. It names who owns each deliverable and what the customer must provide. It ties payments to milestones that can be verified, and it defines acceptance in writing. It describes a change process so that new requests are priced and agreed before work begins instead of discovered at the invoice.

**Bullets:**

- Explicit in scope and out of scope lists
- Named customer owners per process area
- Acceptance criteria written before build
- A change request form and approval path

#### Common mistakes

**Body:** Vague scope such as 'standard reporting' leads to disputes, so list reports by name. Another mistake is ignoring customer effort: most delays come from late data and unavailable users, so write those duties down. Finally, many projects skip the post go live period, then argue about who fixes early defects. State the support window and what it covers.

**Cta:** If you want an independent review of a vendor SOW before you sign, we can read it against your requirements and mark gaps.

**Faq:**

#### Is this suitable for Odoo or Sage projects?

**Answer:** Yes. Change the product field and the modules list. The structure of scope, phases, responsibilities, fees and acceptance applies to any ERP implementation, whether on premise, cloud or open source.

#### Should I use fixed fee or time and materials?

**Answer:** Fixed fee suits a well defined scope, and puts delivery risk on the partner. Time and materials with a cap suits uncertain scope. Whatever you choose, tie payments to deliverables and keep change control strict.

#### Does this replace a master services agreement?

**Answer:** No. The SOW sits under a master agreement that covers liability, confidentiality, intellectual property and data protection. Have an attorney review those terms separately.

#### How detailed should the milestones be?

**Answer:** Detailed enough that both sides can say yes or no to whether a milestone was met. A signed design document and a reconciled test load are verifiable, while 'configuration complete' is not.

## Search terms

erp implementation statement of work template, erp sow template, erp project scope document, syspro implementation sow, odoo implementation scope template, erp consulting contract outline, erp acceptance criteria template

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json