What exactly goes wrong with the unit of measure?
Acumatica holds a base unit for stocking and a sales unit for selling, with a Unit 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. between them. A case of 24 is 24 eaches in the warehouse and one case on the order. Older Commerce Connector builds published against the base unit, so the storefront got the each price and the each quantity for an item your customers buy by the case.
The report in Acumatica community thread 6697 is exactly that: “For some reason the pricing sync for Big Commerce when you have multiple units of measure enabled is to use the base unit and not the sales unit.” The Acumatica moderator’s explanation of why it is sticky is worth quoting, because it tells you something about how the sync decides what to send: “The Base unit of measure is not likely to change when compared with Sales unit of measure… changing the UOM in Stock Item will not be reflected to Sales Price because the last modified date of the Sales Price will not be updated.” In other words the price record does not look changed, so it does not re-export.
The availability half of the same problem is in thread 12444, where a user’s storefront showed 36 units available when the sales unit figure should have been six. Same root cause, different field, and the second one is arguably worse because it produces an oversell rather than a wrong price.
Checked against: Community 6697: BigCommerce sales price sync with wrong unit of measure, Community 12444: Shopify sales unit and base unit
Which Acumatica release fixed it, and is it actually fixed?
Two separate fixes, in the same era, for the two halves of the problem. For price and product sync, the moderator in thread 6697 supplied a customization package for 2021 R1 that exported prices for the sales UOM and created sales order lines in sales UOM, and stated the capability landed out of the box in 22R2: “you can use Sales UOM for product and sales price sync”. For availability, the moderator in thread 12444 said “this feature is done in 2022r2 version of Acumatica. In this version sales units will be used for the availability calculation”.
Here is the part you should carry into your own project. In February 2023 a second user replied on that thread saying “I have that version of Acumatica, but I don’t see a way to turn on that option. Do you have any documentation?” Nobody answered. A capability that exists and cannot be found is, for a project team on a deadline, not meaningfully different from a capability that does not exist.
So the honest position as of 20 August 2026 is this. Sales-unit price, product and availability sync exist from the 22R2 generation onward. Where the setting lives is not well documented in public, and we have not verified the configuration path on a current release. Ask your VAR to demonstrate it in your tenant rather than confirming it exists.
Checked against: Community 6697: 22R2 sales UOM support and the 2021 R1 customization, Community 12444: 2022 R2 sales-unit availability, and the unanswered request for documentation
How do you tell whether your store has this problem right now?
Five minutes, no admin access to Acumatica needed for the first step. If the ratio between the storefront number and the ERP number is your conversion factor, you have found it.
Pick an item where the sales unit is not the base unit and the conversion factor is large enough to be obvious, say a case of 24 rather than a pair of two.
Note the sales price per case in Acumatica and the quantity available in cases.
Look at the same item on the storefront. If the price is the case price divided by 24, or the quantity is the case quantity times 24, the sync is running on base units.
Check whether the storefront’s unit label says case or each. A right number with a wrong label is a separate and equally expensive problem.
Repeat for an item where a customer has a negotiated price, because price and UOM interact and the two problems together are hard to unpick after launch.
Checked against: Community 6697: base UOM used for the BigCommerce price sync
What does a UOM mistake cost, compared with the other sync problems?
More than most of them, because the number is plausible. A missing product is obviously missing. A price that is one twenty-fourth of the right price is a price somebody will pay, and an availability figure that is 24 times too high is a figure your warehouse will try to pick.
It is also the failure mode that most reliably reaches finance rather than IT. Orders come in at the wrong value, margin looks wrong, and the diagnosis arrives weeks after the cause. If you sell in more than one unit, prove the UOM path before you prove anything else.
A related question that is still open in the Acumatica community is using a unit other than the sales UOM for commerce orders, which is what you need if the web channel sells in a different unit from your other channels. We have not found a resolved answer to that, so if it describes you, treat it as a build item rather than a configuration item.
Checked against: Acumatica Retail and Commerce forum index (open thread on using a different UOM for commerce orders)
When is UOM not worth solving in the connector?
If only a handful of items sell in a non-base unit, the cheapest correct answer is often to restructure those items rather than the integration. Make the case the base unit and the each a separate item, or sell only the case online. That is a data decision your operations team can make in an afternoon, and it removes a permanent dependency on connector behaviour you do not control.
If most of the catalogue sells in multiple units, and your customers switch between each, case and pallet on the same item, the connector is not the right place to solve it at all. That is a product-model problem, and it usually wants a Middleware 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. layer or a front end that presents unit choice as a first-class part of the buying experience.
Common questions
- Why does my Acumatica case price show as an each price on BigCommerce?
- Because the price sync is running against the base unit of measure rather than the sales unit. This is documented in Acumatica community thread 6697, where the reported behaviour on older builds was that only base-UOM prices exported. Sales UOM support for product and sales price sync was stated as available out of the box from 22R2, with a customization package offered for 2021 R1 before that.
- Why did changing the UOM on the stock item not fix the price on the storefront?
- Because the price record did not change, so the connector did not consider it something to re-export. The Acumatica moderator in community thread 6697 explains it directly: changing the unit of measure on the stock item is not reflected to the sales price because the last modified date on the sales price is not updated. You have to touch the price records themselves, or clear and reprocess the entity, to force the export.
- Is sales-unit availability supported in Acumatica?
- Yes, from 2022 R2, according to the Acumatica moderator in community thread 12444, who wrote that in that version sales units will be used for the availability calculation. What is missing is public documentation of where the setting lives. A user on that exact version replied in February 2023 saying he could not find the option and asking for documentation, and the question was not answered in the thread.
- Can we sell online in a unit that is not the Acumatica sales UOM?
- There is an open question in the Acumatica community on exactly this and we have not found a resolved answer to it, so treat it as unverified. The general mechanism is that the storefront would present the web unit, and something in between would convert to the ERP sales unit on the order. That conversion is business logic neither system owns, which usually puts it in middleware or in a custom app.
- Should we just make the case the base unit?
- For a small number of items, often yes, and it is underrated. Restructuring a handful of items so the unit you sell online is the base unit removes the dependency on connector behaviour entirely, and it is a change your operations team can make without a development cycle. It is the wrong answer when unit flexibility is how your customers buy, because you would be flattening a real business capability to work around a sync.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.