Every fastener distributor knows what /M and /C mean. Almost no software does, and the gap between those two facts is where a specific, expensive category of order error lives.
This article is about one line on one purchase order, and why it is harder than it looks.
The convention
The notation is Roman: C is one hundred, M is one thousand. A price expressed as $42.50/C is forty-two dollars fifty per hundred pieces. A quantity expressed as 5M is five thousand pieces. Both appear on purchase orders without explanation, because within the industry none is needed.
The quantity basis and the pricing basis are specified independently, and they frequently differ on the same row. A line can be quantified in thousands and priced per hundred, which is entirely normal and looks like a data-entry mistake to anything expecting one consistent unit.
| As written on the PO | What it means | Extended value |
|---|---|---|
| 5M @ $42.50/C | 5,000 pieces, priced per hundred | 50 × $42.50 = $2,125.00 |
| 5 M @ $42.50/M | 5,000 pieces, priced per thousand | 5 × $42.50 = $212.50 |
| 5 EA @ $42.50 | 5 pieces, priced each | $212.50 |
The second and third rows extend to the same money and differ by a factor of a thousand in pieces. A plausibility check on order value will not catch it.
Why general-purpose extraction gets it wrong
A model trained broadly on business documents has seen M mean million far more often than it has seen it mean thousand, because outside this industry that is what it usually means. Revenue of $5M is five million dollars. A fastener line reading 5M is five thousand pieces. Both are in the training data and the general case is more common.
There is a second, subtler failure. Some unit conversions are not merely unknown, they are impossible without item-level data. Feet is a length; each is a count. Converting between them requires knowing the length per piece for that specific SKU. A system that returns a number anyway has not converted anything — it has invented a quantity.
The check that separates safe products from confident ones
Ask a vendor what their system does with a line reading 200 FT of an item your catalog holds in eaches. The correct answer is that it stops and asks. Any answer that produces a quantity is describing a guess.
Why the error survives review
A CSR checking a re-keyed order is checking against the source document at speed. A quantity of 5,000 on a screen next to a document reading 5M is correct, and a quantity of 5 next to the same line is also, at a glance, unremarkable. Both look like a number that came from the document, because both did.
The error surfaces at picking, when someone finds five pieces on a pallet ticket for a job that needs five thousand, or at delivery, when a customer receives a hundred times what they wanted and an invoice to match.
What correct handling looks like
- Read the quantity basis and the pricing basis as separate values, because they are.
- Resolve both against the specific SKU's item-master record, not against a general rule — pack quantity varies per item.
- Show the conversion arithmetic on screen next to the line, so a reviewer can check the reasoning rather than only the result.
- Block the line when a unit is unrecognised or the conversion is dimensionally impossible. Do not default to each.
- Keep the customer's original text visible beside the interpretation, so the reviewer is checking a translation rather than trusting one.
The fourth step is the one that costs a vendor their touchless-rate headline, which is precisely why most products do not do it. A system that blocks on unresolvable units reports a lower automation percentage than one that assumes. It is also the one that does not ship five pieces against an order for five thousand.
The short version
- C is per hundred, M is per thousand, and both are Roman numerals rather than metric abbreviations.
- Quantity basis and pricing basis are independent and often differ on the same line.
- Pack quantity lives on the item record, so no general conversion rule exists.
- Some conversions are dimensionally impossible and the only correct output is a question.
- A high touchless rate achieved by defaulting units is worse than a lower one achieved by stopping.
More articles
- What Manual Order Entry Actually Costs Your DeskEvery vendor quotes a cost-per-order benchmark and almost none of them source it. Here is the arithmetic to work out your own number in about ten minutes, using figures you already have.
- Nine Controls That Actually Reduce Order Entry ErrorsPractical controls for a distributor's order desk, most of which need no new software. Ordered by how much they reduce risk per unit of effort.