There is a moment in a lot of distribution businesses where somebody adds a step. A produce distributor starts portioning and packing. A chemical distributor starts blending to customer spec instead of reselling drums. A building products distributor buys a saw and starts cutting to length. Nobody calls it manufacturing at the time. It is a service the customers asked for, and it starts on one line, in one corner of the building.
The software problem arrives later, and it arrives in a specific order. Knowing that order is useful, because the thing that finally forces a system change is usually the fourth symptom, and by then the first three have been quietly absorbed by people working around them.
First: costing stops being true
A distribution ERP knows what a thing cost because it bought it. There is a purchase order, a receipt, and a landed cost, and the margin on a sale is a subtraction. That model holds perfectly right up until the moment you sell something you did not buy.
When you transform material, the cost of the output is not on any purchase order. It is the sum of the inputs consumed, plus labor, plus whatever was scrapped or lost to yield, and none of those are things a distribution system is built to capture. So the cost gets estimated. Somebody builds a spreadsheet with a standard recipe cost, and it is roughly right for a while, and it stays in place long after the input prices have moved.
This is the first thing to break and it is almost always the last thing to be noticed, because a wrong cost does not throw an error. It just quietly misprices the value-added product — usually the highest margin thing in the catalogue, and the entire reason for adding the step.
Second: inventory develops a third version
Distribution inventory has two versions on a bad day: what the system says and what is on the floor. Production adds a third — material that has been consumed on the line but not yet recorded anywhere, because the transaction that would record it does not exist in the system.
The workaround is a periodic adjustment. Somebody counts, somebody posts a variance, and the number becomes true again for a while. It works, in the sense that the balance sheet closes. What it destroys is the ability to answer a question in real time: what is available to promise right now. That answer now depends on how long ago the last adjustment ran.
Third: traceability gets a hole in the middle
This is the one that turns from an annoyance into a risk. Traceability is a chain of lots, and a transformation is the link where one set of lots becomes another. If production happens outside the system of record, that link is a manual entry — a batch sheet, a log, a tab in a workbook.
Nothing goes wrong with this until you need it under time pressure. A recall, a customer complaint, a heat number query on a fabricated part, an FSMA 204 request with a 24-hour clock. Then the trace runs cleanly up to the transformation, stops, gets picked up by a person with a folder, and continues on the other side. It is not that it cannot be done. It is that the time it takes is unbounded, and the accuracy depends on the discipline of whoever was on shift.
Fourth: scheduling leaves the building
By now production has grown enough to need sequencing, and the ERP has nothing to sequence with. So the schedule moves to a whiteboard, or to a planner who holds it in their head, or to a standalone scheduling tool. This is the point where most companies conclude they need a second system — and they are right, in the sense that they do need the capability. They are usually wrong about what to buy.
The instinct is to buy an MES and integrate it. That solves scheduling and shop floor reporting, and it reintroduces every one of the first three problems as an integration concern instead of a missing-feature concern. The costing still has to be reconciled. Inventory still has two owners. The traceability chain still has a seam in it — the seam has just moved from a spreadsheet to an interface.
What actually fixes it
The observation underneath all four symptoms is the same: a transformation is a transaction, and it needs to live where the other transactions live. When the work order draws from the same inventory the warehouse picks from, consumes lots that carry their own traceability, and posts material and labor to the same ledger, none of the four problems can occur. Not because they are solved, but because the conditions that create them are gone.
That is a different purchase from an MES. It is the argument for production and distribution on one data layer rather than two systems kept in agreement — and it is worth making the decision at symptom one, when it is a costing question, rather than at symptom four, when it has become an integration project.
A test worth running
If you want to know where you are on this list, ask what a specific run of your value-added product cost — not the standard, the actual — and how long it takes to find out. If the answer is "at month-end" you are at symptom one. If it is "let me check with production" you are further along than you think.