ERP Requirements Document Template - Structured for US Buyers

An ERP requirements document is the foundation of any structured ERP selection. Done well, it tightens the longlist, sharpens vendor responses and produces a defensible audit trail for the eventual choice. Done badly, it produces hundred-page checklists that vendors answer with optimistic color-coding and no one reads after signature. The difference is not length but discipline: a tight, MoSCoW-prioritized, business-process-anchored document outperforms a sprawling feature checklist by a wide margin.

This template covers a twelve-chapter structure used across US mid-market selections, including the spreadsheet-based requirements catalog that vendors fill in during the RFP phase. It draws on patterns from successful mid-market selections (50–3,000 staff) but the structure generalizes to small-business selections (with section pruning) and enterprise selections (with deeper integration and architecture chapters). The template is editorial and platform-agnostic — vendor preferences should not appear in a requirements document, and a well-written document should be answerable by at least five candidate vendors without favoritism.

The twelve-chapter structure

A well-structured ERP requirements document covers twelve chapters. The chapters are ordered to support a vendor reading them in sequence:

1. Company profile (3–5 pages). Headcount, revenue, locations, ownership, brief history, industry vertical, sub-vertical positioning, growth ambition over the next five years. Frames vendors' understanding of fit.
2. Business processes (10–25 pages). End-to-end business processes by functional area: order-to-cash, procure-to-pay, plan-to-produce, hire-to-retire, record-to-report. Process maps where helpful. Process volumes (transactions per day, peak periods).
3. Functional requirements (spreadsheet catalog, 200–600 line items). The detailed requirements catalog, separated by module, with MoSCoW priority and brief description. A spreadsheet (Excel or Google Sheets) is the standard format; Word and Confluence work but are harder to score.
4. Non-functional requirements (3–6 pages). Performance (response times, batch windows), availability (SLA expectations), scalability (user growth, transaction growth), accessibility, multi-language.
5. Architecture and integration (5–10 pages). Current system landscape, integrations to retain, deployment-model preferences (cloud, hybrid, on-premises), data-residency requirements.
6. Compliance and regulatory (3–5 pages). US compliance specifics: US GAAP and ASC 606 revenue recognition, SOX internal-controls and audit-trail requirements (relevant for public companies and acquisition targets), IRS electronic record-retention rules (Rev. Proc. 98-25; keep records typically 7 years), multi-state sales-tax and economic-nexus handling, 1099 reporting for contractors, and structured e-invoicing readiness (voluntary in the US today, increasingly exchanged over the DBNAlliance / Peppol network). Industry-specific obligations — for example HIPAA in healthcare or FDA 21 CFR Part 11 in life sciences. Data-privacy obligations such as CCPA/CPRA where applicable.
7. Data migration (2–4 pages). Master-data volumes, transactional history retention requirements, legacy systems to migrate from, data-quality known issues.
8. Implementation approach (2–4 pages). Big-bang or phased preference, target go-live timeframe, internal resource availability, training expectations.
9. Support and operations (2–3 pages). Managed-services expectations, response-time SLAs, language coverage for support, named-account-manager preferences.
10. Commercial framework (2–3 pages). Pricing model preferences (subscription vs perpetual), license-model preferences (named user vs concurrent), annual price-escalation caps, exit clauses.
11. Selection process and timeline (1–2 pages). Selection process steps, decision criteria weighting, target decision date, contact information.
12. Evaluation criteria and scoring (1–2 pages). The scoring methodology that will be applied to vendor responses. Transparency here improves vendor response quality materially.

Total document length runs 40 to 80 pages for typical mid-market selections, plus the spreadsheet requirements catalog. Documents above 120 pages usually contain repetition and noise; documents below 30 pages usually lack the specificity needed for honest vendor responses.

MoSCoW prioritization

Every requirement should carry a MoSCoW priority. The four levels:

