AI for Parts & BOM Management
Learn how per-part counts for a build of fifty are rolled up through a nested assembly, where hand calculations go wrong, and how to check the result.
·
⏱
7 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
Per-part counts for a build are a structural calculation: walk the tree, multiply at each level, keep the units straight. Done by hand it is slow and fragile. Asking the assembly directly, with a code interpreter running the arithmetic and showing its working, turns it into something you can check in minutes. Treat the result as a verified input to purchasing, adjust it for pack sizes and scrap, and keep the system of record where it is.
Every build plan reaches the same question sooner or later: we are making fifty, so how many of each part do we need? On paper it is multiplication. In practice the answer is buried in an assembly that nests sub-assemblies inside sub-assemblies, where one screw appears in four places and a gasket only shows up when a particular option is selected.
The usual route is to export a flat BOM, paste it into a spreadsheet, and hope the quantities were rolled up correctly. When the count is wrong, the error surfaces late: a line stopped for one missing fastener, or a pallet of spares nobody wanted. This post walks through how per-part counts actually get computed from an assembly, where the arithmetic goes wrong, and what it looks like to point an AI agent at the assembly and the build quantity and get counts back with the working shown.
Why a Build Quantity Is Harder Than It Looks
A build of fifty sounds like a single multiplier, but the multiplier applies at every level of the structure. If a top-level assembly contains two identical sub-assemblies, and each sub-assembly contains six fasteners, the unit count is twelve and the build count is six hundred. Add a third level and the numbers compound again.
Three things make this harder than a spreadsheet formula suggests. First, the same part number can sit at several depths, so a naive sum of the visible rows misses some instances or counts others twice. Second, quantities in a BOM are not always integers: a length of tubing, a bead of sealant or a metre of cable is counted by length or volume, and the unit of measure has to survive the rollup. Third, the assembly that was modelled is not always the assembly that gets built. Variants, options and suppressed components change what the real count is.
A concrete example makes the compounding obvious. Suppose a gearbox end-cap sub-assembly uses six identical socket-head screws, two dowel pins and one O-ring, and each finished unit contains two end caps. That is twelve screws, four pins and two O-rings per unit. For fifty units, the plan needs six hundred screws, two hundred pins and one hundred O-rings, before any allowance for spares. Now picture the same logic across a structure with five levels and four hundred lines, and it is clear why a quick mental multiplication does not scale.
For a deeper look at how nested structures and cost rollups behave, see Multi-Level BOM Management: How to Tame Nested Assemblies and Cost Rollups.
IN PRACTICE
We've started reusing parts we didn't even know we had, and that has real downstream impact on procurement and BOM costs.
- Verified User, Defense & Space
The Rollup Done by Hand: Where Counts Go Wrong
Teams that do this manually tend to hit the same handful of problems. They are worth naming, because each one is something an automated rollup has to handle explicitly.
Counting the flat BOM instead of the structure. A flat export lists each part once with a quantity per parent, not a quantity per top-level unit. Multiplying that figure by fifty undercounts anything that lives below the first level.
Forgetting that mirrored or patterned instances are separate physical parts. A pattern of eight holes may call for eight fasteners, but the BOM row might read as one line with a quantity of one.
Mixing units. Three hundred millimetres of tubing per unit is not three hundred pieces, and the purchase quantity depends on stock length and cut waste.
Ignoring scrap and spares. A build of fifty rarely needs exactly fifty times the unit count, particularly for small consumables where the pack size is larger than the need.
There is also a quieter failure: stale data. A rollup is only as current as the assembly it reads. If a revision released yesterday swapped a fastener for a different size, a spreadsheet exported last week still shows the old part, and the purchase order follows it. Re-running the count against the live assembly, every time the build plan is reviewed, removes that class of error without extra effort from the person planning the build.
None of these are hard individually. The trouble is that they are easy to miss when the assembly has several hundred lines and the person doing the rollup is also doing three other jobs.
What Changes When You Ask the Assembly Directly
The alternative to exporting and summing is to ask the question where the data lives. Leo is an AI assistant for mechanical engineers that connects to an organisation's knowledge base, including PDM and PLM systems and local or network directories, and answers questions grounded in the assembly itself. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), so the assembly does not need to be re-keyed into a separate tool.
In practice, the request is plain language: point the agent at the assembly, give it the build quantity, and ask for the count of each part. Because the answer is grounded in the assembly structure rather than recalled from general knowledge, it can walk the tree level by level. A code interpreter then runs the rollup as a calculation instead of the model estimating a total, which matters because a language model asked to add up hundreds of numbers in its head is the wrong tool. The calculation is executed, and the arithmetic is shown alongside the result.
That last point is the practical benefit. A count with its working visible can be checked in a minute: you see that part X appears under two sub-assemblies, six times each, multiplied by fifty. If the number looks wrong, you can see which step to challenge. A bare total gives you nothing to challenge.
Leo sits as an intelligence layer on top of existing PDM and PLM, not as a replacement for them. The system of record stays where it is; the agent reads from it and returns counts.
Checking the Counts Before You Order
A returned count is an input to a purchasing decision, not the decision itself. A few quick checks keep errors from reaching a purchase order.
Spot-check one high-quantity fastener by hand. If the rolled-up figure matches your own multiplication for one part, the structure walk is probably sound.
Confirm the unit of measure on every non-discrete line. Lengths, volumes and weights should be called out as such, with the conversion to a purchasable quantity stated separately.
Compare the total line count against the assembly. A part that appears in the model but is missing from the result suggests a suppressed or excluded component that should be reviewed.
Cross-check against the drawing. A mismatch between drawing and BOM changes the real count, which is covered in Catching a Drawing That Disagrees With the BOM Before It Reaches the Shop.
It also helps to keep the question specific. Asking for counts for a named assembly at a named revision and a stated build quantity gives the agent nothing to guess about. Vague requests, such as asking for the parts in the product, force assumptions about which configuration and which revision you meant, and assumptions are where wrong counts begin.
The match still cannot confirm everything for you. It will not know that a supplier only sells a fastener in boxes of one hundred, or that a build has a scrap allowance your shop floor applies by habit. Those rules belong to your process, and the counts should be adjusted for them after the rollup, not baked into it silently.
From Counts to Purchasing and Handoff
Once the per-part counts are trustworthy, they feed everything downstream. Procurement uses them to size orders. Planning uses them to see which long-lead items gate the build. Engineering uses them to spot parts that appear in huge numbers and are worth standardising, a theme covered in AI BOM Management in 2026.
The engineering-to-manufacturing handoff is where counts most often drift, because the engineering structure and the manufacturing structure are not identical. If you are building for production, read From EBOM to MBOM: How the Engineering to Manufacturing Handoff Actually Works before trusting any single rollup, since the manufacturing structure may group, split or add items the engineering view does not show.
When a part changes, the same question runs in reverse: which builds and assemblies does it touch? That is the territory of Where-Used Impact Analysis: Find Every Affected Part. Counts and where-used answers are two sides of the same structural data.
FAQ
Get Part Counts You Can Check
Ask your assembly for per-part counts, with the working shown.
See how Leo reads your assembly, runs the rollup for your build quantity, and returns per-part counts you can verify before you order.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
