Only Certify People Who Actually Showed Up

Certify the people who actually showed up, not everyone who registered. A registration list and an attendance list are different things, and sending a certificate to both groups quietly tells the people who came that showing up didn't matter — the person who no-showed got the same document.

Last updated: August 2026

This sounds obvious stated plainly, and most organizers would agree with it if asked directly. What actually happens is different: the certificate batch gets built from the registration list, because that's the list that already exists in a spreadsheet, and the smaller, messier attendance list — who actually walked in the door — never gets reconciled against it. Nobody decides to certify no-shows. It happens by default, because the wrong list was the convenient one.

Why does certifying no-shows actually matter?

Because a certificate is a claim, and "attended" is usually part of that claim even when it isn't spelled out. A certificate of attendance that goes to someone who registered and never came is simply false — it says something happened that didn't. A completion certificate sent the same way is worse, because it implies work was done on top of presence that never occurred. See certificate of attendance vs certificate of completion for how to word each one so it says only what's true.

There's a second-order effect too: once one no-show has the same certificate as everyone who attended, the certificate stops functioning as a useful signal at all. If anyone can end up with one regardless of whether they showed up, the document has quietly downgraded itself to a formality, and the effort put into the workshop or course loses whatever proof-of-work value the certificate was meant to carry. Building the batch in Certificate Maker from the right list to begin with is a one-time decision that fixes this for every certificate in the batch, not a per-recipient check.

How do I get the right list — attendance, not registration?

The reliable way is to build the certificate batch from a check-in record, not a signup form. Three sources work, in order of reliability:

1. A QR check-in scan log. If attendees were scanned in at the door, that scan log is the attendance list — it only includes people who were physically present, not people who intended to be.
2. A sign-in sheet. Manual, but still a record of who was actually in the room, unlike a registration form filled out days earlier.
3. A registration list, filtered honestly. The weakest option — it requires someone to actually go back and mark who attended, which is exactly the step that gets skipped when the certificate batch is due out the same afternoon.

If the event was ticketed and scanned at the door, this step is already done: Event Tickets check-in produces a scan log that is, by construction, a record of who actually walked in — not who clicked "register." That log is the input a certificate batch needs, with nothing extra to reconcile.

Isn't this just a nice-to-have, or does it change what a certificate can claim?

It changes what the certificate can honestly say. A certificate that goes only to people confirmed present, by a check-in system rather than a self-reported form, can state attendance as a fact rather than an intention. That's a claim most certificate tools can't actually back, because most of them have no connection to who was in the room — they only know who registered or who was typed into a spreadsheet afterward. Pairing an event's real check-in data with the certificate batch closes that gap, which is a structural advantage, not a policy one: it's true because of how the list was produced, not because of a promise on top of it.

It's still worth being precise about the limit here too, because the check-in fact and the verification fact are different claims: a verification page confirms who uploaded a certificate and when it was issued — not that the course ran, that the recipient attended, or that the content was accurate. Confirming attendance is something the organizer does by building the batch off the right list; verification is a separate, later confirmation of who issued the certificate and when. Why your certificate's verification link stops working covers that second part.

Frequently asked questions

Should partial attendance still get a certificate? That depends on what the certificate claims. If it's a single-session attendance certificate and the person left early but attended most of it, that's a judgment call — but a multi-session completion certificate should reflect an actual completion threshold, not a generous rounding.

What if I don't have a check-in system — can I still avoid certifying no-shows? Yes, with more manual effort: cross-reference a sign-in sheet against your registration list before building the certificate batch, rather than certifying the registration list directly.

Does using a check-in list slow down sending certificates? No — if the check-in already produced a scan log or a sign-in sheet, that list is the certificate batch input directly. It's the registration-list shortcut that's actually slower in the long run, once someone has to explain why a no-show has a certificate.

Can I send certificates for a workshop that combined ticketing and check-in? Yes — that's the straightforward case. How to send certificates after a workshop without a monthly subscription covers turning that same attendance list into a certificate batch.

Once the list is the real one, Certificate Maker turns it into a batch of certificates in one upload — free to build and preview, paid once to issue.