ERP Requirements Template: How to Write Your Specification

A good ERP requirements template is the cheapest insurance you can buy on an ERP project. It forces your team to agree what the business actually needs, it gives every supplier the same brief, and it becomes the reference point when scope, price or delivery are later questioned. This guide explains what the document is for, gives a section-by-section plan, and finishes with a complete model you can copy into your own file.

If you are still at the earlier stage of deciding what an ERP is or whether you need one, start with what an ERP is and how to choose an ERP. Once you know you are going ahead, the specification below is your next step.

What an ERP requirements document is for

An ERP requirements document, sometimes called an expression of needs, a user requirements specification or a statement of requirements, describes your business from the point of view of the system that will run it. It does not choose the software. It tells suppliers what the software must do, in what conditions, and how you will judge the answer.

It serves four purposes:

• Alignment inside your company. Finance, sales, purchasing, warehouse and production rarely describe the same process in the same words. Writing the document forces the conversation.
• Comparable proposals. Without a common brief, one integrator quotes for a narrow scope and another for a broad one, and the cheaper offer is simply the less complete one.
• A basis for the contract. The statement of work that follows should refer back to your requirements. Anything that was written down and prioritised is easier to hold the supplier to.
• Control of scope. When someone asks for an extra feature mid-project, you can check whether it was in the original scope, and decide consciously rather than drift.

The most common failure is not a document that is too short. It is a document that lists features but says nothing about processes, volumes, exceptions and data. Our guide on ERP project mistakes shows how often a weak specification sits behind a project that overruns.

Requirements document, RFP and statement of work: the differences

These terms are used loosely in the UK, and the confusion can cost you time. Here is how they relate.

If you are a public body or work with public money, formal procurement rules may shape how the RFP is issued and scored. Take advice from your procurement team before you issue anything. Private companies have more freedom, but a structured process is still worth following.

Before you write: the preparation that saves weeks

Do not open a blank document first. Three preparatory steps make the writing far easier.

Form a small project team

Name a business owner who will make decisions, and a representative from each department that will use the system. Add someone from IT, and, if you handle personal data in volume, someone who understands your data protection obligations under UK GDPR. A team that is too large stalls; a team that is too small misses processes. Keep it small enough to meet regularly.

Map your current processes

Describe how work flows today, from quotation to cash collection, from purchase requisition to supplier payment, from production order to delivery. You do not need elaborate diagrams. A page per process with the steps, the people involved, the tools used and the pain points is enough.

Separate the problems from the solutions

Teams often write requirements as solutions: "we need a screen showing stock by bin". The underlying need may be "pickers must find stock quickly without errors". Writing the need rather than the screen lets the integrator propose a better answer than the one you imagined.

The standard plan of an ERP requirements document

The plan below works for almost any small or mid-sized business. Each section is detailed in the model further down.

1. Presentation of the company and the project: who you are, why you are changing, what success looks like.
2. Scope: entities, sites, departments, processes, and what is explicitly out of scope.
3. Process description: how the business works today and how it should work.
4. Functional requirements by module: finance, sales, purchasing, inventory, production and so on.
5. Technical requirements: hosting, integration, security, performance, reporting.
6. Data migration: what comes across, from where, and in what condition.
7. Timetable: milestones, constraints and dependencies.
8. Budget: the envelope, the cost items to be priced and the format of pricing.
9. Selection criteria and response rules: how proposals will be scored and what you want in the reply.

Section one: presentation of the company and the project

Keep it short but concrete. Describe your activity, your organisation, the number of legal entities, the sites and countries involved, and the broad profile of users by department. State the reasons for the project: an outgrown accounting package, spreadsheets that no longer scale, a need to trade online, an acquisition, or a requirement to comply with new reporting rules. State what you want to be true afterwards, in business terms.

Avoid pages of corporate history. A supplier needs to understand your business model and your complexity, not your brand story.

Section two: scope

