Chemical Manufacturing Software: Fixing the Formula-to-SDS Gap

Why formula and batch software makes or breaks a chemical manufacturer

Walk the office of a $40M specialty chemical blender and you will find the same stack every time. QuickBooks or Sage 100 for the money. Some version of an inventory module that was never meant to hold a bill of materials with a potency-adjusted quantity. SDS authoring in SAP EHS, Sphera, or a Chemwatch or MSDSonline subscription. Batch tickets printed from a Word template. And underneath all of it, the actual formulas: an Excel workbook on a shared drive that the technical director built in 2014, with tabs named things like MASTER_v3_USE_THIS.

The workbook is the company. It holds the raw material substitution notes, the yield factors, the pH adjustment logic, and the one comment cell that says "do not use Supplier B lot after Feb, chelation issue." None of that lives in the ERP (Enterprise Resource Planning). So when a batch runs, the operator reads the printed ticket, weighs to it, writes actuals in pen, and hands the sheet to QC. QC runs the panel, writes results on a second sheet, and someone in the office types both into the system three days later. By then the drums have shipped.

The expensive version of this happens about once a month. A customer calls about drum lot 24-0817. They want the COA and they want to know which lot of the surfactant went in, because their own downstream customer flagged something. Your quality manager now opens four things: the batch ticket PDF folder, the receiving log, the Excel workbook to find which formula version was active on August 17, and the SDS system to check whether the classification on file matches what actually got blended. That reconstruction takes four to six hours. We have watched it take two days when the batch used a substituted raw material and nobody wrote down the substitution reason. At 40 batches a month with even three trace requests, that is a full-time person doing archaeology instead of quality.

Problem: your formulas live in Excel and your ERP does not know it

The specific failure: a formula changes and nothing downstream knows. Your technical director drops the amine loading from 4.2% to 3.9% because a supplier changed assay. He updates the workbook. The ERP still has the old BOM, so the MRP run buys the wrong quantity. The SDS still shows the old composition, so the hazard percentage band is now wrong. The COA template still calls out the old spec range.

Why the off-the-shelf tools cannot fix this: NetSuite and Sage X3 model a bill of materials as a fixed quantity list. Chemical formulas are not that. They are percentage-based, they scale to a batch size, they carry potency and assay adjustments, they have theoretical yield versus actual yield, and they have substitution rules that are conditional on incoming lot properties. Process-oriented systems like BatchMaster or Deacom get closer, but you are then buying their opinion of your formula model, and every blender we have worked with has at least three formula behaviors the vendor did not anticipate. Chemwatch and Sphera do not touch your BOM at all; they are authoring tools that consume a composition you hand them.

What a custom build does: one formula record with real versioning. Every version is immutable once released, carries an effective date, an approver, and a change reason. The version is what gets stamped onto the batch, not a copy of it. The formula engine holds percentage-by-weight lines, potency-adjusted actual quantities computed at batch release from the specific lot assay on hand, and substitution rules expressed as conditions the system evaluates rather than notes a human reads. When a version releases, the system fires downstream: it recalculates the hazard composition bands, flags the SDS for regeneration, updates the COA spec template, and pushes the new consumption factors to whatever holds your purchasing. One change, one place, everything propagates. In our experience that single data flow is around 60% of the value of the whole build.

Problem: SDS authoring is disconnected from what you actually made

The specific failure: you subscribe to an authoring tool. Someone in EHS types the composition in. When the formula moves, nobody retypes it, because retyping is a 20-minute job across 40 SKUs in three languages and it never makes it to the top of anyone's list. Six months later your SDS says 1 to 5% of a component that is now 6.5%, which moves the classification band, which means the label is wrong, which means the shipping papers are wrong.

Why the incumbents cannot fix this: Chemwatch, MSDSonline, SAP EHS, and Sphera are all downstream of a composition you supply manually. They have excellent hazard rule engines and excellent regulatory content libraries. They have no idea what you blended yesterday. The integration they offer is usually a file drop or an API you still have to feed, and feeding it correctly requires exactly the formula model you do not have.

