For issuing organisations
How to Create and Issue Certificates in Bulk
One template, one clean list. What actually breaks when you issue hundreds of certificates at once, and the data checks that stop a batch going out with the wrong names on it.
Last updated · 7 min read
The short version
Bulk issuance is one template plus one clean list. The template is designed once and does not change between recipients; the list carries everything that does. Everything difficult about issuing 2,000 certificates rather than 20 lives in the list, not in the design.
Which is worth saying plainly, because most organisations approach this as a design problem and then spend three days on data. Get the list right and the run itself takes minutes.
What actually breaks at volume
Producing a hundred certificates by hand is tedious but tractable. Four things stop being tractable, and they arrive in this order.
Personalisation errors compound silently. One duplicated name in a batch of 500 is invisible until the person receives someone else's certificate. Manual processes have no point at which that gets caught.
Delivery becomes its own project. Five hundred certificates means 500 individually addressed emails with the right attachment on each. Attaching the wrong PDF is a data-protection incident, not a typo.
Corrections arrive after delivery, always. Some recipients will tell you their name is wrong, and the number is reliably not zero, because it is a function of how the list was typed rather than of how careful the run was. In a file-and-email process, each correction means regenerating, finding the original email, and hoping nobody has already circulated the wrong version.
Verification requests start landing months later. An employer wants to confirm a certificate you issued in March. If the only record is a folder of PDFs and a spreadsheet, answering takes somebody twenty minutes, and you will be asked repeatedly.
The first two are volume problems and automation solves them. The second two are record-keeping problems, and they are why the output format matters as much as the process.
Three ways to do it
| Approach | Works well when | Falls over when |
|---|---|---|
| Design tool + manual export | Under ~50 certificates, one-off, no verification requirement | Any repeat run, any correction, anyone asking whether a certificate is genuine |
| Mail merge or a template automation | Hundreds of certificates, in-house control, a competent spreadsheet owner | Delivery, corrections, and verification, none of which it addresses |
| Managed credential issuance | Recurring cohorts, or certificates anyone will need to confirm later | A single small batch where nobody will ever check anything |
The honest dividing line is not volume. It is whether anybody will need to confirm these certificates afterwards. A training provider issuing 40 certificates a year to people who will never be asked to prove it does not need any of this, and should use a mail merge. A professional body issuing 40 certificates a year that members put on a licence application needs verification from the first one.
The recipient list
One row per recipient, in a spreadsheet exported as CSV. That is the shape to send us if we are running the batch for you. The five fields below are what we ask for, and they are the fields any route needs somewhere.
Where they live differs. Issuing a batch yourself asks for only a name and an email address per line, because the award and the issue date are chosen once for the whole batch rather than repeated on every row. So the list is shorter, and the two fields it drops are the two most worth getting right once instead of four hundred times.
- Name. Exactly as it should be printed. This is the field corrections come back on.
- Email. Required, and the identifier that ties a recipient to everything they have been awarded. Two certificates on one email address belong to one person; the same person under two addresses becomes two people.
- Issue date. The date the award was earned, which is frequently not the date you are issuing it.
- The award. Usually one award for the whole batch, named consistently. The award carries the description, level, criteria, and validity period, so it is defined once rather than typed into every row.
- Description. Optional, per recipient. Distinction, specialism, cohort. Leave it empty rather than filling it with placeholder text.
Data hygiene is most of the work
This is the part that actually takes the time, and the part every guide skips. Before a run, check five things.
- Names as the recipient writes them. Registration forms produce ALL CAPS, surname-first ordering, and stripped diacritics. All three are wrong on a certificate, and a name printed wrong is the most upsetting error you can make in this process. It is somebody's name.
- Duplicate and shared email addresses. Sort by email and look. Two rows sharing an address means either a genuine duplicate or two people using one mailbox, and the second needs a real address before the run rather than a support ticket after it.
- Whitespace and encoding. Trailing spaces travel invisibly through every copy-paste. So do the mangled characters that appear when a spreadsheet is exported in the wrong encoding, and they print exactly as mangled onto the certificate.
- Date formats. Ambiguity between day-first and month-first ordering silently produces certificates dated in the wrong month for every row where the day is twelve or under. Fix the format in the sheet, not in your head.
- Who is actually eligible. Attendance lists are not completion lists, and neither is the same as a pass list. Reconcile against assessment records before issuing, because withdrawing a certificate is materially harder than delaying it by a day. It is also worth deciding at this point which of the three the certificate claims to be: a certificate of completion says something narrower than a certificate of achievement, and issuing the stronger wording by default devalues the batches where you earned it.
One more, worth the five minutes: run a batch of three first. Pick a short name, a very long name, and one with an apostrophe or a diacritic. Long names are what break a fixed-width layout, and you would rather find that on three certificates than on 500.
What a run produces
Each recipient comes out with a print-ready PDF, a high-resolution PNG for sharing, and the thing that distinguishes this from a folder of files: a permanent verification page carrying their name, the award, the issuing organisation, the issue date, and its own credential ID, signed at issuance so altering the record breaks the signature.
That page is what the QR code on the certificate points to, what a recipient adds to their LinkedIn profile, and what an employer opens instead of emailing you. The mechanics of the signature are on the security page, and the certificate generator covers the design side: what your template can carry, and what stays fixed across a batch. Bulk issuing covers the batch itself: the ceiling on one run, the review step before anything is signed, and the errors a recipient list can carry through every check because they are correctly formatted and simply wrong.
Generating and sending are separate steps
Deliberately. Generation produces every certificate and its verification page; sending is a second action, taken once somebody has looked at the output.
Keeping them apart is what makes a bad batch recoverable. A wrong award name caught between the two steps is a regeneration nobody outside your organisation ever hears about. The same error caught after 500 emails have gone out is a correction, an apology, and a fortnight of circulating certificates you would rather did not exist. Always look at a handful of the generated certificates before anything is sent.
Delivery, and the emails that will not arrive
Some percentage of any batch does not reach its recipient. Plan for it rather than discovering it three weeks later when somebody asks where their certificate went.
Addresses go stale. Cohort lists are frequently months old by issuance, and student or work addresses are deactivated the moment somebody leaves. A bounce is not a failure of the run; it is a row that needs a current address.
Corporate mail gateways are unpredictable. A single organisation's filter can quarantine an entire batch destined for its staff while every other recipient receives theirs normally. If a whole company's worth of recipients report nothing arriving, that is the explanation, and the fix is on their side.
People do not read every email. A notification competing with a hundred others does not always win, regardless of whether it was delivered.
The structural answer is that the email is a notification, not the credential. Each certificate exists at its own verification page from the moment it is generated, and that page does not depend on anything arriving in an inbox. Recipients who never saw the email can be given their link directly, and one whose address has changed does not need the certificate reissued, only re-sent. A process where the credentialis the attachment has no equivalent recovery: a bounced email means the certificate is simply gone.
Practically: send in one batch, review what bounced, chase the failures as a short list, and keep the verification links to hand for the handful of people who will ask you directly.
Corrections after the fact
Some always come. Names get misspelled, people marry, a grade is recorded wrong. What matters is whether a correction breaks the links already in circulation.
In a file-based process it does, unavoidably: the corrected PDF is a new file, and the old one is already in an inbox and possibly on a LinkedIn profile. On a credential that lives at a permanent URL, the correction is made and the URL stays the same, so every link already shared keeps working and now shows the corrected details. Editing names on issued certificates covers how that works and what it cannot fix.