The Cost That Was Never Work in Progress
Material issued to a job used to be expensed the moment it left the store, and the finished output came back onto the books as a debt to nobody. Both are now fixed, and what is left is more interesting than either: the ledger will tell you what a job consumed and what its output was valued at, and it will not pretend those two numbers agree.
This is the article for whoever prepares your accounts, and it used to be the least comfortable one in the manufacturing set. The operational picture — what you can do without a bill of materials — was always defensible and in places genuinely good. The accounting picture underneath it had two specific defects that a manufacturer would meet in their first month. Both have since been fixed, and this article has been rewritten rather than quietly deleted, because how they were wrong is the useful part.
What replaced them is not a manufacturing accounting module. It is narrower and more honest than that: the ledger now keeps part-finished work on the balance sheet where it belongs, and it refuses to hide the difference between what a job consumed and what its output was valued at. That difference is the subject of the second half of this article.
Fixed: material issued to a job is no longer expensed on the way out
The old entry on an approved stock issue was expenses debited, inventory assets credited, with no exception. For a retailer that is broadly right. For a manufacturer it was wrong in a specific way: the material had not been consumed in the sense the accounts claimed. It had been transformed, and it was sitting on the factory floor as part-finished goods you still owned.
There is now a Work in Progress account, and an issue charged to a job debits it instead of expenses. When output is received back into stock against that same job, the receipt credits Work in Progress. Material moves from raw inventory into WIP, stays an asset while it is being worked on, and leaves WIP as finished stock — which is what a manufacturing system is supposed to do.
The job is the trigger, and nothing else is
An issue only becomes work in progress if it is charged to a project. Issue the same material with no job on it and it still debits expenses, exactly as before — because a write-off, a breakage, a sample and internal consumption really are consumption, and treating them as WIP would be the original error running backwards. There is no bill of materials, no routing and no production order in the product, so the project is the unit of work in progress. If your team does not code issues to jobs, none of this engages, and that is the one thing to check in week one.
What that changed at month-end: part-finished production used to be worth nothing on paper, so closing the books mid-run — and a mill or a bakery is always mid-run — understated profit by the full cost of everything on the floor and understated total assets by the same amount. The worst books belonged to the busiest month, which is the least convenient time to be reading your own numbers wrong.
The old distortion scaled with how busy you were. A factory with nothing in progress had accurate books; a factory running flat out had the worst ones.
Fixed: your own output no longer arrives as a debt
Receiving finished goods back onto stock used to post inventory assets debited, accounts payable credited. The debit was right — the goods are an asset. The credit was not: accounts payable is money owed to a supplier, and there was no supplier. You made the goods. It created a payable to nobody that grew with every production receipt, and because it sat inside the same balance as real supplier debt it was invisible — the creditors listing simply stopped agreeing with the invoices you actually held, by the cumulative value of everything you had ever manufactured.
The credit is now derived from where the stock actually came from. A delivery against a purchase order or a procurement request still credits accounts payable, because somebody genuinely is owed. Output received against a job credits Work in Progress, which is the entry that relieves the job. A receipt with neither — found stock, an opening balance, a customer return — credits a separate Inventory Received Clearing account, so the value is visible as its own balance you can journal out rather than buried in what you owe your suppliers.
Note the ordering, because it is deliberate: a supplier document beats a job. Material bought for a job is still a purchase, and it only becomes work in progress later, when somebody issues it from the store.
What is left: the two figures still do not agree, and now you can see it
The remaining problem is not a defect so much as the consequence of having no recipe: the cost going in and the value coming out are computed independently. The issue is valued at the unit cost stamped on the line when the stock left the store — the same figure the job costing report uses, which is a change in itself, because the ledger used to read the item's buying price at approval time and so disagreed with the job report about the cost of the same movement. The receipt, though, is still valued at the finished item's standing buying price, a field on the item master that has nothing to do with this run and is not updated by it.
So the two numbers differ, and the difference stays behind in Work in Progress after the job's output has been received. That residual is not an error and it is not netted away. It is the variance between what a job consumed and what its output was priced at, and the honest thing to do with it is show it: there is a Work in Progress by Job report that lists what each job has taken in, what has come back out, and what is still sitting there — with a view for exactly the jobs whose output has arrived and which still did not clear.
The residual can be negative, and a negative one is the more informative case. It means the output was valued above what the job consumed, and the usual reason is labour: the standing price on the item master reflects a selling-side view that includes work the ledger never capitalised, because time costed to a job still sits in payroll expenses and nothing carries it into inventory value.
One milling run, as the books record it now
Read that residual rather than clearing it. It is negative — the job was relieved of 25,500 more than it was ever charged — and the explanation is almost entirely the 24,000 of labour, which is in the standing price of 70.00 but never entered the ledger as inventory value because time costed to a job stays in payroll expenses. The remaining 1,500 is margin baked into the item master. Neither the payable-to-nobody nor the material stranded in expenses happens any more; what is left is one number, attributable to one job, that tells you the item master is priced for selling rather than for costing.
How far from correct is this, honestly
Manufacturing accounting, by layer
True landed cost of imported inputs
Freight, duty and clearing allocated across a receipt by value or quantity, written onto the batch and carried into weighted average cost. Genuinely strong, and the hardest of these to do by hand.
Raw material valuation
Stock by warehouse and bin, batch identity, weighted average cost, blind counts with valued variance. Reliable.
Cost attribution to a job
Material, labour and purchases all code to a job, so what a run consumed is recoverable from source records. The attribution works; the accounting treatment of it does not.
Work in progress
Its own asset account, debited by an issue charged to a job and credited by output received against that job, with a per-job report of what is still carried. Engages only where issues are coded to jobs.
The credit side of a production receipt
Derived from where the stock came from: a payable for a purchase, work in progress for a job's output, a named clearing account for anything else. No standing journal needed.
Finished goods valuation
Still received at the item's standing price rather than the run's cost, and still with no labour content. Correcting it means editing the item master before the receipt.
Overhead and cost variance
No absorption, no standard costing, no purchase-price or usage or labour variance. The WIP residual is the only variance figure and it is a by-product, not a costing system.
The shape of that scale is the honest summary of this cluster: attributing cost to a run is solid, the ledger now keeps part-finished work on the balance sheet, and what remains manual is everything about valuing the output — which is the half that needs a bill of materials to do properly, and there is no bill of materials.
The routine that is left
Two of the three standing journals this article used to prescribe are gone, because the postings they corrected no longer happen. What is left is shorter, and it is review rather than correction.
-
Make sure issues are coded to jobs
This is the whole mechanism. An issue with no job on it is expensed, and no amount of month-end work recovers that as work in progress after the fact. If your storekeeper is issuing against a reason but not a project, fix that before anything else on this list.
-
Read the WIP by Job report at close, and ask about the residuals
Jobs still carrying value are legitimately in progress. Jobs whose output has been received and which still did not clear are the interesting ones — the report has a view for exactly those. A large negative residual usually means the item master price includes labour the ledger never capitalised; a large positive one usually means scrap, or output received at a price set years ago.
-
Set the finished item's price before the receipt, not after
The output is valued at the standing price on the item master. That price feeds weighted average cost, which feeds margin on every subsequent sale, so getting it right at the receipt is the difference between one correct number and a quarter of wrong margin reporting.
A WIP balance you cannot decompose is worse than none
That is the reason the per-job report shipped in the same change as the account. The previous version of this defect — a production receipt crediting payables — was dangerous precisely because a wrong figure was hiding inside a correct-looking total. An unexplained Work in Progress balance would repeat that mistake under a new name, so the balance is readable per job, per movement, from the day the account existed.
One thing not to do: do not try to fix the finished-goods valuation by leaving the standing price alone and correcting it in a journal. The standing price feeds weighted average cost, which feeds your margins on every subsequent sale of that item. Get it right on the item master before the receipt, or your gross margin reporting is wrong for reasons that have nothing to do with this.
What AWRA OpsHub does today
- True landed cost allocated across a receipt by value or quantity, written onto the batch and carried into weighted average cost.
- Weighted average cost per item, maintained as receipts land.
- Double-entry journals posted automatically from every approved stock movement, with the source adjustment referenced on the entry.
- The account pair stamped onto the movement when it is raised, from the tenant's chart — so a later change to the chart does not restate entries already posted.
- A selectable inventory account on a receipt, so different classes of stock can hit different asset accounts.
- Material, labour and purchases all attributable to a job, from source records.
- A full chart of accounts you can extend, on top of the system accounts.
- Adjustment reporting by reason and period.
- A work-in-progress account, debited when material is issued to a job and credited when output is received against that job, so part-finished work stays on the balance sheet as an asset.
- Issues valued at the cost stamped when the stock left the store, which is the same figure the job costing report uses — so the ledger and the job agree about the cost of a movement.
- The credit on a receipt derived from where the stock came from: a payable for a purchase, work in progress for a job's output, a named clearing account for found stock, opening balances and returns.
- A work-in-progress report per job, showing what each job has taken in, what has come back out, and what is still carried — including a view for jobs whose output arrived and which still did not clear.
More we can add to your workspace
- Work in progress only engages where an issue is charged to a job. An issue with no project on it is expensed exactly as before, and nothing warns you that it might have wanted to be a job.
- A cost of goods sold account in the default chart — stock issues debit a general expenses account.
- A cost on a receipt. It is valued at the finished item's standing buying price, so the run's actual cost only reaches the output if somebody edits the item master first.
- Labour capitalised into inventory value. Time costed to a job sits in payroll expenses today, and nothing carries it into the finished good.
- Overhead absorption of any kind.
- Standard costing and therefore no cost variance — purchase price variance, usage variance or labour variance.
- A scrap or write-off accounting distinct from an ordinary issue beyond the reason you choose.
- A selectable account pair per issue. It comes from the organization defaults at the moment the movement is raised today, so a per-run treatment is the build.
The two bullets this article was originally written about — a production receipt crediting payables, and a work-in-progress account — were genuine defects rather than pending features, and both are now closed. What remains is the honest scope of a system that does inventory and job costing well and leaves manufacturing costing to a build: the recipe, which values output from what it consumed; absorption, which puts overhead in the number; and a standard, which is what makes variance analysis worth the name. The first bullet is the one to act on, because it is the only one where your own process decides whether the mechanism works at all.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
Still show this article to whoever closes your books before you buy — the two entries it was written about are fixed, and the remaining boundary is easier to plan around when it is read early rather than discovered at year end. The practical test is one question to your storekeeper, not your accountant: are material issues coded to jobs? If they are, part-finished work is on the balance sheet and the residual per job is readable. If they are not, none of this engages and you are back to where this article started.
Bring your accountant to the demo
Ask to see the journal entries a stock issue and a production receipt actually post — the entries, not a report of them — and ask what happens when the same issue is raised without a job on it. It is a five-minute test and it tells you more than any feature list.
See AWRA for manufacturing