ERP Requirements Gathering: Template & Fit-Gap Method

Most ERP problems are born in the first month, long before anyone logs in. Someone said "we need inventory and GST", the vendor said "no problem", and six months later the team is arguing over a report nobody wrote down. Missing, vague or unprioritised requirements are the cheapest problem to prevent and the most expensive to fix.

This guide gives you the method we use as business analysts: map the current process, find the pain, write requirements that can be tested, prioritise them, and run a fit-gap analysis against the ERP you intend to use. It includes a template you can copy into a spreadsheet and a short worked example for a distribution company. It applies to any ERP, but the examples use ERPNext, because that is what we implement.

If you have already seen what goes wrong, read common ERPNext implementation mistakes and why customisation without process planning fails. This post is the prevention.

Why requirements fail

• Only the owner was asked. The people who do the work, such as storekeepers, billing staff and accountants, know the exceptions.
• The requirement is a feature name. "GST, inventory, HR" tells you nothing about how your business works.
• Nobody ranks. When everything is "must have", nothing can be phased.
• Tomorrow's process is copied from yesterday's spreadsheet. An ERP rarely fixes a broken process by itself. See implementation psychology.
• Nothing is testable. Without acceptance criteria, user acceptance testing becomes opinion.

Step 1: Set scope boundaries and stakeholders

Before any workshop, write one page that answers: which companies, branches and countries are in scope? Which departments? Which existing systems stay or go? What is explicitly out of scope for phase one? Then list stakeholders by role, such as sponsor, process owners, key users, IT, auditor or CA, and mark who must sign.

A good rule: every process has one process owner who can decide, and one or two key users who know the details. Without a named owner, requirements wander.

Step 2: Map the current process (as-is)

For each major process, such as quote to cash, procure to pay, stock control, payroll, month-end close, capture:

Item	Question to ask
Trigger	What starts the process? A customer call, a stock level, a month end?
Steps	Who does what, in which order, using which tool or document?
Inputs and outputs	What documents, data and approvals go in and come out?
Decisions and exceptions	Where does the process branch? What happens when a customer returns goods, or a supplier invoice does not match the order?
Pain points	Where does it fail, repeat or wait? How often?
Controls	Who approves, checks or audits? What evidence is kept?
Volumes and timing	How many orders, invoices, items and users? Peak seasons?
Reports used	Which reports does management actually use to decide?

Use a simple swim-lane diagram, with one lane per role. It does not need special software. A whiteboard and a phone photo are enough, as long as the owner confirms it. Capture real examples: three actual invoices, one return, one purchase from a new supplier.

Step 3: Design the to-be process

Now ask what the process should look like in the new system. Challenge steps that exist only because of the old tools: double entry, manual copying, approvals by phone. Decide where the ERP will enforce a rule, such as a credit limit or a mandatory field, and where it will only record. Our guide to the ERPNext sales workflow shows a standard quote-to-invoice path you can compare against.

Step 4: Write requirements that can be tested

Use a consistent sentence: "The system shall [do something] for [role], so that [outcome], when [condition]." Then add an acceptance criterion. Copy this structure into a spreadsheet:

ID	Process	Requirement	Priority	Owner	Acceptance test	Fit-gap
SAL-01	Quote to cash	Sales staff create quotations from item price lists, with customer-specific discounts, and convert them to sales orders	Must	Sales head	Create a quotation for customer A at its agreed price, convert it, and the price stays unchanged	Standard / configuration
SAL-07	Quote to cash	Discounts above 10 percent need manager approval before the order can be submitted	Should	Sales head	A 12 percent discount order cannot be submitted until the manager approves	Configuration (workflow)
INV-03	Stock	Expiry batches are issued earliest-expiry first	Must	Store manager	A delivery picks the earliest-expiring batch with stock	Standard (v15 or later)
FIN-05	Month-end	Finance sees branch-wise profit and loss five working days after month end	Must	Finance head	The report matches the manual sheet for the last three months	Configuration (cost centers, report)
PUR-04	Procure to pay	The system flags a supplier invoice when the amount differs from the purchase order by more than 2 percent	Could	Purchase head	An invoice 3 percent above the order shows a warning	Customisation or workaround
REP-09	Reporting	A daily WhatsApp summary of sales to the owner	Could	Owner	Summary arrives by 8 pm with total sales and collections	Integration (later phase)

Good requirements are specific, testable, one idea each, and traceable to a process step. Avoid phrases such as "user-friendly", "fast" and "flexible" unless you define them with numbers. Beware of invented numbers in your own document too. If you do not know the volume, write "to be measured in week 2" instead of guessing.

Step 5: Capture the non-process requirements

Some requirements do not belong to a single process. List them separately:

Category	Examples
Data and masters	Item codes and naming rule, customer and supplier masters, opening balances, historical data to migrate
Compliance	GST, e-invoicing and e-way bill in India. VAT, e-invoicing and WPS in the GCC. Audit trail and retention
Security and roles	Who sees cost prices, who approves, who can edit posted data, branch restrictions
Integrations	Payment gateway, e-commerce, WhatsApp, biometric devices, bank files, Tally or CA exports
Reports and print formats	Invoices, delivery notes, statements, dashboards, regulator reports. List every one
Performance and hosting	Users, locations, internet quality, backup and recovery expectations
Training and support	Who is trained, when, in which language, and who supports after go-live