What a custom build does: the SDS becomes a generated artifact, not a maintained document. Composition flows from the released formula version. You keep the hazard content subscription, because writing your own GHS rule engine is a bad idea and their regulatory library is worth the money, but you drive it through their API from your formula data instead of by hand. The build wires the classification call, receives the phrases back, renders your Section 1 through 16 with your company data, and versions the output against the formula version that produced it. Change the formula, the SDS regenerates and lands in an approval queue. Section 3 can no longer drift from reality, because there is no human retyping step to skip.

The one place AI earns its keep here is incoming supplier SDS extraction. You receive PDFs from 60 suppliers in 20 formats. Someone types the hazard data, the CAS numbers, the exposure limits, and the transport classification into your raw material master. A document extraction model reads the PDF, pulls Section 2, 3, 9, and 14, maps CAS to your material record, and drops anything it is unsure about into a human review queue rather than guessing. We build this with confidence thresholds and a mandatory review step for anything that changes a classification. It is not glamorous. It removes about 15 hours a month of typing and, more importantly, removes the transcription errors that were silently propagating into your own documents.

Problem: batch genealogy exists on paper, so traceability is archaeology

The specific failure: the recall drill. Your customer, or worse your auditor, asks which finished lots contain raw material lot RM-7741. You need forward trace, backward trace, and you need it in hours. What you have is a paper batch ticket in a banker's box, a receiving log in one system, and shipment records in another, joined by a human reading lot numbers.

Why the incumbents cannot fix this: your accounting-first ERP records that you consumed 400 kg of surfactant. It does not record that 250 kg came from lot A and 150 from lot B because the first tote ran out mid-charge. That split is the entire trace, and it only exists in the operator's handwriting.

What a custom build does: capture consumption at the charge, not at the batch. The operator scans the lot barcode on the tote before charging, the scale integration writes actual weight against that specific lot, and when they switch totes mid-charge the system records two consumption lines automatically. Genealogy becomes a graph the database walks, not a story a person reconstructs. Forward trace from RM lot to every drum shipped, backward trace from a customer complaint to every input, both under 10 seconds. Build this on tablets in the plant with a rugged case and offline queueing, because your blending floor Wi-Fi will drop and an operator will not wait for it. We size this at roughly 3 to 4 weeks of the first release when scales are already networked, and closer to 6 to 8 when we are integrating Mettler Toledo or Rice Lake indicators over serial.

Problem: QC results and COAs are a bottleneck, not a control

The specific failure: batch completes Tuesday, QC runs the panel Wednesday, the COA gets typed Thursday, the truck was supposed to leave Wednesday. So it left Wednesday and the COA got emailed Friday, which means you shipped without release. Everyone knows. Nobody says it.

Why the incumbents cannot fix this: a generic ERP has a QC hold flag. It does not model your spec ranges per customer, and it does not know that Customer A wants viscosity reported at 25C and Customer B wants it at 40C off the same drum, or that Customer C's contract specs are tighter than your internal spec so the same result passes internally and fails for them.

What a custom build does: specs are records with customer overrides, and results entry is on a tablet at the lab bench with instrument capture where the instrument supports it. The system evaluates against the internal spec and every customer spec the batch is allocated to, and it does this the moment a result is entered. Fail against a customer spec, the allocation blocks and the sales rep gets notified before the truck is loaded. COAs generate per customer per lot with the right test set, right units, right conditions, and go out automatically at release. This is also where forecasting is honest AI rather than decorative: with two years of batch results, a model flags a batch as at-risk of failing spec based on the incoming lot assays and the process parameters, before the panel runs. Not to make the release decision, but to tell the plant manager on Monday which of this week's batches deserve a second look. On high-volume commodity blending we have seen that surface a real signal. On low-volume specialty work with 30 batches a year per SKU, there is not enough data and we tell clients to skip it.

Problem: shipping documents and regulatory reporting are a second manual system

The specific failure: DOT and IATA classification gets decided at the shipping desk by someone reading the SDS. Tier II reporting in March means someone exports a year of transactions and hand-builds a spreadsheet by threshold. TSCA and, if you export, REACH volume tracking is a separate annual scramble.

Why the incumbents cannot fix this: your shipping software knows weights and addresses. Your SDS tool knows hazards. Neither knows your inventory positions over time, which is what threshold reporting actually needs.

What a custom build does: transport classification derives from the same formula-linked hazard data that drives the SDS, so the shipping paper, the label, and the SDS cannot disagree. Threshold reporting becomes a query, because you have daily on-hand positions per material per location already sitting in the database. March becomes an afternoon.

