Product Stewardship and Substance Compliance Software: How Do You Roll Up 900 Supplier Declarations Before Friday?

Why substance compliance quietly becomes a market access problem

A Tuesday email from a customer's procurement portal asks for a full material disclosure for assembly 4471-B, plus a REACH statement, plus confirmation on two substances added to the candidate list, by Friday. The compliance manager opens the shared drive. There are around 900 supplier declarations in it. Perhaps 300 are more than three years old. Sixty are scans of scans. A dozen are Excel templates the supplier filled in by writing not applicable across every row. The bill of materials for 4471-B has changed twice this year because purchasing qualified an alternate connector, and the alternate has no declaration at all.

By Thursday afternoon the answer that goes back is a statement of belief, signed by someone whose job depends on it being true, based on data nobody can fully evidence. Everyone in this industry knows that email. It is not a paperwork problem. If the statement is wrong, the consequence is not a fine in the first instance, it is a customer removing your part from their approved list, which means a product line loses a market.

The stack is typically an ERP (Enterprise Resource Planning) holding purchasing and bills of material, a PLM holding engineering structures, a shared drive of declarations, an Excel rollup workbook maintained by one person, and possibly a subscription to Assent, Sphera or iPoint for supplier campaigns. Each holds a piece. None of them holds the join between a bill of material revision, the specific supplier part that was actually bought against each line, the declaration covering that part on that date, and the finished product statement you issued to a customer last quarter. That join is the whole job, and it lives in a workbook.

Problem 1: declarations arrive as documents and your rollup needs data

There is a perfectly good standard for this. IPC-1752A defines a machine readable declaration format, and IEC 62474 defines a substance data exchange. A minority of your suppliers will use them. The rest send a PDF on letterhead, or your own Excel template completed wrongly, or a certificate of conformance that says the part complies with RoHS and nothing else.

The subscription platforms are genuinely good at the campaign side of this. They chase suppliers, they escalate, they have relationships. What they are less good at is your parts. Their data model is theirs, your part numbering and approved vendor list logic is yours, and matching a supplier document referencing their part number to your internal part number across revisions, alternates and manufacturer part numbers is where the accuracy is lost. That matching is exactly the work that gets done by hand at 6pm.

What a custom build does: treat the document as evidence and the extracted data as a record with a provenance link back to the page it came from. Document extraction is one of the two places AI earns its keep here, reading the substance table, the declaration scope, the signatory and the date out of a hundred different layouts and putting them into your schema for human confirmation. The second place is matching, resolving a supplier's part string against your approved vendor list including manufacturer part numbers and known abbreviations. In our builds these two together take the manual handling of a declaration from ten or fifteen minutes to under two, and more importantly they make every extracted value traceable to a source page during an audit.

Problem 2: rollup logic is specific to how your company models a product

Rolling substance data from parts to a finished product sounds like arithmetic. It is not, because product structures are opinionated. Phantom assemblies exist in the bill of material but not in the physical product. Alternates mean the part in the box depends on which one purchasing had in stock that week. Process chemicals such as plating, flux, adhesive and marking ink are physically present and frequently absent from the bill of material entirely. Configurable products have a structure that only resolves at order time.

Then there is the threshold logic. RoHS restrictions apply at homogeneous material level, not at part level, so a declaration that gives you a percentage against the whole component is not directly usable. REACH candidate list obligations for articles use a 0.1 percent by weight threshold, and how that threshold applies through an assembly is a question your regulatory counsel should answer for your products, not a setting in a vendor default.

What a custom build does: encode your structure rules explicitly. Phantom handling, alternate resolution, process chemical attachment at operation level, and a documented rule for how thresholds propagate for each regime you report against. The output is not a single compliant flag, it is a statement with a computed basis: which parts contributed, which are covered by declarations, which are assumed, and what the exposure is if an assumption is wrong. That last column is what turns compliance from a claim into a risk position management can act on.

Problem 3: the lists move and your parts do not

The REACH candidate list of substances of very high concern is updated periodically, typically twice a year, and each update can turn a part you have been buying for a decade into a reportable article overnight. RoHS exemptions expire on published schedules. PFAS restrictions are moving in multiple jurisdictions at once. None of that involves any change on your side, which is precisely why it gets missed.

The commercial platforms do monitor the lists and that is a fair reason to buy one. What they cannot do is tell you which of your open customer commitments are affected, because they do not hold the record of what you told which customer on what basis and when.

