ERP BRD Consulting

What an ERP business requirement document contains

The exact structure depends on the size of the project, but a solid ERP BRD usually contains the following sections, in roughly this order:

1. Document control: version, authors, reviewers and change history.
2. Executive summary: why the business is investing and what success looks like.
3. Business objectives: the outcomes the ERP must support, stated in business terms.
4. Scope: entities, locations, departments and processes in and out of scope, and the phasing.
5. Stakeholders and roles: sponsor, process owners and key users.
6. Current state: a summary of today's processes, systems and known pain points.
7. Future-state processes: how core flows should work, with references to process maps.
8. Functional requirements: grouped by process, each prioritized and owned.
9. Non-functional requirements: security, roles, audit, hosting, performance, languages and currencies.
10. Data requirements: master data, ownership and what history must be migrated.
11. Integration requirements: systems to connect, direction of data and frequency.
12. Reporting requirements: operational, financial and management reports.
13. Assumptions, constraints and risks.
14. Acceptance criteria and sign-off.

My article on how to create an ERP BRD walks through these sections in more depth if you want to try drafting one yourself.

Writing requirements that vendors cannot misread

The requirements chapters are the heart of the BRD, and the place where weak documents fall apart. A requirement such as "the system should support inventory" will be answered with a confident yes by every vendor. It tells you nothing.

I write each requirement with a standard set of fields:

• a unique ID and the process step it belongs to;
• a plain statement of the need, written from the business point of view;
• the reason it matters, or the problem it solves;
• a MoSCoW priority agreed with the owner;
• an acceptance criterion describing how it will be confirmed.

For example, rather than "multi-currency support", the BRD says that the business invoices customers in several currencies, needs exchange differences posted automatically at payment, and needs management reports in a single reporting currency. That level of detail lets vendors give honest answers and lets you compare them.

The requirement content itself comes from proper elicitation, which is covered by my ERP requirements gathering service. The BRD packages that material with the context, scope and controls needed to make it a decision document.

Who reviews and signs off the BRD

A BRD without proper sign-off is just a draft that everyone remembers differently. I treat the review as a structured part of the work, not a formality at the end.

Typical roles in sign-off are:

• Process owners: each head of finance, sales, operations, procurement or HR confirms that the sections for their area are accurate and complete.
• IT or systems lead: confirms non-functional, integration and data requirements are realistic.
• Finance controller: confirms accounting, tax and reporting requirements, and any audit obligations.
• Executive sponsor: approves scope, priorities and the overall document as the project baseline.

I run short review sessions per section, keep a comment log, and record how each comment was resolved. Disagreements between departments are surfaced and settled during review rather than discovered during implementation. Once signed, the BRD becomes a baseline under change control: later changes are allowed, but they are logged, assessed and approved, not slipped in quietly.

This discipline is what turns the BRD into a reliable reference for gap analysis, design and UAT.

How vendors and implementers use your BRD

A good BRD does different jobs at different stages of the project.

During selection, vendors use it to decide whether to bid, which product and edition to propose, and how to estimate effort. A clear BRD reduces the guesswork in their proposals, so the numbers you receive are more comparable. It also lets you invite scripted demos that follow your processes rather than the vendor's favorite screens. If you are running a formal tender, the BRD becomes the core of the ERP RFP.

During design, the implementer uses it to run fit-gap analysis and produce a solution design document. Every design decision should trace back to a BRD requirement.

During testing, the acceptance criteria in the BRD become the basis for UAT scripts. The business tests against what it signed, not against what the implementer chose to build.

During disputes, which do happen, the signed BRD is the reference point for what was agreed. That alone often prevents a disagreement about scope from becoming a commercial conflict.

Why use an independent ERP BRD consultant

Many vendors offer to write the BRD for free as part of their sales process. It is a tempting offer, but it carries an obvious risk: a BRD written by a vendor tends to describe what its product does well and quietly leave out what it does not. Once that document becomes your baseline, other vendors are compared on the first vendor's terms.

As an independent consultant, I write the BRD from your business outward. I have no product to fit it to, so the requirements describe your processes, your controls and your growth plans. You can share the document with any vendor, and each one is measured against the same neutral standard.

I also stay with the document after it is signed. I can use it to evaluate proposals, review the implementer's solution design, and check that UAT covers what the business agreed. If you need help before the BRD, my ERP business analysis service covers the discovery work, and you can contact me to scope a BRD for your project.