Start With What NetSuite Will Touch, Not What It Can Do
If you have a NetSuite implementation in front of you right now, the first thing to resist is the urge to open a generic BRD template and start filling in sections. I’ve been on enough ERP implementations to know that the document structure matters far less than capturing the right content. And with NetSuite specifically, the right content means documenting your business processes, your data, and your decision points before anyone touches a configuration screen.
NetSuite is a highly configurable platform. That configurability is exactly why a weak BRD causes so much damage. When your implementation partner asks “how do you want this to work?” without a documented answer, they’ll make a decision for you. Those decisions accumulate, and by the time you’re in UAT, you’re looking at a system that technically functions but doesn’t match how your business actually runs. Getting your business requirements document right before configuration begins is the only lever you have to prevent that.
What Your NetSuite BRD Needs to Cover
A NetSuite BRD isn’t just a list of features you want. It needs to document the current state problems, the future state intent, and the specific decisions that will drive configuration. Here’s how I structure it, based on what I’ve found actually works in practice.
Organisational Context and Problem Statement
Before you document a single requirement, write down why the organisation is moving to NetSuite. This sounds obvious but it’s almost always skipped or given one paragraph of filler. I need a proper problem statement here, one that describes the actual operational pain. On a utilities sector implementation I worked on (Organisation B), the problem statement covered three specific issues: manual reconciliation between a legacy finance system and a separate inventory tool, double data entry for supplier invoices, and no single source of truth for project cost reporting. Those three problems directly shaped which NetSuite modules we prioritised and how we configured the chart of accounts.
If you need a framework for structuring your problem statement section, the approach described in our business problem statement guide maps directly onto what a BRD introduction needs.
Scope: Modules, Entities, and Exclusions
NetSuite is modular. Your BRD must explicitly state which modules are in scope and which are not. This is where I see the most scope creep risk on NetSuite projects. A stakeholder in your workshop mentions something that sounds like a requirement but actually belongs to a module that was never budgeted. If it isn’t written down as an exclusion, it becomes an assumption, and assumptions become disputes.
List your in-scope modules clearly. Common ones include:
- Financial Management: General Ledger, Accounts Payable, Accounts Receivable, and any multi-currency or multi-subsidiary requirements.
- Order Management: Sales orders, purchase orders, fulfilment workflows, and approval routing.
- Inventory and Warehousing: Location-based inventory, bin management, and reorder point configuration.
- CRM: Lead and opportunity management, customer records, and activity tracking if replacing a separate CRM tool.
- Reporting and Saved Searches: Standard reports versus custom saved searches, and who owns report creation post-go-live.
- Integrations: Any system that NetSuite will exchange data with, including payroll platforms, ecommerce storefronts, or third-party logistics providers.
Current State and Data Migration Requirements
This section causes more implementation delays than any other. Your BRD needs to document what data exists today, where it lives, what quality it’s in, and what needs to migrate into NetSuite. I’ve found it useful to be brutally honest here. On Project X, a mid-market retail implementation, the finance team insisted their customer master data was clean. I spent two days doing a desktop analysis of their export files and found roughly 1,400 duplicate customer records and inconsistent address formatting across 60% of entries. That finding went directly into the BRD as a constraint, which meant the project budget included a data cleansing workstream. If I hadn’t documented it, the project would have absorbed that cost invisibly during go-live.
Business Process Requirements by Module
This is the core of the document. For each in-scope module, document the business process as it needs to work in NetSuite, not as it works today. The two are not the same. Capture the key decision points within each process: who approves what, at what threshold, under what conditions. These translate directly into NetSuite workflow rules and approval routing configuration.
Use the requirement format that works for your project. I typically use a numbered statement format (REQ001, REQ002) with a priority column. The priority conventions that work best for ERP implementations are straightforward: Essential means the system cannot go live without this, and Desirable means it should be included if configuration time permits. Avoid building a complex priority taxonomy that stakeholders won’t remember by week three.
Non-Functional Requirements
NetSuite is a cloud platform, which removes many of the infrastructure questions that come up in on-premise implementations. But non-functional requirements still matter. You need to document user access and roles, performance expectations for saved searches and reports, data retention requirements, and any regulatory or compliance obligations that affect how data is stored or exported. If your organisation operates across multiple subsidiaries or currencies, document those rules explicitly. NetSuite’s multi-book accounting and intercompany eliminations need to be configured correctly from day one, and the rules that drive those configurations must come from your BRD.
What Belongs in the BRD Versus What Belongs Elsewhere
One of the most common mistakes I see on NetSuite projects is trying to put everything into the BRD. The document becomes unmanageable and no one reads it. Here’s a practical split:
| Document | What It Contains | Who Uses It |
|---|---|---|
| Business Requirements Document (BRD) | Business context, problem statement, scope, process-level requirements, data migration scope, user roles, non-functional requirements | Business stakeholders, project sponsor, implementation partner for scoping |
| Functional Requirements Document (FRD) | Detailed system behaviour, field-level rules, workflow logic, UI specifications | Implementation partner’s technical team, configuration leads |
| Data Migration Plan | Source-to-target mapping, data cleansing rules, migration volumes, cutover schedule | Data migration lead, ETL developers, business data owners |
| Integration Design Document | API specifications, data flow diagrams, error handling rules, sync frequency | Integration developers, NetSuite administrator |
| Test Plan / UAT Scripts | Test scenarios traced back to requirements, acceptance criteria, sign-off process | Business testers, QA lead, project manager |
If you want to understand the distinction between business and functional requirements in more depth before you start writing, the BRD versus FRD comparison on this site is worth reading first.
A Worked Example: Where the Friction Actually Hits
On a professional services implementation I worked on (Client A, Project X), we were replacing a combination of spreadsheet-based project tracking and a legacy billing system with NetSuite’s Project Management and Billing modules. The initial BRD workshops went well. We documented the project billing process clearly, including milestone billing rules and time and materials billing for separate project types.
The friction came when we got to revenue recognition. The finance director had signed off on the requirements in the workshop, but when I circulated the draft BRD for approval, the CFO came back with a significant pushback. She pointed out that the revenue recognition rules we had documented didn’t comply with the organisation’s interpretation of their applicable accounting standard for multi-element arrangements. This hadn’t come up in any of the workshops because the finance director and the CFO had different understandings of how those rules applied to their specific contract types.
We had to pause the BRD sign-off for three weeks while the finance team resolved the internal disagreement. It was frustrating, but that three-week delay at requirements stage saved what would have been months of rework post-configuration. The lesson I took from it was this: for any NetSuite implementation involving revenue recognition, billing rules, or intercompany transactions, you need the most senior finance stakeholder in the room during requirements review, not just for sign-off. Their involvement during drafting catches the gaps that workshop attendees don’t know exist.
If your project involves running workshops to elicit these requirements, the BA kick-off meeting guide has practical advice on structuring those sessions to surface exactly this kind of hidden complexity early.
Stakeholder Sign-Off and Version Control
Your BRD needs a formal approval section. This is not optional on a NetSuite implementation. I always include a distribution list, a revision history table, and a named approvals table with title, date, and version number. Once the document is signed, any change to a requirement must go through a formal change request. This is your primary defence against scope creep during configuration, and it’s the mechanism that keeps your implementation partner accountable to what was agreed.
Set a document status on the cover page: Draft, Under Review, Approved. Move it through those stages deliberately. An approved BRD with a date on it is a commercial document as much as it is a technical one. It’s what you point to when someone says “but I thought we were getting X” six weeks into configuration.
Getting your NetSuite BRD right before configuration begins is the single highest-leverage activity on an ERP implementation, because every decision your implementation partner makes in the absence of a documented requirement is a decision you’ll have to live with, rework around, or pay to change later.
Frequently asked questions
What should be included in a NetSuite business requirements document?
A NetSuite BRD should cover the business context and problem statement, in-scope and out-of-scope modules, process-level requirements for each module, data migration scope and quality notes, user roles and access requirements, and non-functional requirements such as performance and compliance. It should also include a formal approvals section with named sign-off from senior stakeholders. The document is separate from the functional requirements document, which covers detailed configuration specifications.
How is a NetSuite BRD different from a functional requirements document?
A BRD documents what the business needs and why, written in business language for stakeholders and sponsors to review and approve. A functional requirements document documents how the system will behave, written at a level of detail that an implementation partner or developer can configure against. For a NetSuite project, both documents are needed, but the BRD must be completed and approved first.
Who should approve a NetSuite BRD?
The BRD should be approved by the project sponsor, the business owner of each in-scope process area, and the most senior finance stakeholder if the implementation includes financial management, billing, or revenue recognition modules. Implementation partner sign-off is also advisable to confirm the requirements are within scope and technically achievable. Approval should be formal, dated, and version-controlled.
How long should a NetSuite BRD be?
There is no fixed length, but most mid-market NetSuite implementations produce a BRD between 20 and 50 pages depending on the number of modules in scope and the complexity of the business processes. The document should be as long as it needs to be to unambiguously define the requirements, and no longer. Padding with generic background information reduces the document’s usefulness.
Can I use a generic BRD template for a NetSuite implementation?
A generic BRD template gives you a useful starting structure, but it needs to be adapted for NetSuite specifically. You need to add sections covering module scope, multi-subsidiary and multi-currency rules if applicable, integration touchpoints, and data migration scope. A template designed for a bespoke software project will not prompt you to think through the NetSuite-specific configuration decisions that need to be captured before your implementation partner starts work.
Try Ash, Your Virtual BA
If you’ve read this far, you’re probably sitting with a NetSuite implementation on your plate and a blank document in front of you. Ash, the virtual BA assistant on this site, can help you draft your NetSuite business requirements document section by section, prompting you through the module scope, process requirements, data migration considerations, and stakeholder approvals that this article covers. Rather than starting from a generic template and guessing what to adapt, you can work through the structure with guidance built specifically for BA practice. Try Ash Virtual BA and start building your BRD today.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Business Requirements at the Core: How to Uncover, Model, and Align Analysis with Real Business Needs | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.