A bad ERP rarely announces itself. It goes live, invoices go out, and the cost settles where it is less visible: minutes per device, parts bought twice, grades that never reached the price list, two days spent assembling a client report. In a refurbishment or ITAD operation those costs are specific, and most of them can be estimated. Here is where they sit, with illustrative numbers you can replace with your own.
The usual ways an ERP project goes wrong
The generic failure modes come first, and they still explain most disappointing ERP projects in any sector.
Over-customisation. Every gap filled with custom development works on delivery day and costs money at every upgrade after it, until the system is frozen on an old version that nobody wants to pay to migrate.
An integrator who does not know the trade. Each refurbishment concept is mapped to the nearest standard object: the device becomes a serial-number option on a product, the grade a product variant, the harvested part a manual stock adjustment. Each choice is defensible on its own. Together they give a system that holds the data and cannot answer a question about it, which is the data-model problem in its structural form.
Adoption failure, then the spreadsheets grow back. If recording a test result takes six screens, it gets recorded from memory at the end of the shift, or not at all. The ERP keeps invoicing and accounting, and the operation runs in files next to it, the same files the project was meant to retire, failing in the order described here.
How to read the numbers below
Each area below comes with a worked example. Every figure in those examples is an illustrative assumption, not an industry benchmark or a measured result: round numbers chosen so the arithmetic is easy to follow. The reference workshop processes 1,000 devices a month at a loaded labour cost of €20 an hour. Replace all of it with your own volumes, times and prices before drawing any conclusion.
A disclosure as well: REAV sells a refurbishment ERP, the REAV ERP, and the lines on what a purpose-built system does describe the approach we took.
1. Serial-number traceability
A generic ERP can record a serial number without making it the record everything else attaches to. Intake is booked by lot, the test result lives in the test tool, the repair in a spreadsheet, the sale on the marketplace. When a client asks where one asset went, or an auditor samples ten serials, each answer is a small investigation, and where the trail breaks, the chain of custody breaks with it: you cannot prove what happened to that one device.
Worked example. Assume ten such questions a week at 15 minutes each: 150 minutes a week, so 10 hours over a four-week month, or €200. The hours are the small part. The audit sample where the trail stops cannot be priced in advance.
Built for refurbishment, the system assigns one identifier at intake, links the client from day zero, captures the IMEI where there is one, and has every later stage write to that record. The question becomes a lookup. See traceability in the REAV ERP.
2. No connection to the erasure software
Erasure tools such as Blancco issue a result and a report for each drive or device. With nowhere for them to land, someone retypes the result or ticks an "erased" box, and the certificate goes into a folder named by date. A mistyped serial attaches a certificate to the wrong device, or to none. The erasure certificate a client asks for eight months later has to be found by hand. And a drive that failed and went to physical destruction leaves a gap instead of a documented outcome. For an ITAD provider, that gap is the liability the client paid to transfer.
Worked example. Assume 2 minutes per device to retype the result and file the certificate: 2,000 minutes a month, about 33 hours, so roughly €670 a month or €8,000 a year spent copying data that already exists digitally. If one entry in 200 is mistyped, that is five devices a month whose record contradicts their certificate.
Built for refurbishment, test and erasure results fill the device record automatically, the certificate is filed against the serial and exports in one click, and drives that fail are routed to physical destruction and recorded as such. See the Blancco integration.
3. Spare parts and dismantling
Dismantling runs the bill of materials backwards: one device in, several usable parts out, none with a purchase price. Without a reverse BOM, harvested parts are booked at zero value or not at all, and end up in a drawer only one technician knows about. Parts already on a shelf get bought again, and repairs look cheaper than they were, so the next repair-or-dismantle decision is a guess.
Worked example. Assume 50 devices dismantled a month at three usable parts each: 150 parts. If one in five is not found when needed and an equivalent is bought at €20, that is 30 parts and €600 a month, €7,200 a year, for parts the operation already owned.
Built for refurbishment, the system holds a reverse BOM per model, revalues harvested parts into sellable stock as they come out, and costs parts and labour per device. See spare parts and dismantling.
4. Valuation by grading
The grade sets the price, and it changes during processing: a screen replaced, a battery swapped. Stored as a product variant or a text field nothing downstream reads, it reaches the listing by hand, sometimes out of date. Grading not updated after repair gives value away silently; grading wrong the other way produces returns and wears down the marketplace seller rating.
Worked example. Assume a €30 gap between adjacent grades. If 5% of the 1,000 devices leave one grade below their real condition, that is 50 devices and €1,500 a month given away. If 2% leave one grade above, that is 20 returns; at an assumed €25 each for shipping, handling and re-test, another €500 a month.
Built for refurbishment, the grade lives on the device record, changes with the device, and the sales channel reads it there. In the REAV ERP, listings and stock are driven per channel from that record, with Back Market already connected in production.
5. Margin per device
Generic setups report margin per month, per invoice, at best per purchase lot. A lot mixes devices that earn well, devices that break even and devices that cost more in parts and labour than they will ever sell for, and the average hides all three.
Worked example. A lot of 200 laptops shows €4,000 of gross margin, €20 a device. Inside it, assume 160 devices earned €40 each (€6,400) and 40 units of one model with a recurring board fault lost €60 each (minus €2,400). Sent straight to dismantling at break-even, those 40 would have left the lot at €6,400. At lot level nobody sees them, and the next lot of that model is bought on the same terms.
Margin per device needs the share of purchase price, the parts and labour, and the sale price attributed to the serial, counting the devices that never sold. The REAV ERP measures real cost per device, allocates a lot’s purchase price across its devices, and shows margin per device on the finance dashboard.
6. Supplier lot management
The declared and real contents of a purchase lot routinely differ. Without per-device intake data, you cannot say whether a lot paid back once every device in it was repaired, dismantled or recycled, and you cannot show the supplier what was missing. A receipt booked as "1 lot, 300 units" gives you nothing to dispute with, and the next lot from the same source is bought at the same price.
Worked example. Assume 300 devices bought for €30,000, €100 each on average. At intake, 285 are counted, 20 of them dead although declared working. Without per-serial evidence, the 15 missing units alone are €1,500 you cannot claim, and the 20 misdeclared ones cannot be argued at all.
Built for refurbishment, intake is by lot with a serial per device on arrival and the source linked from day zero. With each device carrying its share of the purchase price and its own costs, lot payback becomes a sum over its devices. Predictive margin on purchase lots is on the REAV ERP roadmap for November 2026: planned, not shipped.
7. Reconciling everything by hand for the client
An ITAD client expects a report per asset: tag, serial, erasure result and certificate, grade, disposition and, where resale is shared, the settlement value. When those live in different places, the report is built by matching an erasure export, an ERP export and a grading sheet line by line on the serial.
Worked example. Assume the 1,000 devices arrive as four client batches of 250, at 3 minutes per asset to match, check and correct. That is 12.5 hours a batch and 50 hours a month: €1,000 a month, €12,000 a year, spent assembling information the operation already produced. The settlement, and the cash, wait until the report is right.
Built for refurbishment, the report comes out of the device records, because certificate, grade and disposition are already filed against each serial. In the REAV ERP, certificates and audit proof export in one click, and an impact report is generated from real production data.
Two more that are easy to miss
Returns tied to nothing. Assume 3% of 1,000 monthly sales come back: 30 returns. If they are not tied to the serial, the grade sold and the repair done, a recurring fault on one model or one bench stays invisible and keeps shipping. Built for refurbishment, each return becomes an RMA linked to the order and the serial.
Regulatory figures rebuilt at period end. Weights, materials and the reuse-versus-recycling split become one more reconciliation when dismantling is not recorded as it happens. The REAV ERP records dismantling weights and materials for EPR declarations; automatic WEEE transfer notes are in progress, and Digital Product Passport export is planned for 2027, not shipped.
Adding it up
Count only what is measured in hours or in parts bought twice: traceability questions (€200), retyped erasure results (€670), parts bought again (€600), under-grading (€1,500), over-grading returns (€500) and client reports built by hand (€1,000). On these illustrative assumptions, that is about €4,500 a month, close to €54,000 a year, for a workshop of 1,000 devices a month.
The larger items are left out because they cannot be estimated honestly in advance: loss-making devices hidden in lot averages, supplier shortfalls never claimed, a contract lost after an audit where the trail broke. So is the cost of the ERP project itself. Rerun the sums with your own figures. Whatever you reach recurs every month the system stays as it is.
How to tell if your ERP is costing you
Seven questions, answered for a device chosen at random, not the one you would show a visitor.
1. Can you produce one device’s full history, certificate included, in under five minutes without opening a spreadsheet?
2. Does anyone retype erasure results or file certificates by hand?
3. Are harvested parts in stock, with a value and a source serial, the moment they come out?
4. When a repair changes a grade, does the new grade reach the sales channel without being retyped?
5. Can you name the three device models that lost you the most money last month?
6. Do you know whether your last purchase lot has paid back, and could you show the supplier what was missing, serial by serial?
7. How many hours did your last client report take?
If more than two answers are "no" or "I would need to check", the system is costing you money every month, and the worked examples above are a way to estimate how much.