Product Safety and Compliance Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does building a document library instead of a requirement engine keep happening?

Because the pain everyone describes is finding documents, so the solution everyone specifies is finding documents faster. Upload the certificates, tag them by item, add search, done. It is a clean brief, it is cheap to build, and it is the wrong system.

Compliance evidence is not a document. It is a relationship between a product, a market, a requirement and a document with a validity period. A library stores the document and loses the other three, which means the only question it can answer is what you have. It cannot answer what you need, which is the question that decides whether a listing stays up.

The second reason is that requirement logic looks like domain knowledge rather than software. It depends on product type, materials, whether the item is intended for children, whether it contains a cell, whether it has electronics, what it is packaged in, and which markets it sells into. Teams treat that as too variable to encode and default to manual assignment, which is the failure this whole guide is about.

The fix is to generate the requirement list from product attributes and destination markets, as data, at the moment an item is created. Attributes in, requirements out. Then every item has a visible list of what it needs, what it holds and what is missing, and a range level gap view is a report rather than an investigation. Ask any prospective developer how the requirement list is produced. If the answer is that someone assigns requirements per item, you have bought a checklist tool and it will drift out of date within a quarter.

What goes wrong when you migrate years of supplier documents?

The migration looks straightforward and contains a trap that only reveals itself under scrutiny.

You have thousands of files across shared drives, inboxes and a folder structure that made sense to whoever built it. The plan is to load them, extract the fields and attach each to its item. What actually happens is that a meaningful share cannot be attached with confidence, because the document references a model number, a material or a scope that does not quite match the item it was filed against. Factories revise designs. Model numbers gain suffixes. A report covers a family and somebody filed it against every variant on the assumption it applied.

The dangerous outcome is not the documents that fail to match. It is the ones that are attached anyway to clear the migration backlog, because a wrong attachment produces a green status on an item with no valid evidence, and that is worse than a red one.

The second problem is expiry. Migrating a document without capturing its issue date and validity period means the system starts life with thousands of records whose expiry is unknown, so the first expiry report is meaningless and everyone stops trusting it.

The fix is to make scope mismatch a first class outcome of migration rather than an exception. Every attachment carries a match status, anything with a scope or model discrepancy lands in a review queue, and the migration is not considered complete just because the files moved. Prioritise by exposure: the items you sell most of, in the markets with the most active enforcement, first. And accept that migration will produce a list of items with no valid evidence, because that list is the actual value of the exercise.

Why do the product master and marketplace integrations break after launch?

Two integrations decide whether this system stays accurate, and both fail quietly.

The product master integration breaks on attribute change. Requirements are derived from attributes, so when a merchandiser corrects a material field or changes an age grading in the product system, the requirement list for that item should change too. If your integration only creates items and does not react to updates, the item keeps the requirement list it was born with. An item reclassified as a children's product six months after launch will quietly carry the wrong requirements, and nobody looks because the status is green.

The same applies to markets. Adding a country to an item's distribution is a commercial decision made in a different system by a different team, and it changes the compliance obligation immediately.

Marketplace and retailer integration breaks on format churn. Document categories, naming conventions and accepted file types change on the platform's schedule, not yours, and there is rarely an announcement that reaches your compliance team. A pack generator built against last year's template produces submissions that are rejected, and rejections often arrive as a portal status rather than as a message anyone reads.

The fixes are practical. Subscribe to attribute and market changes rather than to item creation, and re-evaluate requirements on every change with a visible alert when an item's obligations increase. Hold pack templates as versioned configuration rather than as code, so a format change is an update rather than a release. And reconcile submitted packs against the recipient's accepted status rather than treating submission as completion.

What happens when packaging and market-specific obligations are not covered?

Product safety evidence gets the attention because it is the thing that stops a listing. The obligations that get deferred are the ones that require data you have never collected, and they arrive with deadlines.

Packaging is the clearest example. Producer responsibility schemes require data about the packaging you place on a market, meaning material types and weights per component, and that data lives with your suppliers rather than in your product record. A compliance system scoped without it cannot report, and collecting it retrospectively across a supply base is a project of its own with a regulatory date attached.

The same pattern applies to any obligation keyed to composition rather than to a certificate. A new restriction on a substance requires knowing which items contain it, which requires material data you may only hold as a declaration in a file. A system that stores declarations as documents can tell you a declaration exists. It cannot tell you which of your 340 items are affected.

