ERP Business Analyst in the USA

Writing sales tax and nexus requirements the right way

Sales tax is where generic requirement templates fail US companies most often. "The system must calculate sales tax" tells a vendor nothing. As a business analyst, my job is to document the inputs and decisions behind tax so the system can be configured and tested against them.

Typical requirements I capture include:

• Which addresses drive tax: ship-to, bill-to or service location, and how drop shipments are handled.
• How products and services are classified for taxability, and who maintains those codes.
• How exemption and resale certificates are collected, stored, linked to customers and checked for expiry.
• How marketplace sales are recorded when the marketplace collects tax on your behalf.
• What reports the person preparing returns needs, by state and locality.

I do not decide where you have nexus or what you must collect; that comes from your CPA or tax advisor. What I make sure of is that their guidance is turned into clear, numbered requirements and test cases. If a platform needs a third-party tax engine to meet them, the fit-gap matrix shows it. For a broader view of how this fits into system choice, see my ERP consultant page for the USA.

Vendor, payables and year-end reporting requirements

Procure-to-pay in a US business carries details that are easy to forget until December. Many companies must issue information returns, such as Form 1099, to certain vendors and contractors. If vendor records do not capture the right tax details and classifications from the start, finance ends up rebuilding the data from bank statements and email at year-end.

In requirements workshops with your AP and finance team, I document what each vendor record must hold, who can create or change it, what triggers a W-9 request, how payments are categorized and what reports are needed at year-end. Your accountant confirms the reporting rules; I make sure the ERP is specified to support them.

The same workshops cover approval routing for purchase orders and bills, three-way match between PO, receipt and invoice, payment runs by ACH or check, and how vendor bank details are verified before they change. These are small requirements on paper, but they decide whether payables run cleanly or through constant workarounds. The detail goes into the BRD and later into UAT scripts.

Controls, approvals and audit-ready processes

Many growing US companies reach a point where internal controls stop being optional. A lender asks for reviewed or audited financials, a private-equity investor wants consistent reporting across portfolio companies, or the board starts asking who can approve what. An ERP can enforce controls, but only if someone has defined them.

I document the control requirements alongside the process maps: approval limits by role and amount, which users can create vendors, post journals or release payments, how segregation of duties is maintained in a small team, and what audit trail each transaction must leave. Where one person has to hold several roles, I record the compensating review that makes it acceptable to your auditor.

These requirements shape role design and testing. During the gap analysis, I check whether each shortlisted platform can enforce them with standard configuration or needs workflow add-ons. During UAT, the scripts test that a user without approval rights genuinely cannot push a transaction through. This is detail that vendors rarely raise themselves, and it is much cheaper to specify before implementation than to retrofit after an audit comment.

Multi-entity, multi-state operations in the requirements

US companies often grow by adding entities: a new LLC for a location, a separate company for a product line, an acquisition that keeps its own books. Each addition changes the requirements, and the BRD needs to describe the structure the business will have, not just the one it has today.

I capture which entities buy from or sell to each other, how intercompany charges are priced and settled, which entities share customers, items or vendors, and what consolidated reporting leadership expects. I also document operational differences between states: separate payroll providers, different warehouse processes, state-specific licensing details on documents or local requirements your advisors flag.

Because many of these teams sit in different time zones, workshops are scheduled in overlap hours and every session ends with written notes and open questions assigned to owners. People who could not attend can review and comment asynchronously before sign-off. All of this is delivered remotely, which keeps the work moving without travel. If you want a starting point, my ERP requirements checklist and guide to writing an ERP BRD show the structure I use. You can also see what else I offer US businesses on the USA overview.