Quick answer
Verify the two dates against the source record before calculating. A correct method applied to a wrong date of birth produces a confidently wrong result.
The error distribution
In practice, age errors in evaluation files cluster into four types. A transposed day and month, most often where a record crosses between a day-first and month-first convention. A reference date left on today. A manual borrow done with thirty days rather than the real month length. And a figure copied forward from a previous report without recalculating.
What these have in common is that none of them is caught by checking the arithmetic. Each produces a number that is internally consistent and plausible for a school-age child, which is precisely why they survive review.
Use this guide with the right tool: Open the Assessment Age Calculator for age on a specific testing or evaluation date. If the question shifts, compare it with the School Grade Age Calculator or the Chronological Age Calculator.
Transposition is the quiet one
03/04/2019 is 3 April in most of the world and 4 March in the United States. Where a file contains records from more than one source — a transfer, an immigration document, a private assessment — both conventions can appear in the same folder.
The defence is to write dates unambiguously in your own records: 3 April 2019, or 2019-04-03. A month written as a word cannot be transposed. Where an ambiguous date must be interpreted, note the interpretation you made rather than resolving it silently.
Carried-forward ages
A child's age in a report from eighteen months ago is not their age now, but it is right there in the file and it is formatted correctly. Copying it forward is an easy mistake to make under deadline and a hard one to spot on review, because the value is a real age that was once correct.
Recalculating from the date of birth every time is the only reliable habit. The calculation takes seconds; verifying whether an existing figure is current takes longer than redoing it.
A review step that actually catches things
Reading a calculated age back and asking whether it looks right does not work — wrong ages look right. What works is comparing the two input dates against the source record, character by character, before calculating, and then confirming that the reference date matches the event the age is meant to describe.
For anything consequential, a second person checking the inputs is more valuable than a second person checking the output. Where that is not practical, the shareable result link lets a reviewer open the exact calculation and see the inputs rather than only the answer.
Worked example
Substitute your own dates and follow the instructions that actually govern your situation. Where a result sits close to a cutoff, verify the underlying date and rule independently before relying on it.
Common mistakes to avoid
- Writing dates in all-numeric form. Use a written month or ISO format in your own records. An ambiguous date will eventually be read the other way.
- Copying an age forward from an earlier report. Recalculate from the date of birth every time. A previously correct age is still wrong today.
- Reviewing the output instead of the inputs. Wrong ages look plausible. Check the two dates against the source record before calculating.
Use the right calculator
Each of these runs in the browser, states its assumptions, and links to the neighbouring calculation when the question turns out to be a different one.
Frequently asked questions
What is the single highest-value check?
Comparing the date of birth against the source record before calculating. Most errors enter there and nothing downstream catches them.
How should I handle an estimated date of birth?
Use it, flag it clearly in the record as estimated, and note the source. Every interpretation downstream inherits the uncertainty.
Does a calculator remove the risk?
It removes arithmetic error only. Input verification and reference-date selection remain human steps.