BOM software in India with multi-level cost rollup

A Bill of Materials (BOM) lists every component — raw material or sub-assembly — that goes into a finished product, with the quantity, unit, and wastage for each line. BOM software stores those recipes in one place and rolls the cost up automatically. Indian manufacturers usually start with BOMs in spreadsheets, but a spreadsheet BOM breaks the moment a steel, polymer, or yarn price moves: someone has to re-key the new rate into every cost sheet that uses it. ReadyBooks.ai stores the recipe once and recomputes the rolled-up cost for you, so when a copper price changes you see the new cost on every product that uses copper without touching a single formula. That is the difference between quoting in hours and quoting in minutes with today's prices.

Yes. Any component in a BOM can itself be a sub-assembly with its own BOM, and those sub-assemblies can nest to any depth. The nesting limit is configurable per tenant and defaults to up to 8 levels, which covers most discrete-manufacturing assemblies. When you roll up the cost of a top-level product, every sub-assembly line resolves to its child BOM's active version cost, so the rollup walks the whole tree automatically. A cycle-detection check prevents a BOM from referencing itself directly or indirectly, so you cannot accidentally build an assembly that contains itself.

Standard cost rolls up as overhead plus, for each line, (quantity ÷ output quantity) × component unit cost × (1 + waste%). Raw-material lines use the item's weighted-average cost (WAC). Sub-assembly lines resolve to the child BOM's active version cost, so the rollup is recursive down the whole tree. When you change one input cost — say a raw material's WAC moves after a new purchase — every BOM that depends on it recomputes up the tree in a cascade. You do not re-run anything by hand; the dependent costs follow the change automatically.

Yes. Every BOM has versions that move through a lifecycle: Draft, Active, Superseded, and Archived. You activate a version with an effective-from date, and you can schedule a future version that flips live automatically on its date — useful when a recipe change is agreed now but should only apply from the start of next month. Critically, the recipe a production order used is frozen to the version that was active when the order was created. That means revising a BOM never rewrites the cost or component list of orders you already ran, so historical records stay accurate for costing and audit.

Nothing changes on them. When a production order is created, ReadyBooks.ai freezes the BOM version that was active at that moment onto the order. Later edits — a new active version, a scheduled future version, a different component, a changed wastage percentage — apply only to orders created after the change. Orders you already ran keep their original recipe and their original rolled-up cost. This is what keeps month-on-month cost comparisons honest and keeps an auditor from finding a finished order whose recipe no longer matches what was actually consumed.

Use the where-used view. Pick any component or sub-assembly and ReadyBooks.ai shows every parent BOM it feeds into. This matters when a supplier discontinues a part, a price jumps, or a material is reclassified: before you commit to the change you can see exactly which finished products are affected. Combined with cascade recompute, you can change one input and immediately understand both the blast radius (where-used) and the cost impact (the rolled-up cost on every affected product).

Yes. The version diff compares two versions line by line and shows the cost deltas alongside the component changes. So you can see not just that a line's quantity or wastage changed, but what that did to the rolled-up cost. This is the fastest way to answer 'why did this product get more expensive between March and May' — the diff puts the recipe change and the rupee impact side by side instead of forcing you to reconstruct old cost sheets.

Yes. Cost visibility is permission-gated. You can hide per-line costs, the rolled-up totals, and margins from staff who should not see them — for example a shop-floor operator who needs the recipe and quantities to run a job but has no business reason to see your material costs or markup. The same BOM screen shows the recipe to everyone and the money only to the people you authorise.

Quoting from a spreadsheet BOM is slow because every price change forces a manual recost: you re-enter rates, re-check formulas, and hope nobody fat-fingered a cell. ReadyBooks.ai rolls the cost up the moment any input changes, with today's weighted-average prices, the yield, and the wastage already baked into the formula. So when a customer asks for a price, you open the product, read the current rolled-up cost, add your margin, and send the quote — minutes instead of hours, and with numbers you can defend because they trace back to actual purchase costs.

Yes. You create a production order against a specific BOM version. Raw material is consumed per the recipe and finished goods are added to stock. Because the order freezes the version it was created against, the consumption and the costing always match the recipe that was live at the time — even if you revise the BOM later. The BOM header itself is never hard-deleted; when a recipe is retired it is archived, so the history stays intact for any order that referenced it.