SDS review checklist template for customer document packages

What is an SDS, TDS and CoA package checklist for, and when do you use it?

An SDS, TDS and CoA package checklist is a pre-send check that a customer document package contains every document the recipient and the market require, in a current version, for the right product, grade and lot, with no contradiction between documents. The safety data sheet (SDS) carries hazard and handling information, the technical data sheet (TDS) describes the grade and its typical properties, and the certificate of analysis (CoA) reports test results for one lot.

Use the checklist at the moment a package is about to go out: a customer submission, an export shipment, a qualification response or an approval listing. The person who owns the submission fills it in, usually someone in supplier quality, regulatory affairs or sales support at a manufacturer or distributor.

The checklists that rank for this topic check one SDS when it arrives at a site. They have no TDS or CoA rows, no step that records what the recipient asked for, and no check across documents. This template works in the other direction: it starts from the recipient's requirements and ends with a send date. The editable Word checklist and an Excel and CSV register with the same columns are at the end of this page.

Which documents does a customer or market require in an SDS, TDS and CoA package?

A customer or market requires an SDS where a regulation says so, while the TDS and CoA are required because the recipient's specification, purchase order or approval process asks for them. The checklist therefore records, for each document, the requirement it meets, since a missing SDS and a missing TDS have different consequences. A missing SDS can be a breach of the receiving market's rules; a missing TDS is a gap against the customer's own list, and the customer decides whether it can follow later.

The table below shows where each document requirement comes from, which decides what goes on the required list in section 1.

CoA content can differ by recipient even for one product, because customers can set different tests, specifications or acceptable ranges (Datacor, 2024). The key row for an EU recipient is the language rule: an English SDS for a German site does not meet REACH Article 31(5) unless the Member State provides otherwise.

Package checklist section 1: submission purpose and required documents

Package checklist section 1 records what the submission is for, who receives it, which market it enters, and every document the package must contain, each with the requirement it meets. The section is complete before anyone opens the folder of available files.

The table below previews the section 1 fields of the checklist; the example values are illustrative.

The column that decides the rest of the check is "Requirement it meets": every later row is tested against it.

The order matters. A checker who opens the available files first tends to check what is there and miss what was asked for, which is how a package goes out complete in its own terms but short of the customer's list. Freezing the required set first turns omission into something the checklist can detect.

Where the recipient's requirement is not written down, record it as an open question and ask the recipient before continuing. A guessed requirement tends to produce a resubmission, because the gap appears only when the recipient reviews the package.

Package checklist section 2: state of each SDS, TDS and CoA

Package checklist section 2 gives each required SDS, TDS and CoA one row with its issuer, issue date, revision or lot, state, remaining validity and an identifier cross-match. The state takes one of four values: present, missing, expired or unapproved.

The table below previews the section 2 columns; the example values are illustrative.

The column that most often fails is the identifier cross-match, because it is the one check that reads two documents at once.

For the SDS, record the revision number and revision date, which REACH Article 31(9) requires on an updated EU SDS as "Revision: (date)" (REACH, consolidated 2025). For the TDS, record the version or date printed on it. For the CoA, record the lot number and the date of analysis or release, plus any retest or expiry date; for active pharmaceutical ingredients, ICH Q7 recommends that the CoA show the grade, batch number, release date and the expiry date where one applies (a retest date may be on the label, the CoA or both) (ICH Q7, 2000, section 11.41).

Unapproved covers a document not yet released by its issuer, such as a draft TDS or a CoA from a quarantined lot. Expired covers a passed validity end date and any SDS superseded by a later revision. Where no validity can be read, the cell reads "to be confirmed" rather than a guess. A no in the cross-match column moves the item into section 3.

What counts as a mismatch between the SDS, TDS and CoA in one package?

A mismatch between the SDS, TDS and CoA in one package is any case where two documents, or a document and the order, give different values for the same identifier or property. Each document matches the order on a different level.

The CoA is lot-level: its lot number has to be the lot being shipped. The TDS is grade-level: its grade name and version have to be the grade on the order. The SDS is product and jurisdiction level: its product identifier has to cover the grade, and its regulatory content has to be written for the receiving market. A package can hold three correct documents that still fail together, for example a CoA for the right grade but a different lot.

Typical mismatch pairs are product names that differ between SDS section 1 and the TDS title, a CoA lot that is not on the packing list, a physical property such as flash point given differently in SDS section 9 and the TDS, a CoA specification limit that differs from the recipient's specification revision, and an SDS written for another jurisdiction.

Section 3 of the checklist records each mismatch in the columns previewed below; the example values are illustrative.

The deciding column is "Blocks send", because it separates a fix that holds the package from one that can follow it. Treat expiry, a wrong target and a contradiction as failures of their own kind: each needs a different fix and owner from a missing document.

Package checklist section 4: remediation plan and send date

Package checklist section 4 states the final position, ready to send or needs remediation, then lists every fix with what has to change, who changes it, by when, and the condition that closes it, and ends with the earliest send date.

The table below previews the section 4 columns; the example values are illustrative.

Take each blocking item from section 3 and turn it into one fix. A missing CoA becomes a request to the laboratory or the supplier for the CoA of the shipped lot. A superseded SDS becomes a request for the current revision for that market and language. A name mismatch becomes a correction by the document owner, or a written note to the recipient explaining that two names refer to one grade, if the recipient accepts that.

