Posted in Digital Commerce
June 8, 2026
from the field
Customer-specific pricing in Acumatica ecommerce
Customer-specific pricing is the most common place an Acumatica commerce project quietly goes wrong. Pricing rules live in Acumatica because that is where contracts, customer tiers, and effective dates already live. When the storefront tries to duplicate that logic, the two systems eventually disagree, and buyers notice. The right pattern keeps Acumatica as the source of truth and the storefront as a thin renderer.
Key takeaway
If pricing logic lives in two places, it is wrong in both. Acumatica is the source of truth; the storefront is the renderer.
Why does customer-specific pricing break naive Acumatica integrations?
Acumatica carries pricing logic that does not live cleanly in any standard ecommerce data model. Customer-class price lists, contract pricing with effective dates, tier overrides per customer, volume break tables, promotional overlays, freight programs, and currency conventions all interact. A given line item can have five legitimate prices depending on which customer is logged in, which warehouse is shipping, what date the order is placed, and whether a contract is active. The storefront's product page sees one product. Acumatica sees a rule graph.
Naive integrations flatten the graph. A nightly job exports a single price per SKU per customer to the storefront, and the storefront serves it. That works for the simplest catalogues. It quietly breaks the moment a contract changes mid-month, a new tier is added, a promotional price is applied to a customer-class subset, or an effective-dated change kicks in between exports. The buyer sees a stale price; the rep sees the right price; finance sees two different numbers on the invoice and the order. Each one is a small breach of trust. Compounded across a year, they cost the project its credibility.
The fix is not heroic engineering. The fix is to stop duplicating Acumatica's pricing logic in the storefront and to call Acumatica at cart and quote time instead. Acumatica's contract-based REST and SOAP web services expose the pricing model in a way the storefront can consume. The architecture conversation is about when to call those services, how to cache responses safely, and how to communicate latency to the buyer.
Where should customer-specific pricing actually live?
In Acumatica, in almost every case. The ERP already holds the customer master, the contract terms, the price lists, the price classes, and the effective-dated logic. The audit trail that finance and procurement rely on already lives there. Replicating any of that in the storefront creates a second source of truth that has to be reconciled, and reconciliation is the work nobody budgets for.
What the storefront should own is the buyer-facing experience around the price: the visual layout, the explanatory text ("your contract price"), the comparison to list price where it adds value, the fallback when the call to Acumatica is delayed, and the analytics on how buyers respond to the price they see. None of that requires the storefront to recompute the price itself.
The middleware question shows up here. For platforms whose data model cannot express the full Acumatica pricing graph, a middleware layer can translate between the two. The middleware does not own the pricing logic; Acumatica still does. It owns the translation, the caching strategy, and the resilience patterns that keep the storefront responsive even when the ERP is slow. That separation is what keeps the architecture honest as the business adds customers, contracts, and product variants.
How do you call Acumatica for prices at cart and quote time without slowing the storefront?
The performance question is real, and the answer is a layered cache. The first layer is per-request: when a buyer opens the cart, call Acumatica once to price the full cart, not once per line item. The second layer is short-lived: cache the priced cart for the duration of the buyer's session, refreshed if they add or remove a line. The third layer is per-customer reference data: cache the customer's price class, contract, and currency for the session so the call to Acumatica focuses on the line items rather than the customer context.
The caching strategy has limits, and that is the point. Cache the inputs (the customer's class, the contract reference, the currency) where they rarely change. Do not cache the output (the priced line) past the session, because the contract or the price list could change between sessions. The pattern is shorter than most teams expect: minutes of caching, not days.
Communication matters too. If the call to Acumatica takes longer than the storefront's budget, surface a brief loading state ("calculating your contract price") rather than serving a placeholder price. Buyers tolerate a half-second pause; they do not tolerate a price that changes between cart and checkout. The flow we build through ERP integration and expansion engagements treats the buyer's confidence in the price as a feature of the architecture, not an afterthought.
What does this pattern look like across BigCommerce, Shopify, Shopware, and Drupal Commerce?
BigCommerce, particularly through its B2B Edition, supports customer groups and price lists that can hold the buyer-facing view of the price, with the underlying pricing logic still calculated in Acumatica and pushed into the BigCommerce data model on a tight schedule or at session start. The connector ecosystem around Acumatica + BigCommerce includes patterns for this, and a decoupled BigCommerce build extends it further when the buyer experience needs to outrun the connector defaults.
Shopify B2B includes company-level catalogues and price lists that can express tier and customer pricing for a defined catalogue size. Beyond a certain complexity, particularly when contracts have effective dates and multi-tier overrides, a decoupled Shopify build that calls Acumatica directly carries the logic more cleanly than trying to encode it in Shopify's data model.
Shopware's API-first data model and Drupal Commerce's flexible pricing rules tend to give engineering teams more room to call Acumatica at cart time without fighting the platform. The trade-off is that the integration is more custom by default, which is fine when the team is staffed for it and a constraint when the team is not. Pillar 5 covers the decoupled commerce patterns in more depth.
How should contracts, effective dates, and approvals interact with pricing?
Contracts add an effective-date dimension that storefronts often handle poorly. A buyer's contract may take effect next Monday, with a new price tier and new SKUs available. The storefront should honour the date Acumatica records, not the date a connector last ran. The simplest pattern is to send Acumatica the cart at request time and let the ERP apply the effective-dated contract; the storefront renders whatever Acumatica returns.
Approval chains intersect pricing in a few ways. An order above a contract threshold may need a contract holder's sign-off. An override of a price by a sales rep may need finance approval. A non-contract line on an otherwise contracted account may need a separate approver. The chains belong in Acumatica because they touch the audit trail finance relies on. The storefront surfaces the requirement and shows the buyer what comes next, but it does not invent the chain.
Common patterns that work in production
- Price the full cart once per buyer interaction. Send Acumatica the customer, the shipping context, and the lines; render whatever comes back.
- Cache customer reference data for the session only. Class, contract, currency, ship-to. Refresh on login.
- Show a brief loading state when Acumatica is the bottleneck. Buyers tolerate a half-second pause; they do not tolerate stale prices.
- Treat list price as a display field, not a pricing input. The actual price comes from Acumatica.
- Surface contract context in the cart. "Your contract price" makes the operation visible and reinforces the customer relationship.
- Log every pricing call and its result. The audit trail belongs in Acumatica; the storefront logs are a debugging aid, not the source of truth.
- Test contract effective-date changes deliberately. Pricing bugs around effective dates are the most common quiet failures we see in production.
The architecture work behind these patterns is the work most B2B commerce projects underestimate. It pays back the moment a buyer notices that the price in the cart matches the price on the contract and the price on the invoice, every time, without anyone having to check. That is the standard customer-specific pricing on Acumatica has to meet, and it is the standard the architecture has to be built around.
Related Articles
Acumatica ecommerce: how to architect commerce on Acumatica ERP
- The architecture fit report: where B2B ecommerce projects fail before the first line of code
- Native, middleware, or decoupled: choosing the right commerce architecture for B2B
- The architecture fit framework: how to run discovery and strategy before platform selection
- Why the platform does not matter until you understand the business logic
- How an Acumatica manufacturer avoided a rebuild by getting the architecture right first
- Acumatica distributor case: how discovery pointed to a decoupled architecture
Frequently Asked Questions
How do I show customer-specific pricing on an Acumatica ecommerce site?
Call Acumatica at cart and quote time rather than caching prices nightly. Acumatica's contract-based REST and SOAP services expose the customer's price class, contract terms, and effective-dated rules. The storefront sends the customer and the cart, Acumatica calculates the prices, and the storefront renders the result. Cache customer reference data (class, contract, currency) for the session; do not cache the priced line beyond it.
Can BigCommerce or Shopify carry Acumatica contract pricing natively?
Both platforms have B2B features that can express a useful subset of customer and tier pricing. The question is whether your contract logic, particularly effective dates and multi-tier overrides, fits inside that data model. When it does, the connector pattern works well. When it does not, a decoupled architecture that calls Acumatica directly is the cleaner answer.
How often should the storefront sync prices from Acumatica?
Sync is the wrong word. The pattern that survives contact with real customers is to call Acumatica at cart and quote time rather than to cache prices on a schedule. Schedules drift; cart-time calls do not. The exception is when the platform genuinely cannot call out at request time, in which case the sync window has to be measured in minutes and tied to contract change events.
What about performance? Will calling Acumatica every time slow down the cart?
Done well, no. Price the full cart in one call per buyer interaction, cache customer reference data for the session, and surface a brief loading state if the call takes longer than the storefront budget. In production, the latency budget for a cart re-price is typically a few hundred milliseconds, which a well-tuned Acumatica deployment can hit.
Where should price overrides and rep discounts live?
In Acumatica, with an audit trail. A sales rep can request an override through the storefront or a CSR tool; Acumatica logs the override, the rule it broke, the approver, and the timestamp. The storefront surfaces the override and the resulting price; it does not authorise the override on its own.
How do we handle contract effective dates that change mid-month?
Send Acumatica the request time when the storefront calls for pricing; Acumatica applies the contract that is active at that moment. Avoid caching across the effective-date boundary. Test the pattern deliberately: it is the most common quiet failure in production Acumatica + commerce builds.
Do we need middleware for customer-specific pricing, or can the storefront call Acumatica directly?
Direct calls are cleaner when the storefront platform allows them and the team owns the integration. Middleware earns its keep when the storefront data model cannot express Acumatica's pricing graph cleanly, when caching needs to be coordinated across multiple front ends, or when the integration team needs a stable contract that is decoupled from Acumatica release changes.
Next step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.