ERP Requirements Consultant, India

The chapters of an Indian ERP requirements specification

A specification is not a longer BRD. The BRD explains the business and its goals; the specification is the reference a partner signs up to deliver. For an Indian company, the structure I use looks like this:

• Document control: version, authors, reviewers, approvers and a change log.
• Scope: each legal entity, each GSTIN, plants, godowns, branches and the users who work there.
• Functional chapters by process area: order-to-cash, procure-to-pay, inventory and job work, production, projects or service where relevant, record-to-report and fixed assets.
• Statutory register: tax, invoicing, deduction, reporting and retention needs kept apart from the process chapters so they can be reviewed by your accountant in one sitting.
• Non-functional chapter: hosting, security, audit trail, performance and availability.
• Interfaces and data migration.
• Reports and dashboards, listed with fields and filters rather than names alone.
• Glossary: terms such as voucher type, challan or godown, so a foreign parent or an offshore developer reads them the same way.

Workshops and process mapping, the analysis that feeds these chapters, sit on a separate page: ERP business analyst in India. This page is about the document that results and how it is used. My general approach to ERP requirements gathering describes the method outside the Indian context.

A statutory register your accountant can sign off line by line

Indian statutory needs change more often than most process requirements, so I keep them in a register with its own columns: requirement ID, the statement, the source of the rule as described by your advisor, the person who confirmed it, the evidence that will prove it in testing and a recheck note. The wording is written for acceptance, not as tax advice. Examples of the style:

• When an e-invoice is cancelled, the original document stays visible with a cancelled status, a reason and the user who cancelled it.
• Data your accountant needs for GST return preparation can be exported in a layout that their return software or GST service provider accepts.
• TDS deducted on vendor payments can be reconciled, per vendor and per period, with the deposits and returns your accountant files.
• Where your auditor expects an edit log in the accounting software, it is always on and cannot be disabled by ordinary users.
• Books and supporting documents remain retrievable for the retention period your advisor confirms.
• The base currency is rupees, with foreign currency for imports and exports, and print formats support regional-language text where customers need it.

Each line in this register defaults toward a must priority, but the tax treatment behind it is always confirmed by your chartered accountant. My job is to make sure the system can be tested against that guidance.

Non-functional requirements for plants, branches and auditors

Indian specifications tend to be rich in screens and thin on how the system must behave. That gap matters, because performance, access and hosting problems are expensive to fix after the contract is signed. The non-functional chapter I write covers:

• Hosting and data location: whether the system is vendor cloud, partner-hosted or on your own servers, where data and backups sit, and whether any customer contract or sector rule creates a location expectation. Those questions go to your advisor and to each bidder in writing.
• Access control: roles scoped by entity, GSTIN and branch, maker-checker approval for vendor master and bank detail changes, and segregation between booking and paying.
• Audit trail: who changed what, when and from which value, kept for masters as well as transactions.
• Performance: behavior at month-end and when many e-invoices are generated in one run, with targets agreed by your team rather than invented by the partner.
• Availability for remote sites: what depots or plants on weak connections must still be able to record, and how that data syncs.
• Personal data: handling of employee and customer data in line with India's data protection law as your advisor interprets it.

Each statement is phrased so a partner must answer yes, no or partly, with an explanation.

Priority tags, traceability and the document in RFPs and contracts

Without priorities, every line looks equally important and partners quote for everything. I tag each requirement as must, should, could or later. A must means phase one cannot go live without it; statutory lines usually land here. A should has a workable stopgap. A could is a genuine improvement. Later is recorded so it is not lost. Owners agree the tags in review, and a must needs a reason written next to it.

Each requirement then carries trace links: the demo script step that tests it during selection, the partner's response, the design note that covers it, the test case and the UAT result. When a partner later says a feature was never in scope, the chain shows otherwise, or shows that it really was left out.

In an ERP RFP, bidders answer every line as standard, configuration, customization, third-party add-on or not supported, with effort where relevant. After the choice, the signed version becomes a contract annex and the winning response becomes a commitment. From baseline onward, changes go through a change request with impact noted, and each new version is numbered and approved. My ERP selection consultant page for India explains how these responses feed partner scoring.

Gaps that weaken requirement documents in Indian projects

Certain omissions recur in Indian requirement documents, and each one is a risk to scope, cost or compliance later. When I review an existing document, I check for these first:

• Job work and subcontracting left out, so material sent to processors has no requirement behind it.
• The multi-GSTIN structure assumed rather than stated, leaving the partner to decide how branches and entities are modeled.
• No owner named for producing e-invoices and e-way bills, whether the ERP, a GST service provider or a manual step.
• Migration written as "move all Tally data", with no decision on open items, history or stock valuation.
• Reports listed by name only, such as "GST reports", with no fields or filters.
• No requirement for how statutory updates are delivered under the support agreement.
• Branch users and mobile approvals ignored, so licensing and training are underestimated.

None of these is hard to fix on paper. They are hard to fix once a contract is signed and a configuration is under way. If your project has already started and these gaps are showing up as change requests, an ERP gap analysis is the better first step. The India hub and my main India ERP consulting page give the broader picture of remote work in this market.