Safety Data Sheet Authoring Software: When the Recipe Changes and the Label Does Not

Why the sheet and the drum stop matching

A production chemist substitutes a surfactant because the original supplier is on allocation. The change goes through as a bill of materials revision in the enterprise system, is approved by technical, and runs the following Monday. The safety data sheet for that product was authored fourteen months ago from the previous formulation and lives as a PDF on a shared drive and in a distributor's document portal. Nobody told the regulatory affairs manager, because in the enterprise system a bill of materials revision is a routine event that happens dozens of times a month.

Six weeks later a customer's health and safety team notices the sheet does not mention a hazard class the new component carries. Or worse, a shipment is held at a border because the transport classification on the paperwork does not match the declared composition. Now you are recalling documents and explaining to a customer why your own record of your own product was wrong.

This is the defining failure of chemical compliance software, and it is a plumbing failure rather than a knowledge failure. Your regulatory team knows how to classify. What they do not have is a connection between the system where formulations actually change and the system where documents are produced. In most manufacturers those two systems are joined by a person hearing about a change.

What the incumbents do well and where the gap sits

Sphera, Verisk 3E, Chemwatch, SAP Environment Health and Safety Management and Cority are the established names, and they are not weak products. Sphera and 3E carry deep regulatory content and phrase libraries that would take years to build. Chemwatch is strong on substance data. The SAP module has the advantage of living inside the enterprise system where recipes already are.

The gap appears in two places. First, the classification content is excellent and the workflow around it is generic, so the specific way your business decides things, which technical authority approves a hazard determination, how a customer specific variant is handled, what happens when a raw material supplier changes their own sheet, ends up as email around the product. Second, the connection to a live recipe is usually a periodic extract rather than an event. A weekly file of formulations is not the same as knowing that formulation 4471 changed at 14:20 on Tuesday and its sheet is now stale.

The honest positioning is that you should not build your own substance database. The build that pays is the workflow and integration layer around licensed content.

Problem one: classification has to be recomputed, not remembered

Under the globally harmonised system that most jurisdictions have adopted in some form, classification of a mixture is calculated from its components, their concentrations and their own classifications, using defined rules and cut off values. That is a computation, and computations should be run rather than recalled.

What actually happens in most manufacturers is that classification is a decision made once by a competent person, recorded in a document, and revisited when someone remembers. Every input to that decision can change underneath it. A supplier revises their own safety data sheet and adds a hazard. A jurisdiction adopts a newer revision of the globally harmonised system, as the United States did when the hazard communication standard was updated to align with a later revision. A harmonised classification changes in Europe. Your own formulation changes.

A build worth paying for treats classification as a derived value that is recomputed whenever any input changes, with the result versioned and the derivation stored. That gives you two things you cannot otherwise have. A stale list, meaning every product whose sheet no longer reflects its current classification, available on demand rather than discovered by a customer. And an answer to the audit question of why a product was classified as it was in March, which requires storing the inputs as they were in March.

Problem two: one product is many documents

People outside regulatory affairs think of a safety data sheet as a document. It is a matrix. The sheet for one product varies by jurisdiction, because classification rules and required content differ, and by language, because the sheet must be supplied in the language of the destination. A product sold into a dozen countries can carry dozens of valid current versions, plus the superseded ones you must retain.

Labels are related but not identical: content derives from the same classification but is constrained by physical size, which forces decisions about which precautionary statements to carry. Transport classification is a separate determination under the applicable road, air and sea rules and can differ from the supply classification.

The engineering consequence is that documents must be generated rather than authored and stored. The authoritative object is the product and its versioned classification. The sheet in a given language and jurisdiction is a rendering of that object, produced on demand and archived when issued. Manufacturers who instead maintain a folder of documents per product end up with the drift that started this article, multiplied by the number of countries they sell into.

Problem three: phrase libraries are the quiet maintenance burden

The standardised hazard and precautionary statements are published, and their official translations exist. The rest of a safety data sheet is not standardised. First aid measures, firefighting measures, handling and storage advice and disposal considerations are written text that has to be consistent across your range, appropriate to the hazard, and translated accurately.

This is where in house systems age badly. A phrase library grows organically, translations are done once and never reviewed, and eventually the same hazard produces three different first aid paragraphs because three people wrote them in three different years. Then a large customer reads two of your sheets side by side.

