ERP Requirements Consultant, USA

How a US requirements specification is organized

I organize the specification by process area rather than by department, because ERP modules cut across departments. A typical US outline runs: quote to cash, procure to pay, inventory and fulfillment, production or project delivery, record to report, fixed assets, and reporting. Each area opens with a short process summary, then lists its requirements.

Every requirement follows the same anatomy:

• ID and area, so it can be cited in an RFP response or a contract schedule.
• Statement, one behavior per line, written as "the system must" or "the system should".
• Priority using Must, Should, Could or Won't, settled with the owner of that area rather than assigned by whoever argued hardest.
• Acceptance condition, the observable result that proves the requirement is met.
• Source and owner, so questions go to the right person later.

Prioritization is described in words, not quotas. Must means the business cannot operate or stay compliant without it. Should means a workaround exists but is costly. Could means useful if the chosen platform does it in standard. Won't marks items deliberately parked for a later phase, which stops them returning as surprise scope. The broader method behind this is set out on the ERP requirements gathering page.

Statutory and control requirements written for a US context

The statutory section is where vague wording does the most damage. I write each item as a condition a tester can check, and flag it for your CPA, payroll provider or counsel to confirm. I do not decide tax positions or legal obligations.

• Sales and use tax. The specification states how tax is calculated, whether by native tables or an external tax engine, which fields the engine receives, how exemption status reaches the invoice and what return-preparation extract is required by jurisdiction.
• Payroll interface. Many US companies keep payroll with an outside provider. The requirement covers the inbound journal: mapping by entity, department and state, how accruals and reversals arrive and who reconciles the clearing account.
• Information reporting. Vendor tax classification and taxpayer ID capture, with the year-end extract your advisor needs.
• Retention and archiving. The retention periods your advisors give you, how closed periods are locked and how records are exported if you leave the platform.
• SOX-style controls. If you are listed, preparing to list or answering to lenders and investors who expect formal controls, the specification lists segregation of duties, approval evidence, master data change logs and periodic user access review. Whether SOX applies, and how far, is for your auditors to say.

Currency and language belong here too: USD as functional currency, foreign currency for import or Canadian and Mexican trade, and any user-language need your team identifies.

Non-functional, integration and migration requirements

Lines about hosting, security and speed are the lines vendors find easiest to agree to without thinking. I write them as questions with a required answer:

• Hosting and data location. Which region holds production data and backups, whether a US region is available, and what independent assurance reports the vendor can share.
• Access control. Single sign-on, role-based permissions, restrictions by entity or location and how access is removed when someone leaves.
• Audit trail. Which records keep a field-level history of changes and how long that history is kept.
• Performance and availability. Expected behavior during period-end and seasonal peaks, and support cover across Eastern to Pacific hours, plus Alaska or Hawaii if you have sites there.
• Privacy. Handling of customer and employee data under state privacy laws, as your counsel interprets them.

Integrations get their own annex. For each one I record the systems involved, the direction, the trigger, the frequency, the owner and what happens on failure: eCommerce orders, EDI with retail customers, bank files, the tax engine, payroll and BI.

Data migration requirements state which objects move, how much history, who cleans the master data and how opening balances are reconciled and signed off. Leaving these as "vendor to advise" invites a migration scope that is sized after the contract is signed.

From requirement to demo script, test case and contract

A specification earns its keep when the same IDs appear everywhere downstream. I maintain a traceability register in which each requirement points to the demo script step that exercises it, the fit-gap result for each shortlisted platform and the UAT case that will prove it before go-live.

In practice the document is used in three ways:

1. In the RFP. An extract of the requirements goes into the requirement annex, and vendors respond line by line with standard, configuration, extension or not supported. That makes responses comparable and puts claims on the record.
2. In demos. Scripts are built from Must requirements, so a vendor cannot spend the session on features nobody asked about. The US ERP selection page covers how those demos are scored.
3. In the contract. The signed specification version, or the vendor's response to it, can be referenced in the statement of work, so the delivery team and the buyer argue from the same text.

Version control keeps this honest. The document has a version number, a change log and a sign-off record for each process owner. After baseline, any change goes through a simple request: what changes, why, who approved it and which tests are affected. The ERP RFP consulting service describes the annex and response format in more depth.

Common gaps in US ERP specifications, and remote delivery

Some omissions recur in specifications written without a structured review, and each carries a predictable risk:

• Tax handled in one line. A single "calculate sales tax" requirement leaves the tax engine subscription, the data it needs and the return extract unpriced.
• Payroll left out entirely. If the payroll journal import is not specified, account mapping and reconciliation arrive as unplanned work during the first close.
• Controls added late. When approval evidence and segregation of duties are not written in from the start, they get bolted on after go-live, often through manual workarounds.
• Every line marked Must. Without honest priorities, vendors cannot see what really matters and scope decisions become political.
• No acceptance conditions. Requirements without a pass condition cannot be tested, so UAT turns into opinion.

The work runs remotely. Workshops are short video sessions per process area, scheduled in hours that overlap with your main time zone, and drafts sit in a shared document where owners comment directly. Visits can be added by arrangement. Because no vendor or VAR pays me a commission or referral fee, no requirement is worded to favor one product.

If you need the wider analysis work, including process maps and fit-gap, see the ERP business analyst for US companies page. Wider advisory work is described under ERP consulting for US companies, and the United States hub lists the other pages for this market.