Where should a B2B price be calculated: in the ERP, in the storefront, in middleware, or at request time?

There are four, and every pricing argument on an ERP-connected commerce project is really an argument about which one you have chosen, usually without saying so out loud. The ERP can calculate the price and keep it to itself until an order arrives. The ERP can calculate it in advance and something can copy the result into the storefront. The storefront can calculate it from its own rules. Or something can ask the ERP at the moment a buyer loads the page.

Only one can win, because each of the four holds a different set of inputs. Acumatica and Cin7 know the contract, the expiry date and the customer’s tier. Shopify B2B and BigCommerce know the cart, the quantity and the session. MiddlewareMiddleware is a layer of software that sits between the ERP and the storefront, translating and enforcing rules that neither system holds on its own. It can be a hosted integration platform or a custom service. knows whatever you told it last. If two of them are allowed to produce a price, they will eventually produce two, and the customer will quote the one that suits them.

The thing that makes this harder than it sounds is that the number a buyer needs is not stored anywhere. A list price is a field. A price class rate is a field. The effective price for this customer, this item, this quantity, today is the output of a calculation that runs when someone asks for it. A connector that copies fields cannot copy a calculation, which is why Acumatica’s own community, answering a direct question about syncing the effective sales price to Shopify rather than the Default Price, replied "No. Only Default Price is supported."

Options one, two and three cost nothing measurable at page load, because the price is already sitting in the platform’s own database by the time a request arrives. That is the whole appeal of a pushed price list, and it is why it survives contact with a Black Friday-sized traffic spike without anyone doing arithmetic first.

Option four is where latency becomes a design problem. A request-time price call adds a round trip to the ERP on the product page, the category listing, the cart and the checkout. The category listing is the one that catches teams out: a page showing 48 products needs 48 prices, and if the integration asks for them one at a time you have built something that gets slower as your merchandising improves. Any request-time design needs a batch endpoint that takes a customer and a list of item IDs and returns a list of prices in one call.

We do not publish first-party latency measurements for this, and we would treat anyone else’s single number with suspicion, because it changes completely with the ERP, the hosting region, the size of the price call and whether the ERP instance is also running a month-end close. What we will say is what the design has to contain, because that part does not vary.

Cache the answer keyed on customer or price class plus item plus quantity band, never on item alone, because an item-keyed cache will serve one customer’s negotiated price to another. Give the cache a time to live short enough that a same-day price change is visible within the window your commercial team can live with, and add an explicit invalidation path so a price change in the ERP can push the old entry out rather than waiting for it to expire. Then decide what happens on a cache miss when the ERP does not answer, which is the next section and the part most projects skip.

A pushed price is exactly as fresh as the last run of the job that pushed it. On the Acumatica to BigCommerce path that means the Price List entity’s Prepare and Process schedule, which sites commonly run overnight because it is expensive to run often. Cin7 Core’s sync behaviour is documented as a four-hour cycle in SparkLayer’s Cin7 Core integration documentation, which is a different shape of the same constraint.

Staleness only becomes a commercial problem in three specific situations, and if none of them apply to you the overnight push is fine and you should stop worrying about it. The first is a price that has to take effect the same day it is entered, which is normal in commodity trading, metals, fuel-indexed freight and resin. The second is a contract with an expiry date, because a flattened price list has no way to know that yesterday’s price stopped being valid at midnight. The third is a price that depends on something the push cannot see, such as the lot the stock came from.

There is a second kind of staleness that is easier to miss and harder to explain to a customer. A push can fail silently and leave the previous run’s prices in place, which looks identical to a successful run that produced no changes. Acumatica’s community carries a thread on exactly this shape of failure, "Error on Shopify Price List Sync: Sync ID is not found for the record", and a separate one where BigCommerce sales prices synced against the wrong unit of measure, which is a wrong price rather than an old one. Any pushed-price architecture needs a monitor that alerts on the job not running, not only on the job erroring.

The practical test is to ask your commercial team a single question: if a price we agreed this morning does not appear on the website until tomorrow morning, who notices and what does it cost us? If the honest answer is nobody and nothing, you are a price-list business and you should buy the cheap architecture with both hands.

Every ERP goes offline. Acumatica instances take upgrade windows, Cin7 has maintenance, and both have the ordinary bad afternoon that any hosted system has. The difference between the four architectures is not whether they survive that, it is how visible the failure is to a buyer and how much of it you get to choose.

Options one, two and three degrade invisibly. The prices are already in the platform database, so the storefront keeps trading. What stops is order transmission, and orders queue instead. That is a genuine architectural advantage of the pushed price list and it rarely gets stated in a platform comparison, because platform vendors are not the ones who get the phone call.

Option four fails in public unless you have designed for it, and the design has to be decided by the business rather than by whoever writes the integration at 6pm on a Thursday. There are four honest behaviours and each of them is wrong for somebody.

Pick one, write it into the requirements, and then test it by turning the ERP connection off in a sandbox and looking at the page. A surprising number of teams discover at that moment that their storefront shows a price of zero, which is the one option nobody chose.

Six numbers decide this, all of them already in your ERP, and any competent person in finance or sales operations can pull them in an afternoon. Get them before your next platform demo, because they change which demo is even relevant.

The read on the answers is blunt. If question three is a few thousand rows or fewer and questions four and five are zero, you are a price-list business, and options one and two are correct: buy the native connector, spend the saved money on catalogue data, and stop reading architecture pages. If question three runs to tens or hundreds of thousands of rows, or question four is meaningfully non-zero, you are a request-time business and no connector configuration will rescue that. Question six is the one that quietly kills pushed price lists on Shopify, because Shopify documented on 20 August 2026 that Basic, Grow and Advanced plans allow "up to 3 active catalogs across all your B2B markets", with a maximum of 25 catalogues per company location and 10,000 per store on Plus.

One honest caveat about the arithmetic. Row counts are a proxy for cost, not a rule. A distributor with 200,000 customer-item price rows that never change is easier to push than one with 8,000 that change daily. Use the count to tell you how big the push is, and use question four and question five to tell you whether the push can be right at all.

We build integrations for a living, so read this section with that in mind: an agency has an obvious incentive to talk you into option four, and option four is wrong for a lot of the companies that ask us about it.

The scheduled push wins outright in four situations. It is also the right first phase for a business that will eventually need request-time pricing, because a phase one on pushed prices gets a storefront trading and tells you which prices actually get looked at, which is information you cannot buy any other way.

The case we will not call for you is volume breaks. Several vendors, Acumatica included, advertise that customer-specific volume break rules synchronize to the storefront, and we have not verified that end to end against a live instance. Shopify’s own documentation is clear that you can add up to ten price breaks per product and that once volume pricing applies "the price becomes fixed. Any overall adjustment discount set on the catalog won’t apply", which is a real constraint rather than a rumour. If break quantities are how your pricing works, prove the whole chain in a sandbox with your own data before you believe any of us.