Upload a Certificate, and CORA Reads the Expiry Date Printed On It

What CORA reads off a certificate

Four fields, read straight off the document you upload: the credential's name, the issuer, the issue date and the expiry date. A photo taken on a phone works. So does a scanned PDF. Nothing is written to the worker's record until an admin looks at what came back and presses save. Nothing is written silently.

The part that's genuinely different: CORA never works out an expiry date

Here's the trap, and it's worth understanding, because it's the whole reason this page exists. A CPR certificate usually prints only the date it was completed. Say that date is 12 March 2026. The obvious thing for a piece of software to do is read that date, apply the well known rule that CPR runs for a year, and write 12 March 2027 into the expiry field.

It would be right most of the time. That's exactly what makes it dangerous. A date that looks plausible is a date nobody double checks, the field doesn't say where it came from, and eighteen months later a provider hands an auditor a compliance register carrying a renewal date that appears on no document anywhere.

So CORA reads what's printed on the certificate, and says so plainly when nothing is printed at all:

"CORA reads the dates printed on the certificate. When a certificate doesn't print an expiry, CORA tells you so, because an empty field gets checked by a person and a filled one does not."

Enforced three separate ways

An instruction to a model is a request, not a guarantee, so the rule against inventing an expiry is built in three times over, not once.

The instruction CORA sends when it reads a certificate forbids it outright, in plain language: never calculate an expiry date.

A second, independent check looks at whatever comes back and throws away any date that doesn't arrive with the exact text printed on the certificate sitting right beside it. A calculated date has nothing on the page to quote, so it has nowhere to land, even if the first rule were somehow ignored.

And a test inside CORA's own build feeds the reader a made up, calculated expiry on purpose, specifically to prove it gets thrown away before it ever reaches a worker's record.

Ambiguous dates are flagged, never guessed

03/04/2026 is the 3rd of April in Australia and the 4th of March in the United States, and the certificate itself never says which convention its printer used. Most Australian certificates print a date with the month spelled out, "12 March 2026", which settles the question outright and needs no flagging at all.

When the numbers alone can't settle it, CORA gives its best Australian, day-first reading, marks the date ambiguous, and shows you the exact text printed on the certificate right next to it, so you make the call, not a guess dressed up as a reading.

Nothing is retained unless you save it

The reading exists only while the form is open. Close the tab without saving, and nothing from that certificate is kept anywhere. The file itself reaches storage, and the record is written, only the moment an admin presses save, exactly the same as if every field had been typed in by hand.

Where this matters beyond CPR

The same discipline applies to every credential CORA reads: a driver's licence that prints its own expiry, an NDIS Worker Screening Check clearance, a qualification certificate that might print neither date clearly. Whatever's on the page is what gets read. Whatever isn't, stays blank for a person to fill in.

Every claim on this page is written the same way every claim on this site is written: about what CORA actually does, checkable in a demo. See the standard we hold every claim on the site to.

What happens once the admin confirms

Confirmed dates land in the credential register against that worker's record, with their own issue and expiry dates, ready to be filtered, exported, or picked up by CORA's reminder system the moment a renewal comes into range. See how the reminders actually work.