The minimum order value no system knows about

Almost every distributor has a minimum order value. Very few have it in the system that actually creates the order. It sits in a price list or in the footer of a quotation, which worked fine for as long as a person typed every order into the ERP by hand.

The rule fired, four steps too late

A distributor of medical and practice supplies works with a 75 euro minimum and a 15 euro small order charge below it. The rule is older than most of the staff and appears on every price list they send out.

Then came the web shop and two EDI connections. Around sixty percent of orders now reach the ERP without anyone reading them.

A hospital ward orders two items worth 38 euros. The order is created, acknowledged, picked and shipped. The small order charge is applied during the invoice run, by a rule that sits in the ERP and executes at that point rather than earlier. The invoice says 53 euros.

The hospital matches invoices against order acknowledgements. The acknowledgement says 38. The invoice is rejected, the case goes into a dispute queue, and it consumes more handling time on both sides than the charge brings in.

Nothing about the rule was wrong. It ran at the wrong moment, and by then the customer was holding a document with a different number on it.

Three thresholds sharing one field

Master data usually holds several thresholds next to each other, and conversations mix them up freely.

A minimum order value is an amount per order. A minimum order quantity is a number of units per item, and it usually belongs to your supplier rather than to you. A free freight threshold decides who pays for shipping.

We regularly find automations that test one of these numbers and trigger the consequence of another. An order for 180 euros gets held back when the only thing at stake was the freight cost. An order for 40 euros passes because the field being tested happens to hold the freight threshold.

Minimum order quantity is also a different thing from pack size. Pack size defines the increments you can order in. Minimum order quantity defines where those increments start.

The purchasing side has the mirror image

A reorder proposal built from reorder point and coverage calculates a quantity and sends it to the supplier. Whether the supplier will accept that quantity is not something the proposal can know, because the supplier's minimum lives in the supplier's price list.

Suppliers handle the mismatch in different ways, and each one leaves a different mess behind. Some round up quietly and ship 12 where you asked for 3, which breaks the goods receipt match and stalls invoice verification. With others the line just gets dropped, so the stock never arrives while the ERP still shows an open purchase order, and the reorder logic sees no reason to try again. The friendlier suppliers ship the 3 and add a small order charge of their own that nobody budgeted for.

The quiet round-up is the expensive one, because it never surfaces as an error. Stock goes up, coverage stretches, and the next reorder proposal for that item arrives months later than planned.

Net, gross, before or after discount

The number written into the agreement is unambiguous. The value it gets compared against rarely is.

It might mean line totals before customer discount or after it, with or without freight and surcharges, with or without VAT. A customer on a 22 percent contract discount clears 75 euros on list prices and falls short on net. Either reading is defensible. What matters is that the contract, the shop and the workflow use the same one, and in most of the setups we look at they do not.

Per order, per shipment, per ship-to

Minimums are written against an order. Shipments split.

An order for 120 euros becomes an 80 euro partial delivery and a 40 euro backorder. If the charge is applied per shipment during invoicing, the customer pays a penalty on an order that met the threshold. One order going to three wards in the same hospital produces the same outcome by a different route.

Which unit the threshold applies to is a commercial decision. It needs an answer before somebody writes the condition into a workflow, because the workflow will otherwise answer it by accident and nobody will notice for a year.

Check at intake, not at invoicing

The check belongs at order intake, before the acknowledgement goes out. Anything later means correcting a document the customer already has.

What happens after the check depends on the channel. In a shop you can show the threshold and the amount still missing before the order button. Some customers add an item, and that is the only version of this rule that produces revenue instead of friction.

For EDI and mail orders, accept the order and put the charge on the acknowledgement as its own line. The customer sees the number while the goods are still in the warehouse.

Customers with a negotiated exemption need a flag on the master record with a valid-from date. An exemption that exists only in an email from a field rep does not exist as far as any automation is concerned.

Rejecting orders automatically is the weakest option available. A customer whose order goes unanswered picks up the phone, and that call costs more than the charge was worth.

What your own data will tell you

Pull the last three months of orders and count how many fell below your threshold. A rule that works produces a handful. Ten percent means the rule exists on paper and nowhere else.

For those orders, compare the acknowledged value against the invoiced amount. Every gap is a potential dispute sitting in your customer's accounts payable.

Then look at the purchasing side of your item master and count how many items carry the supplier's minimum order quantity. If most of them hold a zero, your reorder proposals are sending out quantities suppliers will not accept, and somebody is correcting that by hand every week.