None of these look like mistakes at the time
Ask a shop controller to describe a mistake they've made costing a job, and most will struggle to name one — not because they haven't made any, but because the ones that matter most don't announce themselves. The job total still looks reasonable. The month still closes. Nothing throws an error.
That's exactly what makes the ten below worth listing explicitly. Each one produces something that looks fine on the surface — right up until an owner asks why a job that was quoted at a healthy margin came in flat, and no one has a confident answer for which cost actually drove it.
None of the ten below are hypothetical edge cases dreamed up for effect — each is a pattern that recurs across shops of very different sizes and kinds, the ordinary, unremarkable ways a job-cost report quietly drifts out of sync with what actually happened in accounts payable.
1 · Coding to whichever job is open
A materials invoice with no clear job number gets coded to the job currently in progress on the shop floor — without checking whether the invoice actually belongs to a different job that just hasn't started cutting metal yet.
Both jobs may be drawing similar materials around the same week, which means “the job that's active right now” genuinely isn't a reliable signal on its own. Guessing works until, eventually, it doesn't.
The tell: a materials cost on a job that doesn't match what that job's router or BOM actually calls for.
2 · Forcing a shared cost onto one job
A freight bill covering a mixed shipment, or a bulk purchase of shop consumables, gets coded entirely to whichever job happens to be the largest or most recent — rather than recognized as a cost that doesn't honestly belong to any single job.
The job that absorbs it looks more expensive than it really was, and every other job on that shipment looks cheaper than it really was — a distortion that compounds every time a similar invoice arrives and gets the same treatment.
The tell: a job whose freight or consumables line looks disproportionately high relative to its size and scope.
3 · An outside-processing invoice arriving after close
A part sent out for heat treat or plating comes back and ships to the customer — and the job gets closed out and reported as complete before the processing invoice, which can lag weeks behind the physical part, has even arrived.
When the invoice finally does show up, it either gets coded to whatever job is open at that later date, or sits unassigned indefinitely — either way, the job it actually belongs to reports a cost that's understated by exactly that amount.
The tell: a job closed as complete whose known outside-processing step has no matching invoice in the job-cost total.
4 · Report date versus posting date
A job-cost report pulled on the day a job ships reflects only the invoices that have been coded by that date — not every cost the job has actually incurred, some of which are still sitting in a supplier's invoicing cycle or an unprocessed AP pile.
Treating that snapshot as final, rather than as a point-in-time estimate that will keep moving as later invoices land, is what creates the gap between what the job-cost report showed at ship date and what the ledger eventually shows once everything has posted.
5 · Uninvoiced receipts left out
Material gets received on the dock and consumed on a job well before the supplier's invoice for it actually arrives — sometimes weeks later, depending on the supplier's billing cycle. Until that invoice lands, the job-cost report simply doesn't know that cost exists.
Leaving uninvoiced receipts out isn't a rounding error — it's a real cost that's already been incurred and consumed, understating every open job by exactly the value of material that's on the floor but not yet on an invoice.
6 · Confusing price variance with quantity variance
A job comes in over its material budget, and the assumption is that the supplier charged more than quoted — when the actual cause was using more material than estimated, a completely different problem with a completely different fix.
Treating every variance as a pricing issue means renegotiating with a supplier who did nothing wrong, while the real cause — a scrap rate higher than planned, or an estimate that underestimated the material a part actually requires — goes unaddressed and repeats on the next similar job.
7 · Coding invoices once a quarter
A quarterly coding pass means matching three months of invoices against a job list and a memory that's three months stale. Every ambiguous line that would have taken thirty seconds to resolve a week after it arrived now takes real investigation, if it can be resolved at all.
It's also where the previous six causes compound — a full quarter gives all of them time to accumulate before anyone looks closely enough to catch even one.
8 · Treating a multi-job invoice as one line
A stock supplier ships materials for three open jobs on one delivery, and the invoice gets entered as a single total against one job rather than split across the three the delivery actually covered.
The result is one job overstated and two understated — a confusing outcome that's entirely avoidable once the invoice's line items are read individually rather than treated as one lump sum.
The tell: an invoice total that's larger than what any single open job's router would call for, from a supplier known to ship multi-job orders.
9 · Losing a shop's costs in consolidated AP
A company running more than one shop location processes all invoices through one central accounts-payable function, and a location's specific job costs get absorbed into a companywide total without being split back out by which shop, and which job at that shop, actually incurred them.
That consolidation distorts both records: the individual shop's local job-cost picture, and the group-level view that assumes each shop's numbers reflect its own actual activity.
10 · Closing a job silently
A job that's clearly running over gets quietly closed out and absorbed into overhead without anyone flagging it for review — no note about whether the estimate was wrong, whether there was scrap, or whether some invoices were simply never matched to it.
The mistake isn't closing a genuinely unprofitable job — that's sometimes the right call. It's doing it without a documented reason, which means no one can later tell the difference between “we decided this job lost money for a known reason” and “we lost track of what it actually cost.”
Why none of these trigger an alarm
Look at the ten together and a pattern emerges: not one of them breaks the arithmetic. The invoice total still adds up. The month still closes. Every one of these is an error of attribution — the right amount of cost existing, just connected to the wrong job, the wrong period, or no job at all.
That's precisely why a casual glance at whether the numbers “look right” catches none of them. They require checking whether each specific invoice is connected to the specific job it should be, which is a fundamentally different kind of check than confirming a total.
The pattern behind all ten
Every one of these causes happens at the same moment: the instant an invoice is coded to a job — or isn't — without checking it against everything that's actually known about that job. A job assumed to be the only one the invoice could belong to. A cost assumed to be fully allocated by ship date. A silence assumed to mean nothing unusual happened.
The fix, in every case, is the same shape: check the reference, the invoice content and the timing together against the job list, every single time, rather than relying on a controller's memory to catch the exceptions. That consistency is what a systematic matching process provides and an ad hoc review, however careful, structurally can't.
It's worth sitting with that for a moment, because it reframes the whole list. These aren't ten unrelated traps to memorize — they're ten symptoms of one underlying gap, and closing that one gap addresses all ten at once rather than requiring ten separate fixes.
A twenty-minute check that catches most of it
Pull your most recent invoice batch and check for any line coded to a job without a clear reference, amount and job-scope agreement.
Scan open jobs for costs that seem disproportionately high relative to their known scope — a sign of an absorbed shared cost.
Check every job closed in the last month for an outside-processing step with no matching invoice yet in its total.
List jobs whose material cost is above estimate and confirm whether it's a price variance or a quantity variance before acting.
Confirm any large invoice from a multi-job supplier has been split by line, not recorded as one job's cost.
Check that any recently closed job has a documented reason attached, not just an absence from the open list.
Six checks, about twenty minutes against a typical shop's most recent invoice batch. It won't catch everything that's ever gone wrong, but it's a fast, honest read on whether any of the ten above has already crept into your current job-cost report.
The mistake that compounds all the others
There's an eleventh pattern underneath the ten, worth naming separately: none of this knowledge survives a handoff unless it's written down. A controller who's learned which suppliers are unreliable about job numbers, which jobs routinely draw shared freight, which reference formats are normal — all of that context leaves with them unless it's documented somewhere the next person can find it.
Shops with high turnover in the costing role are, in practice, the ones most exposed to every cause on this list, simply because the informal knowledge that used to compensate for an imperfect process keeps resetting to zero.
A composite case, built from several real ones
No single shop hits all ten in one year, but the pattern below — assembled from cases that recur across many job shops rather than any one in particular — shows how a few of these compound into something bigger than any of them look on their own.
A twenty-person contract manufacturer had coded invoices to jobs once a quarter for as long as anyone could remember. One close, the new controller noticed gross margin was down about six points from the prior quarter, with no obvious explanation — the job mix hadn't visibly changed, and nothing in the schedule suggested a pricing problem.
Working backward through three months of invoices turned up three separate, unrelated causes. An outside-plating invoice from a job closed in month one had never been matched — mistake three. A stock supplier's multi-job delivery had been coded entirely to the largest job on it rather than split across all three it actually covered — mistake eight, worth roughly a third of the total gap on its own. And a job that ran over on material had been assumed to be a supplier price increase, when the real cause was a scrap rate no one had checked against the estimate — mistake six, smaller individually but compounding across a full quarter of similar jobs run the same way.
None of the three would have been remarkable on its own, caught within the cycle it happened. Stacked across three months of no checking, they added up to a margin number the owner noticed and had no immediate explanation for — exactly the scenario a shorter coding cadence is built to prevent.
Why these compound instead of canceling out
A reasonable instinct is to assume small errors in both directions roughly cancel — a cost mismatched one way balanced by another mismatched the other way, netting out to something close to correct. In practice, that's not how most of these ten behave.
Most of them are one-directional. Uninvoiced receipts only ever produce understated cost, never overstated. A shared cost forced onto one job overstates that job and understates every other job on the same shipment, which doesn't offset — it just redistributes the distortion. A multi-job invoice coded as one line doesn't cancel out anywhere; it just obscures which job actually bore the cost.
Because the errors skew in a consistent direction relative to whichever job absorbs them, they accumulate rather than average out, which is exactly why a gap that looks small after one month can look substantial after a full quarter of the same unchecked pattern repeating.
That one-directional bias is the strongest argument for a short coding cadence over a long one: it caps how much any single unchecked cause can accumulate before someone notices.
Each cause, and its one fix
Ten causes can feel like ten separate things to remember. In practice, each one has a single, specific habit that prevents it — worth having as a quick reference rather than re-deriving from the full description each time.
| Cause | The one fix |
|---|---|
| 1 · Coded to open job | Check the invoice for its own job reference before assuming which job it belongs to |
| 2 · Shared cost forced onto one job | Flag freight and consumables as shared cost rather than coding them to a single job |
| 3 · Late outside-processing invoice | Hold a job open for known pending processing costs before reporting it complete |
| 4 · Snapshot treated as final | Treat any job-cost report as a point-in-time estimate, not a closed number |
| 5 · Uninvoiced receipts ignored | Track material received and consumed even before its invoice arrives |
| 6 · Price vs quantity confusion | Check quantity used against estimate before assuming a supplier price issue |
| 7 · Quarterly coding cycle | Code invoices weekly or monthly instead |
| 8 · Multi-job invoice as one line | Always read each invoice line individually rather than as one total |
| 9 · Multi-site AP consolidation | Tag every invoice with its originating shop location at entry |
| 10 · Silent job closure | Require a documented reason for every job closed over its estimate |
None of these ten fixes require new tools or a change in how the shop operates day to day. Each is a single habit, applied consistently — which is the same underlying principle as the pattern discussed above, just made concrete enough to actually act on the next time any of these ten situations comes up.
Print this table, or keep it pinned somewhere visible during invoice coding, and most of the ten stop being mistakes waiting to happen and start being a five-second check each cycle.
Who actually catches these, in practice
In shops with more than one person touching the books — a controller and a bookkeeper, or an owner reviewing monthly — these ten causes get caught noticeably more often than in shops run by a single person handling both AP and job costing with no one double-checking their work.
That's not a comment on any individual controller's competence. It's simply that a second person looking at the same job-cost report asks different questions, notices different things look odd, and isn't blind to the same assumptions the first person has already made without realizing it.
Shops without the luxury of a second reviewer aren't without options — a short, explicit checklist like the one in this article substitutes reasonably well for a second pair of eyes, precisely because it forces the same questions a second reviewer would ask, even when there isn't one available.
If you're new to the role, start here
A controller inheriting job costing for the first time doesn't need to memorize all ten causes before doing anything useful. Three checks, done in the first week, catch a disproportionate share of what's likely to have already gone quietly wrong under a predecessor.
Compare the current job list against the invoices coded to each job — anything that looks disproportionate is worth a specific look.
Scan for jobs closed recently with no documented reason for how they came in over or under estimate.
Ask the outgoing controller directly about any supplier or job they remember as an unusual case — a chronic multi-job invoice, a supplier who never includes references.
None of these three require deep familiarity with the shop's history — they're checks anyone can run against a current job list and invoice batch within the first week, well before the rest of the role's learning curve has been climbed.
A fourth, less mechanical step matters just as much: ask directly whether invoice coding has ever been done on a regular cadence at all, or only reconstructed once a quarter under deadline pressure. The answer shapes how much of this article's ten points are worth worrying about immediately versus over the coming months.
Does shop size make this worse, or better?
Intuitively, a larger shop with more jobs and more suppliers would seem to have more room for these causes to hide. In practice the relationship is more complicated than that, and cuts both ways depending on which cause is in question.
Larger shops are more exposed to causes eight and nine — multi-job invoices and multi-site consolidation — because they're more likely to have the concurrent job volume and multiple locations that create those specific problems in the first place. A three-person shop with one open job rarely has a multi-job invoice to worry about.
Smaller shops are more exposed to causes one and three — coding ambiguity and late outside-processing invoices — for the opposite reason: with fewer people, there's less redundancy, and a single person handling everything has no colleague to catch what they miss. A missed processing invoice on a shop with five open jobs is a much larger share of that shop's total cost than the same miss at a manufacturer with two hundred.
The practical conclusion is the same either way: no size is naturally immune to this list, just exposed to a different subset of it.
Knowing which end of that spectrum your own shop sits on is worth a moment's honest thought — it points directly at which two or three of the ten deserve the closest attention first, rather than treating all ten as equally likely.
What this doesn't fix
Naming these ten causes doesn't decide your shop's policy on write-offs, doesn't set your estimating margins, and doesn't tell you what to do about a job type that keeps running over. Those remain decisions for whoever owns pricing and estimating, made with accurate information — which is the one thing this list is actually trying to protect.
The step-by-step method for coding invoices to jobs without falling into any of these ten is in how to build a job costing workflow.