A formulation engineer at a personal care manufacturer makes what feels like a small change. The fragrance loading on a body wash drops from 1.5 percent to 1.4 percent because procurement found a more concentrated supplier. The engineer updates the bill of materials in the system, saves it, and moves on. Two weeks later, the cost accountant runs the period close and finds that the cost of goods sold for the entire body wash line has shifted in a way that does not match any of the inventory movements. Every batch produced before the change now appears in the ledger with the new lower fragrance cost rolled in. The historical numbers have been silently rewritten.
This is one of the most common BOM versioning mistakes, and it is almost entirely invisible until a finance review or an audit surfaces it. The system did exactly what the engineer asked. It updated the active BOM. The problem is that the active BOM is also what the historical cost rollup references when it recalculates, so a single edit can propagate backward through every batch that ever used that recipe. COGS accuracy does not survive this kind of editing model, and neither does the variance reporting that depends on a stable comparison baseline.
Why Editing the Active BOM Is the Default Mistake
Most homegrown systems and many older ERPs treat the BOM as a single record that can be edited in place. There is one row per product, with child rows for the components, and the user with the right permissions can change any of them at any time. This is convenient for the engineer who needs to make a change, and it appears to work as long as nobody looks closely at what happens to the historical data afterward.
The breakdown comes from a feature that is supposed to be helpful: cost rollups that recalculate dynamically. When component prices change or component quantities change, the system recomputes the per-unit cost of the parent product. If that recomputed cost is then used to value the on-hand inventory and to back-cost the production runs that have already happened, every change to the BOM moves history. A run that was costed at 4.82 dollars per unit on the day it completed might appear in the system at 4.71 dollars per unit a month later, not because anything physical changed, but because the BOM was edited and the rollup propagated.
This is not a theoretical concern. It is how variance reports stop matching the general ledger. It is how the same product appears at different costs in two reports run a week apart. It is how auditors flag inventory valuation as unreliable. The root cause is the same in every case: the BOM was treated as a mutable record rather than a versioned artifact, and the cost data that depends on it was never insulated from in-place edits.
The Three-State Model That Fixes the Problem
A defensible BOM versioning model has at minimum three states: draft, active, and archived. A draft is a working copy that can be edited freely. It is not used for any production planning, costing, or material reservation. An active version is the one that current production orders reference. There is exactly one active version per product at any time. An archived version is a frozen historical record that cannot be edited but can still be read for audit and traceability.
Engineering changes flow through these states explicitly. The engineer creates a new draft, makes the formulation change, runs whatever review or approval process the organization requires, and then activates the draft. Activation moves the previous active version to archived and promotes the draft to active. The archived version retains its full structure and component costs as of the moment it was archived, so any production order that was confirmed against it continues to reference accurate historical data. The new active version takes over for any production order confirmed after the activation timestamp.
This is the bom draft active archived model that makes engineering change control workable in practice. Engineers can prepare changes without fear of breaking in-flight production. Operations can see exactly which version is current. Finance can trust that historical costs do not move underneath them. The state transitions are auditable events, with timestamps and actors, so the question of when a change took effect has a single defensible answer.
Locking the BOM at Production Order Confirmation
Versioning the BOM is necessary but not sufficient. The second piece is locking each production order to the specific BOM version that was active at the moment the order was confirmed. Without this lock, a production order created against version 7 of a BOM could end up consuming materials according to version 8 if the BOM is activated mid-flight. The cost rollup, the material reservation, and the variance calculation would all reference different versions, and none of them would agree.
The production order BOM lock works by recording the BOM version identifier at confirmation time and using that identifier for every subsequent operation against the order. Material requirements are calculated from the locked version. Reservations are made from the locked version. The expected consumption that the operator sees on the run sheet is from the locked version. The variance calculation when the run completes compares actual consumption to the locked version's expected. The cost rollup that values the produced inventory uses the locked version's component costs.
If a new BOM version is activated while a production order is in flight, the in-flight order continues against its locked version. New production orders confirmed after the activation will lock to the new version. The system can run both versions in parallel, with each order referencing the version that was current when it was confirmed. This is the only way to handle the realistic case where engineering changes happen while production is running, which is most weeks in most plants.
What Cost Rollups Should Actually Do
Cost rollups are useful when they answer the right question. The right question is: what does this product cost to make right now, given current component prices and the active BOM version. The wrong question is: what did this product cost to make in March, recomputed using today's BOM and today's component prices. The first question is forward-looking and supports pricing, margin analysis, and bid generation. The second question is meaningless, because it mixes historical reality with current data and produces a number that does not correspond to any actual production event.
A correctly versioned system computes rollups against the active BOM for current planning purposes and against the locked BOM for any historical analysis. When a finance team asks for the cost of a batch that ran in March, the system retrieves the BOM version that the production order was locked to, looks up the component costs as of that period, and reconstructs the cost from the immutable record rather than recomputing it from scratch. This is one of the cases where the immutable audit ledger discussed in the post on movement immutability earns its keep, because the actual material movements during the run are what get costed, not a hypothetical bill of materials applied retroactively.
The same principle extends to run variance. Variance against the locked cost is meaningful because it compares two stable numbers: the expected cost per unit derived from the locked BOM, and the actual cost per unit derived from the consumed materials and their costs at the time of consumption. Variance against the active BOM after the BOM has been edited is noise, because it includes the effect of the edit alongside any real operational variance.
How Engineering Change Orders Should Flow
Engineering change orders, often called ECOs, are the formal mechanism for proposing and approving BOM changes. In a versioned system, the ECO process maps cleanly to the draft state. An engineer creates a draft BOM version that captures the proposed change. The draft can be reviewed by quality, operations, and procurement before activation. Approvals are recorded as part of the version metadata. Activation is the act that ends the change order and makes the new version live.
This is also the natural place to enforce business rules around change control. Some changes might require multiple approvers. Some might require a regulatory review. Some might be allowed only at certain times of the month to avoid disrupting active runs. All of those rules are easier to enforce against a discrete state transition (draft to active) than against an in-place edit that has no obvious moment to gate. The change control discipline becomes a feature of the state machine rather than a procedural overlay that people remember to follow most of the time.
The connection to procurement is similar. When a draft BOM is being prepared, procurement can see the proposed component changes and start sourcing or repricing without waiting for activation. The draft is visible but not yet authoritative. When activation happens, the new requirements become the basis for material requirements planning, including the calculations covered in the post on MRP planning horizons. The handoff from engineering to procurement becomes a data event rather than an email.
Why This Matters Beyond Cost Accounting
The COGS impact is the most visible consequence of getting BOM versioning wrong, but it is not the only one. Variance reporting depends on a stable expected baseline, and an editable active BOM destroys that baseline. Quality investigations depend on knowing exactly what formulation was used in a specific batch, which is impossible to determine after the fact if the BOM has been edited in place. Regulatory submissions in regulated industries require demonstrating that the formulation under review is the one that was actually produced, which again requires a frozen historical record.
The compounding effect across these use cases is what makes BOM versioning mistakes so expensive over time. A single edit that nobody notices in the moment can corrupt cost history, variance analysis, quality records, and audit response simultaneously. The corruption is hard to detect because the new numbers look plausible. They are just wrong, in the sense that they do not correspond to what actually happened on the production floor.
The fix is not procedural. It is structural. A BOM that can be edited in place will eventually be edited in place, regardless of how strict the change control policy is, because the system permits it. A BOM that exists in draft, active, and archived states cannot be edited in place, because the data model does not allow it. The discipline is enforced by the design rather than by training, which is the only kind of discipline that holds up under pressure. Engineering change control becomes a property of the system rather than a hope.
What Honest COGS Looks Like
Honest COGS in a manufacturing operation has three properties. It does not move once a period is closed, regardless of subsequent BOM or price changes. It can be traced from the period total back to the individual production runs and from there to the actual material movements that fed those runs. And it agrees with the variance reporting, the inventory valuation, and the general ledger without manual reconciliation. All three properties depend on a versioned BOM with locked production orders and an immutable consumption record.
Manufacturers that get this right stop having month-end conversations about why the cost numbers do not tie out. They start having month-end conversations about what the variance is telling them, because the variance is finally a clean signal rather than a mix of operational reality and accounting artifacts. The BOM is no longer a moving target. It is the reference that everything else is measured against, which is what a bill of materials was always supposed to be.
FalOrb helps manufacturers protect COGS accuracy through draft, active, and archived BOM versioning with production order locking. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation. More at falorb.com.