Operations that try to run refurbishment on a standard ERP rarely fail loudly. They succeed at purchasing, accounting and invoicing, then accumulate spreadsheets around the edges for everything the system will not hold: the device that arrived in an unknown state, the part harvested from another unit, the grade, the erasure certificate. Within a year the ERP describes the business and the spreadsheets describe the operation. The reason is structural, and it is worth naming precisely.
The assumption underneath every business suite
Enterprise systems were built around manufacturing and distribution, and they inherit that shape. You purchase known items in known quantities, you consume them according to a known recipe, you produce known products, you sell them. Planning, costing and inventory all rest on that sequence being knowable in advance.
The ISA-95 model, which most industrial software still follows implicitly, puts business planning at the top and shop-floor execution below it. Information flows down as orders and back up as confirmations. It is a good model for a factory.
A repair operation inverts almost every step. Equipment arrives before anyone knows what it is. What can be done with it is discovered, not planned. And the output is not one product but a distribution of outcomes: some devices resold, some dismantled into parts, some sent to recycling, each with a different value and a different regulatory status.
Assumption 1: stock is fungible
Standard inventory is built around the SKU. Forty units of the same reference are interchangeable; the system tracks a quantity, and any one of them satisfies an order.
In refurbishment they are not interchangeable. Two laptops of the same model have different ages, different repair histories, different grades and different erasure evidence. The unit of inventory is the device, not the reference, and everything that matters commercially is attached to the individual unit.
Serial tracking exists in most systems as an option, which is the tell: it is treated as an extra attribute on a quantity rather than as the primary identity of the item. Once grading, repair history and a certificate have to hang off that identity, the option is carrying the whole operation.
Assumption 2: you know what you received
Purchasing assumes a purchase order that the delivery is checked against. Goods-in confirms that what arrived matches what was ordered, and a discrepancy is an exception.
A pallet of end-of-life equipment has no such reference. The declared contents and the actual contents diverge routinely, and not because anyone is being dishonest: condition is hard to assess at the point of collection. The pallet has to be received first and characterised afterwards.
That inverts the sequence the system expects. Triage becomes a production step in its own right - one that consumes labour, produces data and has to be costed - rather than a check at the door. Systems that model intake as verification have nowhere to put it.
Assumption 3: the bill of materials runs forwards
A bill of materials is a recipe: consume these components, produce this product. It drives purchasing, costing and planning, and it is known before work begins.
Repair reads it backwards twice over. First for compatibility: the question is not what to consume but which part fits this specific unit, across model variants, revisions and production years where the same visual part is not always the same part. Then for dismantling: one device is consumed and several usable parts are produced.
Those harvested parts have no purchase price, came from a specific serial number, and exist because someone decided to dismantle rather than repair. A forward-only structure has no place for stock that appears as a by-product of a production decision, which is why harvested parts so often end up in a spreadsheet next to the system rather than inside it.
Assumption 4: compliance is reporting
In a standard suite, regulatory obligations are met by extracting data at period end. The operational record is separate from the compliance artefact.
In refurbishment the artefact is generated by the operation itself, device by device, at the moment the work happens. The erasure certificate belongs to a serial number. The reuse-versus-recycling distinction that WEEE reporting depends on is decided on the floor, per device. The repair history that the Digital Product Passport will eventually require is created at the bench.
Retrofitting this is what hurts. An operation that tracked by lot for three years cannot reconstruct per-device history afterwards; the information was never captured. This is the one assumption where the cost of getting it wrong is not inefficiency but a gap that cannot be closed retroactively.
What a business layer has to add
None of this argues against building on a standard foundation. Purchasing, accounting, HR and e-commerce are solved problems, and rebuilding them to get a device record is a poor trade.
What has to be added sits above that foundation: intake by lot with characterisation as a production step, a device record that carries identity, grade, erasure evidence and repair history, dismantling that produces valued stock, and cost and recovered value attributable per serial number.
The test of whether a system genuinely supports refurbishment is narrow and easy to apply. Pick one device at random. Can the system tell you where it came from, what state it arrived in, what was done to it, what it consumed in parts and labour, what it sold for, and where the evidence is - without anyone opening a spreadsheet. Most systems answer four of those six.