Pack size is the field nobody maps
Integrations move quantities as bare numbers. What those numbers count stays behind in the source system, and the mismatch only ever hits the products you sell by the case. Where it surfaces, why a test run misses it, and the four numbers worth comparing.
The shop said 300 in stock. The warehouse had 3,600.
A drinks distributor we worked with last year listed a mineral water as low stock for most of a quarter. The webshop showed 300 available. The warehouse had 300 cases of twelve, so 3,600 bottles, about a pallet and a half sitting there while the product page pushed customers toward a substitute.
The nightly sync had been reading case counts out of the warehouse system and writing them into a shop field that counts bottles. Nobody spotted it, because 300 is a reasonable number for that product and the run finished green every night.
Nobody complains about a shop that undersells. That is what made it a quarter long problem instead of a two day one.
Interfaces carry numbers, not measurements
The field is called quantity and it holds 5. What the 5 counts lives somewhere else entirely: in the product master of the source system, in a column that never made it into the mapping because the target had no obvious place to put it.
Some APIs do send the unit, in a field called unit or uom. It still gets dropped, because the target system has a required field for quantity and no required field for unit. Anything optional disappears during the first mapping session and does not come back.
Then there is direction. One system treats the single item as the base unit and the case as a multiple of it. The other does the reverse. Whether the factor of twelve multiplies or divides is not something the API tells you. It is a decision somebody made in product master data on each side, possibly years apart.
The invoice is where it usually surfaces
Quantity errors get caught by a warehouse. Price errors do not.
A wholesaler in medical supplies had a portal that sells by the case and an ERP that prices by the unit. Whoever built the connection thought about the difference once: the quantity gets multiplied, five cases becomes 500 units. The price passed through untouched, because it sits in a field called price on one side and a field called unit price on the other, and in a mapping screen those look identical.
The warehouse picked five cases, which was right. The invoice charged 500 at the case price. Forty seven pounds of gloves billed at four thousand seven hundred.
Both numbers on that invoice are valid for that product. Only the combination is wrong, and no required field validates a combination.
Why the test run passed
About eighty percent of that wholesaler's catalogue had a pack size of one. When the factor is one, every possible mapping produces the correct answer. Case and unit are the same thing, case price and unit price are the same number, and the integration looks finished.
The products with a real pack size are the minority, and they are usually not the ones somebody picks for a demo order. Three test orders, three products with pack size one, three correct results, sign off.
Weight and volume behave the same way. Kilograms against grams in a shipping module, litres against millilitres in a dangerous goods check. A parcel declared at 12,000 kg gets rejected by the carrier, which at least makes the error loud. The same mistake in the other direction prints a label for a 0.012 kg parcel and ships it.
What we specify on these integrations
The unit travels with the number. Every quantity field in a workflow gets a second field next to it, whether or not the target asks for one. It costs nothing and it puts the answer in every execution log, which is where you will be looking when somebody queries an invoice.
Conversion happens once, at the point of entry, and never again downstream. The medical supplies case went wrong specifically because the conversion existed in two places in the scenario and only one of them was ever updated.
The factor comes from master data, not from the workflow. Hardcode it and nobody touches it when a supplier moves from cases of 100 to cases of 90. The delivery then arrives at the new pack size and the invoice reflects the old one.
And there is a ceiling per line. Anything above 2,000 pounds in value or 1,000 units in quantity goes to a person for release rather than straight to invoicing. That catches unit errors, and it catches the customer who typed an extra zero into the portal.
Four numbers worth comparing
Pick three products with a pack size greater than one and order a single pack of each through your own channel.
Then compare the quantity on the order, the quantity on the delivery note, the unit price on the invoice, and the stock movement in the warehouse system.
If one of those four disagrees with the others, it has disagreed since the day the integration went live.