COA Design: Common Pitfalls and How to Fix Them

A certificate of analysis is often the last document a customer sees before accepting or rejecting a batch — and its design determines whether that decision goes smoothly or triggers a phone call, a dispute, or a failed audit. This post walks through the real-world COA failures that tripped up one fictional-but-familiar lab, and exactly what they changed.

How Meridian BioAnalytics Got Into Trouble

Meridian BioAnalytics is a contract testing lab serving nutraceutical and dietary supplement manufacturers. By the time they had 12 active clients and roughly 200 samples moving through the lab each month, their COA process had quietly become a liability.

They were generating certificates in Excel, copying results manually from their instrument exports, and emailing finished PDFs from a shared inbox. It worked — until it didn't.

In a single quarter, Meridian logged:

• 3 customer complaints tied to COAs that listed the wrong specification limits (a copy-paste error had carried over limits from a previous client's product)
• 1 FDA-related inquiry after a COA was issued showing a passing result for a sample that had actually triggered an out-of-specification flag during reanalysis
• 14 revision requests from clients who received COAs missing required fields — lot number, instrument ID, analyst signature, or method reference

None of these were fabrication or fraud. They were design and process failures.

The Three COA Design Flaws Behind the Failures

Flaw 1: Specification Limits Were Hard-Coded Into the Template

Meridian used a single Excel template for all clients, with specification limits typed directly into cells. When a new product came in, an analyst would update those cells — but not always. Over time, different versions of the template multiplied across shared drives, and there was no mechanism to verify that the limits on a given COA matched the approved spec on file for that specific product.

The fix: specification limits should pull from a controlled product master — a single source of truth that is updated only through a documented change process. Any COA generation tool, whether a LIMS or a validated spreadsheet, should reference that master rather than allow ad-hoc editing of the certificate itself.

Flaw 2: No Link Between the COA and the Audit Trail

When the OOS event occurred, Meridian could not immediately produce a complete record showing which analyst had run the original test, when reanalysis was triggered, what the reanalysis result was, and who had authorized the final disposition. The COA showed a result; the investigation records lived in a paper binder; the approval email was in someone's personal inbox.

A COA is not a standalone document. It is the summary output of a chain of events — sample receipt, preparation, analysis, review, and release. If that chain isn't traceable from the certificate itself (or from a system linked to it), the COA is an assertion without evidence. Auditors know this.

Flaw 3: Required Fields Were Left to Analyst Discretion

Meridian had a QA policy that required 11 specific fields on every COA: sample ID, lot number, product name, client name, test method, instrument ID, analyst name, review/approval signature, date of analysis, date of report, and specification source. But the template had no enforcement — fields could be left blank and the file would still save and send.

Of Meridian's 14 revision requests, 9 came down to missing instrument ID or missing method reference. Both are critical for traceability and both were simply forgotten under time pressure.

What the Redesigned Process Looked Like

Meridian's QA director spent four weeks redesigning the COA workflow before touching any software. She mapped every field to its source, identified who was responsible for entering or approving it, and defined which fields were mandatory versus conditional.

The resulting COA template had required fields enforced at the system level — a certificate could not be marked ready for release without all 11 fields populated. Specification limits were locked to the product master and displayed with their revision number so any future audit could confirm which approved spec was in effect at the time of testing.

Every COA was now issued with a unique document ID that linked back to the sample record, the instrument run file, and the analyst and reviewer log. When Meridian implemented Aliquora to manage sample tracking and COA generation, that linkage became automatic — the certificate pulled from the same database that housed the OOS flags, the audit trail, and the approval workflow, so nothing could be manually overridden without a logged reason.

In the two quarters following the redesign, Meridian received zero revision requests tied to missing fields and zero COA-related complaints.

Frequently Asked Questions

What required fields should every COA include?

At minimum: sample ID, lot number, product name, client name, test method and version, instrument ID, analyst name, reviewer/approver name, date of analysis, date of report, and the specification limits with their source or revision reference. Regulated industries may require additional fields — always check your applicable guidance documents.

How do you prevent the wrong specification limits from appearing on a COA?

Specification limits should never be typed directly into a COA template. They should be stored in a controlled product master record and pulled automatically into the certificate at generation time. Any change to a specification should go through a documented change control process that timestamps and identifies who made the update.

What is the relationship between a COA and an out-of-spec investigation?

A COA should only be issued after all OOS investigations are resolved and final disposition is documented. The certificate should reflect the confirmed, approved result — and your system should make it impossible to release a COA while an open OOS flag is attached to that sample.

Can a COA be amended after it has been issued?

Yes, but the amendment must be clearly identified as a revised version, the original must be retained, and the reason for the change must be documented. Issuing a new COA with the same date and document number as the original — without any revision notation — is a documentation integrity failure that auditors treat seriously.

How does LIMS software help with COA generation?

A LIMS reduces manual transcription errors by pulling test results, sample metadata, and specification limits directly from the database rather than requiring analysts to copy values by hand. It can also enforce required fields, gate release on open OOS flags, and generate an audit trail that is permanently linked to each issued certificate.