Training tracking in Excel: a template that works, where it breaks, and what replaces it
Almost every training record starts as a spreadsheet, and for a long while that is the right call. A training tracking template in Excel is free, it is on the machine you already have, and you can restructure it on a Tuesday afternoon without asking anyone for a budget. If you have thirty people and four courses, a good spreadsheet beats most of the software you could buy.
Then somebody asks a question it cannot answer. Usually one of these: whose first-aid certificate expires this quarter? — can you show me the evidence that Dan completed this? — who was assigned this and hasn't done it? And you discover that the sheet records what happened but cannot prove it, schedule it, or chase it.
This is the honest version: a training tracking spreadsheet structure worth copying, the specific point at which each part fails, and what the alternatives actually cost. No pretence that you need software on day one, and no pretence that a spreadsheet lasts forever.
The training tracking template worth copying
Download a dozen free training tracker templates and most share the same fatal design: one grid, people down the side, courses across the top, and a date typed into each cell. It is readable, it fits on a screen, and it is why the sheet eventually stops being trustworthy.
The problem is that a date in a cell is a conclusion, not a record. It cannot hold who signed it off, which attempt it was, where the certificate lives, or what version of the course was taken. And it can be overwritten by anyone, silently.
Use three sheets instead. It takes twenty minutes to build and it survives contact with an auditor.
Sheet 1 — People. One row per person, and no training data on it at all.
| ID | Name | Role | Department | Start date | Active |
|---|---|---|---|---|---|
| P-014 | J. Okafor | Technician | Field ops | 2024-03-11 | yes |
| P-021 | D. Mercer | Technician | Field ops | 2025-09-02 | yes |
| P-033 | A. Lindqvist | Supervisor | Field ops | 2021-01-18 | yes |
Sheet 2 — Requirements. One row per course, with the two columns most templates omit: how long a completion stays valid, and who it applies to.
| Code | Course | Applies to | Valid for (months) | Mandatory |
|---|---|---|---|---|
| H-FA | First aid at work | Field ops | 36 | yes |
| H-WAH | Working at height | Technician | 24 | yes |
| GDPR | Data protection basics | All | 12 | yes |
| LEAD-1 | Supervisor essentials | Supervisor | — | no |
Applies to is what turns your sheet from a record into a system. Without it, a new joiner arrives
and inherits nothing; somebody has to remember which courses their role needs.
Sheet 3 — Completions. One row per event. You never edit a status anywhere; you add a row here.
| Date | Person | Code | Result | Score | Assessor | Evidence |
|---|---|---|---|---|---|---|
| 2024-04-02 | P-014 | H-FA | pass | — | External | cert/P014-HFA-2024.pdf |
| 2025-11-18 | P-021 | GDPR | pass | 84% | A. Lindqvist | lms/att-8841 |
| 2026-01-09 | P-021 | H-WAH | fail | 51% | External | — |
| 2026-01-23 | P-021 | H-WAH | pass | 78% | External | cert/P021-WAH-2026.pdf |
Note the failed attempt is still there. A tracker that only records passes cannot tell you that someone needed two goes at working at height, or that the gap between them was a fortnight — which is exactly the sort of thing that matters after an incident.
Sheet 4 — Status. Derived, never typed. For each person-and-requirement pair, find the most recent pass and work out whether it is still in date:
=LET(
last, MAXIFS(Completions[Date],
Completions[Person], [@Person],
Completions[Code], [@Code],
Completions[Result], "pass"),
IF(last = 0, "never",
IF([@ValidMonths] = "", "current",
IF(EDATE(last, [@ValidMonths]) < TODAY(), "expired",
IF(EDATE(last, [@ValidMonths]) < TODAY() + 60, "expiring", "current")))))
That is the whole system, and the important part is not the formula. It is that status is a calculated result, not a cell anybody can type into. Every change leaves a dated row saying who assessed it and where the evidence sits.
If you copy nothing else from this page, copy that. It is also, precisely, what separates real learning management software from bad learning management software — and the reason most AI-generated training apps are broken on arrival is that they skip it and make completion a directly editable flag.
Where it breaks
A spreadsheet built that way will carry you further than most. It still ends, and it ends predictably.
1. Nothing chases anybody
The status column tells you who is expiring. It does not tell them. Every week somebody has to
open the file, filter to expiring, and send emails — and the week nobody does, a certificate
lapses. This is the single most common failure, because it is not a flaw in the spreadsheet at all.
It is work the spreadsheet cannot do, silently transferred to a person who has other work.
2. Assignment is invisible
Your Requirements sheet says which roles need which courses. Nothing enforces it. A technician joins, nobody adds their rows, and they simply do not appear as overdue — because a missing record and a completed record look identical to a filter that only sees rows that exist.
This is the difference between "who has done this" and "who should have done this", and only the second one is compliance. Spreadsheets are naturally good at the first and structurally bad at the second.
3. The evidence lives somewhere else
Your Evidence column holds a filename. The file is in a shared folder, named by whoever scanned
it, possibly moved since. When an auditor asks for proof of a specific completion, you are doing a
manual join between a spreadsheet and a directory listing — and the failure mode is not that you
cannot find it, it is that you find something and cannot prove it is the right one.
4. The history is editable, so it proves nothing
Even with a completion log, anyone can change a past row. Correct one date and every derived status shifts, with no trace it happened.
The moment a training record has consequences — an accident investigation, an insurance claim, a regulator, a tribunal — you need to show what the record said on a given date and who changed it. A spreadsheet cannot do that, because its history is editable by design. This is the failure that turns an inconvenience into a liability.
5. Two people open it at once
Shared editing in Excel or Google Sheets does not lock rows the way a database does. Two people appending completions after a training day will overwrite each other, and the loss is silent — no error, no conflict prompt, just a row that quietly is not there. You notice at the next audit, and by then you cannot reconstruct which one went missing.
What a real one has that a spreadsheet doesn't
We maintain a hand-counted inventory of what learning platforms actually ship, tallied across 38 real LMS platforms — SaaS creator tools, open-source and academic systems, marketplace scripts with authenticated demo access, enterprise RFPs, and practitioner threads. Ranked by how many of those 38 ship each capability:
| Capability | Platforms | Share |
|---|---|---|
| Lesson and content types — video, text, file, audio, embed | 33 | 87% |
| Course builder with a real module/section/lesson hierarchy | 32 | 84% |
| Learner progress tracking — durable, with a resume point | 32 | 84% |
| Course catalogue | 31 | 82% |
| Roles and permissions | 31 | 82% |
| Reports derived from records, not parallel counters | 31 | 82% |
| Product/tenant model — who is separated from whom | 30 | 79% |
| Assessments with attempt records, scores and feedback | 29 | 76% |
Read that next to the five failures and the pattern is clear. The two capabilities almost every platform ships — durable progress tracking and reports derived from the underlying records — are exactly what a spreadsheet gives up first. Everything else on the list is content delivery, which is the part a spreadsheet was never trying to do.
Which points at something worth saying plainly: if all you need is the matrix, you may not need an LMS at all. An LMS delivers training. A training tracker records it. Plenty of organisations buy the first when they only needed the second, and end up maintaining a spreadsheet beside it anyway.
Your three options, honestly
Keep the training tracking spreadsheet
Correct if: one person maintains it, the population is small and stable, nothing expires on a short cycle, and no external party will ever ask you to prove a historical state. Add the four-sheet structure above and you have removed most of the risk you can remove for free.
Stop when the first certificate lapses without anyone noticing, or the first time somebody asks for evidence and you cannot produce it in a minute.
Buy software
Correct for most organisations, most of the time — but buy the right category. A creator-focused LMS is built to sell courses; a compliance-focused system is built to chase expiries. They look similar on a feature list and they are not the same product, and this is the single most expensive mistake in this market.
Before you sign, check three things: whether recurrence and expiry are first-class or an add-on, what happens to your historical records if you leave, and whether it can assign by role rather than person by person. If it fails the third, you have bought a nicer spreadsheet.
Build it
Two years ago this was a bad idea without a development budget. It is now a serious option, because a coding agent can produce a working training system in a day or two.
The catch is that it will produce the wrong one unless you tell it exactly what to build. Left to guess, an agent builds completion as an editable flag, a course as a flat list of files, and a report as a counter it increments — which reproduces every failure above inside a database, and that is worse than the spreadsheet, because now the flaws are hidden behind an interface that looks finished.
We have watched this happen under controlled conditions. Three complete learning platforms were built from a single specification by three different coding models. All three worked. One would not compile for production at all — three small errors that never surface in development, and which its own tests reported as passing. One built every access rule correctly on top of a session token a visitor could have forged, so the correct rules protected nothing. One arrived with a catalogue that was 83% leftover test data. The features were not the problem in any of them.
If you build it, build these first
In order:
- A completion event log, before anything else. One append-only row per attempt with date, person, course, result, score, assessor and evidence. Nothing edits a status directly — not the interface, not an import, not an admin screen.
- Status as a derived value. Same rule as the spreadsheet formula, enforced by the schema rather than by discipline.
- Requirements assigned by role, so a new joiner is overdue automatically rather than because somebody remembered them.
- Expiry and recurrence as first-class fields, with a scheduled reminder that leaves the building. An expiry date that nobody is told about is the spreadsheet's failure with extra steps.
- Evidence stored with the record, not referenced by filename.
- Reports built from the completion log, never from a counter kept alongside it. If a report and the records can disagree, they eventually will, and you will believe the wrong one.
Everything else — course authoring, video hosting, quizzes, certificates — is genuine scope and genuinely optional for a first version. Build it when the programme needs it, not because it appears on a comparison table.
If the delivery side is what you actually need, features of a learning management system is the full counted inventory these figures come from, and free learning management system covers where the free tiers stop. If you are weighing self-hosting, open source LMS has the honest running cost.
And if you are going the build route with a coding agent, the Learning Management planner is the spec we hand ours — durable progress records, derived reporting and the scope boundaries written so the agent cannot quietly reduce a completion to a checkbox.