
Posted in Digital Commerce
June 30, 2026
readiness report
Acumatica commerce readiness: what VARs and customers need to know
Adding commerce to Acumatica is less about the storefront and more about whether the ERP is ready to be the source of truth behind it. Readiness comes down to a few things: pricing modelled correctly, inventory and availability you trust, a clean customer master, and a clear view of which business logic the storefront must honour. This report walks what "ready" means, the signals you're not there yet, and how to close the gap.
Key takeaway
Commerce readiness on Acumatica is mostly ERP readiness. If pricing, inventory, and the customer master are clean and you know which logic the storefront must honour, the build goes fast. If they're not, no storefront saves it.
Most Acumatica businesses that want commerce are readier than they fear in some areas and less ready than they think in others. The storefront is rarely the hard part. The hard part is whether Acumatica can act as the source of truth the storefront reads from: prices that are right for every customer, inventory you'd stake an order on, a customer master without duplicates, and a clear line between the logic that belongs in the ERP and the logic that belongs in the buying experience. This report is a plain read on what readiness means and how to tell where you stand.
What "commerce ready" actually means on Acumatica
Readiness has four parts, and they're all on the ERP side. Pricing: customer-specific prices, price classes, contract terms, volume breaks, and effective dates are modelled in Acumatica and produce the right number for the right buyer. Inventory: available-to-promise reflects reality across warehouses, not a stale snapshot. Customer master: accounts, hierarchies, and ship-to relationships are clean enough that a buyer logging in maps to exactly one record. And logic boundaries: you know which rules (configuration, approvals, tax) the storefront must honour rather than reinvent. Get those four right and the storefront becomes a renderer. Leave them shaky and the storefront inherits the mess.
The signals you're ready
- A rep can quote any customer their correct price from Acumatica without a spreadsheet on the side.
- Inventory in Acumatica matches the floor closely enough that you'd let a customer order against it unattended.
- Each customer is one record, with ship-to and billing relationships modelled, not a scatter of near-duplicates.
- You can name the handful of rules, pricing, configuration, approvals, tax, that the storefront must respect, and where each lives.
- There's real order volume or a concrete growth plan that a self-service channel would serve.
The signals you're not ready yet
The tells are consistent, and they show up as manual work papering over a gap. Prices that only exist in a rep's spreadsheet. Inventory nobody trusts, so every order gets a phone call to confirm. A customer master with duplicates that make "who is this buyer" ambiguous. Orders that arrive on paper, by email, or by phone because there's no experience to capture them. And configuration handled in someone's head or on a worksheet the ERP can't validate.
Lustre Products is the clearest version of that last one. About 85% of its orders arrived on a 25-column paper worksheet that had been the industry standard for 35 years. Acumatica could store the order, but its configurator produced text, not a validated build, and re-keying introduced errors that cost roughly $86,400 a year. The readiness gap wasn't the ERP's ledger; it was that the configuration logic had no validated home. That's a solvable gap, but you have to name it before you scope a storefront.
Fix the ERP side before the storefront
The single most expensive mistake is launching commerce before the pricing and inventory are modelled cleanly, because the storefront then exposes every inconsistency to the customer at speed. Pricing is where this bites hardest. Acumatica handles customer-specific and price-class pricing, volume breaks, promotional prices, and effective dates natively, but naive integrations flatten that into a nightly export of one price per customer, which drifts the moment a contract changes mid-month. The fix is to keep pricing in Acumatica and call it at cart and quote time. We cover the mechanics in customer-specific pricing in Acumatica ecommerce.
Accurate Industries shows the other common gap: two good systems that don't talk. It runs Acumatica with a Drupal Commerce storefront, and out of the box they didn't sync, so staff bridged product data, accounts, pricing, and stock by hand. The readiness work there was the integration itself, building a proper client and library against Acumatica's API rather than exporting flat files. Readiness isn't only "is the data clean"; it's "can the storefront read the truth from the ERP without a person in the middle."
Decide how the storefront connects
Once the ERP side is sound, readiness includes knowing how the storefront will connect. Acumatica ships native connectors for BigCommerce, Shopify, and Amazon that fit standard selling and cover a growing set of B2B features. When the way you sell exceeds what field-mapping can express, a configurator, complex contract logic, or an unsupported platform, a decoupled build reads live from Acumatica through its API, and middleware fits when several systems must stay in sync. Choosing among them is its own decision, walked in our comparison of native, decoupled, and middleware.
What this means for VARs
For an Acumatica VAR, readiness is a qualifying conversation. When a client's ERP complaint is really about how they sell, re-keying, a configurator that can't validate, orders on paper, the opportunity is commerce, not an ERP tweak. The move that grows the account without the risk is to keep the ERP and bring in a commerce specialist for the build. We lay out the qualifying signals and the co-delivery model in how Acumatica VARs qualify a commerce opportunity.
A readiness checklist
- Pricing: every customer's correct price comes out of Acumatica, including contracts, tiers, volume breaks, and effective dates.
- Inventory: available-to-promise is trustworthy across warehouses.
- Customer master: one clean record per customer, with hierarchy and ship-to relationships modelled.
- Configuration: any configure-to-order logic has a validated home, not a paper worksheet or someone's memory.
- Logic boundaries: you can name which rules the storefront must honour and confirm they live in Acumatica.
- Integration path: you've chosen native, decoupled, or middleware for a reason you can defend.
- Demand: there's real volume or a growth plan the channel will serve.
You don't have to grade yourself alone. Preflight, Acro's commerce-validation tool for pre-sales and VARs, reads a site and flags fit, risks, and integration gaps in minutes, powered by Celeste. It's a fast way to turn "we think we're ready" into a defensible read before anyone commits to a platform.
Related Articles
Acumatica ecommerce: how to architect commerce on Acumatica ERP
- Acumatica commerce readiness: what VARs and customers need to know
- Acumatica native commerce, decoupled commerce, or middleware: when to choose each
- How Acumatica VARs qualify a commerce opportunity
- Customer-specific pricing in Acumatica ecommerce
- Accurate Industries: building B2B commerce on Acumatica
- Lustre Products: Acumatica + B2B commerce for distributors
Frequently Asked Questions
Is my Acumatica business ready to add B2B commerce?
You're ready when Acumatica can be the source of truth behind the storefront: every customer's correct price comes out of the ERP, inventory is trustworthy, the customer master is clean, and you know which rules the storefront must honour. If those hold and there's real demand, the build goes fast. If pricing or inventory is shaky, fix the ERP side first.
What has to be true in Acumatica before launching commerce?
Four things: pricing modelled correctly (customer-specific prices, contracts, volume breaks, effective dates), available-to-promise inventory you trust across warehouses, a clean customer master with one record per buyer, and clear logic boundaries so the storefront honours ERP rules rather than reinventing them.
Why not just launch and fix pricing later?
Because the storefront exposes every pricing inconsistency to the customer at speed. Naive integrations flatten Acumatica's pricing into a nightly export that drifts when a contract changes mid-month, so the buyer, the rep, and finance see different numbers. Keeping pricing in Acumatica and calling it at cart time avoids that, but it's much cheaper to design in than to retrofit.
We already run Acumatica well but our systems don't talk. Are we ready?
Often yes, with the integration as the main project. Accurate Industries ran Acumatica and a Drupal Commerce storefront that didn't sync out of the box; the readiness work was building a proper connector against Acumatica's API rather than exporting flat files. Clean data plus a real integration is the readiness bar, not clean data alone.
How do we choose between a native connector, middleware, and a decoupled build?
Start native if you sell in standard ways through BigCommerce, Shopify, or Amazon. Use middleware when several systems must stay in sync. Go decoupled when configuration, complex B2B logic, or an unsupported platform exceeds what field-mapping can express. Our comparison guide walks the trade-offs in detail.
How can a VAR assess a client's commerce readiness quickly?
Listen for ERP complaints that are really about how the client sells, then check whether a native connector already covers it. For a fast, defensible read, run the client's site through Preflight, which flags fit, risks, and integration gaps in minutes before you recommend a platform.
Next step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.