A learner finishes a course on Tuesday. Your team approves the record on Thursday, creates the certificate on Friday, and sends the email on Saturday. Which date belongs on the certificate?<\/p>\n
Use the date of the event you are describing, and label it.<\/strong> A completion date records when the learner met your program’s completion requirements. An issue date records when the issuer issued the credential. An email date records a delivery action. They can be different without making the record inconsistent.<\/p>\n This guide gives course administrators a practical way to choose and check those dates. Use your program’s approved definitions where they differ, particularly if an accreditor or another governing body specifies the required fields.<\/p>\n Approval can be a separate event too. If your program treats reviewer approval as part of completion, use that rule consistently. If approval merely checks an already completed activity, do not silently substitute the review date for the activity date.<\/p>\n In Sertifier, the documented Issue Date attribute<\/a> is populated from the date the certificate was sent. Do not assume that creating a draft earlier makes that earlier day its Issue Date. Keep a separate approved completion value when the learner finished before issuance.<\/p>\n A generic label such as \u201cDate\u201d leaves the reader guessing. \u201cCompleted on May 5, 2026\u201d and \u201cIssued on May 8, 2026\u201d explain the difference without requiring a support request.<\/p>\n Consider this fictional program record, where issuance and the later communication are separate events. It is a timeline example, not a description of Sertifier’s default Issue Date behavior. The program defines completion as finishing the required lessons and passing the final assessment. Staff approval checks the record before issuance.<\/p>\n Sample A completed Sample Course on May 5, 2026. The email sent on May 9 does not turn May 9 into the completion date. Likewise, resending the email later should not be treated as evidence of a new course completion. Keep delivery troubleshooting in the credential email delivery workflow<\/a>.<\/p>\n Write down the meaning and source of every displayed date before importing recipients or connecting an automation. The useful question is not just \u201cWhich column contains a date?\u201d It is \u201cWhich event does this value prove?\u201d<\/p>\n For example, Sertifier’s API quickstart<\/a> includes a completion date among additional recipient details. That is a useful mapping example, not a promise that every integration automatically supplies the correct event. Check the current integration’s fields and test the value that reaches the credential.<\/p>\n Do not fill a missing completion date with today’s date just to finish a batch. Hold that record for review while processing other approved records through your normal workflow. A visible date is not a substitute for evidence that the event happened.<\/p>\n \u201c05\/08\/2026\u201d can be read in more than one way. Writing the month in words makes a reader-facing certificate clearer. Keep the original structured value in the source record so a design change does not require reconstructing the underlying fact.<\/p>\n Sertifier documents a date format preference<\/a> under Organization Settings and Account Preferences. Before changing an organization-wide preference, check its scope and test the resulting display. A formatting preference does not decide which event your date should represent.<\/p>\n Time zones need their own decision. In a fictional example, 00:30 UTC on May 6 is 20:30 on May 5 at UTC\u221204:00. Both describe the same instant. Choose the program’s agreed reporting time zone, retain the source timestamp when available, and explain the rule to support staff. Do not add a time zone to a date-only source as if it originally contained a timestamp.<\/p>\n For language and regional variations, use the multilingual credential checklist<\/a> alongside this event mapping.<\/p>\n Use a small sample before releasing a cohort. Include a learner who completed earlier than the issuing day, a record near a date boundary, and an approved correction. Inspect the hosted credential and a fresh downloaded file if your program distributes one.<\/p>\n If the completion record was wrong, review and correct that fact through the supported process. If the problem was only a delayed email, solve the delivery problem. Avoid creating a duplicate credential or changing achievement dates to make a communication timeline look simpler.<\/p>\n Yes, when they describe different events in your approved process. Label them clearly and preserve the evidence for each. Follow any program-specific requirements that govern your certificate.<\/p>\n Not merely because it was reissued. Check whether the learner completed a new activity or whether you are correcting or replacing an existing record. A replacement alone does not establish a new completion event.<\/p>\n No. Expiry concerns the program’s validity or renewal rule. Do not infer it from the email date or invent a validity period. Keep renewal management in the certification tracking process<\/a>.<\/p>\nGive each date a clear job<\/h2>\n
\n
A worked example: one course, three dates<\/h2>\n
\n
\n
Issued by Sample Organization on May 8, 2026.<\/p>\n<\/blockquote>\nMap the source before designing the certificate<\/h2>\n
\n
Separate date format from date meaning<\/h2>\n
Test delays, resends and corrections<\/h2>\n
\n
Frequently asked questions<\/h2>\n
Can completion and issue dates differ?<\/h3>\n
Should a reissued certificate show today’s completion date?<\/h3>\n
Is an expiry date the same as an issue date?<\/h3>\n
Make the date mapping part of your issuing process<\/h2>\n