Five stages. Each one writes to the audit log as it happens.
A purchase order lot is recorded against a supplier and a material. The moment the lot is recorded, the certificate request goes to the supplier and the clock starts.
If the certificate does not arrive, follow-ups go out on a schedule you define. The default is 5 days, then 5, then 7.
After the final follow-up, the lot escalates to your QA lead, an exception is opened, and automated chasing stops for that batch.
Matching uses two independent signals: the batch reference in the supplier’s message, and whether the sender matches the approved contact for that supplier. Both are then reconciled against the contents of the certificate itself.
The lot moves to received. The audit log has a timestamped row for every step: request, each follow-up, any escalation, receipt, and the review decision.
A purchase order lot is recorded against a supplier and a material. By default this is a form, which takes about twenty seconds and identifies the supplier and material in one selection, so there is no name matching to go wrong.
If you raise purchase orders in a system with an API, integration is scoped at onboarding. It is not assumed, because most manufacturers this size raise POs in Sage, Xero or a spreadsheet, and a form is faster than a half-working integration.
The moment the lot is recorded, the certificate request goes to the supplier and the clock starts.
One detail worth naming: the request is sent before the lot record is created. If the send fails, there is no lot sitting in the system that nobody is chasing. The intake simply retries.
If the certificate does not arrive, follow-ups go out on a schedule you define. The default is 5 days, then 5, then 7.
The wording escalates with the stage. The first follow-up assumes the supplier is busy. The last one does not.
The wording is held in a table you can edit. If your QA manager wants to change a sentence, they change it themselves.
After the final follow-up, the lot escalates to your QA lead, an exception is opened, and automated chasing stops for that batch.
That boundary is deliberate. A system that keeps sending after the situation has changed is worse than no system. Past the ladder, a named person owns the problem, and Opscera’s job is to have documented everything that led there.
The exception is created first, then the notification is sent. An exception records that a problem exists. It does not record that somebody was told about it. If the notification fails, the problem is still on the books.
Supplier replies land in a dedicated address for your business. Every PDF attached is handled as its own certificate, so an email with three certificates files three records rather than one.
Matching uses two independent signals: the batch reference in the supplier’s message, and whether the sender matches the approved contact for that supplier. Both are then reconciled against the contents of the certificate itself. Four outcomes:
| Signals | Outcome |
|---|---|
| Both agree | Filed against the lot, marked received, passes review |
| One signal only | Filed and linked, flagged for human review |
| Signals disagree | Nothing linked to the lot. Chase continues. |
| Nothing matches | Exception raised, document not silently filed |
Subject batch reference and sender both resolve to TPL-LOT-006. Document batch reference agrees.
Subject batch reference resolves to TPL-LOT-008. Document batch reference reads TPL-LOT-002. Signals disagree, no lot linked.
The third row is the one that matters. When a supplier attaches the wrong certificate and sends the right one shortly after, linking the first would leave two certificates on one lot with no way to tell which is authoritative. So it links neither, and keeps chasing.
Every message is also forwarded to your QA inbox with the supplier set as the reply-to address, so your team can reply directly to the supplier without leaving their own inbox.
See what happens when matching failsThe lot moves to received. The audit log has a timestamped row for every step: request, each follow-up, any escalation, receipt, and the review decision.
Nothing is generated later. The record was written as it happened.
TPL-LOT-010 · TPL-PO-010 · Template Peptides SA · Template Vitamin C Powder
| Timestamp | Event | Workflow | Outcome | Notes |
|---|---|---|---|---|
| 2026-07-06 09:02:14 | PO Logged | WF2 PO Intake | success | PO TPL-PO-010 logged for Template Peptides SA / Template Vitamin C Powder. Initial COA request sent to [email protected]. |
| 2026-07-11 09:00:07 | COA Chase Sent | WF1 COA Chase Loop | success | Follow-up 1 sent to [email protected] (chase 1, 5d open) |
| 2026-07-16 09:00:11 | COA Chase Sent | WF1 COA Chase Loop | success | Follow-up 2 sent to [email protected] (chase 2, 10d open) |
| 2026-07-23 09:00:09 | COA Chase Sent | WF1 COA Chase Loop | success | Final Follow-up sent to [email protected] (chase 3, 17d open) |
| 2026-07-28 09:00:06 | COA Escalated | WF1 COA Chase Loop | success | Escalated to [email protected] after 3 chases, 22d open. Exception created. No further automated chasing for this batch. |
Supplier certification expiry is monitored continuously, with alerts at 90, 60, 30, 14 and 7 days out, so renewal documentation can be requested before the certificate lapses rather than after.
A separate weekly review covers what expiry monitoring cannot reach: certificates filed without an expiry date, and suppliers approved on a certification basis with no certificate on file at all.
That second one is not an alert about a date. It is an alert about an approval with nothing behind it, and it is the one that gets found at audit.
Book a process review