The cost of the run is assembled after the fact, in a spreadsheet, from three exports
The components came out of stock, so their value is in one report. The hours were logged somewhere, if they were logged, and they are in another. The freight on the inbound steel and the outside plating charge are in somebody's head or in an email. Once a month those get joined by hand into a workbook that produces a unit cost, and that unit cost is what the margin conversation runs on. It is nobody's fault and it is not sloppy, the numbers genuinely live in three places. The cost is only wrong in the specific way a joined-by-hand number is always wrong: it is a month old, nobody else can reproduce it, and when it moves, the reason it moved is a second investigation.
What you get with manufacturing costing
A finished unit priced from its own run. When a manufacturing order is costed, the value of the components it consumed is taken from their own recorded stock value, the cost of every work order on that order is added, computed from the tracked time intervals at the work centre's hourly rate, and a per-unit extra cost you can type on the order itself is added on top, for the charges the bill of materials was never going to know about. That total is what the finished unit is priced at, and the cost records behind it are reachable from the order in one click rather than by joining two reports.
Where a run produces byproducts as well as a main product, each byproduct takes a set percentage share of the run's total cost and the main product is priced at the remainder. Co-products stop being free.
Machine time also lands where cost centres can see it. When a work order's duration is set or recomputed, it is valued at the work centre's hourly cost and spread across that work centre's analytic distribution as analytic lines, tagged to the manufacturing order, in hours, so the same hour appears both in the unit cost and against the cost centre that owns the machine. Cancel the work order and the lines come back out. The expense account can be set per work centre, or left to fall through to the finished product's own.
And the runs that are still open when the period ends do not simply miss it. You post a work-in-progress entry for the orders you select, confirmed, in progress or awaiting close, valued from the components already picked as at a date you choose plus the work order time logged before that date. It is a posting a person makes deliberately, not a job that runs on its own, and the reversal date is required, not optional: the entry and its reversal are booked together, which is the part that gets forgotten when this is done by hand.
Where manufacturing costing comes from
All of it is already in Odoo Community. Nothing to install beside it, no Enterprise tier to unlock, no extra per-user fee, and it runs on infrastructure you own. The costing layer that assembles all of this is in the core, not a paid add-on billed at renewal, and that difference is the product.
One boundary is worth naming here rather than leaving to be found: this prices products carried at FIFO or average cost. A product held at standard cost keeps its standard price, and nothing here computes the variance between the two or reports on it.
This page describes how a run is costed and posted. It does not describe planning: there is no finite-capacity scheduling and no advanced planning anywhere in what we install, and nothing here estimates what a run will cost before it runs.
What is work in progress in manufacturing accounting?
Work in progress is the value tied up in production runs that have started but have not finished at the moment you are reporting. The components have left raw materials and the finished goods do not exist yet, so without a work-in-progress entry that value is briefly nowhere: inventory is understated, and the labour and overhead consumed so far have hit the period as expense with no asset to sit against. The entry moves that value into a work-in-progress account as at the reporting date and is reversed immediately afterwards, because it is a point-in-time statement about an unfinished thing rather than a permanent posting the run will cost itself properly when it closes. Booking the reversal at the same time as the entry is the part most often skipped by hand, and it is what stops last month's snapshot from quietly persisting into this month's balance.
What goes into the cost of a manufactured unit?
Three things, and only the first is obvious. The material cost, the value of the components actually consumed, taken from their own valuation rather than from what the bill of materials said they would be. The conversion cost, the time spent at each work centre, valued at that work centre's hourly rate, which is what turns machine and labour time from an overhead pool into something attributable to a specific run. And whatever else attached to this run and to no other: an outside plating charge, a one-off tooling cost, freight on a substituted component. That third category is the one that escapes, because the bill of materials has no line for it and there is no obvious place to put it, so it either lands in overhead and is smeared across everything or it is remembered in a spreadsheet. A cost model that has no per-run place to type it will be wrong in exactly the cases somebody is asking about.
How should the cost of a production run be split when it also produces byproducts?
By assigning each byproduct a defined share of the run's total cost, with the main product taking the remainder. The alternative, leaving byproducts at zero and loading the entire cost onto the main product, is the common default and it distorts two decisions at once: the main product looks more expensive to make than it is, and the byproduct looks like free inventory, which makes it look profitable to sell at any price. Because there is no physically correct answer to how a joint cost divides, the split has to be a stated percentage that someone chose and can defend, usually on relative sales value, rather than something the system infers. The requirement on the system is narrow but real: hold the share per byproduct, apply it at the moment the run is costed, and reduce the main product by exactly what it gave away.
Why should machine hours be posted to analytic accounts as well as into the product cost?
Because they answer two different questions and only one of them is about the product. Rolled into the finished unit's cost, an hour of machine time tells you what that unit cost to make. Posted to an analytic account, a cost centre, a department, a line, the same hour tells you what that resource consumed this month, across every product that touched it. Without the second view, the question "what is this cell costing us" can only be answered by summing hours out of individual production records, which is why it usually gets answered from a capacity assumption instead. The important property is that both views come from the same logged interval rather than from two separate entries: an hour recorded once, valued once, and landing in a product cost and against a cost centre by construction, cannot drift apart the way two independently maintained numbers will.