The job that "just ran long" — and nobody could say why
A five-axis job comes off the machine two shifts later than the quote assumed. The part is good, the customer is happy, and the shop still made money on paper — QuickBooks says the invoice covered the material and then some. But nobody can say why it ran long. Was it the fixture? A slow first article? An operator learning a new program? The traveler came back with hours scrawled in a margin, if it came back with hours at all, and by the time anyone looks at it the job is three revisions old and the trail is cold.
This is the gap that labor efficiency variance is built to close. It's not a new metric — cost accountants have used it for decades — but most small job shops never compute it because they never capture the two numbers it needs: what the job was supposed to take, and what it actually took, broken down the same way, operation by operation. Once those two numbers exist, the variance is arithmetic. The hard part was never the formula. The hard part was getting clean, comparable hours out of the shop floor in the first place.
This article gives you the formula, shows it worked at the operation level, and explains what a favorable or unfavorable result is actually telling you — so "the job ran long" turns into a number you can act on instead of a shrug at quarter-end.
What labor efficiency variance actually measures
Labor efficiency variance measures the time gap between the standard hours a job should have taken and the actual hours it took, then prices that gap out in dollars. It is distinct from a labor rate variance, which measures whether you paid more or less per hour than planned. Efficiency variance assumes the rate is right and isolates the question of speed: did the operation run faster or slower than the router said it would?
That distinction matters because the two variances have different causes and different fixes. A rate variance is usually a payroll or overtime problem. An efficiency variance is a process problem — tooling, fixturing, operator skill, a router that was never realistic to begin with, or a legitimate one-off like a first article that ate extra setup time. Lumping them together is how shops end up "fixing" the wrong thing.
The formula, in its classic form:
Labor efficiency variance = (Standard hours − Actual hours) × Standard labor rate
Standard hours are the hours the routing says the operation should take, given the quantity run. Actual hours are what got logged against that operation. The standard rate — not the actual rate — is used deliberately, so the number reflects only the time gap, not any pay-rate noise.
The formula, worked at the operation level
The variance means little computed once per job at the end of a run. It earns its keep computed per operation, because that's the level where a router lives and where a cause can actually be traced. Here's an illustrative worked example for a representative shop — round numbers, chosen only to show the mechanism, not a benchmark to compare yourself against.
Say a routing calls for a deburr-and-inspect operation to take 0.75 standard hours for a batch of 40 parts, at a standard labor rate of $28/hour. The operator logs 1.1 actual hours against that same operation on the traveler.
- Standard hours: 0.75
- Actual hours: 1.1
- Variance in hours: 0.75 − 1.1 = −0.35 (unfavorable — it ran over)
- Variance in dollars: −0.35 × $28 = −$9.80 unfavorable on that one operation, for that one batch
Run that same math across every operation on the router — setup, first machining pass, deburr, inspection — and you get a variance profile for the whole job instead of one blended number. That's the difference between "this job ran 22% over" and "the deburr-and-inspect step is where the time went, and it's gone the same way on the last four batches of this part number." One of those statements gets you a corrective action. The other gets you nothing.
This is the same underlying comparison covered in more depth in standard time vs actual time in manufacturing and in actual vs quoted labor tracking — efficiency variance is simply that comparison, priced.
Reading the sign: favorable vs unfavorable
A negative variance — actual hours higher than standard — is unfavorable: the operation ate more labor than planned, and margin on that job shrank accordingly. A positive variance means the operation ran faster than standard: favorable, on paper.
Favorable variances deserve a second look before anyone celebrates them. A consistently large favorable variance on the same operation, across multiple jobs, often means the standard itself is loose — the router was built with too much padding, which means every quote built on that router is overpriced and possibly losing bids it shouldn't lose. An unfavorable variance that shows up once, on a job with a documented first-article inspection or a new operator, is a different story than the same unfavorable variance repeating on a mature part number that should be running like clockwork by now.
The number doesn't diagnose itself. It tells you where to look. What you find when you look — a dull tool, an undocumented fixture change, a router nobody updated after the process improved — is the actual finding.
Where the number comes from — and where it breaks down on paper
Labor efficiency variance is only as good as the actual-hours input, and this is where paper-based shops lose the thread. A traveler that gets hours written in after the fact, rounded to the nearest half hour, remembered at the end of a shift rather than logged at the operation, produces actual hours that are really guesses. Run the formula on a guess and you get a confident-looking number that means very little.
The fix isn't a more elaborate spreadsheet. It's capturing actual hours at the operation where they happen — clocked in and out against a specific job and operation, not reconstructed later from memory. That's the mechanical prerequisite for the whole exercise: per-operation job costing only works when the operation-level hours going into it are real. WorkTickets builds this at the level the formula needs — a router defines the standard time per operation, a traveler or mobile clock-in captures the actual time against that same operation, and the actual-vs-quoted comparison (available on every tier) rolls those two numbers together automatically instead of asking someone to reconcile a paper stack at month-end.
For shops that want to run this by hand first and see whether the discipline sticks before adopting anything new, the Job Costing & Quoted-vs-Actual Workbook sets up the same standard-hours-versus-actual-hours structure in spreadsheet form — a reasonable way to prove the value of the exercise before deciding it's worth automating.
Turning variance into action, not blame
A variance report that nobody reads is just a spreadsheet with an extra column. The value is in the pattern across jobs, not the number on any single one.
The useful cadence is simple: pull the variance by operation across a stretch of jobs on the same part number or the same work center, and look for repetition. A single unfavorable reading is a data point. The same operation running unfavorable five jobs in a row is a standard that needs revisiting, a process that's drifted, or a training gap — and now it's a specific, defensible one, backed by hours logged against a specific operation rather than a feeling that "that job always seems to run long."
That's the whole point of tracking this at all: not to score operators, but to find out which parts of the router don't match reality anymore, before that mismatch quietly erodes margin on every job that uses it.
Where to start
If your shop is still comparing "the quote" to "how it felt" at job close, the fastest way to see this mechanism run for real is to route one part number properly, clock actual hours against its operations, and look at the variance the next time it runs. WorkTickets does that comparison natively — routing and travelers build the standard side, clock-in and manual time entry with supervisor approval build the actual side, and actual-vs-quoted labor per operation is available starting on the Essentials tier. The 14-day trial is enough to run it on a handful of live jobs and see where your own routers are wrong. For the fuller context on why this matters to margin across a whole shop, the job costing resource hub is a good next stop.