What a system should enforce is that free text lives in a managed library keyed to hazard classes and product families, with a translation state per language, an owner, and a review cycle. Authors select from the library rather than typing, and a request for a new phrase is a governed action. This is unglamorous and it is what makes a document set defensible.

Problem four: distribution is part of compliance, not an afterthought

Issuing a corrected sheet is not compliance. Getting it to everyone who received the previous one is compliance. That means you must know who has which version: which customers, which distributors, which portals, which of your own sites, and in some cases which regulatory notification body.

Most manufacturers cannot answer that. Sheets go out attached to order confirmations, uploaded to portals by sales staff and emailed on request, with no register, so a revision becomes a broadcast to a mailing list that has decayed for years.

A build should treat distribution as a tracked event. Every issue of a sheet to a party is recorded with the version and the date, so a revision produces a precise list of who needs notifying and evidence that they were notified. Where a jurisdiction requires notification of mixture information to a poison centre body, including the unique formula identifier now required in the European scheme, that submission should be generated from the same classification data rather than assembled separately by hand.

What a custom chemical compliance build has to include

• An event driven feed from the enterprise system so a bill of materials or recipe change immediately marks affected documents as stale, rather than a periodic extract.
• Classification as a recomputed derived value with versioning, stored derivation and effective dates, covering mixtures calculated from component data.
• Raw material inbound handling, so a supplier's revised sheet updates component classification and cascades to every finished product that uses it.
• A managed phrase library keyed to hazard class and product family, with translation state, ownership and review cycles.
• Document generation on demand per jurisdiction and language, with issued versions archived immutably and superseded versions retained.
• Label output constrained by physical label size, with explicit rules for which precautionary statements are carried when space runs out.
• Transport classification handled as a distinct determination for the relevant modal rules, capable of differing from the supply classification.
• A distribution register recording who received which version when, driving targeted revision notices and providing evidence of notification.

What this costs and how long it takes

A focused first release, meaning the live recipe feed, classification for your home jurisdiction, the phrase library and authoring with generation of the sheet in one or two languages, runs $80,000 to $170,000 and ships in 12 to 18 weeks. A full platform adding further jurisdictions and languages, label generation, transport classification, poison centre notification output and the distribution register runs $220,000 to $500,000 phased over 9 to 18 months.

What drives the number up in this category: the number of jurisdictions, since each has its own required content and its own adoption of a particular revision of the globally harmonised system; the number of languages, because translation governance is ongoing operational cost as well as build effort; label printing integration, which is fiddly and legally sensitive because the label is the artefact a worker actually reads; the state of your enterprise system data, since formulations recorded as text rather than structured components are a data project first; and whether you license regulatory content or maintain rules yourself.

What keeps the number down: start with your home jurisdiction, your top product families by revenue, and licensed substance content rather than your own database. Extending to new jurisdictions afterwards is incremental once the model is right.

When you should not build this

Do not build if you make a modest number of formulations shipping to two or three jurisdictions with a stable recipe set. Chemwatch or an authoring service from 3E will produce compliant documents for less than the build costs, and outsourcing authoring entirely is a legitimate answer at that scale. Do not build if you have no regulatory affairs capability in house, because software does not make classification decisions, competent people do.

Build when two or more of these are true. Recipes change frequently enough that document drift is a standing risk rather than an incident. You ship to enough jurisdictions and languages that the document matrix has outgrown a folder structure. Your raw material suppliers revise their own sheets and you have no cascade. You cannot produce a list of who holds which version of which sheet. Your classification decisions cannot be reproduced from stored inputs when an auditor asks. At that point the link between the recipe and the document is the control, and it needs to be code rather than a person hearing about a change.

How to choose a developer for SDS and compliance software

Ask them how they will detect a formulation change. If the answer is a nightly extract, ask what happens to a product that changed and shipped the same day. The right architecture is event driven from the enterprise system, and a developer who has done this will ask which system holds the authoritative recipe and whether it emits change events.

Ask how they version classification. The correct answer stores the inputs, the rule set version and the result, so any historical determination can be reproduced. If only the current classification is stored, you cannot defend a decision made two years ago.

Ask what they will license versus build. A developer proposing to build a substance database from scratch is proposing to spend your money recreating something Sphera and 3E have spent decades on. The sensible build is the workflow, the integration and the generation layer around licensed content.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. Note the distinction from licensed regulatory content, which remains the licensor's and carries its own subscription. Your workflow, your integrations and your phrase library should be unambiguously yours.