The Job-Level Number That Doesn't Tell You Anything
The quarter closes and the number is ugly. Job 4471 quoted at a healthy margin and came in flat, maybe worse. Everyone in the shop has a theory. The supervisor says the material showed up late and rework ate the buffer. The programmer says the fixture change added setup time nobody billed for. The owner just sees one line in QuickBooks: labor cost, total, higher than it should have been.
This is the point where most shops stop. They didn't lose money on Job 4471 in the abstract — they lost it in a specific place, on a specific operation, for a specific reason. But a job-level total can't say which one. It can only say something went wrong somewhere between quote and delivery. Chase that with a hunch and you'll "fix" the wrong step, again, next quarter.
Per-operation job costing exists to close that gap. Instead of comparing one quoted number against one actual number for the whole job, it compares quoted-versus-actual at every operation in the routing — saw, mill, deburr, weld, inspect, whatever the part actually passes through. The job-level total still matters for the P&L. But it's the operation-level breakdown that tells you what to change before the next job like it hits the floor.
What Per-Operation Job Costing Actually Measures
A routing is the sequence of operations a part travels through, each with a standard time — the estimate baked in at quoting. A traveler carries that routing with the job as it moves through the shop, whether it's a printed sheet with a barcode or a digital version pulled up on a tablet at each work center.
Per-operation job costing means logging actual time against each operation on that routing, not just clocking a job in and out once at the start and end. An operator clocks into "Mill — Op 20" specifically, and clocks out (or switches to a downtime reason — setup, run, waiting, rework) when that operation is done. Multiply that by every operation on every job and you get a dataset that job-level costing simply cannot produce: actual time by operation, compared against the standard time that operation was quoted at.
A job-level total answers "did we make money." Per-operation job costing answers "on which step did we stop making it" — and those are two different questions that require two different levels of data.
A Worked Example: Same Job, Two Views
Take an illustrative job, quoted at 40 labor hours across five operations, actual hours logged at 46. At the job level, that's a straightforward variance: 6 hours over, roughly 15% adverse. That number alone tells the shop the estimate was wrong somewhere. It doesn't say where.
Break the same 46 hours down by operation (numbers below are a representative example, not a benchmark):
- Saw: quoted 5, actual 5 — on target
- Mill: quoted 14, actual 20 — 6 hours over
- Deburr: quoted 3, actual 3 — on target
- Weld: quoted 10, actual 10 — on target
- Inspection: quoted 8, actual 8 — on target
The job-level view showed a diffuse 15% overrun. The operation-level view shows the entire overrun sitting in one operation: milling, at 43% over its standard. Everything else quoted correctly. That's the difference in practice between a total that tells you a job lost money and a breakdown that tells you exactly which step, which programmer decision, which tool, or which setup to go look at.
This is the core argument for job costing for machine shops done at the operation level rather than the job level: the fix is only ever findable at the resolution the data was captured at.
Why the Operation Level Is the Only Place Variance Means Anything
Actual-vs-quoted labor tracking is only diagnostic if the "actual" side is captured at the same granularity as the "quoted" side. A quote is built operation by operation — a setup allowance here, a run-rate estimate there. If the actual time gets logged as one lump per job, you've compared a granular estimate against a blunt actual, and the comparison can only ever say "over" or "under," never "why."
This matters more than it looks like it should, because the underlying labor data is often worse than shops assume. Manual, paper-based time tracking has been measured with a calculation error rate as high as 8% of total payroll (Timeero) — and the American Payroll Association has estimated that businesses can lose up to 5% of gross payroll annually to time theft, cited via Homebase. Neither of those figures is about job costing specifically, but they describe the same underlying capture problem: if the raw time data feeding a job-level total is already noisy, an operation-level breakdown at least isolates where the noise concentrates, instead of spreading it evenly across a number that looks precise but isn't.
Operation-level actual-vs-quoted labor tracking turns a single suspicious total into a short list of specific operations worth investigating — which is a much cheaper problem to solve than "the whole job ran hot."
Turning Operation-Level Data Into a Fix
A labor efficiency variance is the gap between the labor hours a job was quoted at and the labor hours it actually took, expressed at whatever level of detail was captured. At the job level, a variance is a scoreboard number — useful for knowing whether a customer or a job type is structurally underpriced, not useful for changing behavior on the floor.
At the operation level, the same variance becomes something a supervisor can act on this week:
- A single operation runs consistently over standard across many jobs — the standard time itself may be wrong, and the quote needs revising, not the operator.
- A single operation runs over standard on one job only — something specific happened (tool wear, a fixture problem, an inexperienced operator on that shift) and it's worth a five-minute conversation while the job is still fresh.
- Setup time is consistently the overrun, not run time — that points at changeover practice or fixturing, a different fix entirely from a slow cycle.
None of that distinction is visible from a job-level total. It only becomes visible once the actual hours are tagged to the operation and the reason code — setup, run, waiting, rework — that produced them.
Where Scrap and Rework Fit In
Rework is itself an operation-level event, and it belongs in the same dataset. Scrap and rework logged against the specific operation that caused it — not against the job as a whole — is what lets a shop tell the difference between "milling took longer because the cycle is genuinely long" and "milling took longer because the same part got reworked twice for the same defect."
Cost-of-quality research gives some sense of the stakes here. EASE.io has put scrap and rework at up to 2.2% of annual revenue for the average manufacturer, and cost-of-poor-quality estimates from Jama Software and Autodesk both put the broader figure at 15%–20% of sales in mature operations, with Jama citing a wider range of 5%–35% depending on the shop. Those are industry-wide estimates, not a guarantee for any specific shop — but they're a reasonable argument for why "which operation is producing the scrap" is worth being able to answer precisely, rather than approximately.
Building This Without an ERP Project
The obstacle for most small job shops isn't believing in per-operation job costing — it's that the tools capable of it have historically come bundled inside full quote-to-cash ERP systems with implementation timelines and price tags this size of shop has already declined. That's the gap WorkTickets is built to sit in: a routing and traveler for each part number, clock-in and clock-out at the operation level with setup/run/waiting/rework reason codes, and actual-vs-quoted labor comparison per operation and per job, available on every tier. Scrap and rework logging tied to the causing operation is included at every tier as well. Job-level profitability summaries that roll operation-level actuals up against configured work-center burden rates are available starting on the Professional tier.
It doesn't do capacity scheduling, inventory, or purchasing — it's deliberately scoped to the routing-through-costing layer, not a full ERP replacement. For a shop that's currently running job costing off a spreadsheet and a stack of paper travelers, that narrower scope is the point: the data starts at the operation level from day one, instead of arriving as a job-level total that has to be reverse-engineered after the fact.
For a closer look at how to set this up on a specific job, the job costing example for manufacturing walks through a full routing end to end, and the actual-vs-quoted labor tracking piece covers the comparison mechanics in more depth. The labor efficiency variance article goes further into reading variance patterns across multiple jobs, and the broader job costing for machine shops guide and job costing resource hub tie the whole method together. Shops that want to build the habit manually first can start with the job costing & quoted-vs-actual workbook before moving the same structure into software.
WorkTickets offers a 14-day trial across its Essentials, Professional, and Business tiers, with an Enterprise option for shops that need it — current pricing is on the pricing page. The fastest way to see whether operation-level costing changes anything for your shop is to run one real job through it and look at the breakdown instead of the total.