Define the perimeter precisely. List the entities, the sites, the departments and the processes in scope, and, just as important, those that are out of scope for the first phase. Many projects run into trouble because "phase two" was assumed by one side and not the other. If you expect to add subsidiaries, a warehouse or an online channel later, say so, so that the supplier designs for it.

Section three: processes

This is the most valuable part of the document. For each core process, describe the steps, the roles, the documents produced, the exceptions and the volumes in qualitative terms (for example "a few large orders" versus "many small web orders"). Your suppliers will use this to judge fit and effort.

Typical end-to-end processes include order to cash, procure to pay, plan to produce, record to report, and hire to pay where payroll is in scope. Our industry guides describe the specific flows of manufacturers, distributors, contractors and other sectors, and are a useful source of vocabulary.

Section four: functional requirements by module

For each module, list what the system must do. Give every requirement a reference, a short description, a priority and a column for the supplier's answer. A common priority scale is "must have", "should have", "nice to have". Be disciplined: if everything is a must, nothing is.

The modules usually covered are:

• Finance: general ledger, accounts payable and receivable, bank reconciliation, fixed assets, budgeting, multi-currency, and reporting.
• Sales and customer management: quotations, orders, pricing rules, credit control, returns, and subscriptions if relevant.
• Purchasing: requisitions, approvals, orders, receipts and three-way matching.
• Inventory and warehouse: locations, lots and serial numbers, stock valuation, transfers and barcode scanning.
• Production: bills of materials, routings, work orders, planning, subcontracting and quality control.
• Projects and services: time and expense capture, billing models, resource planning and project profitability.
• Reporting and analytics: operational dashboards, management accounts and regulatory reporting.

You do not need all of them. Include only the modules that are in scope.

Section five: technical requirements

Cover the deployment model (cloud, hosted or on-premise), the integrations with your other systems, the security requirements, the user access model, performance expectations, backup and recovery, and support. If you have not yet settled the hosting question, read cloud versus on-premise ERP first, because it shapes almost every technical answer.

UK-specific points to consider include VAT handling, the digital record keeping and submission obligations that apply to your business, support for BACS and faster payment file formats, Open Banking feeds, and the rules that govern invoicing. The direction of travel on structured invoices is covered in our guide to ERP and e-invoicing.

Section six: data migration

Say which data must be brought across (customers, suppliers, products, open orders, opening balances, history), where it lives today, who owns it and how clean it is. Be honest about quality: duplicates, missing fields and inconsistent codes are the norm, and suppliers price differently if they know in advance. The wider topic is covered in ERP migration.

Section seven: timetable

Give the target go-live window in business terms, such as "before the financial year end" or "outside the peak trading season", and list known constraints: audit dates, stocktakes, seasonal peaks, holidays and key people's availability. Do not invent a precise duration of your own. Ask the supplier to propose a plan and justify it. For the general shape of a project, see ERP implementation.

Section eight: budget

Whether to disclose a budget is a judgement call. If you do, suppliers can scope realistically. If you do not, ask for pricing in a standard format so you can compare: licences or subscriptions, implementation services, data migration, training, support, and optional extras. Our ERP cost guide explains the cost items to ask for and the hidden ones to watch.

Section nine: selection criteria and response rules

Tell suppliers how you will decide. Publish the criteria and their weighting, even if only in broad terms. Typical criteria are functional fit, sector experience, quality of the proposed approach, the team, technology, total cost and references. Specify the response format, the deadline, the contact for questions and the date of demonstrations. A clear scoring grid makes the final decision defensible.

Writing requirements that suppliers can actually answer

The wording of each requirement matters as much as the structure. Follow these rules.

• One requirement per line. "The system must manage lots and expiry dates and generate labels" is three requirements, and a supplier can answer "yes" to one and be silent on the others.
• Use testable language. "Easy to use" cannot be verified. "A warehouse operator can confirm a receipt from a handheld device" can.
• State the volume and the exception. A process that works for a handful of orders may not for a very large number. A rule that has an exception must say so.
• Prioritise honestly. Reserve "must have" for things the business cannot operate without.
• Ask for a structured answer. Use a response scale such as "standard", "configuration", "custom development", "third-party", "not available", so you can distinguish between a feature that exists and one that must be built.

