Certificate of analysis preparation in fewer hours

A batch has passed its tests. The material is packed, the export documents are ready and the container is booked. One thing is missing: the certificate of analysis. The QC chemist opens last month's certificate for the same customer, saves it under a new name, and starts changing the batch number, the dates and the results, one cell at a time, from the analysis register and two instrument printouts.

If you make intermediates, APIs, specialty or dye chemicals and sell to regulated or export customers, certificate of analysis preparation is part of every dispatch. Search for how to do it and you will find templates, glossary pages and software vendors claiming that a certificate takes half an hour or more by hand and minutes with their product. What you will not find is how to tell where your own hours go, or whether you need software at all.

This article is about that.

What goes into a certificate of analysis?

For APIs and intermediates, the ICH Q7 good manufacturing practice guide sets out the content in section 11.4, Certificates of Analysis. In short, the certificate should show:

• the name of the material, with its grade where appropriate
• the batch number and the date of release
• the expiry date or the retest date, where the material has one
• each test performed in accordance with compendial or customer requirements, with its acceptance limits and the numerical result
• a date and the signature of authorised personnel of the quality unit
• the name, address and telephone number of the original manufacturer

Customers outside pharma ask for something similar, and many add their own requirements: their product code, their specification number, extra tests, a different order of tests, their own layout. That is where the work multiplies.

Where do the hours in certificate of analysis preparation actually go?

It is tempting to think of a certificate as a typing job. Watch one being made and the typing is the shortest part.

Finding the results. The assay is in the HPLC report, moisture in the KF register, appearance and melting point in the analyst's notebook. Someone has to collect every result for this batch from three or four places before writing a single line.

Finding what this customer wants. The tests, limits and units for the same product can differ by customer. One wants a test the standard specification does not include; another wants limits tighter than yours. These requirements sit in quality agreements, purchase orders and old emails, and someone has to remember which one applies.

Keeping one format per customer. A plant with forty products and twenty export customers can end up with dozens of certificate files, each a copy of a copy. The wrong template, or a stale limit carried over from an old revision, is an easy mistake.

Checking. Every transcribed number has to be checked against its source before the certificate is signed, usually by a second person. A transposed digit in an assay value is the kind of error a customer notices.

Re-issuing. A customer asks for a corrected certificate, a different layout, or a copy for a later dispatch from the same batch. Each request is another round of finding, editing and checking.

Filing. The signed certificate has to be kept against the batch and the dispatch so it can be found again, months later, when a customer or an auditor asks.

Notice that almost none of this is typing. It is collecting, matching and checking, done by the people who know the products and the customers best.

How do you measure COA hours in your own lab?

Before changing anything, find out what certificates cost you now. Your dispatch register and your certificate files already hold most of the answer.

Take the last month and note:

1. Certificates issued, split by product and by customer.
2. Formats in use: how many distinct certificate layouts did you send?
3. Tests per certificate, roughly. A five-test certificate and a twenty-five-test certificate are different jobs.
4. Corrections and re-issues, and why: wrong value, wrong limit, wrong format, customer request.
5. Dispatches that waited for a certificate, and for how long.
6. Who prepared and who checked, and what they were pulled away from.

Then time one week as it happens: a simple log of start and stop times for each certificate, split into collecting results, preparing, checking and re-issuing. A log kept at the time is worth far more than an estimate made afterwards.

The arithmetic is simple enough to check yourself. For example, if you issue 120 certificates a month and each takes 20 minutes to prepare and 10 minutes to check, that is 60 hours. If one in ten needs a correction that takes another 30 minutes, add 6 hours. That is well over a working week of a qualified chemist every month. Your numbers may be much smaller or much larger. The point is to know them.

What can you fix without new software?

Several of the slowest hours come from how results and customer requirements are kept, not from the certificate itself.

• Keep one results sheet per batch. Every test, method, limit, result and analyst in one place, filled in as the analysis is done, not reconstructed at dispatch.
• Write one requirements sheet per customer and product. Their tests, limits, units, product code and specification number, with the source document named. Built once, reviewed when the quality agreement changes.
• Generate certificates from the data, not from old certificates. A spreadsheet that fills each customer's layout from the results sheet and the requirements sheet removes most retyping. Lock everything except the fields that change per batch.
• Agree fewer formats. Ask customers whether your standard certificate, with their product code and specification number added, is acceptable. Each customer who agrees is one less format to maintain.
• File by batch number. Store every certificate issued against the batch, with its revision, so a re-issue starts from the record.

If you issue a few dozen certificates a month for a handful of customers, these steps may be all you need.

When is AI the wrong tool for COA preparation?

AI is not always the answer, whatever a vendor says. Be sceptical if:

• Your results are already structured. If every result sits in a LIMS or a well-kept spreadsheet, filling a certificate is a template problem. A report or a mail-merge does it with no reading required.
• Volume is low. A few certificates a week rarely justify more than a results sheet and a requirements sheet.
• The decision is a judgement. Whether an out-of-specification result is investigated, whether a batch is released, whether a customer accepts a deviation: these belong to your quality unit. A system can show the result against the limit; it must not decide.
• You cannot validate it yet. Under GMP, ICH Q7 (paragraph 5.40) says computerised systems used for GMP work should be validated. Anything that produces the certificate you sign becomes part of your quality system. Start where the risk is lower, for example in preparing drafts that a person checks against the source, and plan the validation before you rely on it.

What does a working system look like?

Where the volume is real and the hours are in collecting and matching, a well-built system does the collecting and the matching, not the releasing. In practice it should:

• Read the sources you already have: instrument reports, analysis registers, scanned worksheets and customer specifications, and pull out each result and each requirement as a named field.
• Keep the source. Every value on the draft certificate points back to the page it came from, so the checker can confirm it in seconds.
• Apply the customer's requirements. Choose the right tests, limits, units and layout for this customer and product, and show where each requirement came from.
• Validate before it drafts. A missing test, a result outside a limit, or a limit that differs from the customer's current specification is shown, not smoothed over.
• Flag doubts to a person. An unreadable figure, a batch number that matches nothing in the register, a test the customer asks for that was never run: these go to QC, not onto the certificate.
• File the result against the batch, in the system you already keep.

The authorised person still signs. The difference is that they review a checked draft instead of building each certificate from scratch. Our document intelligence page shows an example of what we build for documents like these. The same reading-and-matching problem, seen from the receiving side and for metals, is the subject of our article on mill test certificate verification.

What should you ask before buying anything?

Whether it is a LIMS, a certificate module, a service or a custom build, ask:

1. How many hours does our certificate work take today, measured, and how many will this remove?
2. Does it work from the records we actually keep, including registers, printouts and scans, or only from data already in its own database?
3. Where does it hold each customer's requirements, and can we see and approve them?
4. Can every value it puts on a certificate be traced back to the original result?
5. What happens when it is unsure? Does it guess, or does it flag?
6. What will validation involve, who does it, and what does it cost us in time?
7. If our volume is low, will you tell us this is not worth doing?

If the answer to the last question is anything but yes, keep looking.

Where to start

Take one month of dispatches and count three things: certificates issued, formats in use, and certificates corrected or re-issued. That page will tell you whether you need a results sheet, fewer formats, or something that reads your records and drafts certificates for you.

If you would like a second opinion on it, book a 30-minute call about this one process at prakreon.com/contact. We will ask who prepares your certificates, how many go out and how long each takes, and we will tell you plainly if the answer is a better spreadsheet rather than new software.