Why Sustain360 isn't a generic ERP.
A generic ERP — even a strong one — is built around a forward supply chain. Goods come in, get assembled, get sold. A dismantling yard runs the supply chain backwards: a vehicle comes in, gets disassembled into hundreds of distinct parts, each of which carries its own grade, price, channel, and chain of custody. The mismatch is not cosmetic. It runs through the data model, the workflow engine, and the compliance layer.
Generic ERPs assume the bill of materials runs forward. A dismantling yard explodes it in reverse, with grading, against a regulator.
1. The forward-chain assumption
Generic ERPs are built on the forward bill of materials. A SKU is sourced, assembled, and sold. Inventory is a stock count against a SKU. The system's source of truth is the SKU, and the SKU is stable across time. None of that holds for used auto parts. The source of truth is the individual part, not a SKU; the grade and price move; and the part is anchored not to a supplier but to a specific source vehicle's VIN.
A dismantling yard is closer to a reverse bill of materials than to a manufacturing chain. A single VIN explodes into hundreds of parts, each of which is its own first-class record. The platform has to hold that explosion, anchor every part to the VIN, and carry the grade and the audit trail through binning, valuation, listing, and sale. Generic ERPs do not model this shape natively.
2. Stage-driven, not transaction-driven
Generic ERPs run on transactions: purchase order, goods receipt, sales order, invoice. Dismantling runs on workflow stages: acquire, inspect, dismantle, bin, value, sell, fulfil, report. Each stage has its own roles, its own state, and its own audit. Mapping the eight stages onto a generic ERP's transaction layer almost always requires custom states bolted onto a sales-order document, which is a poor approximation of a real workflow engine.
3. Per-part, per-market pricing
Generic ERPs treat pricing as a price list per customer or per channel. A used part's price is a function of its component grade, its mileage, current market data, stock age, and yard policy — recalculated as the inputs change. Putting that logic into a generic ERP usually means a custom rules layer on top of the price list, owned and maintained as bespoke code by the customer. Sustain360's pricing rules engine is part of the platform.
4. Compliance from inside the workflow
EU ELV directive and UK ATF / DVLA paperwork is the part most generic ERPs cannot produce at all. Depollution certificates, Certificates of Destruction, material-recovery records, and per-vehicle audit trails are not standard ERP outputs. Sustain360 produces them as a query against the workflow that actually performed the depollution — same operators, same times, same VINs.
5. Compatibility groups and parts taxonomy
Generic ERPs treat parts as catalogue items with attributes. Used-parts retail revolves around compatibility groups — which vehicles, engines, model years, and trims a given part fits. The taxonomy is its own discipline. Channels like eBay Motors and PartVisor expose fitment to buyers, and a listing without compatibility groups will not surface to a buyer who searches by car rather than by part number. Sustain360 holds compatibility groups against every part and propagates them to every channel that supports fitment metadata.
6. Hardware and yard-floor reality
Generic ERPs assume a warehouse, not a yard. A warehouse runs against picking aisles, fixed bins, and standardised cases; a dismantling yard runs against open ground, mixed bin sizes, and a flow that moves from disassembly area to shelving to despatch. The ergonomic surface — what an operator scans, what they label, what they print — has to fit the yard floor, not the warehouse floor.
Sustain360's hardware abstraction reflects that reality. Code-128 and QR labels print at the binning station onto whatever Zebra-compatible printer the yard already runs. Scanners are keyboard-emulating HID devices, USB or Bluetooth, no drivers. Mobile capture works in the rain or in a half-stripped vehicle's interior. None of that is unusual for dismantling software; all of it is unusual for a generic ERP. The cost is felt in deployment: ERP rollouts tend to follow with hardware refreshes; dismantling rollouts use the hardware the yard already owns.
7. Audit and chain of custody
An ERP records transactions. A dismantling platform records the chain of custody of a vehicle and every part removed from it, with operator, role, time, grade, and price captured at every transition. The difference is not in volume — both systems generate audit data at scale — it is in shape. An ERP's audit asks who created or modified a record. A dismantling platform's audit asks what happened to this VIN, in order, who did each thing, and what document was produced at each step.
EU ELV directive and UK ATF / DVLA audits assume the second shape. A platform that produces the first shape can be made to answer the audit, but only with substantial bespoke effort each time. A platform that produces the second shape answers the audit as a query against existing data.
8. When a generic ERP still has a role
An aggregator with a corporate finance system already running across the group will likely want to keep that ERP for general ledger, fixed assets, payroll, and consolidated reporting. Sustain360 integrates rather than replaces — exports flow to the corporate ERP through the REST API and webhooks, and reconciliation runs through scheduled CSV exports. The platform is the yard's system of record; the ERP remains the group's financial system.
The right separation is usually clear: Sustain360 runs the vehicles, the parts, the workflow, and the regulator paperwork. The corporate ERP runs the books at consolidated-group level. The integration between them is shaped by the corporate ERP's standard AR/AP shape and the reconciliation cadence the finance team prefers — typically weekly or monthly rather than real-time. Most aggregator deployments configure this shape during onboarding and rarely touch it afterwards.