The closing condition is what turns a fix into a checkable item. "Receive CoA for the shipped lot showing every test on the customer's specification revision" can be closed by reading one document; "fix the CoA" cannot.

The earliest send date is the latest due date among the blocking fixes, not the shipment date. If that date falls after the planned shipment, the gap is visible to the person who can move the shipment or ask the recipient for a short extension. Non-blocking items, such as a missing page number, can be listed with an owner and left to follow the package.

How do you check an SDS for expiry and the right market before sending it?

You check an SDS for expiry by comparing its revision with the issuer's latest revision for that market, because the main SDS rules set update triggers rather than a printed expiry date. The market check then confirms language, format and regulatory content for the receiving country.

In the United States, the preparer adds significant new hazard information "within three months" of becoming aware of it (29 CFR 1910.1200(g)(5), eCFR 2026). In the EU, suppliers update the SDS without delay on new hazard information, an authorisation decision or a restriction (REACH Article 31(9), consolidated 2025). In Canada, the update is due within 90 days of the supplier becoming aware of significant new data, and the earlier three-year supplier update cycle no longer applies, although federally regulated workplaces and several provinces and territories require employers to seek an updated SDS every three years (CCOHS, accessed 2026).

For an EU recipient, also check the format. Commission Regulation (EU) 2020/878 replaced Annex II from 1 January 2021, and SDSs not complying with it could be provided until 31 December 2022 (Commission Regulation (EU) 2020/878, 2020). An EU SDS still in the earlier format fails the market check.

The market check covers the language rule in section 1, supplier details and an emergency telephone number in SDS section 1, including in the EU the number of the receiving Member State's official advisory body where one exists (REACH Annex II as amended by Regulation (EU) 2020/878, sections 1.3 and 1.4), and SDS section 15 regulatory information written for that jurisdiction. A recipient's own age rule, such as "SDS revised within the last N years", goes in days of validity remaining.

How to fill in the document package checklist, with an illustrative example

Fill in the document package checklist in four passes, one per section, and do not start section 2 until section 1 is agreed with the recipient or the internal owner. The example below is illustrative: the product, customer and values are invented to show how a filled row reads.

1. Section 1: record purpose, recipient, market, SDS language and the required list with the basis of each document.

2. Section 2: open each available file once and record issuer, date, revision or lot, state, days remaining and the identifier cross-match.

3. Section 3: list every missing, expired, unapproved or contradictory item with the documents involved and both values.

4. Section 4: write the fix, owner, due date and closing condition for each blocking item, then the earliest send date.

The table below shows an illustrative filled extract for an initial supply of a hydraulic fluid grade to a customer site in Germany, which decides whether this package can go.

In this illustrative case the English SDS blocks the package, because REACH Article 31(5) asks for the official language of the Member State, so the first fix is a German SDS of the same revision.

When is a document package ready to send to the customer?

A document package is ready to send to the customer when every document on the section 1 list is present, current, approved and matched to the order, and no contradiction between documents remains open. Non-blocking items may remain if they are listed with an owner.

Ready to send is a single position for the whole package. One missing CoA or one SDS in the wrong language makes the position "needs remediation", even if every other document is correct, because the recipient checks the package against its own list and returns it on the first gap.

Timing is part of readiness for the SDS. Under the US Hazard Communication Standard, the SDS goes with the initial shipment and with the first shipment after an update (29 CFR 1910.1200(g)(6)(i), eCFR 2026). Under REACH, it is provided no later than the date the product is first supplied (REACH Article 31(8), consolidated 2025). Where a supplier gives SDS access electronically, a 1999 OSHA interpretation letter says that after a significant change to health hazard information the supplier must make sure downstream users know the updated sheet is available, for example by letter (OSHA interpretation letter, 1999).

Record the send date and what was sent in the register, with the revision of each document. The record answers the next question a recipient asks, which is usually which revision they hold, and it shows who must receive an updated SDS when the revision changes.

Where the SDS package checklist does not fit

The SDS package checklist does not fit tasks that need a new technical or regulatory judgment, because it checks completeness and consistency among documents that already exist. It does not classify a product, write an SDS, decide whether a grade suits an application, or confirm that a substance is absent from a regulatory list.

Three situations need something else. Answering a customer questionnaire item by item is a separate response document, with one answer and one source per question. Resending one known document to a recipient who already holds the package needs a covering note, not a full check. Writing or revising the SDS itself starts from each jurisdiction's classification criteria and SDS content rules, such as Appendices A, B and D of 29 CFR 1910.1200 or the CLP Regulation and Annex II of REACH.

The jurisdiction rows in this page cover the United States, the European Union and Canada. Other markets have their own SDS format and language rules, and the required list for them comes from that market's regulation and the recipient. The checklist also assumes the issuer controls its own documents: a distributor checking a manufacturer's documents can find a mismatch but cannot correct it, so the fix owner in section 4 is the manufacturer. Lubinpla's submission document check works from your own TDS, SDS and CoA files: it fixes the recipient requirements first, compares each document against them and returns, for your review, whether the package can be sent, with remediation requests.