Most ERP demos look fine. Someone enters an order, the system calculates a price, an invoice comes out the other end. It’s only after go-live, usually a few weeks in, that a metals service center finds the gaps: a unit of measure that won’t convert the way the mill invoice does, a costing report that can’t separate a heat number from a lot number, or a process ticket that has to be tracked in a spreadsheet because the ERP has no concept of what happened to the material between receipt and shipment.
None of this shows up in a demo built around a generic distribution or manufacturing workflow. It shows up the first time a real metals transaction runs through the system.
Where Generic ERP Runs Into Trouble
Catch Weight and Dual Unit of Measure
Metal is bought by weight and sold by piece, or bought by the coil and sold by the cut length, and the two numbers rarely reconcile cleanly. A distribution-focused ERP typically has one unit of measure per item, with conversions bolted on afterward. That works until a customer orders in feet, the mill invoices in pounds, and the system has no native way to tie theoretical weight to actual weight without a manual adjustment on every transaction.
Purpose-built metals ERP treats catch weight as a first-class feature of the item record, not an exception process. Theoretical versus actual weight, dual UOM pricing, and the variance that comes with them are handled the same way order entry is: as a normal part of the transaction.
Processing and Material Genealogy
Slitting, cutting to length, blanking, and toll processing all change the identity of the material, not just its quantity. A coil that comes in gets split into multiple slit coils, each with its own weight, and each still needs to trace back to the original heat number for quality and compliance purposes. Generic ERP built around discrete manufacturing or distribution usually has no concept of this kind of transformation. Inventory modules assume an item goes in and the same item comes out; metals inventory routinely does neither.
Without that genealogy built into the system, tracing a customer complaint back to a specific heat, or pulling a certified Material Test Report for a shipment, becomes a manual reconstruction project instead of a report.
Costing That Reflects What Actually Happened
Standard costing models assume a bill of materials that doesn’t change transaction to transaction. Metals costing has to account for scrap generated during processing, yield variance between theoretical and actual weight, and the freight and processing charges that get allocated back to a specific lot. Generic ERP can usually be configured to approximate this, but it takes customization, and every customization is something the vendor didn’t build, test, or support the way they did the core product.
The pattern: Almost every gap above traces back to the same root cause. Generic ERP treats metals-specific requirements as configuration on top of a distribution or manufacturing core. Purpose-built metals ERP treats them as the core.
What This Actually Costs
The cost of the gap rarely shows up as a single line item. It shows up as a spreadsheet someone maintains alongside the ERP to track what the system can’t, a costing report nobody fully trusts, and a customization budget that keeps growing because every new metals-specific requirement is another change order against a system that wasn’t built for the business in the first place.
None of that is necessarily a reason to avoid a generic platform. A service center running a narrow, simple product line may never hit these limits. But for shops running catch weight, multiple units of measure, and processing operations that change the identity of the material, it’s worth asking a vendor directly how their system handles a coil that gets slit into six pieces and sold to four different customers, and getting a specific answer rather than a reassurance.
Where to Look Next
Paragon’s Metalware ERP was built around these exact requirements rather than adapted to fit them afterward, with the same core available on-premise or, through MetalNet, from the cloud. If your customers need self-service access to quotes, orders, and MTRs on top of either platform, that’s what MetalWeb is for.
Key Takeaways
- Catch weight and dual unit of measure need to be native to the item record, not a manual adjustment on every order.
- Processing operations change the identity of material. ERP built for discrete manufacturing usually has no concept of that.
- Material genealogy back to a heat or lot number should be a report, not a reconstruction project.
- Metals-specific costing (scrap, yield, processing allocation) is a core requirement, not a configuration afterthought.
- Ask vendors for a specific answer on how they handle a coil split into multiple pieces sold to multiple customers.
Outgrowing Generic ERP?
Paragon’s metals software team can walk through what a purpose-built system handles that a generic one doesn’t, using your own inventory and order examples.
Get a free consultation