Metal fabrication shops are usually job-shop or make-to-order operations, and the question that decides whether an Acumatica implementation goes well is whether the team builds work-order-based job costing correctly from the start, because fab work has a cost structure — heavy scrap variance, machine time as a real cost driver, quoted jobs that need to reconcile against actual — that punishes a generic "just use standard BOM costing" approach.
Production Orders double as job cost objects
In Manufacturing Edition, a Production Order (AM301000) is naturally a cost-collection object: material issues, labor time via the routing operations, and machine/overhead allocation all post against the order, and the order rolls up actual cost versus the BOM's estimated cost. For a fab shop this maps directly onto "job costing" without needing the Projects module, as long as each customer job is its own production order (not batched into a generic production run) — which is a process discipline decision, not a system limitation, but one that gets skipped under deadline pressure and then the costing data is useless.
SELECT OrderNbr, EstimatedCost, ActualMatCost, ActualLaborCost, ActualOvhCost,
(ActualMatCost + ActualLaborCost + ActualOvhCost) - EstimatedCost AS Variance
FROM AMProdItem
WHERE OrderType = 'RO' -- regular production order
AND Status = 'C' -- completed
ORDER BY Variance DESCScrap and yield tracking needs a deliberate configuration, not a default
Acumatica supports scrap reporting on production operations — a quantity field on the routing step where you record scrapped units or material — but out of the box it is a simple count, not a scrap-cost-attribution engine. For metal fab, where a cutting or forming step might scrap 8% of raw plate and that variance genuinely needs to hit the job's cost variance (not just get absorbed silently into overhead), I typically add a scrap reason code table and route scrap cost to a dedicated variance account rather than letting it blend into the standard material variance. That separation is what lets a shop tell "this job had bad material" apart from "this operator's setup is consistently off," which is the actual business question behind "track scrap."
If the item class uses standard costing, scrap on a production order shows up as a cost variance at order close, not as a line-item scrap cost. If a client's requirement is "show me scrap cost per job on the shop floor screen," standard costing alone will not do it — you need either actual costing on the WIP or a custom scrap-tracking screen that captures it as its own event, independent of the cost roll-up timing.
Feeding actuals back into the next quote
The recurring ask from fab shop owners is "make my quotes more accurate using what jobs actually cost," which is really asking for the Estimating module's estimate-to-production-order conversion to be closed-loop: convert an estimate to a production order, run the job, then compare actual to estimate and adjust the routing's standard labor/machine times for the next similar job. Acumatica's Estimating module supports the conversion path natively; the feedback loop back into standard routing times is a manual review process, not an automated learning system — I am explicit with clients that "the system gets smarter automatically" is not a real feature here, a person still has to review variance reports and adjust standards periodically.
Wrapping up
Metal fabrication fits Acumatica's Production Order model well because a job-shop production order is naturally a cost object. The parts that need real design decisions are scrap attribution (pick actual costing or a dedicated variance path, don't assume standard costing shows what you want) and the estimate-to-actual feedback loop, which stays a human process no matter how well you configure the system.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.