Ask three ERP developers for a quote with a two-line brief and you will get three numbers that cannot be compared. One has assumed a basic inventory system, another a full manufacturing suite, and the third has left out GST e-invoicing. The fix is not more meetings. It is a requirements document that describes your business in your own words, module by module.
This guide shows how to write that document: who should write it, what goes in each section, which questions every module must answer, how to plan data migration, and the mistakes that cause scope disputes later. If you are still deciding whether to build or buy, read our comparison of custom versus off-the-shelf software first.
Quick answer: An ERP requirements document describes your business, not the software. It lists your entities, branches and godowns, maps current processes, then for each module records the masters, transactions, approvals, reports, statutory needs and integrations you require, marked must-have or later. Add data migration, users and roles, hosting and acceptance criteria, and attach real sample documents.
Who should write it
One person on your side should own the document, usually an operations head or the owner, but each section must be written by the people who do the work. The stores in-charge knows how material is actually issued. The accountant knows which reports the auditor asks for. A consultant or developer can structure the document and ask questions; they should not invent your processes.
- Owner: one decision-maker who resolves conflicts between departments and signs off priorities.
- Process owners: one person per department, such as purchase, stores, production, sales, dispatch, accounts and HR.
- Reviewer: someone who reads the whole document for gaps between departments, because that is where most problems hide.
The sections of a good ERP requirements document
- Business overview: legal entities, GSTINs, branches, plants, godowns, product lines and rough volumes such as invoices per month, item count and users.
- Current process maps: how an order moves from enquiry to cash today, including the Excel sheets and WhatsApp groups that fill the gaps.
- Module list with priority: each module marked must-have for phase one, needed later, or nice to have.
- Module detail: masters, transactions, approvals, reports and exceptions for each module, as in the table below.
- Statutory requirements: GST invoicing, e-invoicing if it applies to your turnover, e-way bills, TDS, and batch or expiry rules for your industry.
- Integrations: Tally, banks, biometric devices, e-commerce stores, weighbridges, barcode printers or an existing CRM.
- Users, roles and approvals: who can see costs, who can edit rates, who approves a purchase order above a limit.
- Data migration: what moves from the old system, and as of which date.
- Non-functional needs: number of users and locations, internet reliability at the plant, cloud or on-premise hosting, backups and mobile use.
- Acceptance criteria and phasing: how you will decide each module is ready, and what goes live first.
Module-by-module questions to answer
For each module, answer the same five questions: which masters it needs, which transactions it records, who approves what, which reports come out of it, and what the exceptions are. The exceptions are where most of the cost and delay sit.
| Module | Questions to answer | Usually written by |
|---|---|---|
| Inventory | How many godowns? Batch, serial or expiry tracking? Which valuation method? How are transfers and stock adjustments approved? | Stores in-charge |
| Purchase | Indent to PO to GRN flow, rate approvals, partial receipts, rejections and debit notes | Purchase head |
| Production | Single or multi-level BOM, job work out and in, scrap and by-products, how work in progress is counted | Production manager |
| Sales and dispatch | Price lists and schemes, credit limits, partial dispatch, sales returns and e-way bills | Sales and dispatch heads |
| Accounts | Which ledgers live in the ERP and which stay in Tally, bank reconciliation, ageing, cost centres | Accountant |
| HR and payroll | Attendance source, shifts, overtime rules and statutory deductions | HR or admin |
Write each answer as it happens today and as you want it to happen. A line such as "we issue material against a verbal request" is useful. It tells the developer that an issue slip and an approval step belong in the scope.
Data migration: decide early what moves and what stays
Migration is often treated as a last-week task, and it is a common reason go-live dates slip. In the requirements document, state clearly:
- Masters: items, customers, vendors, BOMs and the chart of accounts, and who will clean them before import.
- Opening balances: stock by godown and batch, debtors and creditors, as of a fixed cut-over date.
- Open transactions: pending purchase orders, sales orders and job work challans that must continue in the new system.
- History: whether past years' transactions are imported, or kept read-only in the old system for reference.
Cleaning the item master is usually the slowest job, because the same item often exists under several names. Start it while development is going on, not after.
Mistakes that cause scope disputes later
- Copying a brochure feature list: a line like "MRP, CRM, HRMS, BI" tells a developer nothing about your process. Describe what happens, not product names.
- Writing solutions instead of problems: "we need a dashboard" is less useful than "the owner cannot see yesterday's dispatches by 10 am".
- Ignoring exceptions: returns, rejections, rate differences, partial dispatches and job work are where scope grows.
- No samples: attach real invoices, challans, job cards and the reports you print every week. They answer dozens of questions at once.
- Everything in phase one: mark priorities honestly. Our ERP software development projects usually start with the module that hurts most, often inventory and billing, and add the rest in phases.
What to do with the finished document
Share the same document with every vendor you are considering, and ask each one to respond module by module: what is included, what is excluded and what they have assumed. That turns quotes into something you can compare line by line. Our guide on how to choose an ERP software development company covers the vendor evaluation itself, and our enterprise ERP cost and implementation guide explains how scope drives budget.
Keep the document alive after signing. When a requirement changes, update it, so that the version the developer builds against and the version your team tests against are always the same.
How EthicsComputer can help
If you have a rough list but not a full document, EthicsComputer can run an operational walkthrough of your departments and turn it into a written scope with modules, phases and a fixed quote. Our ERP software development service builds the system around that scope, and the source code is handed over to you. For plant-specific needs, see manufacturing ERP software, and for rollout and training support, see ERP implementation.
Which module is hurting your business most right now?
Send us your process notes or a few sample documents, and we will help you turn them into a requirements document a developer can quote against.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