What a custom build does: keep every statement you have issued as a versioned object with the data it was computed from. When a list updates, the system re evaluates every affected product and produces two work queues: parts needing a fresh declaration, and customers who received a statement that is now stale. That second queue is the one that protects the relationship, because telling a customer before their auditor does is a completely different conversation from telling them after.

Problem 4: SCIP, conflict minerals and every customer's own portal

The EU SCIP database requires notification of articles containing candidate list substances above the threshold placed on the EU market. Conflict minerals reporting under the United States rules runs on the CMRT template. Some customers want IPC-1752A back. Others want their own spreadsheet, with their own column names, uploaded to their own portal, quarterly.

This is the part that consumes a compliance team's week and creates no value beyond keeping accounts open. It is also entirely mechanical, which makes it exactly the right thing to automate.

What a custom build does: one internal data set, many output shapes. Customer specific export templates are configuration rather than code, so the compliance team adds a new customer format themselves. Submissions and responses are logged against the customer and the product so the next request is answered from history rather than rebuilt. The measurable win in our delivery experience is that a customer disclosure request drops from days of assembly to a review of a generated pack.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this category runs a first release of $60,000 to $140,000 in 12 to 16 weeks. That covers declaration intake with extraction and matching, the part level substance data model, ERP and PLM bill of material integration, and automated rollup with a computed basis for each product. The full platform, adding supplier campaign management, list change monitoring with re evaluation, SCIP and CMRT outputs, customer specific export templates and a supplier facing portal, runs $180,000 to $400,000 phased over 6 to 12 months.

What drives the number up:

• The number of regulatory regimes you report against, since each carries its own threshold logic, exemption handling and output format.
• Bill of material complexity, especially configurable products and heavy use of alternates, which makes resolution rules genuinely hard.
• PLM integration, which varies enormously between Teamcenter, Windchill, Arena and a home grown structure database.
• Historical backfill, meaning how many years of existing declarations you want extracted and matched rather than starting clean from today.
• Multi division rollout where each division numbers parts differently and insists it is correct.

What keeps it down: start with one product line, one regime, and your top 500 purchased parts by spend. That usually covers the majority of your customer requests and proves the extraction accuracy before you scale it.

Build versus buy, and when the subscription is the right call

Buy if you have a few hundred purchased parts, one product line and one regulated market. Assent and iPoint will chase your suppliers better than you will, and the subscription will be cheaper than running your own system. Buy the campaign capability even if you build, in many cases: supplier chasing is a relationship business and the platforms have the clout of asking on behalf of many customers at once.

Build when two or more of these are true. You carry several thousand purchased parts across product lines with different structures. Your rollup depends on one person's workbook and that person has no realistic backup. You have configurable products where the compliance answer depends on the configuration ordered. Your customers each demand a different output format and your team rebuilds packs by hand every quarter. You have been asked, or expect to be asked, for full material disclosure rather than a simple compliance statement, which is a far harder data problem.

The honest hybrid is common and we recommend it often: subscribe for supplier campaigns and list monitoring, build the part matching, rollup, statement versioning and customer output layer that the subscription cannot fit around your product structures. That combination usually costs less than forcing either approach to do the whole job.

How to choose a developer for product stewardship software

Ask them to whiteboard the data model. A developer who has done this draws part, manufacturer part, supplier declaration with scope and date, substance with a threshold basis, bill of material revision, and issued statement as a versioned object. If they draw parts and substances in a two table diagram, they have not met an alternate part or a phantom assembly yet.

Ask specifically how they handle homogeneous material level for RoHS versus part weight percentages for other regimes. If the answer treats every threshold the same way, your outputs will be wrong in a manner that is hard to detect and embarrassing to correct.

Ask what extraction accuracy they will commit to and how it is measured. The right answer includes a confirmation queue, a provenance link from every extracted value to the source page, and a rate that improves with corrections. Any claim of fully automatic extraction with no human review is a claim you should not accept on data you sign for.

Ask about ERP and PLM integration by name and version. A Teamcenter structure query is not a Windchill one, and pulling the as bought supplier part against a bill of material line is a different question from pulling the engineering structure. Vague integration claims here become months.

Ask who owns the code and settle it before kickoff. You should own the repository, the infrastructure and the right to move the work elsewhere. At Digital Heroes the code is yours from the first commit. On a system that underwrites statements you sign, holding your own compliance evidence is not negotiable.