A bill of materials describes the materials and components that make up a product. A bill of substances describes its chemical composition. For formulation-based products, a formula or recipe connects the ingredients and quantities to the product being made.
These structures answer different questions. Which component belongs in this assembly? How much of an ingredient goes into this formulation? Which substances are present in the finished product, and at what concentration?
The practical issue is how those answers connect. A product record may identify an adhesive by part number without making its composition available for assessment. A formulation record may describe that adhesive in detail without identifying every assembly that uses it. Both records can be accurate while leaving an important question unanswered.
To understand what your PLM can do, look beyond the names of its structures. Examine the relationships it preserves, the calculations it supports, and the evidence behind its results.
Three structures, different questions
A BOM, a formula, and a bill of substances are related views of a product. They do not have to share the same number of levels, and they are not competing versions of a fixed hierarchy.
Modern BOM management can support multiple domains, configurations, variants, and connected product information. Formula management can support ingredient quantities, production versions, costing, and regulatory work. The presence of a BOM therefore does not mean formulation or substance information must exist only in attachments.
The limitation arises when those relationships are missing or the information is not available in a form the system can evaluate.
Consider a purchased coating. Its identity as a purchased material matters for procurement and manufacturing. Its ingredient quantities matter if your organization develops or produces it. Its substance composition matters when you need to assess a restriction or prepare a composition declaration.
One view cannot answer all three questions on its own.
From ingredients to substances
A raw material and a substance are not necessarily the same thing. A purchased ingredient may be a mixture containing several substances, while a formulation may combine multiple ingredients that contribute the same substance to the finished product.
The product model needs to preserve that distinction. Otherwise, a search for a substance may miss products that contain it through a purchased mixture or intermediate.
Consider a simplified formulation. A finished product contains 20% of an intermediate. That intermediate contains 10% of a purchased ingredient, and the ingredient contains 4% of a particular substance by weight. Assuming the proportions remain unchanged through processing, that route contributes 0.08% of the substance to the finished product.
If other ingredients contain the same substance, their contributions also need to be included. A useful rollup preserves the paths behind the total, so someone can see which materials contributed to it and which composition records were used.
That calculation also needs a clear basis. Ingredient inputs and finished-product composition are not automatically interchangeable: a model must account for relevant processing changes rather than assume that every input percentage carries through unchanged.
The same caution applies to source data. An exact calculation does not make incomplete composition information complete. If a supplier provides a concentration range or a partial declaration, the assessment needs to retain that limitation.
Substance identifiers, such as CAS numbers where applicable, help connect records. But an identifier and a percentage are only part of the evidence. Source, version, coverage, and the basis of the concentration matter when someone needs to defend the result.
The goal is a traceable composition view that makes both its conclusions and its limitations visible.
What connected data can answer
The value of these structures becomes clearer when you apply them to routine product questions.
Which products contain this substance?
The system needs a path from the substance to the materials that contain it, through relevant formulations or components, and up to the finished products.
For an assembled product, that path may run through a coating, seal, or adhesive associated with a component. For a formulated product, it may run through several intermediates and purchased mixtures.
BOM-based PLM can support structured substance information and compliance rollups. The important question is whether those capabilities are implemented with sufficient data and connected to the product versions you need to assess.
If the supporting information exists only in supplier PDFs, those documents remain useful evidence, but their contents must be interpreted before the system can use them in a repeatable assessment.
What does a raw material price increase change?
This question primarily depends on ingredient quantities, applicable prices, and the formulations that use the material. It does not require a substance-level breakdown to calculate ingredient cost.
A formulation cost rollup can calculate the effect through intermediates and finished products. Broader production costing may also include resources, routings, overheads, and yield. Oracle’s process-manufacturing documentation explicitly distinguishes these inputs.
Margin assessment requires additional commercial context. A changed market price does not necessarily apply to every purchase, site, or production period, so the calculation must use the price relevant to the scenario being evaluated.
A substance view and a cost view can share the same product relationships while relying on different inputs.
Which products need regulatory review?
Substance composition helps identify potentially affected products. The assessment also needs the applicable requirements and the product context that determines how those requirements apply.
A stored compliance result records a previous assessment. Re-evaluating that result requires knowing which composition version, rules, and assumptions produced it. An updated rule can then trigger review of the relevant products without erasing the history of their earlier approvals.
Structured composition supports this process. It does not, by itself, guarantee that every regulatory question has been answered.
Can we prepare a customer declaration?
Connected composition data can support preparation of a declaration, provided the available information covers the customer’s request.
The output should identify the relevant product version and use the appropriate source data. Where composition is incomplete or reported as a range, the document needs to reflect that rather than imply greater certainty.
Generating a draft and issuing an approved declaration are separate steps. The system should reduce repeated assembly of information while preserving review, approval, and a record of what was provided.
Keep the views connected
A flat substance list can be a useful output. It may show the total concentration of each substance in a finished product without requiring the reader to inspect every ingredient and intermediate.
Flattening becomes a problem when that output is maintained independently and loses its connection to the source structure. It is not a problem simply because the presentation is flat.
A derived composition view can remain linked to the formula version, supplier composition records, and calculation that produced it. Manufacturing instructions can remain associated with the same approved product definition without appearing in the substance list itself. Manufacturing BOM and process information likewise serve complementary purposes: one describes what is required, while the other explains how the product is made.
Site context should follow the same principle. A product made in two plants may use different approved raw materials or formulation versions. Each site can have its own derived composition view, provided that view identifies the version it represents.
One unlabeled global list is insufficient if the underlying products differ. A version-specific flat list may be exactly the output a reviewer needs.
The hybrid case makes these connections especially important. An engineered assembly might use an adhesive, coating, sealant, or lubricant whose composition must be assessed. The assembly structure identifies where the material is used; the composition records explain what it contains.
Those records do not have to occupy one database row or one application. They do need reliable links, defined ownership, and version alignment. A reviewer should be able to move from an affected substance to the relevant material, then to the component and product configurations that use it.
Without that path, engineering and formulation teams may each hold a valid record while someone still has to reconstruct the impact manually.
This is the structural foundation of a living PLM. Connected records make it possible to trace a changed input to the products it affects. Review workflows then determine what happens next.
When evaluating your product model, choose a question your team has actually faced. Trace the records needed to answer it. Can you identify the relevant versions, explain the calculation, and inspect the supporting evidence? Where does someone have to leave the system and rebuild the relationships?
That exercise will tell you more than whether a platform uses the label “bill of materials” or “bill of substances.”
.png)
.png)
