How to Create an ERP BRD: Structure, Process and Template

An ERP business requirements document (BRD) records what your business needs an ERP to do and why, in language the business can approve and vendors can price. To create one, define objectives and scope, map current and future processes, capture prioritized, testable requirements for each area, add data, integration and reporting needs, and get formal sign-off from process owners. A good BRD is the single most useful document in an ERP project.

I write and review BRDs as part of ERP discovery. This guide explains the structure I use, how to gather the content, and the mistakes that make a BRD useless.

What a BRD is (and is not)

A BRD describes business needs, not technical solutions. It says "approve purchase orders above a department's limit before they are sent to the supplier," not "add a custom approval field to the PO form." The solution comes later, in a design document written after you have chosen a platform.

That distinction matters. A BRD written in business language can be used to compare several ERP platforms fairly. A BRD written around one product's screens quietly locks you into that product.

Why you need a BRD for an ERP project

• Alignment. Finance, operations, sales and leadership agree on what the project must deliver before money is spent.
• Fair vendor comparison. Every vendor responds to the same requirements, which makes scorecards meaningful. See how to choose an ERP.
• Accurate quotes. Partners can estimate effort against defined scope instead of padding for uncertainty. This directly affects ERP implementation cost.
• Scope control. When new requests appear mid-project, the BRD shows whether they were in the original agreement.
• Test basis. User acceptance testing checks the system against the BRD's requirements.

Recommended ERP BRD structure

This is the section outline I use. Adapt the depth to the size of your project; a small business may cover some sections in a paragraph.

How to write the requirements section

Section 8 is the core of the BRD. Each requirement should be one line in a consistent format, so it can be scored by vendors and tested later. I use a simple table with these columns:

• ID: a unique reference, for example FIN-012 or INV-007
• Process / module: where it belongs
• Requirement: one clear, testable statement
• Rationale: why the business needs it
• Priority: must, should or nice to have
• Owner: the process owner who approves it

A good requirement is specific, testable, and free of solution design. Compare:

• Weak: "The system should handle inventory well."
• Strong: "INV-007: Track stock by batch and expiry date in each warehouse, and suggest picking by earliest expiry. Rationale: products are perishable and customers require batch traceability. Priority: Must."

Here is how a few rows look in practice:

For a module-by-module list of what to cover, use my ERP requirements checklist as the input to this section.

How to gather BRD content

1. Start with objectives

Interview the sponsor and senior leaders first. What problems must the ERP solve? What does good look like a year after go-live? These objectives anchor every later decision about priority.

2. Run process workshops

Hold a workshop per end-to-end process: order-to-cash, procure-to-pay, inventory and fulfillment, production or project delivery, record-to-report, and hire-to-pay if HR is in scope. Invite the people who do the work, not only their managers. Walk through real examples, including exceptions such as returns, partial deliveries and credit holds.

3. Map current and future state

Draw simple process maps showing steps, roles, systems and handoffs. Mark pain points. Then sketch the future state and note what changes. Process mapping is the foundation of my business process consulting work, and it is where most useful requirements emerge.

4. Collect documents and data samples

Gather current forms, reports, spreadsheets, price lists, chart of accounts and sample transactions. They reveal requirements people forget to mention, such as a specific invoice layout a key customer insists on.

5. Draft, review and prioritize

Write the draft, then review each section with its process owner. Challenge priorities: if everything is a must-have, ask what the business would actually do without each item.

6. Get sign-off

Formal approval turns the BRD into the project baseline. After sign-off, changes go through a change-request process with impact on scope, time and cost assessed.

How long should an ERP BRD be?

Long enough to be complete, short enough to be read. A single-entity business with a handful of core processes may need a compact document; a multi-country group with manufacturing and projects will need much more. Length is not the goal. Every requirement should be traceable to a business objective, and every core process in scope should be covered. If sections are being skimmed in review, they are probably too long or too vague.

Keep the BRD a living document until sign-off, stored in one shared location with version control, so nobody works from an outdated copy.

Common BRD mistakes

• Copying the old system. Documenting every legacy screen and workaround carries old problems into the new system.
• Writing solutions instead of needs. This limits your options and biases vendor selection.
• No priorities. Unprioritized requirements make scope decisions impossible.
• Too vague to test. If you cannot check it in a demo or UAT, rewrite it.
• Forgetting data and integrations. These are often the hardest parts of the project and belong in the BRD.
• No owner sign-off. Without accountable approval, requirements get reopened throughout the project.

Next steps

If you need a BRD for an upcoming ERP selection or implementation, I can facilitate the workshops, map your processes and write a document your team and vendors can both work from. See my ERP consulting services or get in touch.

Frequently Asked Questions

What is an ERP BRD?

An ERP business requirements document (BRD) describes what the business needs an ERP system to do and why. It covers objectives, scope, current and future processes, prioritized requirements, reporting, data, integrations and non-functional needs, and is formally approved by the business.

Who should write an ERP BRD?

Usually a business analyst or independent consultant, working closely with process owners from each department. The analyst facilitates workshops and keeps the document consistent, but the content and sign-off must come from the people who own the processes.

Should a BRD be written before choosing an ERP?

Ideally, yes. A BRD written in business language lets you compare platforms fairly and get accurate quotes. If you have already chosen a platform, a BRD is still valuable as the baseline for design, scope control and user acceptance testing.

How is a BRD different from a functional specification?

A BRD states business needs independent of any product. A functional specification or solution design explains how a specific platform will meet those needs, including configuration, customization and integration details. The specification is written after the BRD and after platform selection.