Reports and print formats are the most underestimated item. Ask for a sample of each and decide whether a standard report can satisfy it. Our guides to print formats and dashboards show what can be built without code.

Step 6: Prioritise with MoSCoW

Class	Meaning	Rule of thumb
Must	Go-live is impossible or illegal without it	Statutory documents, invoicing, stock control, core reports
Should	Important, with a workaround for a short time	Approvals, some integrations, dashboards
Could	Nice to have if time and budget allow	Convenience reports, notifications
Won't (now)	Agreed not in this phase	Advanced analytics, secondary modules

Limit "Must" to what you truly cannot run the business without. If more than half of your requirements are Must, you have not prioritised yet. Phase the rest. A first release that covers the core and goes live on time beats a perfect system that never ends. See our implementation timeline for how phases fit together.

Step 7: Run the fit-gap analysis

Take each requirement and classify how the ERP will meet it:

Class	Meaning	Effect on cost and risk
Standard	Works out of the box	Lowest
Configuration	Met by settings, masters, workflows, custom fields or print formats	Low
Report or print	Needs a new report or print format using standard tools	Low to medium
Integration	Needs an API or third-party connection	Medium
Customisation	Needs code, such as a custom app or script	High, and it adds upgrade risk
Workaround	Process change instead of system change	Needs user buy-in
Not now	Deferred by decision	None now

Count the classes. A healthy ERPNext project usually has most requirements in standard and configuration. If most are customisation, either the product is wrong for you or your process is unusual in ways worth challenging. Our posts on over-customisation risk and ERPNext for startups discuss the trade-offs.

The fit-gap report also feeds your cost estimate. See ERPNext implementation cost in India for the cost drivers, and how to evaluate the demo properly for testing standard fit on your own data.

A worked mini-example: a tile distributor

A distributor with two warehouses and a showroom lists these pain points: stock mismatch between warehouses, discounts promised on the phone, slow month-end, and a reliance on one accountant. The analyst converts them as follows.

Pain point	Requirement	Fit-gap
Stock mismatch between warehouses	Warehouse-wise stock visible to sales at order time, with inter-warehouse transfers recorded	Standard
Phone discounts	Customer-wise price lists, with approval above a limit	Configuration
Slow month-end	Bank reconciliation weekly, accruals checklist, branch P&L report	Configuration plus process change
One accountant knows everything	Documented chart of accounts, roles, and a backup accountant with access	Configuration plus training
Breakage claims on tile boxes	Record breakage against delivery notes and supplier claims	Customisation or workaround, decide in workshop

Notice how the list stays short, and how one item is honestly flagged as undecided. That honesty is a feature.

Step 8: Sign-off and change control

1. Walk through the document with each process owner. Read it aloud. Fix what is wrong.
2. Freeze version 1.0 with the requirement IDs, priorities and fit-gap classes.
3. Sign it by the sponsor and process owners, and by the implementer.
4. Control change: a new request gets an ID, an impact note on cost and timeline, and a decision. Small changes in the same process are normal. A new module is a new phase.
5. Link requirements to tests. The acceptance column becomes the user acceptance test script.

Keep the requirements sheet alive after go-live. It becomes the baseline for upgrades, audits and new staff training.

Checklist: is your requirements document ready?

• Every in-scope process has an as-is map and a named owner.
• Requirements are testable, with IDs, priorities and acceptance tests.
• Reports, print formats, integrations and data migration are all listed.
• Compliance for each country and branch is covered, and a CA or tax adviser has reviewed it.
• Fit-gap classes are assigned and agreed.
• Out-of-scope items are written down.
• Sponsor and owners have signed.

How Nexeves helps

Our business analysts run requirements and fit-gap workshops, produce the documents above, and then build to them. Learn about our ERPNext implementation approach or start a conversation through the contact page.

Frequently asked questions

What is ERP requirements gathering?

It is the process of understanding how your business works today, deciding how it should work in the ERP, and documenting that as prioritised, testable requirements. It covers processes, data, reports, compliance, integrations and security.

What should an ERP requirements document include?

Scope and stakeholders, as-is and to-be process maps, a requirements table with ID, priority, owner and acceptance test, reports and print formats, integrations, data migration needs, compliance, security roles and a fit-gap classification.

What is fit-gap analysis in ERP?

It compares each requirement with what the ERP does today, and classifies it as standard, configuration, report, integration, customisation, workaround or deferred. It shows how much customisation you really need.

How long does requirements gathering take?

It depends on the number of processes, branches and stakeholders. A small business may need a few workshops over one to two weeks, while a multi-branch company needs longer. We set the time from your process list, not from a fixed number.

What is the MoSCoW method?

MoSCoW sorts requirements into Must, Should, Could and Won't have now. It helps you phase the project and protects go-live from low-value requests.

Who should be in the ERP requirements workshops?

The sponsor, one owner for each process, the key users who do the daily work, a finance or CA representative, IT, and your implementation partner. Include people who handle exceptions, not only managers.