Safety Data Sheet Authoring Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does building your own substance database go wrong so often?

The biggest scope failure in chemical compliance software is a developer proposing to build the regulatory content. It is an understandable mistake, because from the outside a substance list looks like a table. From the inside it is decades of curation: substance identifiers, harmonised classifications across jurisdictions, exposure limits, transport data, and the maintenance to keep all of it current as lists are updated.

Sphera, Verisk 3E and Chemwatch have spent a very long time assembling that, and a software budget spent recreating it buys you a worse version with no maintenance behind it. The failure usually surfaces about six months in, when the first list update lands and nobody has an answer for who applies it.

What is genuinely worth building is everything around the content: the connection to your live recipes, the approval workflow that reflects who in your organisation may sign off a hazard determination, the handling of customer specific variants, the phrase governance, and the generation of the right document for the right jurisdiction and language. Those are specific to how your business operates and no vendor can supply them.

So write the boundary into the specification before anyone quotes. Licensed content in, workflow and integration built, and an explicit answer to what happens when the licensor updates a classification. A proposal that does not name that boundary has not thought about it, and you will pay for the thinking later.

What goes wrong when you migrate legacy sheets and formulation data?

Two migrations, two very different difficulties. The document archive is the easy one to underestimate and the easy one to overdo. You have thousands of issued sheets across products, languages and versions, and the instinct is to import everything. Resist it. What you must retain is the issued record, meaning the exact document as supplied, with its issue date, so a superseded version can be produced if questioned. That is an archive, not a data set, and trying to parse old documents back into structured classification data produces confident errors.

The formulation data is the migration that actually determines your schedule. If recipes sit in the enterprise system as structured components with concentrations, integration is straightforward. In most manufacturers a meaningful share do not: some are text descriptions, some live in laboratory spreadsheets, some carry a trade name for a raw material rather than a composition, and a few reference a supplier blend whose composition you have never held.

Audit that before the project starts, not in week six. Count how many finished products have a fully structured composition, how many reference a raw material with no classification on file, and how many are described in prose. That count is the real project plan. Where composition is genuinely unavailable, decide explicitly whether you request it from the supplier, treat the material conservatively, or discontinue the product, and record which choice was made for each one.

Why do the enterprise system and supplier data integrations break after launch?

The single most common architectural error here is a nightly extract. A weekly or nightly file of formulations is not the same as knowing that a formulation changed at twenty past two on a Tuesday, and a product that changed and shipped the same day slips through a batch process entirely. Ask any prospective developer what happens in exactly that case. If the answer is that the change is picked up overnight, you have bought the original problem with better reporting.

The right shape is event driven from the system that holds the authoritative recipe, so a bill of materials revision immediately marks every affected sheet and label as stale and puts it in a work queue. That queue is the control. It is also the metric worth watching, because a queue that is growing tells you something about your change rate that no compliance report will.

The inbound side breaks differently. Supplier safety data sheets arrive as documents, by email, in whatever format the supplier chose, and they change without notice. Any process that depends on someone reading them will fail silently. Build an inbound register with an owner per supplier, a recorded date of the version you hold, and a cascade so a revised component classification recomputes every finished product containing it.

Then alert on absence as well as error. A feed that stops producing is more dangerous than one that fails loudly, because nothing looks wrong.

What happens when distribution and revision notification are not covered?

Issuing a corrected sheet is not compliance. Getting it to everyone who holds the previous one is compliance, and most manufacturers cannot say who that is. Sheets go out attached to order confirmations, get uploaded to customer portals by sales staff, and get emailed on request, with no register anywhere. So a revision becomes a broadcast to a mailing list that has been decaying for years, and the customer who most needs the update is the one whose contact left in the meantime.

The consequence is not theoretical. When a customer's health and safety team finds they are working to a superseded document, the question that follows is not about the document, it is about whether your quality system works at all. That is an audit question and it tends to arrive with a supplier questionnaire attached.

Covering it means treating distribution as a tracked event rather than an attachment. Every issue of a sheet to a party is recorded with the version, the date and the channel, whether that party is a customer, a distributor, a portal or one of your own sites. A revision then produces a precise notification list and evidence that notification happened, which is what you need when someone asks.

The same structured classification should generate any required notification of mixture information to a poison centre body, including the unique formula identifier the European scheme requires, rather than having that assembled separately by hand into a different format.

Should you build custom or configure what you already own?

If you make a few hundred formulations shipping into two or three jurisdictions with a stable recipe set, do not build. Chemwatch will produce compliant documents for far less than a build costs, and outsourcing authoring entirely to a service such as Verisk 3E is a legitimate answer at that scale. Spend the money on your laboratory instead, because the constraint on that business is formulation capability, not document generation.

If you already run the environment, health and safety module inside your enterprise system, look hard at what it can do before you build alongside it. It has the structural advantage of living where the recipes already are, which is the exact connection everyone else has to engineer. The honest test is whether your approval workflow and your customer specific variants fit inside it, or whether they are currently being handled by email around the product.

Build when two or more of these are true. Recipes change often enough that document drift is a standing condition rather than an incident. The matrix of jurisdictions and languages has outgrown a folder structure. Your suppliers revise their own sheets and you have no cascade. You cannot produce a list of who holds which version. Or your classification decisions cannot be reproduced from stored inputs when an auditor asks why a product was classified as it was two years ago.

How do hidden costs get into the quote?

Translation is the largest and the most persistently underestimated. The standardised hazard and precautionary statements have official translations, and that part is solved. The rest of a sheet, first aid, firefighting, handling and storage, disposal, is written text that has to be translated accurately and then maintained. That is an ongoing operational cost with a per language, per revision shape, not a one off build line. Ask for it to be modelled at your actual revision rate.

Label printing integration is the second. The label is the artefact a worker actually reads, it is legally sensitive, and it is constrained by physical size, which forces explicit rules about which precautionary statements survive when space runs out. Those rules are a decision your regulatory team must make, and the printing integration itself is fiddly work against specific hardware.

Third is your formulation data audit, discussed above, which is frequently a project before the project. Fourth is licensed content subscription, which is yours to pay whether the software is bought or built and should sit in the total picture rather than appearing later. And fifth is each additional jurisdiction, since each brings its own required content and its own adoption of a particular revision of the globally harmonised system for classification and labelling.

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

The builds that work treat classification as a derived value that is recomputed whenever any input changes, with the inputs, the rule set version and the result all stored. That gives you two things you cannot otherwise have: a stale list available on demand rather than discovered by a customer, and the ability to answer why a product was classified as it was in March, which requires knowing what was true in March.

They treat the product and its versioned classification as the authoritative object, and every sheet as a rendering produced on demand for a jurisdiction and a language, archived immutably when issued. Manufacturers who instead maintain a folder of authored documents per product get drift multiplied by the number of countries they sell into, which is the failure this whole category exists to prevent.

They govern free text rather than allowing it. Phrases live in a managed library keyed to hazard class and product family, with a translation state, an owner and a review cycle, and authors select rather than type. It is unglamorous and it is what stops the same hazard producing three different first aid paragraphs written by three people in three different years.

And they leave ownership unambiguous. You should own the repository, the infrastructure accounts, your phrase library and the unrestricted right to hire another firm, with licensed regulatory content remaining the licensor's under its own subscription. At Digital Heroes the client owns the code from the first commit. Make sure that distinction is written down, because the phrase library in particular is years of your own regulatory team's work and it should never sit inside somebody else's product.