What this actually costs and how long it takes

These are Digital Heroes numbers, from delivery across 2,000-plus projects, not a market survey. A focused first release for a chemical manufacturer runs $60k to $130k and ships in 12 to 16 weeks. That release is: formula master with versioning and approval, batch execution with lot-level genealogy capture, QC results and customer-spec COA generation, and SDS generation driven off formula composition through your existing hazard content subscription. A full platform, adding scale and instrument integration, DOT and IATA document generation, Tier II and TSCA reporting, customer portal, and ERP or accounting sync, runs $150k to $400k phased over 6 to 12 months.

What pushes price up in this category specifically. Instrument and scale integration is the big one: networked scales with a clean protocol are cheap, serial indicators bolted to a 1990s mixer are not, and every one is bespoke. Multi-jurisdiction SDS, meaning you ship into the EU or Canada or Latin America and need language variants and jurisdiction-specific classification, adds meaningfully. Any 21 CFR Part 11 requirement, which applies if you touch pharma intermediates or FDA-regulated food contact, adds validation work: IQ, OQ, PQ documentation, audit trail rigor, and electronic signature controls. That is typically a 25 to 40% adder on the affected modules, and it is not optional if it applies. Continuous or semi-continuous process, as opposed to discrete batch, changes the data model and the genealogy math. And the quiet one: if your formula workbook has undocumented logic in it, and it does, discovery takes longer than anyone budgets. We front-load that with two weeks of working directly with your technical director before writing anything.

Build versus buy: take a position

Buy is the correct call if you run one plant, under 15 to 20 active SKUs, blend to fixed recipes rather than to spec, and ship domestically into unregulated or lightly regulated channels. In the quotes our clients have shown us, BatchMaster, Deacom, or Datacor Chempax land in the $40k to $120k range for year one and get you 80% of the way, and that 80% is enough at that size. Fighting a vendor for a $200k build to serve 15 SKUs is ego, not economics. Do not do it.

The signals it is time to build, and any two of these is enough. First, you have a person whose actual job is reconciling systems: they take QC results and type them somewhere, they take batch tickets and type them somewhere. That person costs you $60k a year and is a walking error rate. Second, your formula workbook has logic that no commercial system models, and every demo you sit through ends with the vendor saying "you could handle that with a custom field." Third, a trace request takes more than an hour. Fourth, you have modified your off-the-shelf system so heavily that you are afraid to upgrade it, which means you are already paying to maintain custom software, just badly and on someone else's platform. Fifth, and this is the one that closes the argument: your formulas are your competitive position and they are sitting in a file that a departing employee could email to himself in nine seconds.

The version we recommend most often is neither pure. Keep your accounting where it is. Keep your hazard content subscription. Build the formula, batch, QC, and SDS-generation layer as your own, and integrate outward. That is the $60k to $130k first release, and it puts the custom money exactly where the off-the-shelf market has no good answer.

How to choose a developer for chemical manufacturing software

Ask them to model a formula on a whiteboard, cold, before you sign anything. If they draw a parent record with child quantity lines, they have built inventory software and not chemical software. You want to hear percentage-by-weight, potency and assay adjustment, theoretical versus actual yield, and immutable released versions unprompted. This one question filters most of the market in ten minutes.

Ask what they have integrated. Not "do you do integrations," but specifically: have you pulled from a Mettler Toledo indicator, have you driven the Chemwatch or Sphera API, have you written to Sage or NetSuite. The answers should come with a story about what broke. Chemical builds live or die at the integration boundaries, and the boundaries in this industry are old, serial, and undocumented.

Ask about compliance scope up front and make them tell you what does not apply to you. A firm that reflexively quotes Part 11 validation for a lubricant blender who never touches FDA product is either padding or does not know the regulations. The right answer names your actual exposure: GHS and SDS accuracy, DOT and IATA, Tier II thresholds, TSCA inventory, and Part 11 only if you touch regulated intermediates.

Get the code ownership and escrow terms in writing before the kickoff, not at the end. You are encoding the formulas that are the company. The contract should say you own the repository, you get the deployment, and you can walk. Any firm that hesitates on this is telling you what their retention strategy is.