How to Write an ERP Requirements Document That Vendors Can Price
By Apex Horizon Digital
An ERP requirements document is useful only if a vendor can understand the work, identify assumptions, and explain what is included in the price. A list of module names cannot do that. "Inventory, purchasing, and reporting" may describe a simple workflow or a highly controlled multi-warehouse operation. A priceable document connects business outcomes to concrete transaction flows, roles, data, reports, integrations, exceptions, and testable results. It gives vendors enough structure to compare the same problem while leaving room for them to propose a better design.
Key takeaways
- Describe complete workflows and exceptions instead of listing feature names.
- Separate mandatory outcomes from preferred design ideas and future scope.
- Use acceptance criteria and declared assumptions to make vendor estimates comparable.
1. Start with context, outcomes, and scope boundaries
Open with a short description of the company, operating model, locations, transaction types, user groups, and current systems. Then state the problem in operational terms. For example, the goal may be to stop re-entering approved purchase data into three files and give finance a traceable handoff. List the workflows included in the engagement and the workflows explicitly excluded. Add expected project constraints such as required hosting, language support, data ownership, or an accounting system that must remain. This section helps vendors understand why a requirement exists and prevents them from pricing different interpretations of the same project.
2. Specify each workflow as a business scenario
For every workflow, document the trigger, actors, steps, decisions, information captured, output, and completion condition. Include the common exceptions because they often create most of the implementation effort. A purchase workflow should say what happens when a request is rejected, a quantity changes after approval, a supplier delivers partially, or an invoice does not match the receipt. Avoid dictating the screen layout unless a specific interaction is essential. A good vendor should be free to recommend a simpler route while still being accountable for the required business result.
3. Make roles, data, reports, and integrations explicit
Create a role table that shows who can create, view, approve, edit, cancel, export, and administer each record. List the master data needed by the workflow, its current source, approximate condition, owner, and migration expectation. Reports should include their audience, purpose, filters, fields, timing, and the decision they support. For every integration, name the source of truth, records exchanged, direction, frequency, authentication owner, error handling, and reconciliation method. These details expose hidden dependencies early and allow vendors to separate configuration, data work, and integration engineering in the estimate.
4. Write acceptance criteria that can be tested
Acceptance criteria translate a requirement into observable behavior. Instead of saying "the system supports approval," specify that a request above a defined threshold is routed to the assigned approver, records the decision and timestamp, prevents fulfillment before approval, and allows an authorized delegate during leave. Include performance or volume expectations only when they are grounded in known operations. Also define the test data, responsible business reviewer, evidence required, and severity rules for defects. Clear criteria reduce debates near go-live because both sides know what proves that a scope item works.
5. Give vendors a redacted pricing pack
A practical pricing pack can use anonymized names and sample values while preserving the structure of the work. Include one workflow map, a role matrix, a sample master-data sheet, one representative report, an integration table, acceptance scenarios, and a list of assumptions requiring confirmation. Ask every vendor to return the same breakdown: discovery, design, build or configuration, migration, integrations, testing, training, deployment, support, exclusions, and change-control method. The goal is not to force identical solutions. It is to make differences in approach, ownership, risk, and total commitment visible.
- Workflow example: request, approval, order, receipt, exception, and close.
- Role example: requester, approver, buyer, receiver, finance reviewer, and administrator.
- Integration example: source, destination, fields, timing, retry, and reconciliation.
- Acceptance example: given condition, user action, expected result, and required evidence.