An actual-vs-standard production report is the manufacturing floor's reality check on the numbers Estimating promised — did this production order actually cost what the standard said it would, and where exactly did it diverge: material usage, labor efficiency, or overhead absorption? Building this well means keeping those three variance buckets genuinely separate, because "we're over budget" is useless to a plant manager; "we used 8% more resin than standard on lot 4412" is actionable.
Material, labor, and overhead variance are three different questions
Acumatica's production order cost detail (AMProdItem / AMProdOper-family DACs, tracking material issues, labor/machine time from the routing, and applied overhead against the production order) already separates these at the source — a material issue transaction is a different record from a labor time entry against a production order operation. The report's job is to keep that separation all the way through to the printed page: standard material cost vs actual material issued, standard labor hours vs actual clocked time (valued at standard rate, so a labor rate change doesn't get blamed on an efficiency problem), and overhead applied vs overhead standard. Collapsing all three into one "total variance" number is the single most common complaint I hear from plant managers about reports built by someone who hadn't walked the shop floor first.
MaterialVar = SUM(ActualMaterialCost) - SUM(StandardMaterialCost)
LaborVar = SUM(ActualLaborHours * StandardLaborRate) - SUM(StandardLaborHours * StandardLaborRate)
-- note: rate held constant to isolate an efficiency variance from a rate variance
RateVar = SUM(ActualLaborHours * (ActualLaborRate - StandardLaborRate))
OverheadVar = SUM(AppliedOverhead) - SUM(StandardOverhead)Only closed or substantially-complete orders give a meaningful variance
A production order still in progress has partial actuals against a full standard — comparing them prematurely makes every open order look like it's running over, because standard cost assumes completion and actual cost so far reflects only whatever portion has happened. Filter the report to closed production orders by default, or if management genuinely wants to watch in-progress variance, show percent-complete alongside the variance so a 40%-complete order isn't misread as 40% over budget.
Material consumed on a scrapped unit and material consumed on rework are both "extra material used beyond standard," but they mean different things operationally — scrap is lost, rework is recoverable labor cost on top of the lost time. If the production order's transaction records distinguish scrap and rework transactions from normal issues (most configured instances do, via a transaction type or reason code), keep them as separate report lines rather than blending them into the general material variance bucket, or the report can't tell a quality problem from a process inefficiency.
Wrapping up
Keep material, labor, and overhead variance as separate columns sourced from the production order's own transaction-level detail, and split labor efficiency variance from labor rate variance by holding rate constant in the efficiency calculation. Filter to completed orders by default so partial actuals don't get compared unfairly against full standards, and give scrap/rework its own line rather than folding it into general material variance — that distinction is usually the actual reason someone asked for this report in the first place.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.