• Must have. The system cannot be selected without this. Roughly 20 to 30 percent of total requirements. Vendors who cannot meet a Must-have requirement out of the standard or via committed roadmap are eliminated.
• Should have. Important but not selection-killing. Workarounds are acceptable, but Should-have gaps reduce the vendor's score materially. Roughly 30 to 40 percent of total requirements.
• Could have. Nice to have, no impact if missing. Roughly 25 to 35 percent of total requirements.
• Won't have (this time). Explicitly out of scope. Documenting these prevents vendors from padding their response with irrelevant capabilities.

The discipline matters. Selection teams who classify 80 percent of requirements as Must-have produce documents no vendor can fully answer, and end up with arbitrary disqualifications. Selection teams who classify 10 percent as Must-have produce documents that fail to distinguish among candidates. The target distribution — roughly 25 / 35 / 30 / 10 across Must / Should / Could / Won't — is reached only by walking through each requirement and asking “Would I really walk away from an otherwise-perfect vendor that lacks this?”

Sample requirements catalog entries

The spreadsheet requirements catalog holds the bulk of the functional detail. Sample entries from a mid-market machinery-manufacturer requirements document:

Each entry should be specific enough to be answerable yes/no/workaround/no-roadmap. Vague entries (“Good user interface”, “Easy to use”) produce vague answers; specific entries produce useful comparison data. A typical mid-market requirements catalog runs 200 to 600 line items across all modules.

What does not belong in a requirements document

Six categories regularly appear in requirements documents but should not:

Vendor names. A requirements document should be answerable by any candidate vendor. Naming specific vendors in functional requirements (“like SAP's S/4HANA Cloud”) signals bias and produces defensive responses from non-favored vendors.

Implementation methodology preferences. Selecting the software and selecting the methodology are separate decisions. Mixing them constrains vendors' ability to propose what works best for their platform.

Excessive duplication across modules. “The system must have a user interface” appearing in every module section is noise. Cross-cutting requirements belong in the non-functional chapter.

Technical implementation details for the standard cases. “Order entry screen must have a field for customer name” is implicit in “Order entry is supported”. The technical detail belongs in the functional spec, after selection.

Aspirational requirements with no clear business case. AI-powered demand forecasting, blockchain-based supplier verification, voice-controlled warehouse picking — if these are not driven by a current business need, they belong in the Could-have or Won't-have category, or not at all.

Vendor evaluation criteria as requirements. “Vendor must have at least 50 reference customers in the US” is a vendor criterion, not a requirement. It belongs in the selection-criteria chapter, not the requirements catalog.

Distributing the document to vendors

The requirements document is the primary input to the RFP phase. Distribution typically follows this rhythm:

1. Pre-RFI screening (week 0). A brief one-page summary of the selection (company, segment, headcount, target go-live) is shared with the longlist of 8 to 15 vendors. Vendors confirm interest and basic fit within one week.
2. RFI distribution (week 1–3). A condensed version of the requirements document (15–25 pages) plus the spreadsheet requirements catalog. Vendors respond in writing within two to three weeks.
3. Shortlist selection (week 4). Based on RFI responses, 3 to 5 vendors are shortlisted for the full RFP.
4. Full RFP distribution (week 5–9). Full requirements document plus catalog plus commercial framework. Vendors respond within four to six weeks, with a Q&A window of two weeks.
5. Demo and POC phase (week 10–16). The requirements document anchors the demo agenda — vendors demonstrate against the buyer's own scenarios drawn from the document.

Treating the requirements document as a living artifact — updated as the selection process refines the buyer's understanding — produces better outcomes than treating it as a one-shot document fixed at the start. The final version of the document, after demos and POC, becomes the basis for the implementation contract's statement-of-work appendix.

Related Topics

• The ERP Requirements Document
• ERP Requirements Document
• Artificial Intelligence in ERP
• Business Intelligence in the ERP Stack
• What is an ERP System?