Your order automation captures how many, but not of what
An order line needs three fields and most automations write two. The pack size conversion your ERP applies by default is a decision nobody made deliberately, and it stays invisible until a customer receives twenty-four times what they wanted.
This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.
Two fields where there should be three
An order line carries three pieces of information: which item, how many, and how many of what. Most order automation captures the first two and leaves the third to whatever default sits in the item master.
That default is usually right, which is what makes it dangerous. It is right for every customer who orders the way it assumes, and it stays right long enough that nobody is watching by the time one of them orders in a different pack size.
Ten packs ordered, 240 shipped
A distributor supplying clinics and care homes takes orders through a portal, by email as PDFs, and over an interface for its two largest accounts. A care home orders ten packs of gloves. The item is stocked in singles and sold by the outer carton, twenty-four packs to a carton. The workflow writes ten into the quantity field. The pick list says ten cartons.
No step failed. Every one returned success, the confirmation went out, and 240 packs left the warehouse. The receiving end signed for the pallet, because nobody on a loading dock knows what was ordered. It surfaced in invoice matching three weeks later.
Over-shipping is the version everyone tells stories about, and it is the cheaper one. A credit note, a collection, an awkward call. Under-shipping is the expensive version: someone divides where they should have multiplied, ten cartons become ten packs, and it shows up on a Friday afternoon when a ward runs out. That gets solved with an emergency delivery, and nobody ever traces the emergency delivery back to the order line that caused it.
Conversion factors belong to the manufacturer, not to you
Once someone notices this, the usual fix is a lookup table in the workflow: item number, factor, done. It works. It also decays.
Twenty-four to a carton becomes twenty when palletisation changes. The item number stays the same, stock stays correct, and the only thing pointing at a number that no longer exists is your table.
Bring in a second supplier for the same item and you get a different case size. Your ERP holds that on the supplier relationship, where it belongs. Your workflow holds it in a column somebody filled in eighteen months ago and has not opened since.
Customers also order in different units. The hospital takes the carton, the small practice takes the single pack, same item, same portal. One factor per item cannot express that.
Hospitals convert four times before anyone sees a number
Demand starts on a ward and gets thought about in pieces: two hundred cannulas this month. Purchasing orders in packs. The supplier ships pallets. Central stores receives, breaks the pallet down, issues to the ward and posts consumption against a cost centre in pieces again.
Every one of those hand-offs is a conversion. With a person sitting at any of them, an absurd number gets caught. Chain ordering, goods receipt and consumption posting together and a factor of twenty-four travels all the way into a consumption report, which is not a document anyone reads carefully.
What we build instead
Put the unit on the line. Three fields, not two. In a portal that is a dropdown next to the quantity box. In an EDI or API payload the field is already in the schema and simply left empty. That alone removes most of this.
Do the conversion in the ERP. The factor lives there already, maintained by the people who maintain everything else about the item. Any copy of it elsewhere is a second version of the truth that will eventually disagree with the first.
For PDF and email orders, set a ceiling. If a line resolves to more than five times what this customer has taken of this item in the last twelve months, hold it for review. Small piece of logic, and it catches mistyped quantities too.
Then show the arithmetic on the confirmation: ten cartons of 24, 240 packs in total. Customers fix that the same day. They do not fix an invoice three weeks later, they dispute it.
How to check yours
Open the step that writes the line into your ERP and look at the unit field. Hard-coded, or empty, means the item master default is deciding your shipping quantities for you.
Then pull six months of credit notes and look for quantities that are a clean multiple of what was ordered. Twelve, twenty, twenty-four and a hundred turn up more often than chance would explain.
In most of the setups we review this is not a rebuild. One field needs carrying through three places, and one threshold needs a name against it.