Acumatica ecommerce: how to architect commerce on Acumatica ERP

Ecommerce on Acumatica works through one of three architectures: a certified native connector to a third-party platform like BigCommerce or Shopify, a decoupled architecture where the storefront calls Acumatica's APIs at request time, or a middleware-led pattern that consolidates API calls and applies business rules between the two. The right choice depends on how much of the buyer experience depends on logic that lives only in Acumatica, customer-specific pricing, contract terms, multi-warehouse availability, approval chains, and how much capacity the team has to own the integration.

Acumatica Commerce Edition packages the ERP modules most relevant to product sellers (distribution, inventory, order management, customer management) and adds the connector layer to a chosen commerce platform. It is not a self-contained storefront. Buyers still pick a commerce platform (typically BigCommerce, Shopify, Shopware, or Drupal Commerce) and connect it to Acumatica through a certified connector or a decoupled architecture.

The Acumatica Marketplace lists certified connectors for several platforms, with BigCommerce having the longest track record in distribution and light manufacturing. Shopify and Magento are covered through certified or partner-built connectors. Shopware and Drupal Commerce typically pair with Acumatica through custom integration on top of the contract-based APIs. The phrase "native" covers a wide range, so check what the specific connector actually syncs before assuming parity with your business logic.

Yes, and customer-specific pricing is one of the highest-leverage places to get the architecture right. The pattern that holds is to keep pricing logic in Acumatica (where contracts, customer tiers, and effective dates already live) and to call the ERP at cart and quote time rather than caching prices nightly. Naive integrations that flatten Acumatica's price list into a nightly export consistently end up wrong, and customers notice within a quarter.

When the commerce scope crosses into territory the standard connector does not carry cleanly: multi-tier customer-specific pricing with effective dates, contract pricing with minimum commitments, configurator-to-quote workflows, complex approval chains, or dealer and distributor self-service portals. The pattern Acro Commerce recommends is that the VAR keeps the customer relationship and the ERP scope, and the architecture partner takes the commerce build. Both sides bill for what they do best.

The Acumatica xRP platform is the application framework Acumatica runs on, including its data model, business logic layer, and the contract-based APIs commerce layers call. It matters because every commerce integration eventually depends on what xRP exposes. The more your integration calls xRP directly through its contract-based REST and SOAP services, the more your architecture inherits Acumatica's data integrity guarantees rather than recreating them in the storefront.

Kensium is one of the established connector vendors in the Acumatica ecosystem and a serious option for many B2B sellers. The honest answer to "best" is that the right approach depends on which of your business rules the connector has to carry, what your integration team owns, and how much customisation the buyer experience needs. The cluster covers the buyer's framework for comparing Kensium with other approaches, focused on business-logic fit rather than vendor preference.

A focused B2B build on top of a stable Acumatica deployment typically runs four to nine months from discovery to first production release, with phased releases continuing after launch. Projects that try to launch commerce before the ERP data model is settled run longer, sometimes much longer. The cheapest accelerator is discovery: a few weeks of structured work that prevents the integration from being designed against a moving target.

Often, yes. If the platform already carries the buyer experience your customers expect and the integration to your current ERP is brittle, the highest-leverage work is on the integration layer rather than a replatform. Discovery should always test the keep-and-improve path before recommending replacement, because the cheapest successful project is the one that does not rebuild what already works.

A B2B portal on Acumatica is the layer where the ERP's operational truth meets the buyer, covering account access, order history, reorder, customer-specific pricing, and quote-to-cash flows. Five portal patterns show up in production across Acumatica deployments, from the native self-service portal through ISV-extended, decoupled, custom, and hybrid models. The right one depends on the depth of B2B features the buyer expects and the team capacity available to maintain the experience.