When does native ERP tax functionality stop being enough for multi-state ecommerce?
NetSuite SuiteTax, Business Central, Acumatica, and Sage Intacct were built to handle tax for invoice-driven accounting workflows. They were not built to operate as the tax engine for a high-throughput ecommerce checkout, generate state-specific signature-ready returns, or maintain a certificate compliance program across multiple states. Three breakpoints mark when the scope mismatch becomes operational exposure.
15 to 20 active state registrations
California requires a separate use-tax schedule. Washington runs B&O tax alongside the sales tax return. Illinois has county-level local jurisdiction breakdowns. Each state’s return format, line-item requirements, and rounding rules differ. The ERP’s return-ready report produces a transaction extract by date range and jurisdiction. Transforming that into 20 state-specific schedules is manual work that scales linearly with state count. Most brands hit the ceiling somewhere between 15 and 20 states, when tax close starts crowding out other finance-team priorities.
Three or more active sales channels
A brand generating revenue through Shopify direct, Amazon Marketplace, and a wholesale channel runs three transaction systems with different data models and different tax collection mechanics. The ERP records accounting entries after the fact. It does not see Amazon’s remittance by state, exemption certificates processed through the wholesale channel, or the cross-channel reconciliation needed to confirm the brand’s net obligation by state. A coherent multi-state compliance picture requires data that lives outside the ERP.
$20M or more in revenue and the first state inquiry
At this scale, a DOR notice or audit request is a realistic event. An auditor expects transaction-level documentation linking each sale to its tax calculation: the rate applied, the jurisdiction resolved, and the certificate if the sale was exempt. ERP transaction logs capture accounting entries. Tax calculation methodology, rate table versions, and jurisdiction-resolution logic are not in those logs. The gap becomes visible when the brand produces a GL extract and the auditor asks where the calculation evidence is.
What the four mid-market ERPs cover natively
NetSuite SuiteTax
SuiteTax is Oracle’s purpose-built tax determination engine, replacing the older tax group architecture. [1] It manages jurisdiction-to-tax-code mapping, tax codes with configurable rate tables, nexus setup by state, and invoice-time calculation for sales orders, invoices, and credit memos. The Tax Reporting Framework produces period-level transaction extracts for return preparation. SuiteTax covers VAT for international operations and accepts third-party tax engine integrations through the SuiteApp marketplace. What it does not do: real-time checkout calculation at ecommerce throughput, state-specific return preparation, marketplace reconciliation, or exemption certificate management beyond a certificate number field on the customer record.
Microsoft Dynamics 365 Business Central
Business Central handles US sales tax through tax group setup and general posting group configuration, the same infrastructure it uses for VAT. [2]
Transaction-level calculation posts at invoice time. The platform produces basic sales tax summary reports for period-end review. Business Central’s tax model reflects its design history as a primarily European platform; the US sales tax implementation works adequately for single-state or limited-registration operations but lacks the jurisdiction granularity multi-state ecommerce requires.
Acumatica
Acumatica uses tax categories assigned to items, tax zones assigned to customers and locations, and tax rate schedules to determine the applicable rate at invoice time. [3]
The reporting layer produces period-level data by jurisdiction. Acumatica’s API-first architecture makes third-party tax engine integration more accessible than some competitors; the determination call can route through an external engine with less configuration friction than the other three platforms.
Sage Intacct
Sage Intacct manages tax through tax solutions and tax detail configurations at the customer and transaction level. [4]
Customer-level exemption flags mark buyers as exempt; a reference field stores a certificate identifier. Sage Intacct’s strength is multi-entity accounting consolidation across subsidiaries, which matters for brands running multiple legal entities. Its US sales tax functionality handles single-state or light-registration operations; it was not designed for the filing volume, marketplace reconciliation, or certificate management that a 15-plus-state ecommerce footprint requires.
TaxCloud connects to all four through a native SuiteApp for NetSuite, an ISV connector for Business Central, an Acumatica Marketplace module, and a Sage Intacct connector, handling the tax operations layer the ERP wasn’t built to own: calculation at checkout, multi-state filing, certificate management, and the audit documentation trail.
The four ERPs compared across the four consistent gaps
The same four gaps appear regardless of which ERP a brand runs.
| Gap dimension | NetSuite SuiteTax | Business Central | Acumatica | Sage Intacct |
|---|---|---|---|---|
| Real-time checkout calculation | Invoice-time only; not designed for concurrent checkout requests | Invoice-time only; VAT-first architecture | Invoice-time only; API-extensible but no native checkout engine | Invoice-time only; not a checkout tax engine |
| State-specific return preparation | Return-ready transaction extract; no signature-ready state returns | GL-level summary; no state return preparation | Return-ready data; no state returns | Transaction-level data; no state return preparation |
| Marketplace facilitator reconciliation | No native reconciliation of marketplace-collected tax | No native reconciliation | No native reconciliation | No native reconciliation |
| Exemption certificate management | Certificate number field on customer record; no expiration tracking or transaction-level linkage | Customer-level exempt flag; no certificate library | Requires third-party module beyond basic flags | Customer-level exempt flag; no expiration tracking |
The checkout calculation gap surprises finance teams most often. ERP tax engines post as part of an invoice workflow designed for throughput measured in invoices per hour, not concurrent API requests at checkout speed. An ecommerce checkout processing thousands of orders per day requires sub-200-millisecond tax responses; the same engine cannot serve both. The return preparation gap surfaces at filing: return-ready data from the ERP needs transformation into each state’s specific schedule format, with local jurisdiction breakdowns, marketplace exclusions, and frequency variations that differ by state and change periodically.
Marketplace facilitator handling: the gap no mid-market ERP closes natively
Every US sales-tax state plus DC requires marketplace facilitators to collect and remit sales tax on third-party seller transactions. [5] For a multi-channel brand, this creates a split-collection structure: the marketplace remits on its sales, the brand remits on its direct sales. None of the four mid-market ERPs has native machinery to reconcile the two.
The split creates two compliance problems. The first is threshold monitoring. Many states include marketplace-facilitated sales in the remote seller’s economic nexus threshold count, even though the marketplace collected the tax. Washington counts cumulative gross receipts including marketplace-facilitated sales (RCW 82.08.052). [6]
Iowa, Kansas, Kentucky, Michigan, Minnesota, Nebraska, Nevada, New Jersey, North Carolina, Ohio, Rhode Island, Vermont, West Virginia, and Wisconsin follow the same approach. A brand with $70,000 in direct Shopify sales and $45,000 in Amazon marketplace sales may be at $115,000 against a $100,000 threshold in those states. The ERP records only what the brand invoiced and collected directly.
The second is return-side reporting. A brand registered in a state where the marketplace also collected must report accurately on one return. The required treatment varies: some states require including all marketplace sales in gross receipts then deducting facilitated sales; others allow direct exclusion; a few require separate schedules. Producing the correct combined return requires transaction data from both the ERP and the marketplace platform, joined by state and period. That join does not happen inside the ERP.
TaxCloud’s reporting API aggregates transaction data across direct-channel and marketplace sources, applies the state-specific treatment, and produces the net-obligation view by state. The ERP holds the accounting record; the tax platform holds the reconciliation logic.
Exemption certificate management at scale
For a brand with a B2B or wholesale revenue stream, exemption certificates are a daily compliance requirement, not an annual one. California accepts the CDTFA-230 as a blanket resale certificate covering ongoing purchases from an established buyer. [7] Texas uses Form 01-339, the Texas Sales and Use Tax Exemption Certificate, with specific exemption reason codes for resale, manufacturing, agricultural, and other categories. [8]
Every other state with a sales tax has its own required form, its own acceptable exemption reason codes, and its own validity period. A brand selling wholesale in 20 states manages 20 certificate types with different expiration schedules.
All four ERPs handle exemption status at the customer record level: a flag marking a customer as exempt, sometimes with a certificate number field. None maintain a library that stores certificate documents with issue and expiration dates, triggers renewal workflows before certificates lapse, links certificates to the specific transactions they cover at the line-item level, or validates the certificate form against the state’s current acceptable format.
That transaction-level linkage is what a state auditor expects at examination. The question is not “was this customer marked exempt?” It is: show me the certificate valid on the date of this transaction, confirm it is the appropriate form for this exemption type in this state, and confirm no purchases occurred after it expired. A certificate number in a customer field does not answer that question. A validated certificate library linked at the transaction level does.
The operating model: ERP as financial record-of-truth, dedicated partner for tax operations
The operating model question for a brand registered in 15 or more states is not which ERP handles tax best natively. It is where the boundary sits between ERP-as-financial-record-of-truth and dedicated-partner-as-tax-operations.
The ERP stays. NetSuite, Business Central, Acumatica, and Sage Intacct remain the general ledger, accounts receivable, accounts payable, revenue recognition, and financial reporting backbone. The AR aging, invoice records, and cash application stay there. What moves is the set of functions the ERP was not designed to perform.
Calculation at checkout
The tax engine receives the checkout request from the ecommerce platform, calculates tax across all applicable jurisdictions, returns the result within the checkout latency budget, and writes the tax detail back to the order record. The ERP receives the posted invoice with tax already determined.
Multi-state return preparation and filing
The tax engine aggregates transaction data from the ERP and all channels, maps each state’s sales to the correct schedule, prepares the returns, and files. With Streamlined Sales Tax enrollment, the 24 SST member states consolidate further: a Certified Service Provider handles a single filing covering all 24, rather than 24 separate state submissions, with filing costs covered by those states.
Exemption certificate management
The tax platform maintains the certificate library, validates certificates against state rules, tracks expiration, and links each certificate to the transactions it covers. The ERP customer record holds the relationship; the tax platform holds the evidence chain.
Audit documentation trail
The tax platform maintains calculation logs at the transaction level: rate table version, jurisdiction resolved, timestamp, and exemption basis and certificate reference where applicable. ERP transaction logs record accounting entries; tax platform logs record tax determination methodology.
Integration between the ERP and the dedicated tax layer runs through a native connector (NetSuite SuiteApp, Business Central AppSource ISV, Acumatica Marketplace module, Sage Intacct connector), an iPaaS layer for multi-channel orchestration, or a direct API integration for high-volume or heavily customized configurations.
For a brand with a 20-plus-state footprint, TaxCloud handles the tax operations layer in full: calculation across 13,000+ jurisdictions through one API called from the ecommerce checkout or directly from the ERP, consolidated SST filing across the 24 member states with state-covered filing costs, and the transaction-level calculation logs and certificate documentation chain an auditor expects to see.