The third version is age grading and category logic. Whether an item is intended for children changes the requirements substantially, and if that determination is held as a marketing attribute rather than a compliance one, it will be set by whoever wrote the listing.

The fix is to decide during scoping which obligations need structured data rather than documents, and to build the collection of that data into the supplier workflow from the start. Retrofitting a data collection campaign across two hundred factories under a reporting deadline is the most expensive way to acquire information you could have gathered at onboarding.

Should you build custom or configure what you already own?

Several readers should not build, and the distinction is about the unit of work rather than about size.

If you are a manufacturer whose central problem is materials declarations across a component supply base, buy Assent or Source Intelligence. That is exactly what those networks were built for and they operate at a scale you would not replicate. If your compliance function sits inside a manufacturing environment, health and safety context, Sphera and iPoint come from that world and fit it.

The mismatch for a retailer or consumer brand is that their model is a part and a substance declaration, while yours is a finished consumer item sold into several markets with age grading, packaging obligations, marketplace document requests and retailer specific evidence packs attached. Neither model is wrong. They answer different questions.

If you sell a narrow, stable range in one market with a handful of suppliers, a well maintained folder structure and a diary reminder genuinely covers it, and a build is a poor use of capital. And if the real problem is that nobody owns compliance, software will not create an owner. That one is worth being honest with yourself about before you spend anything.

The build case starts when your unit of compliance is a consumer item sold into multiple markets, when evidence expiry is untracked and you cannot produce a list of items with lapsed documents today, when retailers and marketplaces request packs in different formats regularly, when your range changes fast enough that items enter without a requirement list, or when you have been through a withdrawal or a suspension and reconstructing the evidence took days. The arithmetic tipping point is item count multiplied by market count: below a few hundred combinations a disciplined person holds it, and above a couple of thousand the person becomes the bottleneck regardless of diligence.

How do hidden costs get into the quote?

The application estimate is usually the reliable part. These are the items that appear afterwards.

• Market count. Each destination market brings its own requirement set and frequently its own language for supplier communication. Two markets is not twice one, but six is considerably more than two.
• Category breadth. Toys, electricals, cosmetics, food contact materials and textiles each carry distinct requirement logic. A range spanning several is several rule sets.
• Supplier onboarding. Getting two hundred factories to submit through a new route is change management with translation, instructions and follow-up, and it lands on your compliance team rather than on the developer.
• Rule content maintenance. Software applies rules; it does not tell you a regulation exists. Whether the content comes from a subscription, your regulatory team or external counsel, it is an ongoing cost line.
• Document extraction tuning. Test reports arrive in hundreds of layouts from dozens of laboratories, and accuracy improves with iteration after launch rather than at delivery.
• Structured data collection. Packaging composition and material data are collection campaigns, not fields, and they need a place in the supplier workflow from the beginning.

What separates a build that works from one that fails here?

Four things.

The first is that requirements are derived, never assigned. Product attributes and destination markets produce the requirement list automatically, and any change to either re-evaluates it. That single property is what keeps the system accurate as the range changes, and its absence is why checklist tools decay within a quarter.

The second is that extraction captures scope, not only dates. Ask any developer what they pull from a test report. The answer must include the model or material reference and the scope the document actually covers, because scope mismatch is the error that bites: a report attached to an item it does not cover looks identical to a valid one in any folder, and it is precisely what fails under scrutiny. Flagging that mismatch is the highest value thing document reading does in this domain.

The third is that suppliers can submit without an account. Requiring every factory to register in a portal is how supplier compliance systems achieve low adoption and a parallel email process that becomes the real channel. State the specific requirement, describe what acceptable evidence looks like, provide an upload route with no login, and validate on arrival so a non-conforming document is rejected immediately with a reason rather than accepted and discovered later. Then publish supplier level performance, which changes behaviour more reliably than escalation emails.

The fourth is ownership of the archive. Own the repository, the infrastructure accounts, the document archive and all extracted data, agreed in writing before kickoff. At Digital Heroes the client owns everything from the first commit. This archive is what you rely on in a withdrawal, an enforcement action or an insurance claim, so it must be fully exportable and directly accessible without any vendor relationship remaining in place.