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

1. A rep can quote any customer their correct price from Acumatica without a spreadsheet on the side.
2. Inventory in Acumatica matches the floor closely enough that you'd let a customer order against it unattended.
3. Each customer is one record, with ship-to and billing relationships modelled, not a scatter of near-duplicates.
4. You can name the handful of rules, pricing, configuration, approvals, tax, that the storefront must respect, and where each lives.
5. 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

1. Pricing: every customer's correct price comes out of Acumatica, including contracts, tiers, volume breaks, and effective dates.
2. Inventory: available-to-promise is trustworthy across warehouses.
3. Customer master: one clean record per customer, with hierarchy and ship-to relationships modelled.
4. Configuration: any configure-to-order logic has a validated home, not a paper worksheet or someone's memory.
5. Logic boundaries: you can name which rules the storefront must honour and confirm they live in Acumatica.
6. Integration path: you've chosen native, decoupled, or middleware for a reason you can defend.
7. 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.

Frequently Asked Questions