Consumer Product Safety and Compliance Software: Why Your Evidence Lives in Supplier Email

Why compliance evidence fails at exactly the wrong moment

A marketplace suspends a listing and asks for the current test report and certificate for an item. The compliance manager searches an inbox, finds a report from two years ago, and discovers it references a model number that differs slightly from the item actually being sold because the factory revised the design and nobody updated the file. Meanwhile the listing is down, stock is in a fulfilment centre, and the clock is running.

That is the acute version. The chronic version is worse in aggregate. A supplier's substance declaration expired eight months ago and nobody noticed because expiry lives in a PDF rather than a field. A new state restriction on a chemical came into force and nobody mapped it to the 340 items in the range that contain it. A packaging reporting obligation applies in three states you sell into and the data needed to report has never been collected from suppliers.

The underlying failure is structural. Compliance evidence is a relationship between a product, a market, a requirement and a document with a validity period. Almost everyone stores the document and loses the other three. So the only way to answer any question is for a person to open files and reason about them one at a time, and that person is the bottleneck for the entire range.

Problem 1: the requirement list is nowhere, so nobody knows what is missing

Ask what evidence a given item needs and you get an answer assembled from memory. It depends on product type, materials, whether it is intended for children, whether it contains a battery, whether it has electronics, what it is packaged in, and which markets it sells into. A toy sold in the United States needs a children's product certificate supported by testing to the relevant standard. The same toy sold in the European Union needs conformity assessment and a declaration of conformity against different requirements. Add a lithium cell and shipping obligations enter the picture. Add packaging and producer responsibility obligations enter in every market that has a scheme.

Assent and Source Intelligence are effective at exactly the job they were designed for, which is engaging a supply base and collecting materials declarations for manufacturers dealing with substance regulations. The mismatch for a retailer or consumer brand is the unit of work: their model is a part and a substance declaration, whereas yours is a finished consumer item sold into six markets with age grading, packaging obligations, marketplace document requests and a retailer specific evidence pack on top. Sphera and iPoint come from environment, health and safety and product compliance for manufacturing, with the same shape. Useful for what they do, badly matched to a consumer range.

What a custom build does: generate the requirement list from product attributes and destination markets, as data, at the moment the item is created. Product type, materials, age grading, power source, packaging composition and markets in, requirements out. Then every item has a visible list of what it needs, what it has, and what is missing, and a range level view of gaps becomes a report rather than an investigation.

Problem 2: documents have expiry dates that nobody is tracking

Test reports have issue dates and are usually accepted for a defined period by your own policy or a retailer's. Factory audits expire. Supplier declarations reference a regulation version that gets amended. Certificates reference a specific model or material that may have changed.

Storing these as files means expiry is invisible until somebody looks. And nobody looks at 4,000 documents.

What a custom build does: extract and store the fields that matter as structured data, meaning standard and version, scope, issuing laboratory or body, issue date, expiry, and crucially the model or material reference the document actually covers. This is the honest and high value use of document extraction here: test reports and declarations arrive in hundreds of layouts from dozens of laboratories, and a model reads them far faster than a compliance analyst can. Where it earns its cost most clearly is the mismatch check, flagging when a report covers a model number, material or scope that does not match the item it has been attached to. That specific error is common, it is invisible in a folder, and it is the one that fails you when a marketplace or a regulator actually looks.

Problem 3: chasing suppliers is a full time job done part time

Every missing document requires an email to a supplier, a follow up, a translation, a clarification about which standard is required, and often an explanation of why the document they sent does not answer the question. Multiply that by a supply base of two hundred and the compliance team spends most of its week on correspondence rather than assessment.

What a custom build does: turn chasing into a managed process. Each requirement has an owner on the supplier side, a due date and an escalation. Requests go out automatically with the specific requirement stated, the acceptable evidence described, and an upload link that does not require an account, because requiring an account is how supplier compliance portals achieve low adoption. Submissions are validated on arrival, so a document that fails the mismatch check is rejected immediately with a reason rather than accepted and discovered later. Then supplier performance becomes visible, which changes behaviour more effectively than any escalation email.

