Why does the price on our website not match the invoice?

Do this before you open a ticket. Take one customer, one item, and one order where the two numbers disagreed. Write down four figures: what the website showed, what the invoice charged, the item Default Price in your ERP, and the effective sales price your order desk would have quoted that day. The relationship between them tells you which cause you have, and it takes about ten minutes.

The reason this works is that each of the five causes distorts the price in a different arithmetic shape. A pricing-layer problem gives you a clean list price. A unit problem gives you a clean multiple. A tax problem gives you a small remainder that changes by ship-to province or state. Nothing else looks like those.

Read the table with your four numbers in front of you. Where two rows both fit, you have two problems, which happens more often than people expect on a first launch.

These two causes are both pricing-layer problems and they are the ones that do not announce themselves. Nothing errors. The item syncs, the order syncs, the number is simply wrong, and you find out when a customer who has bought at a negotiated price for four years sees list price and phones his rep.

The first is the Default Price limit. Asked directly whether the current effective sales price from the ARSalesPrice table could sync to Shopify instead of the Default Price, Acumatica’s own community answered “No. Only Default Price is supported.” Anything you set with a Sales Price Worksheet therefore lives in a table the connector does not read. Per-customer prices can still reach Shopify B2B as catalogues through the Price List entity, which is the path most teams end up on, and that is a different mechanism with different limits.

The second is the price class gap, and it is easy to mistake for the first. On the BigCommerce side, an Acumatica community answer from 2021 R2 states that the Customer Price Class entity “will update groups of customers in BigCommerce store (Customers>Customer Groups), but not the prices”, and that to move prices you prepare and process the Price List entity separately. So a customer can be sitting in the correct group on the storefront with none of that group’s prices behind them. The customer record looks right, which is exactly why nobody checks it.

If either of these is your cause, the fix is an architecture decision rather than a setting. The four options, and what each costs, are worked through on the Acumatica pricing reality check and on the contract pricing mechanic page.

A unit of measureUnit 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. mismatch is the cause that produces the most alarming numbers, because it is usually wrong by a whole packaging factor rather than by a discount. An each price on a case product looks like a catastrophic mispricing to a buyer and like a data entry error to everyone else.

The mechanism is that a stock item carries a base unit, which is how you hold and cost it, and a sales unit, which is how you sell it. Acumatica community threads record both halves of this going wrong on the connector: a sales price syncing against the wrong unit on BigCommerce, and a Shopify sync setting items on the store to the base unit rather than the sales unit. Those observations come from different releases, so check your own store rather than assuming your version behaves the same way.

The test is quick. Pick five items where the base unit and the sales unit differ, and five where they are the same. If the mismatch only appears on the first five, you have found it. If it appears on both sets, unit of measure is not your cause and you should go back to the table above.

One thing worth saying plainly: a unit problem is worse than a pricing-layer problem, because a pricing-layer problem quotes a price you would have accepted and a unit problem can quote one twelfth of it. If your first mismatch report is a unit problem, treat it as an incident rather than a backlog item.

A stale price is the cause people assume last and should check first, because it is free to rule out. Acumatica moves price lists when you prepare and process the Price List entity, manually or on an automation schedule, and the community answer describing that pattern says it is usually run overnight. So the question is not whether your connector supports your pricing, it is when your job last ran and whether it succeeded. One well-known failure, “Sync ID is not found for the record”, stops a whole price list when any single stock item on it has not already synced to the store, which means one deactivated item can freeze pricing for every item beside it.

Tax is the other cheap one to rule out. If the unit prices agree and only the totals disagree, stop looking at pricing. Acumatica recalculates the tax on imported orders by default, which means the amount your storefront charged and the amount your invoice shows can differ even when every price is correct. There is a documented way to stop that recalculation and it has consequences of its own. Separately, Shopify and Acumatica have been reported to disagree by a few cents on AvaTax through rounding, which produces a difference too small to be a pricing fault and too persistent to ignore.

Distinguishing these two takes one query. Sort your mismatched orders by date. Staleness clusters around a date, because it starts when a job failed or a price changed. Tax spreads evenly across dates and clusters by ship-to jurisdiction instead. If your mismatches cluster by geography, you have a tax problem and this page has done its job.

Order these by cost, not by how annoying the symptom is. Two of the five are configuration and can be done this week by the person who already administers your ERP. Two are data work. One is an architecture decision that belongs in a project rather than in a ticket, and pretending otherwise is how a price problem turns into a six-month argument.

This happens often enough to check before you rebuild anything, and it is the case nobody looks for because the website is the new system and the new system is assumed to be the guilty one.

Three things put a number on an invoice that the website never quoted. A rep applied a manual discount or a price override at order entry, which is invisible on the storefront and entirely legitimate. A freight, handling or small-order surcharge landed as an invoice line, so the unit prices agree and the totals do not. Or the order was invoiced against a different effective date than the day it was placed, which matters when a price change fell between the order and the shipment.

The test is to compare the sales order in the ERP with the invoice, rather than comparing the website with the invoice. If the sales order agrees with the website and the invoice disagrees with the sales order, your integration is fine and your order-to-invoice process is the thing to look at. That is a different department and a much cheaper fix.

Write the effective-date rule down whichever way it turns out. A distributor that reprices between order and shipment and has never said so in writing will have this argument with a customer eventually, and the answer should not be improvised on the phone.