How multi-level BOMs in ERPNext structure sub-assemblies for planning and purchasing
Most manufacturers do not build a finished product in one step. A pump may contain a motor assembly, a housing subassembly and a control board, and each of those may be made in-house or bought from a supplier. A multi-level BOM in ERPNext models this by letting a sub-assembly have its own Bill of Materials, which then appears as a single line item in the BOM of the parent product. When planning runs, ERPNext can explode the tree down to raw materials, so purchasing sees what must be bought at each level rather than only the top-level product. Before building anything, the team should decide which sub-assemblies are stocked as items in their own right, because that decision determines whether a sub-assembly needs its own BOM, a purchase item code or both.
The standard BOM form is adequate for a shallow structure with a few levels and a handful of components. The BOM Creator becomes more useful when the tree is deep, when several sub-assemblies share components, or when engineers need to see the whole structure while they edit it. It is a tree-building interface: each node is an item, operations and scrap can be attached where needed, and sub-assembly BOMs are created as part of the same drawing session. It does not replace the underlying BOM records, so reviewers should still open the generated BOMs to confirm quantities, UOM and default settings before they are used by work orders or Production Plans. Confirm in your ERPNext version which BOM fields the Creator exposes, since this differs by release.
Structure is only half of the job. Once BOMs are live, engineering changes will need to reach many records at once, and the BOM Update Tool is the documented route for replacing components and recalculating costs across BOMs. The BOM Comparison Tool lets reviewers check two revisions side by side before a change is accepted, which is useful when purchasing relies on the new component list. Ask your implementation partner to agree a change control step: who approves a BOM revision, which records are updated in bulk, and how a sub-assembly change is tested against open work orders. Without this, a purchasing run can quietly use an outdated tree.
Which BOM build approach fits your product structure
A single-level BOM lists every raw material and purchased part that goes directly into one finished item. This approach suits products with a small number of components, no reusable intermediate assemblies, and little variation between models. ERPNext holds one BOM per finished item, so the setup is quick to build and easy to audit.
- BOM count: One BOM per finished item, so the number of BOMs follows the number of products you sell.
- Costing: The BOM cost equals the rates of its lines plus any operating costs, which makes the cost easy to trace line by line.
- Purchasing: Material requirements come straight from the finished item's BOM, with no intermediate level to explode.
- Maintenance risk: When two products share the same part, that line is duplicated, and a price change or substitution must be edited in each BOM.
Check how many of your products share the same component lines before choosing this approach, because duplicated lines are the first thing to drift apart.
Nested BOMs give each manufactured sub-assembly its own BOM, and the parent BOM lists that sub-assembly as a component. This fits products where sub-assemblies are made in-house, reused across several finished items, or have their own shop floor steps. Planning can then explode the structure level by level, so each assembly's requirements are derived from its own BOM.
- BOM count: One BOM per manufactured sub-assembly plus one per finished item, so the total grows with the number of levels and reused assemblies.
- Costing: A sub-assembly's cost rolls into every parent that uses it, so one correct sub-assembly BOM keeps all parents current after costs are recalculated. Confirm the costing update steps in your ERPNext version.
- Purchasing: Raw material requirements at each level depend on the correct quantities in the lower BOM, so an error low in the tree multiplies upward. Confirm how sub-assembly stock on hand is netted in your planning settings.
- Change control: A revision to a shared sub-assembly is made once, but every parent that uses it needs review.
Check that each sub-assembly you intend to make has a named owner responsible for its BOM revisions and for reviewing the parents it feeds.
BOM Creator lets you build the product structure as a visual tree, placing items, sub-assemblies, quantities and operations in one view. This approach suits products with many levels, frequent engineering changes, and teams that find it easier to review a tree than a list of separate BOMs. The tree is the working design, and the BOMs it produces are what purchasing and production use.
- BOM count: The tree produces the BOMs for the levels you define, so review the generated set before releasing it.
- Costing: The costs shown in the tree depend on the item rates and operating costs entered, so confirm those rates are current before reading the result.
- Purchasing: Editing a level changes the planned requirements for everything beneath it, so check the downstream impact before approving the change.
- Bulk updates: When a change spans many BOMs, the BOM Update Tool updates them in bulk, but test the update on one product first.
Confirm which operation, scrap and sub-assembly options your ERPNext version's BOM Creator supports, and test one product end to end before changing a large tree.
BOM configuration options and when each fits
This table compares the main ways to structure a BOM in ERPNext, from sub-assembly items to operations, scrap and default BOM selection. Read each row for the situation it suits and what it changes for work orders and material requirements. Version-specific behavior should be confirmed against the ERPNext release you run before you commit the design.
| Option | When it fits | What it changes for work orders and material requirements | What to confirm |
|---|---|---|---|
| Sub-assembly item with its own BOM | The sub-assembly is stocked, reused across products or made by a different team or work order | Planning can explode the sub-assembly into its own requirements, and the parent work order consumes the sub-assembly item | How sub-assembly items are picked up in your version's MRP and Production Plan settings |
| Raw materials listed directly on the parent BOM | The sub-assembly is never stocked and is made in the same step as the finished good | Only raw materials appear in material requirements, with no intermediate work order or stock entry | Whether any intermediate stock needs tracking for costing or traceability |
| Default BOM per item | An item has several BOMs for different variants, sites or recipes and one should drive planning by default | Work orders and planning pick the default BOM unless another is selected, so an outdated default can release the wrong components | That only one BOM is marked default for each item and that defaults are reviewed after each change |
| Operations on the BOM | Costing needs labor and machine time, or routings and job cards depend on the BOM structure | Operation costs flow into BOM costing and operation sequences are copied to work orders and job cards | Whether operations are maintained on the BOM or through routings in your version |
| Scrap items on the BOM | Expected scrap or waste is a known share of the input for a given operation or product | Scrap quantities can appear as expected output items, which affects stock and valuation after manufacture | How scrap is valued and which warehouse receives it in your accounting setup |
| Tree editing in BOM Creator | Multi-level structures are large or change often and the team needs a visual, drag-and-drop view | Creates and edits the same BOM documents underneath, so work orders and requirements follow the saved tree | Whether your version supports every field you need in the Creator, such as scrap or operations, before relying on it |
| Bulk updates with the BOM Update Tool | A cost, rate or component change must reach many BOMs at once, such as a supplier price or a replaced part | Updates existing BOMs and their costs in one run rather than editing each document, so review impact before running | Which BOMs the tool touches and whether open work orders need separate handling |
| BOM Comparison Tool | Two revisions of a BOM must be checked before one replaces the other | Shows differences in components and quantities so purchasing sees what material requirements will change | That the comparison covers the fields your purchasing team depends on |
How BOM costing rolls up from sub-assemblies to finished goods
The cost of a parent BOM is only as reliable as the costs beneath it. In ERPNext, the cost of a finished good is built from the rates of its raw materials plus the cost of each sub-assembly BOM it consumes, so an error at the bottom of the tree carries upward into every product that uses that sub-assembly. Before trusting a figure, confirm that each sub-assembly has a default, active BOM marked as default. A missing default BOM means the costing run cannot pick a structure for that node, and the parent figure will look complete while leaving part of the cost out. Check the BOM Creator tree and the costing report for each level, not only the top item.
The raw material rates feeding that roll-up come from item valuation rates and purchase prices, and each source behaves differently. Valuation rate reflects stock already received and reflects what the company paid, including any landed costs posted against receipts. Purchase price on the item or supplier price list reflects what the buyer expects to pay next. Stale rates are the most common distortion: a supplier price that rose months ago, or a valuation rate frozen after a single small receipt, can make a BOM look profitable when current purchasing would not support it. Ask your finance and purchasing leads which rate basis they use for quoting, and confirm that the ERPNext costing settings match that choice. Re-run costing after large purchase receipts, and treat any figure that changed sharply without a known cause as a prompt to investigate the underlying rate before using it for pricing or margin decisions.
How to build and verify a multi-level BOM in ERPNext
This sequence turns an engineering product structure into a costed, purchasing-ready multi-level BOM tree in ERPNext, with a check at each stage so errors are caught before go-live. Each step produces an artifact your engineering and purchasing teams can review.
Clean the item master and units first
Before any BOM is built, review item codes, item groups, units of measure and conversion factors with engineering and purchasing. Remove duplicate items, retire obsolete codes and confirm that every component has one stock UOM and, where needed, a purchase UOM with a correct conversion factor. Owner: the ERPNext administrator with a named engineering reviewer. Check: a filtered item list shows no duplicates or orphan codes, and a sample of components matches the engineering bill of materials line by line.
Define sub-assembly and finished goods items
Create an item for each sub-assembly and finished product that appears as a level in the structure, and mark it as a manufactured item where it is made in-house. Set item groups, valuation and default warehouse consistently so that a sub-assembly can be stocked, transferred and costed on its own. Check: every intermediate level in the engineering drawing has a matching item, and no sub-assembly is modeled as a raw material by mistake.
Build the lowest-level BOMs first
Create BOMs bottom-up, starting with the sub-assemblies that contain only purchased components, then moving up to assemblies that use those sub-assemblies as inputs. You can use the BOM Creator to draw the tree visually or the standard BOM form for line entry. Record quantities, UOM and any scrap or operation details that your team already tracks. Check: each BOM is saved and submitted in order, and no higher-level BOM is created before the items it consumes exist.
Set default BOMs and confirm the active version
For each finished item and sub-assembly, set the default BOM so that work orders and production plans pick the correct structure without manual selection. Deactivate superseded BOMs rather than deleting them, so historical work orders keep their reference. Owner: the production planner with the engineering reviewer. Check: the item master shows exactly one default active BOM per item, and a test production plan selects the expected BOM for each product.
Verify the exploded view against engineering records
Open the multi-level or exploded view of each finished product and compare every level, quantity and raw material with the approved engineering records, such as the controlled drawing set or product structure export. Pay attention to quantities that roll up across levels, since a component used in two sub-assemblies must be counted in both. Check: a signed-off comparison sheet shows zero unexplained differences for each product, and any discrepancy is traced to a corrected BOM line.
Cost the tree and review rolled-up values
Run BOM costing for each finished product so that the cost of each sub-assembly rolls up from its components, using the valuation rates and any operating costs the team has configured. Review the cost of each level for implausible values, such as a missing rate that makes a sub-assembly appear free. Check: each top-level BOM shows a rolled-up cost that equals the sum of its levels, and every component with a zero or missing rate has been investigated and either priced or documented.
Compare BOM versions before go-live
Use the BOM Comparison Tool to compare the new BOM set against the previous version or against a second structure that should match it, and use the BOM Update Tool only after reviewing what it will change in bulk. Make sure that purchasing reviews the resulting raw material requirements for the first planning run. Check: the comparison report lists only the changes that engineering has approved, and a test material requirement run shows purchase quantities that agree with a manual calculation for a sample product.
Confirm purchasing and planning outputs in a trial run
Run a trial production plan and material request from a sample sales order and check that the generated purchase needs reflect the sub-assembly levels correctly, including stock already on hand at intermediate levels. Document the sign-off by engineering, production and purchasing, and freeze the approved BOM set before go-live. Check: the trial output matches the signed-off raw material lists, and a change control step is agreed for any later BOM edit.
Keeping BOMs accurate for purchasing after engineering changes
An engineering change does not update purchasing on its own. In ERPNext, a revised component or sub-assembly lives in a new or edited BOM, but any parent BOM that nests it keeps its old cost roll-up and its old item list until someone refreshes it. Purchasing that runs Material Requests from a parent BOM can therefore order against a sub-assembly that no longer matches the drawing. Before you release a change, decide which BOMs are affected by walking the tree from the changed item upward, and confirm that every parent is either updated or deliberately left on its previous revision with a documented reason.
Use the BOM Update Tool to refresh costs after component prices or rates change, and the BOM Comparison Tool to check what actually differs between two BOM revisions before purchasing relies on the new one. The comparison is the evidence step: it shows added, removed and changed lines, so engineering and operations can confirm that the change is the one that was approved. Confirm in your own test site how each tool handles default BOMs, sub-assembly items and costing refresh in the version you run, since behavior can differ between releases.
Set up a change approval step owned jointly by engineering and operations before any BOM is edited for a live product. Engineering owns the technical change and the effective date, operations owns the stock on hand, open purchase orders and work orders that the change touches, and both sign off on the comparison output. Record who approved the change and when, and agree in advance on whether open work orders finish on the old BOM. Without that gate, the people who edit the BOM tree are the same people who decide what purchasing sees, and errors reach the supplier before anyone notices.
Access, audit and data risks in BOM master data
A BOM is master data that drives purchasing, costing and shop floor instructions, so who can change it matters as much as how it is built. The cards below cover the permissions, revision history and approval steps that keep sub-assembly changes controlled, and the sector standards to check before you assume any of them apply.
Who can edit BOMs and item costs
In ERPNext, BOM edits and item valuation rates are controlled by role permissions on the BOM and Item DocTypes, and the people who can change a sub-assembly tree are often not the people who approve it. List every role with write access to BOM, BOM Item and Item price fields, including users who can submit or cancel a BOM. Check whether purchasing and production planners can alter quantities or item rates on a live BOM.
Role permissions that limit changes
Role Permissions Manager controls read, write, submit, cancel and amend rights per DocType, and User Permissions can restrict a user to specific companies or items. Test a sample user with each role to confirm they can build a draft BOM but cannot submit it, and that cancelling a submitted BOM is limited to a named approver. Review these settings after every role change, since inherited roles can grant more access than intended.
Audit trails for BOM revisions
Frappe records version history for submitted documents, so each change to a BOM can be traced to a user and a timestamp, and cancelled BOMs remain in the database. Confirm that version tracking is enabled for BOM and BOM Item, and decide how revisions are labeled and archived. Verify that your backup and retention policy covers this history, since the audit trail is only useful if it survives an incident or a database restore.
Unapproved changes reaching the shop floor
A BOM that is changed after work orders are created can send the wrong components or quantities to the floor, and bulk updates make this easier to do by accident. Define a rule that active BOMs used by open work orders are changed only through a new BOM version, and check which open orders reference the old one. Before running the BOM Update Tool, review the affected BOMs and the work orders that depend on them.
Keeping BOM data accurate for purchasing
Purchasing and MRP read BOM quantities and item rates directly, so a wrong unit of measure or an outdated sub-assembly can generate incorrect material requests and supplier orders. Compare the BOM Comparison Tool output between versions before approving a change, and spot-check raw material requirements against the engineering source. Ask who owns the approval for each product family and whether purchasing signs off on rate changes.
Confirm sector obligations for industrial controls
The ISA/IEC 62443 series addresses security for industrial automation and control systems, and NIST SP 800-82 Rev. 3 covers operational technology, but neither standard governs ERPNext BOM data directly. Treat them as context for the plant floor and confirm with your regulator, auditor or compliance lead whether any sector rule applies to the ERP records that feed production. Document that decision so the reasoning is available at the next assessment.
Questions buyers ask before building BOMs in ERPNext
What drives the effort of a BOM rebuild in ERPNext?
The effort depends mostly on how many products, sub-assemblies and levels the existing structure has, and how much of the source data is trustworthy. A rebuild effort is driven by the count of distinct sub-assemblies that are reused across products, the number of operations and scrap lines to carry over, and whether item codes are consistent. Teams with clean item masters and documented engineering drawings usually need less reconciliation time. Ask for an inventory of products, active BOM versions, shared sub-assemblies and known data gaps before any estimate is agreed, because those counts set the scope.
Can our own team build multi-level BOMs in ERPNext without a partner?
Yes, a trained team can build them in-house, and the BOM Creator is designed for building the tree visually. The work is mainly engineering data discipline: agreeing item naming, deciding which sub-assemblies are stocked versus made on demand, and checking quantities and units against drawings. Teams that lack an ERPNext manufacturing administrator, or that must migrate hundreds of structures while running production, often bring in a partner for the initial build and the validation pass. Decide which part you own, and which part you want reviewed, before choosing.
What does the implementation partner need from our engineering team?
The partner needs named owners who can confirm the product structure, sub-assembly definitions, raw material units, scrap allowances and any alternative materials. Engineering should also provide current drawings, specifications or validated spreadsheets, and a decision on which BOM version is the approved one for each product. Access to a test ERPNext site and time for review sessions are needed as well. Missing answers on units of measure or variant rules are the most common source of rework, so agree who signs off each category before the build starts.
How are bulk BOM updates scoped in ERPNext?
Bulk updates are scoped by which BOMs change, which raw material or sub-assembly is affected, and what cost or rate changes flow through. ERPNext provides a BOM Update Tool that can update BOM costs and replace items across BOMs, and a BOM Comparison Tool to review differences between two BOMs. Scope should list the affected items, the replacement rules, the BOMs that will be left unchanged, and the test approach. Confirm in the manufacturing documentation how the tool treats submitted and active BOMs, since that determines whether a new version is created.
How does BOM accuracy affect purchasing in ERPNext?
Purchasing relies on BOMs to calculate material requirements, so an error in a sub-assembly quantity or a missing component flows directly into material requests and purchase orders. Inaccurate BOMs can cause overbuying, shortages on the shop floor, and wrong standard costs. Accuracy checks should compare each BOM against the approved engineering record, confirm supplier item codes and units, and verify that scrap percentages match historical yields. Schedule periodic reviews after engineering changes, because stale structures are the usual cause of recurring purchasing exceptions.
What does a quote for BOM work depend on?
A quote follows from a written scope, so it depends on the number of products and BOM levels in scope, the state of source data, whether a migration from spreadsheets or another system is included, and the number of review cycles. It also depends on whether the work includes the BOM Creator build, costing validation, bulk update runs, training for purchasing and production staff, and handover documentation. DeployOpen does not publish a price list. Ask for a scope that lists these items separately so you can compare it with an internal estimate.
Does the BOM structure need to change before a move to ERPNext version 16?
Confirm this before design starts, because version-specific behavior matters. ERPNext version 16 is supported, and newer manufacturing features may change how operations and semi-finished goods are represented. Check the release notes for your target version and decide whether your sub-assembly design should use separate BOMs or the newer approach. An upgrade path should be part of the scope if you are moving from an older release, so the BOM design is not rebuilt twice.
Where to read the official BOM documentation
Treat the official ERPNext documentation as the authority on how BOM tools behave, and use this page for design decisions rather than for button-by-button instructions. The BOM Update Tool and the BOM Comparison Tool are both documented in the ERPNext manufacturing manual, and those pages describe what happens to open and submitted BOMs, which fields are copied, and what the comparison report shows. Read them before you run any bulk change on a live BOM tree, because a sub-assembly update can ripple into every parent BOM that references it.
Check the release notes for the exact ERPNext version your site runs before you rely on any step. The supported major versions receive frequent minor releases, and BOM behavior, costing logic and tool screens can change between them. Confirm the version on your staging copy, read the release notes for every minor release between your current version and your target, and record which behavior you tested. The same check applies to Frappe Framework version, because the BOM Creator and the document events it depends on sit on top of it.
Ask your implementation partner, or your internal ERP owner, to write down which documentation pages and release notes were used to sign off the BOM design. That record matters when purchasing, costing or an auditor asks why a BOM looked the way it did on a given date. If the documentation and your site disagree, trust what you observe on a tested copy of your own data, and raise the difference with Frappe or the ERPNext community before changing production.
How DeployOpen scopes and delivers ERPNext BOM work
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, and multi-level BOM work follows the same method. We start from your product structure and costing needs, build the tree in ERPNext, and hand over a BOM set your purchasing and production teams can run without us.
How we scope
- The written scope lists the product families, sub-assembly levels and BOM counts that the engagement covers.
- We confirm which items are purchased, made in-house or both, and which BOMs need costing and scrap lines.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any BOM work starts.
- The scope names which BOM Update Tool and BOM Comparison Tool tasks are included for later maintenance.
How we build
- We build the multi-level tree in BOM Creator, checking every sub-assembly against the item master and units of measure.
- We set default BOMs, costing inputs and rates, then test that rolled-up costs match the figures your finance team expects.
- Bulk changes run through the BOM Update Tool on a test copy first, with before and after comparisons recorded.
- Purchasing checks confirm that material requests generated from the BOM tree match real procurement lead times and suppliers.
How we hand over
- You receive a BOM register listing each finished item, sub-assembly, revision and its owner in your organization.
- Documented change procedures cover who may edit a BOM, how revisions are approved and how the comparison report is filed.
- Your team is trained on BOM Creator, the update and comparison tools and the checks used during acceptance testing.
How we support
- Ongoing support, BOM audits and upgrades are available as a retainer after handover.
- Confirm with us during scoping how BOM changes from ERPNext upgrades will be tested before they reach production.
