Every open job carries a cost nobody's added up
Job shops running several open jobs at once usually discover the same thing once they try to answer a simple question — what has this job actually cost us so far, before it ships — and find that no one actually knows, because the cost is scattered across supplier invoices that arrived at different times, for different pieces of the same job.
One job's materials invoice landed last week. Its outside-plating invoice hasn't arrived yet. A shared freight bill covering three jobs, including this one, is sitting uncoded in the AP pile. None of that is a failure of anyone's process — it's the normal condition of running concurrent jobs against a supplier base with its own invoicing pace, and it's exactly what makes an up-to-date WIP picture hard to produce.
The result, most months, is that a controller builds a WIP picture by asking the shop floor how each job is progressing, cross-checking against whatever invoices happen to be entered so far, and accepting that the number is an approximation — a process that's slow, incomplete, and has to be redone in full every time someone asks.
Why a WIP schedule is harder than it sounds
Invoices lag the actual cost
Material gets consumed and outside processing gets performed well before the corresponding invoice arrives, so a schedule built only from entered invoices always understates true cost.
Job status changes mid-period
A job can open, accumulate cost, and close for shipment all within the same reporting window, which a schedule built at a fixed point in time can easily miss or double-count.
Shared costs blur job boundaries
Freight and consumables that span multiple jobs need to be excluded or allocated deliberately, not left sitting against whichever job happens to be largest.
No shared chart of accounts across shops
A multi-site manufacturer often finds each location codes similar costs slightly differently, making a like-for-like roll-up a manual translation exercise.
None of these problems get solved by asking the shop floor to track cost more carefully — that request rarely survives contact with a busy production schedule. What actually works is reading the invoices as they arrive and rolling up what's matched, consistently, every time.
What this doesn't do, stated up front
Doesn't recognize revenue or calculate percentage of completion
It reports accumulated cost per job. Any revenue-recognition judgment sits with your accountant, using this cost data as one input.
Doesn't audit job cost accuracy
It reports what matched invoices show. Whether that reflects everything a job has genuinely incurred — including costs not yet invoiced — is a separate estimation your team applies.
Doesn't explain why a job's balance deviates
It surfaces a deviation from a job's own expected pattern. Understanding the cause requires someone with shop-floor context.
Doesn't decide when a job is complete
Job status — open, in progress, shipped — comes from your production system. This reads whatever status you provide and schedules accordingly.
What gets read for each open job
| Field | Notes |
|---|---|
| Job number | So every schedule line traces back to a specific open job |
| Matched invoice amounts | Rolled up per job from the underlying matched invoice lines |
| Invoice and job dates | For assigning cost to the correct schedule period |
| Job status, as provided | Open, in progress or recently closed, so the schedule reflects it accurately |
How it works
Match invoices to jobs
The same matching used for job costing, applied to the current invoice batch.
Filter to open jobs
Only jobs still in progress feed into the schedule; closed jobs are excluded.
Roll up cost per job
Every matched invoice line for an open job summed into one running total.
Export the schedule
One roll-up across all open jobs, with drill-down to any job's underlying invoices.
Twenty open jobs, one schedule
A contract manufacturer with twenty jobs open at month end asked for a single current WIP picture, built the same way every month rather than reconstructed by hand.
| Finding | Jobs |
|---|---|
| Cost rolled up cleanly, no issues | 16 |
| A shared freight invoice initially miscoded to one job | 2 |
| Job closed mid-period, correctly excluded from the next schedule | 2 |
The two miscoded freight lines were the same underlying pattern: a shared shipment covering more than one job had been coded entirely to the largest job on it — corrected once the invoice's own line items were read individually. The two closed jobs dropped off the open-job schedule automatically once their status updated, without anyone having to remember to remove them by hand.
Cost accumulation isn't revenue recognition
A WIP schedule built from matched invoice cost answers one specific question — how much has this job cost so far — and stops there. Whether that cost translates into revenue that should be recognized this period, and by how much, is a separate accounting judgment involving the job's contract terms, its percentage of physical completion, and often a specific accounting standard your business follows.
Keeping these distinct matters because conflating them produces a schedule that looks like it's making a revenue-recognition decision it was never designed to make. The cost side is mechanical and traceable to invoices; the revenue side requires judgment this tool doesn't apply.
When one job's balance doesn't fit the pattern
Once cost is rolled up consistently across jobs, deviations become visible in a way they weren't before — a job whose accumulated cost jumped sharply between two schedule dates, or one carrying cost well past its expected completion timeline with no shipment yet recorded.
None of that is proof of anything on its own. It's a pointer toward a specific job worth a conversation with whoever's running it — which is a much shorter list to work through than reviewing every open job equally, every time, whether or not anything actually changed.
Keeping the schedule current
A WIP schedule built once a quarter answers a question that's already stale by the time it's read. Building it monthly — or whenever invoices are coded — keeps whoever's pricing the next job or reviewing margins working from a picture that's still close enough to current to act on.
It doesn't require invoices to be entered faster than they naturally arrive; it just means reading whatever has been matched at each interval rather than waiting for every single invoice on every open job before publishing anything.
A partial schedule — most jobs current, a couple still missing a recent invoice — is still more useful to a controller than no schedule at all, which is often the practical alternative when the standard is waiting for every cost to be fully in before reporting anything.
When a job closes mid-period
A job that ships and closes partway through a reporting period needs to come off the WIP schedule cleanly — its accumulated cost has become a completed-job cost, not an open one, and leaving it on the schedule by mistake overstates total work in progress.
A schedule built from current job status, rather than from a fixed list maintained by hand, handles that transition automatically — a job that closes simply stops appearing on the next schedule, without anyone having to remember to remove it.
Who this is for
Shop controllers closing the month
A current cost picture across every open job instead of chasing invoices one by one.
Owners pricing the next similar job
A real, up-to-date sense of what jobs in progress are actually costing, not a guess.
Accountants preparing a WIP journal entry
Matched cost data as an input, rather than reconstructing it from a stack of invoices.
Bookkeepers serving multiple manufacturing clients
One repeatable process across every client's job list and invoice format.
Feeding your accountant's WIP entry, not replacing it
A common worry when a shop introduces a systematic WIP schedule is that it's a step toward automating away the accountant's judgment on the actual month-end entry. Worth addressing directly, because it's a reasonable concern and it shapes how the schedule actually gets used.
This schedule doesn't post any journal entry, doesn't decide a percentage of completion, and doesn't touch the general ledger. It's a read-only rollup of matched invoice cost per open job — the input an accountant would otherwise have to assemble by hand before applying their own judgment to the actual entry.
Being explicit about that boundary — a cost input, not a posted number — tends to matter more to an accountant than any technical detail about how the matching works, and it's worth stating plainly when introducing this to a finance team that hasn't used automated matching before.
Framing it as time saved on the assembly step, with the judgment step unchanged, tends to land better than framing it as a replacement for that judgment — even though the underlying schedule is identical either way.
Starting with a handful of open jobs, not all of them
A shop with forty open jobs at any given time can find the idea of building a full WIP schedule daunting enough to never start. A more realistic path is beginning with a handful — five to ten jobs that already have clean, consistently coded invoices — and using that as a proof of concept before extending to the rest.
That first small batch answers the practical questions that matter before scaling up: how cleanly do the invoices actually match, how much manual correction do the flagged lines need, and how does the resulting schedule compare to whatever partial WIP picture existed before. Answers from ten jobs transfer reasonably well to the other thirty, whereas trying to onboard all forty simultaneously multiplies every early surprise by forty.
Jobs with straightforward, well-referenced suppliers are natural first candidates, not because the messier jobs don't matter, but because starting with the easy cases builds a working process before it has to handle the harder ones.
What a controller actually wants from the schedule
A single grand total across all open jobs answers one question and raises several more — it's rarely the actual deliverable a controller wants to see on its own.
A total across all open jobs, for the headline WIP figure.
A per-job breakdown, so any single job's accumulated cost is visible on its own.
A comparison against each job's original estimate, where one exists.
A flag on any job whose cost moved sharply since the last schedule.
Four layers, not one flat number — because a controller asking “where does WIP stand this month” is really asking several distinct questions at once, and a schedule that only answers the first one leaves the rest to be reconstructed by hand whenever someone follows up.
The per-job breakdown in particular tends to get more use than expected once it exists — a controller who has never had a clean, current view into which open jobs are running heavy on cost often finds that comparison alone valuable, independent of anything the total says.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Job and cost data are never used to train AI models.
Full details are on the security page.
A smaller worked example, in detail
Take three open jobs at a mid-sized job shop, scheduled at month end. Job A draws only from one materials supplier with clean, consistently coded invoices. Job B includes an outside heat-treat step whose invoice hasn't arrived yet. Job C shares a freight delivery with two other open jobs, all covered by one invoice.
Job A's cost rolls up cleanly — every invoice matched, no flags. Job B's schedule line reflects only what's been invoiced so far, understating its true cost until the outside-processing invoice eventually arrives — a known and expected gap rather than an error, since the schedule can only reflect matched invoices, not costs that haven't been billed yet. Job C's freight line is correctly split across all three jobs on the shared shipment rather than landing entirely on one.
The resulting schedule combines all three cleanly: A needs no manual intervention, B is flagged as likely understated pending an outside-processing invoice, C's freight allocation needs no correction because it split automatically. None of the three jobs required a change to how invoices are entered to get there.
Scaled up to twenty jobs instead of three, the proportions hold roughly steady: most jobs schedule cleanly, a handful carry a known pending-invoice gap worth flagging, and the total review time stays small relative to the alternative of manually assembling twenty separate cost pictures by hand.
That ratio — most jobs clean, a few with a known gap — tends to hold regardless of how many jobs a shop has open, which is exactly what makes the approach scale rather than getting proportionally harder as the job count grows.