Adapting the document to the type of ERP you are considering

The requirements document should be neutral about the product. Even so, it helps to know how different solutions tend to answer, so that you ask the right questions.

Do not name products in the requirements themselves unless you are already shortlisting. If you are, our comparisons can help you frame the questions, for example Odoo versus Business Central.

Model ERP requirements document

Copy the structure below into a document or spreadsheet and replace the guidance text with your own content. Keep the numbering so that supplier answers can be matched to requirements.

Part one. Company and project

1.1 About the company. Legal name, activity, markets, organisation, sites, number of legal entities, countries and currencies.

1.2 Reasons for the project. Current systems and their limits; business drivers (growth, compliance, integration, reporting, acquisition).

1.3 Objectives. The outcomes you expect, in business terms. For example: a single view of stock, faster month-end close, fewer manual re-keying steps, reliable customer pricing.

1.4 Project governance. Business owner, project manager, department leads, decision-making process, steering committee.

1.5 Users. Departments and rough user profiles: full users, occasional users, self-service users, external users.

Part two. Scope

Part three. Process descriptions

For each process, complete the following template.

• Process name: for example order to cash.
• Owner: the person accountable.
• Trigger and end point: what starts it and what completes it.
• Steps today: a numbered list.
• Roles involved: who does what.
• Documents produced: quotations, orders, delivery notes, invoices, credit notes.
• Exceptions: special cases, approvals, returns, disputes.
• Volumes: qualitative description of frequency and peaks.
• Pain points: what currently goes wrong.
• Target situation: how it should work in the new system.

Part four. Functional requirements

Use the same table for every module.

Add rows for each module in scope. Keep the references stable so that the answers can be scored.

Part five. Technical requirements

Part six. Data migration

Ask suppliers to describe their approach to extraction, cleaning, mapping, test loads, reconciliation and the final cut-over, and to state what they expect your team to do.

Part seven. Timetable

• Target go-live window: expressed against your business calendar.
• Constraints: year end, audit, stocktake, trading peaks, planned absences.
• Dependencies: other projects, hardware, contracts ending.
• Supplier to provide: a proposed plan with milestones, the effort expected from your team and the assumptions behind it.

Part eight. Budget and pricing format

• Budget envelope (optional): state it or explain that you prefer open pricing.
• Pricing to request, in pounds sterling excluding VAT: licences or subscriptions, implementation services, data migration, integrations, customisations, training, project management, go-live support, annual support and maintenance, and optional items.
• Commercial terms: payment schedule, price validity, rates for additional work, and conditions for changing scope.

Part nine. Selection criteria and response rules

Response rules. Give the deadline, the contact for questions, the required format, the validity period of the offer, and the date and agenda of the demonstration. Ask each supplier to run a scripted demonstration based on your real processes, not a generic presentation.

Mandatory attachments. Completed requirement tables, proposed plan, team profiles, price schedule, references, and a draft of the terms under which they would work.

How to use the answers

Once the proposals come in, score them against the grid you published, and take the time to check references. A proposal that answers "standard" to every requirement deserves as much scrutiny as one that proposes heavy development. Look for the integrators who challenge your document, point out contradictions and ask about exceptions: they are usually the ones who will manage the project with the same rigour. For guidance on this stage, see choosing an ERP integrator.

If you run a small business and the full document feels heavy, shrink it rather than skipping it. A short version covering the company, the main processes, the must-have requirements, the data and the selection criteria is far better than nothing. The guide to ERP for small businesses explains how to scale the effort to your size.

Get help structuring your requirements

You do not have to write the document alone. Our service is free: you describe your project, and we put you in touch with an independent ERP integrator who fits your sector, size and preferred technology. Many integrators will review a draft, run a discovery workshop or help you rank your requirements before you send a formal request. The way the introduction works is explained on how it works.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.