Field-level checks on certificate entry, so a malformed expiry date never reaches the dashboard
A mistyped expiry date is the quietest way to end up with an expired certificate reading as current, because nothing complains until an auditor pulls the file. Certly checks supplier and certificate entry on the server, so an empty required field, a malformed contact email, a missing certificate type or an expiry date that is not a real date is refused with a field-level error, shown inline in the
Why a wrong expiry date is so expensive to find later
Certificate records are typed in at the worst moment for accuracy. The document arrives as an email attachment on a Thursday afternoon, somebody opens it, reads a date off a scanned page, and types it into whatever holds the approved supplier list. A spreadsheet cell does not object to what goes in it.
The cost is not the typo. The cost is that a wrong date behaves exactly like a right one. A record with no expiry date at all simply sits there looking complete. In a spreadsheet, a supplier line with no required document named against it never produces a missing row, because nothing knows the document was ever expected. A contact address with a stray space looks correct to the eye and reaches nobody. Each of these is silent, and each surfaces at the point where you are least able to fix it, with an auditor at the table asking for the current allergen declaration.
Three kinds of entry error, not one
- Shape errors: a date that is not a date, an address with no at sign, an empty name. A machine can catch all of these.
- Omission errors: a certificate document uploaded with no certificate type chosen. A machine can refuse that too, rather than storing a file nobody can account for.
- Transcription errors: a real date typed wrong, 2027 where the page says 2026. No validation can see this, and it is worth being honest about which group you are in.
Certly refuses the save when a required supplier field is empty, when a contact email is not a valid address, when an expiry date is not a real date, or when a certificate upload carries no type. That leaves transcription, the group a second pair of eyes still has to catch, and the one way to shrink it is to type fewer dates in the first place.
How the check works when you add a supplier or a certificate
- Add the supplier and say which certificates you require
Suppliers are added and edited in Certly with their contact details and the certificate types you require from them, such as an allergen declaration, a CoA or an audit certificate. Naming the requirement at the supplier level is what gives an absent document something to be absent from.
- Upload the certificate against that supplier and type
Your QA team uploads each certificate document and ties it to one supplier and one certificate type. The upload records the date on the document as its issue date, and the expiry date alongside it. There is no loose pile of files: every document has an owner and a slot.
- Let the due date be derived where the document has no printed expiry
An allergen declaration or a vendor form often carries no expiry date at all. Each certificate type can hold a renewal period for your plant, and when it does, the due date is derived from the issue date rather than typed. One field fewer to read off a scan is one field fewer to get wrong.
- The server checks the entry before anything is stored
On the supplier create and update endpoints and on the certificate upload form, Certly validates the required fields: a supplier name, a contact email in a valid format, a certificate type, and an expiry date that is a real date, whether that date falls in the past or the future. An entry that fails is rejected with a 400 and field-level error messages rather than quietly saved.
- You fix the field, not the record
Those messages are surfaced inline in the suppliers add and edit form and in the certificate upload form, next to the input that caused them. You correct the one date or the one address and submit again, instead of retyping the whole record or hunting for what the form disliked.
What that buys you on a Thursday afternoon
The check runs on the server, not just in the browser
Validation sits on the supplier create and update endpoints and on the certificate upload form, so a stale tab, a half-loaded page or a resubmitted request cannot put a record in that the form would have refused.
Errors arrive field by field
A 400 with field-level messages, rendered inline in the form, tells you which input failed and why. One correction, one resubmit, rather than a single red banner over a form you have to re-read.
Expiry dates in the past are accepted on purpose
The check asks whether the date is real, not whether it is in the future. You can record a certificate that lapsed last quarter, which is exactly what you need to do when you are cleaning up an inherited supplier list.
Fewer dates typed means fewer dates mistyped
For a certificate type with a renewal period set for your plant, you enter the issue date from the document and the due date follows from it. The arithmetic a QA coordinator used to do in their head, three years from the date on the form, stops being a place where a year can slip.
A supplier contact address is checked at entry
A malformed contact email is caught in the form rather than discovered weeks later, when the address your reminders depend on turns out to have had a space in it all along.
What the check catches and what it cannot
| Field | Rejected with a field-level error | Still needs a human |
|---|---|---|
| Supplier name | An empty name on create or update | Whether the name matches the legal entity on the certificate |
| Contact email | An address that is not a valid email format | Whether anyone actually reads that inbox |
| Certificate type | An upload with no certificate type selected | Whether the attached document is the type you selected |
| Expiry date | A blank date, or text that is not a real date | A real date transcribed wrong from the document |
| Derived due date | Nothing to reject: it comes from the issue date and the type's renewal period | Whether the renewal period you set for that type is the one your scheme expects |
Where this sits in the rest of the job
Field checks are the cheapest part of certificate control and the easiest to skip. They matter because everything downstream, every status, every reminder at 90, 60 and 30 days, every page you hand an auditor, is only as good as the date somebody typed. Getting the shape of the record right at entry is what makes the rest of it trustworthy enough to act on. When a renewal is uploaded over a slot, the version it replaces is kept rather than deleted, so a corrected record does not cost you the document that was on file before it.
If you are earlier in the decision than this, the guide on tracking expiry dates compares the honest options, including the spreadsheet you already have, and the glossary entry on an expired certificate on file sets out what a certification body tends to raise when a date has gone past. The renewal periods page covers the derived due date in full, for the declarations and vendor forms that carry no printed expiry. If you want to see what the entry work turns into, the chase log page covers what was sent to a supplier and what came back.
Certly is still in build
The product is not open to general sign-up yet, and this page describes what it is built to do rather than what customers report. Plans are declared: Starter at $3,228 a year covers a single plant tracking up to 50 suppliers and includes a 14-day free trial. If this is the problem on your desk, join the waitlist and you will hear when accounts open.
Questions
Does Certly read the expiry date off the certificate for me?
No. You enter the dates when you upload the document, and the check confirms the expiry date is a real date rather than reading the page. Certly tracks and reminds; it does not verify a certificate's authenticity or guarantee compliance.
What about a document with no expiry date printed on it?
Record the issue date from the form, and where that certificate type has a renewal period set for your plant, the due date is derived from it instead of being typed. The renewal periods page explains how the period is set per type.
Can I record a certificate that has already expired?
Yes. The check accepts any real date, past or future, which is what you need when you are loading an existing supplier list where some documents have already lapsed.
Where do the error messages appear?
The supplier create and update endpoints and the certificate upload form return a 400 with field-level error messages, and those messages are rendered inline in the suppliers add and edit form and in the certificate upload form, beside the field that failed.
Which fields are required?
A supplier name, a contact email in a valid format, a certificate type on an upload, and an expiry date that is a real date. A record missing any of those is refused rather than saved.
Will this stop every wrong expiry date?
No, and it is worth saying so plainly. It stops dates that are not dates and entries that are missing a required field. A plausible but mistyped date, 2027 instead of 2026, is still a valid date and will be accepted.
Who does the entry, my team or the supplier?
Either. Your QA team adds and edits suppliers with their contact details and required certificate types and uploads certificates against a supplier and a type, and a supplier can upload into a slot itself through a single-use, expiring email link with no login.
Can I use Certly today?
Not yet. Certly is in build and this site is taking waitlist sign-ups, so everything here describes what the product is built to do rather than customer results.