Problem 4: regulatory change lands as news and gets handled as a project

A new substance restriction, a new packaging labelling rule, an updated standard. Someone reads about it, a working group forms, a spreadsheet is built listing potentially affected items, suppliers are contacted, and three months later the work is roughly done and the spreadsheet is abandoned.

When the next change lands, the process starts again from scratch, because the previous exercise produced a document rather than a data structure.

What a custom build does: express regulations as rules against product attributes, so a new restriction is entered once and the affected item list is generated instantly and stays live as the range changes. New items entering the range are evaluated against every active rule automatically, which is the part manual processes never manage. Whether the rule content itself comes from a subscription service, your own regulatory team or external counsel is a separate decision, and we would not pretend a build replaces regulatory expertise. It replaces the spreadsheet that expertise currently produces.

Problem 5: every retailer and marketplace wants the evidence in their own shape

One retailer wants a technical file per item in a portal. Another wants a signed declaration in their template. A marketplace wants specific document types uploaded against a listing, with their own naming and category rules. Your compliance team maintains the same evidence in four places and none of them is the source of truth.

What a custom build does: hold evidence once and generate each recipient's pack from it, including their template, their naming and their required declarations. That turns a document request from a two day exercise into a download, which matters most in the situation where it matters most, which is a suspended listing or a retailer withholding an on shelf date until the pack arrives.

What this costs and how long it takes

A focused first release, meaning the product and market requirement engine, structured evidence records with expiry and scope, document extraction with mismatch checking, and the supplier request and chase workflow, runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full platform adding a regulatory rule library with impact analysis across the range, retailer and marketplace pack generation, packaging and producer responsibility data collection, corrective action and incident handling, and integration to your product and item systems runs $180,000 to $450,000 phased over 7 to 13 months.

What drives cost up in compliance work specifically: the number of destination markets, since each brings its own requirement set and often its own language; category breadth, because toys, electricals, cosmetics, food contact materials and textiles each carry distinct requirement logic; and the size and sophistication of the supply base, since a base of small factories needs a far lower friction submission route than a base of large manufacturers. What keeps it down: one category family and two markets in release one, chosen where you have the most items and the least evidence, because that is where the exposure sits.

Build versus buy, and when buying is the right call

Buy Assent or Source Intelligence if you are a manufacturer whose central problem is materials declarations across a component supply base. That is what those networks are built for and they do it at a scale you would not replicate. Buy Sphera or iPoint if your compliance function sits inside a manufacturing environment health and safety context. In all three cases, the fit is about whether your unit of work is a part or a finished consumer item.

Build when two or more of these are true. Your unit of compliance is a consumer SKU sold into multiple markets rather than a component. Evidence expiry is untracked and you cannot produce a list of items with lapsed documents today. You are regularly asked for evidence packs by retailers and marketplaces in different formats. Your range changes fast enough that new items enter without a requirement list being generated. Or you have been through a withdrawal, a marketplace suspension or a retailer audit and the reconstruction of evidence took days, which is the experience that usually starts these projects.

The honest tipping point is item count multiplied by market count. Below a few hundred of those combinations, folders and a disciplined person will hold. Above a couple of thousand, the person becomes the bottleneck and the risk is no longer about diligence, it is about arithmetic.

How to choose a developer for product compliance software

Ask how the requirement list is generated. If the answer is that someone assigns requirements manually per item, you have bought a checklist tool and it will drift out of date within a quarter. Requirements should be derived from product attributes and markets so that new items are covered automatically.

Ask what they extract from a test report. The answer must include scope and the model or material reference, not only dates, because scope mismatch is the failure that actually bites and it is invisible if you only track expiry.

Ask how suppliers submit. If the answer requires every factory to create an account in a portal, expect low adoption and a parallel email process. Low friction submission with validation on arrival is what makes the chase workflow function.

Ask who owns the code, the evidence archive and the extracted data, and put it in the contract before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit. Your evidence archive is what you rely on in a withdrawal, an enforcement action or an insurance claim, and it has to be fully exportable and available without depending on any vendor relationship.