Production After the Bill of Materials
Bills of materials and assembly orders are built; yield variance, standard cost and a production schedule stay on your own sheet. This is what a small Kenyan factory can do on that basis — rewritten on 2026-10-01, because the first version of this article was written when the recipe itself was the open item.
A miller buys three tonnes of maize, mills it, bags flour, and sells it. Somewhere in that sentence is the entire discipline of manufacturing accounting, and the object most software puts at its centre is the recipe: this much maize makes this much flour, so measure the run against the recipe and the difference is your yield. Every serious manufacturing system is built around that object.
We now hold it, in its plain form. A bill of materials lists the components of a finished item and the quantity of each per output quantity, and a component can carry its own bill, so a multi-level product is built one level at a time, sub-assemblies first. An assembly order builds against it: raising the order moves nothing, and completing it takes the components out of one warehouse and puts the finished item in, all or nothing, with the actual cost of what was consumed rolled into the finished item. What the plain form leaves to you is the measurement layer a processor manages on — a yield factor, a variance against standard, a recipe version with an effective date, a work-in-progress stage, labour and overhead in the product cost, and a production schedule. This article is about where that line falls, because it falls in a different place for a fabricator, a miller and an assembler.
Why this article was rewritten
The first version, written in August, said the bill of materials was not in the product, and at the time that was accurate. On 2026-10-01 bills of materials, assembly orders, stock reservations and serial numbers on every movement shipped, and an article telling a miller the recipe could not be held would now be wrong in the other direction. The argument is the same one — the two ends are strong — with the middle redrawn where it now stands.
What a bill of materials actually buys you
It is worth being precise about which parts of that object are in the product, because “a BOM” sounds like one feature and it is really four. Two of the four are built.
- An expected quantity — built. The bill says what one output quantity consumes, so the standard is on the record. What is not computed is the variance: an assembly order consumes exactly the bill's quantities, so a run that really used more shows the overrun as a separate issue, and nothing sets the two side by side.
- A version with an effective date — still yours to keep. Recipes change: a supplier substitution, a moisture adjustment, a reformulation. Editing a bill here changes it going forward, and orders already raised keep their own copy of the lines; asking what the recipe was in March, when March's margin looks wrong, means a dated copy outside the system.
- A production order to issue against — built, as the assembly order. It turns material leaving the store into consumption of a named product, refuses a fraction of a component counted in pieces (one measured in kilograms or litres takes up to three decimals), and will not touch stock reserved for a customer. Confirming a sales order reserves the goods it names; ring-fencing the raw material behind it is a manual hold, with an optional expiry.
- Yield and consumption variance — still on your sheet. The report every processor actually manages on, and the by-product receipt that goes with it.
The layers underneath production — landed cost, quality holds, batch traceability — are the harder half to get right, and they are done. The recipe and the build order now sit on top of them. The measurement layer, yield against expectation, is the one still on a sheet.
What you can do now, precisely
Material leaves the raw store by one of three routes. The first is an assembly order against a bill: completing it takes every component out of one warehouse and puts the finished item in, all or nothing, and the finished item's moving-average cost absorbs the actual cost of what was consumed. Serial-tracked components and finished goods are named on the order, and an unbuild reverses it. The second, for a pack or recipe that is used up rather than built into stock, is issue every component: one click raises a single pending check-out with every line for the chosen number of uses. The third is an ordinary stock issue, and that issue carries more than most people expect. It requires a reason chosen from your own list. It can be charged to a job, at which point the job carries the material at the item's cost. It can come from a specific warehouse and bin, and from held stock where you are working from a reserved allocation. It moves the stock and posts the accounting entry at the moment it is approved, not when it is requested. And above a value you set, it cannot be approved without an elevated permission.
So the record you end up with is still not a consumption variance. It is something different and, for a certain kind of manufacturer, better: a dated, reasoned, attributable, approved account of exactly what material left the store, who released it, and which job or which build carried the cost — with the bill beside it saying what the build should have used.
What the system holds
Recorded as it happens, by the person doing it.
- A bill of materials per finished item, with components at a quantity per output quantity, and sub-assemblies built first on their own bills.
- Assembly orders that build and unbuild, all or nothing, rolling the components' actual cost into the finished item.
- Stock reserved behind a confirmed sales order, backorders filled oldest-first, and manual holds with an optional expiry.
- Every issue out of the store, with a reason from your own list and an approver.
- The material charged to a job at the item's cost, so the job accumulates what it actually consumed.
- Batch and lot identity on the input, with true landed cost written onto the batch.
- Quality holds that exclude quarantined, expired or damaged stock from being issued at all.
- The finished goods received back onto stock as their own batch, traceable onward to the customer.
- Blind cycle counts with valued variance against the store.
- The recall chain in both directions, from a supplier lot to every customer who received it.
What stays on your production sheet
None of this is computed anywhere.
- The variance against the bill. The bill holds what a run should consume; the difference from what it did is your arithmetic.
- The run's unit cost on a variable-yield output. An assembly order carries the components' cost onto what it builds. A milling run whose output weight is known only at the end is received as an ordinary receipt, and the job cost divided by good output is your division, typed onto the check-in line as its unit cost.
- Yield percentage and its trend, by product, by shift, by supplier lot.
- Labour and overhead absorption. A build carries material cost; time and factory overhead stay on the job and on your sheet.
- The inputs behind a sales order. A confirmed order reserves the goods it names; the raw material behind them is ring-fenced with a manual hold.
- By-product valuation. Bran, cake and offcuts can be received onto stock, at a value you decide.
- Rework. It goes back on as an adjustment, not as recorded input against an expectation.
What crosses the seam
- Actual material cost per job, which is the input to your yield sheet rather than a substitute for it.
- The batch identity, which is what lets a yield figure be attributed to a specific supplier lot.
- The landed cost on the batch, which is the only number in this whole picture that is genuinely hard to compute by hand.
The honest summary of the seam: we will tell you accurately what a run cost. We will not tell you what it should have cost. If your margin problem is that you do not know your input costs, that is solved here. If your margin problem is that yields are drifting and nobody can say by how much, it is not.
Which manufacturers this actually fits
This is the section a vendor normally leaves out, and it is the only one that matters if you are evaluating.
Four kinds of factory, honestly assessed
| What your operation needs | Job shop / fabricator | Processor / miller | Food & beverage | Assembly |
|---|---|---|---|---|
| Know the true landed cost of imported inputs | Yes | Yes | Yes | Yes |
| Charge material to a specific job at cost | Yes | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
| Batch traceability and a recall chain | Partly — configurable by you | Yes | Yes | Partly — configurable by you |
| Quality holds enforced at the allocation | Yes | Yes | Yes | Yes |
| Measure yield against an expected quantity | No | No | No | No |
| Hold a recipe and build stock against it | Partly — configurable by you | Partly — configurable by you | Yes | Yes |
| Build a multi-level product, sub-assemblies first | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
| Reserve finished goods behind a confirmed order | Yes | Yes | Yes | Yes |
| Reserve raw material behind a confirmed order | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you | Partly — configurable by you |
Built and maintained Configurable by you, not maintained by us Not built
The pattern in that table is the whole answer. A job shop — a fabricator, a furniture workshop, a metal shop building to order — fits well, because its natural unit of cost is a job and it rarely has a fixed recipe anyway. A processor or miller gets the costing and traceability half and the recipe held as a bill, and runs yield on a sheet — workable, and still the thing they most wanted. Food and beverage with a fixed recipe and a countable output fits the assembly order directly. An assembler now has the bill and the build, one level at a time; what it leaves to you is the planning layer — exploding one finished order into every sub-assembly and purchase, scheduling the work, and a work-in-progress stage for a build that spans days. That layer has two honest routes: a dedicated planning system alongside this one, or the explosion and the schedule commissioned here as a scoped build on top of the bills you already hold. Which is right depends on how many levels deep your product goes and how much of your cost is material.
If your unit of work is a job
This fits, and the job coding is the point
Fabricators, workshops, made-to-order producers. Charge material to the job, add time entries, add purchases, and the job's cost is built from source records rather than estimated. No recipe was ever going to help you.
If your unit of work is a batch with a known recipe
Hold the recipe as a bill, run yield yourself
Millers, bakers, dairies, feed and oil processors. Landed cost, holds and the recall chain are genuinely strong and are the expensive things to build, and the recipe now lives beside them as a bill of materials. Yield goes on a sheet for now, fed by the actual consumption figures. Budget for that discipline being manual.
If yield variance is the reason you are buying
Say so in the first call
We would rather scope the yield and variance layer properly as a build on top of the bills you hold, or tell you to buy a manufacturing-specific system, than have you find that out in month three. That is not modesty — a factory that bought us for yield reporting is a factory that will leave.
Running yield on a sheet, properly
If you are in the second case, the manual discipline is worth doing well rather than grudgingly. Three rules make the difference between a sheet that catches drift and a sheet that gets abandoned in week five.
-
Make the run the unit, and give it a number
Open a job per production run — not per month, per run — and charge every issue to it. The job number becomes the key that joins your sheet to the system's cost figures, and without a shared key the two records drift apart within a fortnight.
-
Take actual consumption from the system, never from memory
The issues charged to that job are your actual input, already costed and already approved. That is the one column you should never be typing twice. Your sheet supplies the expected figure and the output weight; everything on the input side is a lookup.
-
Record the output as a receipt the same day — with the run's cost on it
Finished goods come back onto stock as their own batch, and the check-in line has a unit cost field. Compute total job cost divided by good output and type it there; the receipt's journal posts at that figure and it blends into the item's moving-average cost. Leave it blank and the output comes in at the item's current cost, which for a manufactured good is usually a number nobody has revisited. A product with a fixed recipe and a countable output can skip this step entirely: build it on an assembly order and the components' cost lands on the finished item on its own.
One milling run, costed from records and yielded on a sheet
Three tonnes in, 2,760 kilos of flour out. The 92% is arithmetic you did, and the expected 94% you were measuring against lives in your own record. The input side — the landed cost of two separate maize batches, the packaging, the labour — came from the system without anybody retyping it, which is the real value here. The output side does not: that 69.46 is a division somebody does and types onto the check-in line, where the receipt then posts at it. That manual step is the weakest link in this whole arrangement — a blank cost field falls back to the item's current cost without complaint — and it is the one to put in somebody's job description rather than hope for. An assembly order would remove it, at the cost of consuming the bill's quantities rather than the run's actual ones — which for a variable-yield mill is the wrong trade.
What AWRA OpsHub does today
- Bills of materials — components at a quantity per output quantity, a component with its own bill built first as a sub-assembly, and a guard against a bill that contains itself. On the web, the API and the mobile app.
- Assembly orders that build and unbuild. Completion takes the components out of one warehouse and puts the finished item in, all or nothing; the finished item's moving-average cost absorbs the actual cost consumed, and value moving between inventory accounts is journalled.
- Quantities in each item's own unit — components counted in pieces must come to whole numbers, components in kilograms or litres take up to three decimals, and a count-unit component that would need a fraction is refused, never rounded — and a build cannot draw on stock reserved for a customer.
- A cost on a finished-goods receipt. The check-in line takes a typed unit cost, the receipt's journal posts at it, and it blends into the item's moving-average cost, so a variable-yield run reaches its output at the figure you worked out.
- Issue every component for a pack or recipe that is used up rather than built: one pending check-out carrying every line for the chosen number of uses, approved like any other.
- Stock reservations and backorders — a confirmed sales order reserves its stock at its warehouse, backorders fill oldest-first, and manual holds take an optional expiry.
- Serial numbers on every movement, named on builds, issues, sales, transfers and returns, with every status change traceable per unit.
- Stock issues that require a reason from your own list, and that can be charged to a job at the item's cost.
- Approval before the stock and the ledger move, and an elevated permission required above a value you set.
- True landed cost — freight, duty and clearing allocated across a receipt by value or by quantity, written onto the batch and carried into weighted average cost.
- Quality holds that are enforced by the allocation query itself, so quarantined, inspection-pending, damaged, expired and returned stock cannot be issued or sold.
- Batch and lot identity, with expiry, manufactured and received dates, supplier and source purchase order.
- Traceability in both directions, from a supplier lot forward to every customer and from a finished batch back to its inputs, with a recall status per batch.
- Stock by warehouse and bin, transfers between them with shrinkage recorded, and blind cycle counting with valued variance.
- Custom fields on items, adjustments and transfers, so a grade, a moisture reading or a run number can be captured and required.
More we can add to your workspace
- A yield or scrap factor on a bill of materials, and the yield and consumption variance against it, by product, by shift and by supplier lot.
- Bill versions with effective dates. Editing a bill changes it going forward and raised orders keep their own copy of the lines; a dated revision history is the build.
- A multi-level explosion and material requirements planning, so one order for a finished product raises every sub-assembly and purchase behind it. Each level is built on its own order today, sub-assemblies first.
- Routings, work centres and a production schedule.
- A work-in-progress stage on an assembly order, for a build that spans days. Completion is instant today.
- Automatic reservation of the raw material behind a confirmed order. A sales order reserves the goods it names; the inputs are ring-fenced with a manual hold.
- Lot genealogy through a build, so a finished batch carries the input lots its assembly order consumed.
- A kit sold at the till or on an invoice drawing down its components. A kit sold today is its own stock item, built ahead on an assembly order or issued as one check-out.
- A by-product receipt against a run. By-products go onto stock as an ordinary receipt at a value you decide.
- A rework as recorded input. It re-enters as an adjustment, which is bookkeeping rather than measurement.
- A job's cost carried onto its output by itself, so a receipt against a job takes the job's accumulated cost divided by good output without anybody doing the division and typing it in.
- Standard costing, and labour and overhead absorption into product cost — the accounting consequence has its own article.
- A weighbridge, moisture or grade capture at receiving, and a supplier payment computed from a verified weight.
This ledger was rewritten on 2026-10-01, and updated on 2026-10-15 when a receipt gained a cost of its own. Earlier, six of our manufacturing articles were written as though the recipe existed before it shipped, and this one then described the product as it stood in August for six weeks after the work began — the same mistake in opposite directions. The check we run before any capability claim ships covers both: find the class, the column or the migration that implements it, and write the sentence the code supports.
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 needsHolding a bill is not the same as having a good one — the discipline behind it is worth running carefully, because an assembly order consumes exactly what the bill says. What one contains, how single-level differs from multi-level, and how to write your first five from a supervised run is the bill of materials explained. Read that for the method; this page is about where the system's half of it stops.
Our take
If you make things to order, this fits well and the job is still your unit of cost. If you run fixed recipes with a countable output, hold them as bills and build on assembly orders — the cost lands on the finished item without anybody retyping it. If you run variable-yield batches, take the costing, traceability and the bill, and accept that yield lives on a sheet fed by real consumption figures. If yield variance or production planning is the reason you are shopping, say so: commission that layer on top of the bills, or buy a manufacturing system and let us handle the store, the imports and the recall chain underneath it.
Test the two ends, then one build
Bring one imported receipt with freight and duty, one supplier lot you would need to recall, and one product recipe to set up as a bill and build. The first two are the hard things to do by hand; the third shows you exactly where the system's half of production stops.
See AWRA for manufacturing