Why did BigCommerce get the base UOM price, not the sales UOM price?

Acumatica holds a base unit for stocking and a sales unit for selling, with a conversion between them. If you stock in EA and sell in CS of 12, the sales price your customers know is the case price. The BigCommerce connector, in the behaviour reported here, exported the price defined against the base unit instead.

The consequence is silent and expensive: no error, no failed sync, just a storefront selling cases at each prices. The poster in the Acumatica community put the business case in one line, that "customers build pricing based on the sales unit and not the base/stocking unit". This is a unit of measure conversionUnit of measure conversion is the rule that says one case equals twenty-four eaches, so a customer can buy in the unit that suits them while stock is counted in the unit that suits the warehouse. problem wearing a pricing problem’s clothes.

Because of what triggers a sync. The Acumatica moderator on the thread explained that if the sales UOM changes on a stock item after prices have synced, the system cannot automatically push a correction, because "the last modified date of the Sales Price will not be updated with this change of UOM in Stock Item".

That is worth understanding beyond this one bug, because it is the general shape of change detection in this connector. The sync watches a modified date on the record it exports. A change to a related record that alters the meaning of the exported value does not touch that date, so nothing re-fires. Every integration built this way has a version of this problem.

Acumatica 22R2 is the answer. The thread records sales UOM support arriving in the core product at 22R2, which removed the need for the customisation route. Before that, Acumatica published a customisation package for 2021 R1 build 21.111 and later, exporting prices for the sales UOM and importing sales orders with sales UOM line items, and then an updated package for 2021 R2 named BCPricesSaleUOMFix_21r2.zip.

So the first thing to check is your own version. If you are on 22R2 or later and still seeing base UOM prices on BigCommerce, you are not looking at this defect and you should stop applying its workarounds.

Check whether the wrong number is a UOM problem at all. If the storefront shows list price where a customer should see a negotiated price, that is a different and much more common issue: Acumatica’s community states that only the Default Price syncs to Shopify, not the effective sales price from a Sales Price Worksheet, and the equivalent path on BigCommerce runs through the Price List entity rather than the base sales price.

And check the direction of the error. A price that is exactly twelve times too high on a case of twelve is a UOM conversion running the wrong way. A price that is simply not the one you negotiated is a pricing entity question.

This observation comes from a thread spanning Acumatica 2021 R1 to 22R2 and was read on 20 August 2026. Acumatica ships two feature releases a year, so confirm the current behaviour on your own version before you plan work around it.