ERP requirements document: the short template that works

Many ERP requirements documents are lists of features copied from vendor brochures: “multi-warehouse stock management”, “customisable dashboards”. Every ERP ticks those boxes. The document says nothing about what makes your company specific, and that is exactly where projects are won or lost.

The outline in seven sections

1. 01Context

   Business, headcount, companies, sites, tools in place.

2. 02Flows

   From first contact to payment, and from purchase order to receipt.

3. 03Business rules

   What is not negotiable.

4. 04Data

   What is migrated, from where, and in what state.

5. 05Integrations

   The tools that stay and what they exchange.

6. 06Volumes

   Users, documents per month, items, warehouses.

7. 07Acceptance

   The scenarios that prove it is finished.

1. Context

One page is enough. Who are you, how many people will log in, in how many companies and countries, with which tools today? Add the reason for the project, in one measurable sentence: “cut the month-end close from five days to two”, “stop re-keying between the CRM and invoicing”. The measurements from When to move to an ERP are used here.

2. Flows

This is the section that matters most. For each flow, write the steps, who does them and which document comes out. For example: the sales rep makes the quote, sales administration turns it into an order after the deposit, the warehouse picks, delivery triggers the invoice. A simple diagram beats a long text.

Describe the flow as it should be, not as it is with its workarounds. The ERP project is the right moment to remove a useless step.

3. Business rules

Discounts allowed by level, payment terms by customer type, lot or serial number tracking, mandatory approvals above an amount. These rules are what separate configuration from development. Note for each whether it is legal, contractual or simply a habit: only the first two are truly non-negotiable.

4. Data

List the data to migrate (customers, suppliers, items, price lists, stock, open invoices, history) and its source. Be honest about its state: duplicates, empty fields, inconsistent codes. Data migration is often the most underestimated item.

5. Integrations

Which tools stay? The accountant’s software, the online shop, payroll, the bank. For each, say what must flow, in which direction and how often. See Connecting your business tools.

6. Volumes

Number of users per role, of quotes, orders and invoices per month, of item references, of warehouses. These figures size the hosting and the licence cost. They also avoid bad surprises: an import of 50,000 references is not handled like an import of 500.

7. Acceptance

Write five to ten end-to-end scenarios: “a key account orders 200 units, 50 of which are out of stock; the order is partly delivered; the invoice covers only what was delivered”. The project is finished when these scenarios pass. It is the best protection against a project that never ends.

What to add: the out of scope

An explicit list of what the project does not do: payroll, manufacturing, the online shop, a second company. It protects the budget and the date. A scope that grows along the way is the first cause of failure, detailed in Why ERP projects fail.

For inspiration on an ERP’s standard processes, Odoo’s documentation describes, flow by flow, what the apps do.

Getting it validated

A requirements document is only worth something if it is validated by those who live the flows. Have each section reviewed by the head of the department concerned, then the whole by leadership, and note disagreements rather than smoothing them over: those are what scoping must settle. The complete ERP guide places this document within the whole project. The scoping of our CRM and ERP offer produces it with you, in a few workshops, before proposing a tool and a fixed price.

Frequently asked questions

Sources

1. Odoo applications documentation (new tab)odoo.com