Aligning ERP with Chemical Properties and Manufacturing BOMs

ERP chemical properties BOM alignment is the discipline of making sure planning, purchasing, and manufacturing systems use the same material identities and composition facts that compliance trusts for SDS, labels, and customer statements. Regulatory consultants see the same fracture repeatedly: ERP rows do not match chemical product properties and manufacturing bills of materials (BOMs). Teams then argue from different "truths," and shipments, questionnaires, and audits absorb the cost.

Chemical product compliance under EU frameworks depends on correct substance identity, classification, and documentation. Primary references include ECHA for REACH and CLP information and, for workplace chemical safety context in the US, OSHA's hazard communication materials at osha.gov. None of those systems care which ERP field you use - but your customers and auditors care when the pack list, SDS, and formulation do not line up.

Why do ERP and chemistry data diverge?

Divergence is structural, not personal:

• ERP masters optimized for purchasing and costing, not CAS-level composition
• BOMs maintained in manufacturing systems with revision habits separate from ERP
• SDS authored from a third spreadsheet that nobody reconciles monthly
• Trade names and customer codes that multiply aliases without a golden ID
• Toll manufacturing and multi-site plants with local material numbers
• Acquisitions that never finished master-data harmonization

Commercial pressure adds aliases ("same product, different brand code") without updating regulatory attributes. Planning then orders the wrong grade; compliance discovers it in a customer audit.

What does alignment actually require?

Treat alignment as a small architecture, not a one-time cleanup:

1. Stable product and material identifiers shared across ERP, BOM, and compliance systems
2. Composition attributes compliance trusts (substances, concentrations or ranges, impurities when required)
3. BOM revisions linked to the same identity ERP uses for orders and inventory
4. Hazard and regulatory flags maintained as controlled attributes, not free-text notes only
5. A reconciliation process with owners when systems disagree
6. Change control so formulation or supplier changes update all dependents

Automation can flag mismatches; master data ownership still decides the fix. For related supply-chain friction on substance restrictions, see bridging purchasing and regulatory on RoHS and REACH.

Who should own which attributes?

A practical split for mid-market chemical and specialty firms:

| Domain | Typical owner | Examples | | --- | --- | --- | | ERP mechanics | IT / ERP team | Item creation, units, plants, costing | | Manufacturing BOM | Process / manufacturing engineering | Recipe structure, yields, alternate components | | Regulated chemical attributes | Product regulatory / EHS / RA | Substance IDs, classification inputs, market restrictions | | Supplier identity | Purchasing + quality | Approved supplier, certificate expectations | | Customer-facing codes | Commercial + master data | Brand aliases mapped to internal ID |

Compliance owns acceptance criteria for regulated attributes. IT owns system-of-record mechanics. Both need a shared mismatch queue with SLA - not hallway arguments.

How do you run a first reconciliation that finishes?

Do not start with the entire catalog.

1. Pick one product family with real revenue and audit exposure
2. Export ERP material master fields for that family
3. Export current BOM revisions from the manufacturing system
4. Pull SDS/composition source of truth for the same SKUs
5. Compare substance identity, concentration fields, and units
6. Log mismatches with severity (ship-stopping vs documentation debt)
7. Fix masters, then re-export to prove the gap closed
8. Write the ongoing rule: who updates what when formulation changes

This mirrors the "one workflow first" idea used in pilot playbook: choosing the first workflow. Success metrics: percent of SKUs with complete composition keys, age of open mismatches, and time from formulation change to SDS impact review.

Where does AI or automation help - and where not?

Useful assistance:

• Diffing composition tables across ERP export, BOM, and SDS extracts
• Detecting unit inconsistencies (percent vs ppm, hydrate vs anhydrous)
• Clustering alias codes that likely map to one substance
• Drafting mismatch tickets with cited field values for human disposition

Not useful or not allowed without controls:

• Auto-editing ERP production masters without change control
• Inventing CAS numbers for incomplete trade-name lines
• Closing customer questionnaires with unverified composition

For portfolio-level document drafting once masters are clean, see generating safety docs, specs, and certificates from portfolio data. For chemical storage and management beyond SDS alone, see chemical management and storage compliance beyond SDS.

How should change control connect ERP, BOM, and SDS?

When a formulation or supplier change is approved:

1. Update the BOM under revision control
2. Update regulated attributes in the compliance master
3. Trigger SDS/label impact assessment
4. Update ERP only after identity and regulatory flags are consistent - or update in a defined sequence your SOP mandates
5. Communicate to purchasing if approved suppliers or grades changed

If SDS authors learn about a change from a customer complaint, the process failed upstream. Regulatory change control patterns in the QMS are discussed in regulatory change control in a QMS.

What about multi-site and multi-language masters?

Sites often keep local item numbers for historical reasons. Alignment does not require a single number everywhere overnight - it requires a crosswalk table that is controlled and complete. Multilingual labels and SDS must still refer to the same underlying composition; language versions are not separate chemistries. Related reading: building a multilingual compliance data model and GHS labeling gaps and document inconsistency.

What does "good enough" look like for mid-market?

You do not need a perfect enterprise master-data program on day one. You need:

• Named owners for regulated attributes
• One reconciled product family as proof
• A mismatch queue with aging
• A rule that new products cannot go commercial without composition keys
• Periodic re-check when suppliers or BOMs change

That standard prevents the expensive class of errors: shipping a grade whose SDS describes a different composition than the plant mixed.

FAQ

Should compliance "own" ERP?

Compliance owns acceptance criteria for regulated attributes and the right to block release of master data that fails those criteria. IT/ERP owners own the system mechanics. Shared governance beats a turf war.

What is a good first reconciliation?

Pick one product family and compare ERP material master versus SDS/composition source for substance identity and concentration fields, then link BOM revisions to the same internal product ID.

How often should we re-run alignment checks?

At minimum after any formulation, supplier, or major BOM revision - and on a scheduled cycle (for example monthly or quarterly) for high-risk families. Continuous flagging from exports is better than annual panic cleanups.

Can we map only by trade name?

Trade names are unstable. Prefer internal material IDs linked to substance identifiers (for example CAS where applicable) and keep trade names as aliases. Ambiguous trade-name-only masters are a root cause of mis-shipments and wrong SDS.

Does this apply if we only blend and do not synthesize?

Yes. Blenders still need accurate component identity, concentrations, and supplier documentation. Customer questionnaires and CLP labeling do not care that you "only mix."