A restaurant group in Riyadh sends its weekly poultry order to a chilled-food distributor by WhatsApp: twenty cases of whole chickens for Thursday. The sales coordinator keys it into the ERP as kilograms, multiplying by a per-case weight remembered from the last price list. The warehouse picks twenty cases, weighs them at dispatch and the invoice is raised on what the scale said. The buyer's purchasing officer compares it with the figure the coordinator quoted on the phone, finds a different number, and holds the payment until someone explains it. Nobody made a mistake. The order was taken in one unit, priced in another, and the gap between them was never written down anywhere the buyer could see.
A case is what the buyer orders. A kilo is what the buyer pays for.
Most SKUs a distributor sells are fixed weight. A carton of 24 cans weighs what it weighs, and the price per case is the price per case. Catch-weight SKUs are different: whole birds, primal cuts of lamb and beef, whole fish, wheels of cheese. Each case holds a known count of pieces, but no two cases weigh the same, because no two birds or cuts do. The buyer orders by the case because that is what a kitchen or a butcher counter can plan around. The supplier prices by the kilogram because that is the only fair way to price a product whose weight varies.
Manual ordering handles this by collapsing the two units into one, usually in the coordinator's head. The order is converted to an assumed weight, the assumed weight is priced, and the buyer is quoted a total. When the delivered weight differs, as it always does, the invoice differs from the quote, and the buyer has nothing to check the difference against. In Saudi food distribution, where HoReCa and Modern Trade buyers reconcile every delivery against what they were told, that unexplained difference is where a payment stalls.
Three fields, not one.
The structural fix is to stop treating catch-weight as a single field with alternative values and record three distinct things on the SKU. The ordering unit is countable: the case or the piece. MOQ, order multiples and cart validation all key on it. The pricing unit is weight, the kilogram, and the price and the invoice key on it. The nominal weight is the expected weight per ordering unit, and it produces two things: the estimate the buyer sees at checkout, and the tolerance band the delivery is measured against.
Keeping MOQ in the ordering unit is not a formatting preference. A buyer cannot deterministically satisfy a weight minimum on a variable-weight item. An MOQ of 100 kg on whole chickens leaves the buyer guessing how many cases will clear it, and finding out at the scale. An MOQ of 2 cases is something the cart can enforce before submission and the buyer can satisfy exactly.
Whether a SKU is catch-weight is also a property of the SKU, not of its category. A 1 kg tray of chicken breast is fixed weight. A whole bird is not. The flag is set per SKU, sourced from the ERP and locked where the ERP carries it, so the ordering layer never guesses from a category name.
The buyer orders what they can count. The invoice charges for what was weighed. Both are correct, as long as nobody pretends they are the same number.
The checkout figure is an estimate, and it says so.
Once the three fields exist, the checkout can be honest about what it knows. The rate per kilogram is resolved at checkout through the same pricing layers as any other SKU: base price list, contract override, volume tier break and any promotional or manual override. That rate is the rate applied on the invoice, and no pricing rule changes between the two. What the checkout cannot know is the weight that will leave the warehouse.
So the line total for a catch-weight SKU is labelled as an estimate at line level, and the order total carries the same marker: a single figure, such as "SAR 4,070 · estimated, invoiced on delivered weight". It is one labelled number, not a range. A range invites the buyer to budget on the low end and dispute anything above it. A labelled estimate tells the buyer exactly which part of the figure is fixed, the rate, and which part will move, the weight.
Tolerance decides what the invoice does with the variance.
Take the Riyadh order as a worked example. The SKU is a case of ten whole chilled chickens, with a nominal weight of 11 kg per case and a contract rate of SAR 18.50 per kilogram. Twenty cases give a nominal 220 kg and a checkout estimate of SAR 4,070. The supplier has configured a tolerance of 5% either side for this SKU, so any delivered weight between 209 kg and 231 kg is within the band. These figures are illustrative, set for this example only.
The twenty cases leave the warehouse at 214.6 kg. That is within tolerance, so the invoice is raised on actual weight at the quoted rate, SAR 3,970.10, with no exception raised. If the cases had weighed 205 kg, below the band, the line would follow the short-delivery flow: the buyer sees the adjustment with its reason before the invoice is raised, exactly as for a short pick. If they had weighed 236 kg, above the band, the invoice would be capped at the tolerance ceiling of 231 kg and the line flagged, because a buyer is never invoiced for more than they could reasonably have anticipated.
Within tolerance, the invoice follows delivered weight with no exception. Below it, the short-delivery flow applies. Above it, invoicing is capped at the tolerance ceiling and the line is flagged.
Why catch-weight belongs in the ordering infrastructure.
Back at the Riyadh distributor, the purchasing officer now sees twenty cases in the cart, an MOQ stated in cases, a rate per kilogram and an estimated total that says it is an estimate. When the invoice arrives at SAR 3,970.10, the difference from the estimate is the weight, at the rate they were shown, inside a band they could have calculated themselves. There is nothing to hold the payment over, so there are fewer disputes, and none of the conversion lives in a coordinator's memory.
The point is not that the total stays fixed. It cannot, and claiming otherwise is how catch-weight disputes start. The point is that the rate holds, the weight is measured against a stated tolerance, and every movement in the total reaches the buyer with its reason before the invoice is raised. Emdaad records the ordering unit, the pricing unit and the nominal weight as separate fields on each catch-weight SKU, so MOQ stays enforceable at the cart and the invoice follows the scale.