Plenty of the identifiers a system handles have no published arithmetic behind them at all. There is no closing character to recompute, no weighted sum to compare, no remainder to interrogate. The string has a documented shape and nothing else, and the most a validator can honestly do is confirm the shape.
That situation makes people uncomfortable, and discomfort produces two opposite mistakes. One is to invent a rule so that the field can return a satisfying answer. The other is to give up and accept anything. Both are avoidable once the format-only verdict is treated as a first-class result rather than a failure of imagination.
Which numbers have no published check digit?
The category is broader than it looks. It includes identifiers from registers that never documented an internal rule, internal codes assigned by a company rather than a standards body, and values that were designed to be read by humans and stored by clerks rather than verified by machines.
It also includes numbers that do contain latent structure nobody published. A register may well assign numbers sequentially, or embed a region or a date, without ever stating the convention. From the outside that structure is invisible and unusable, and treating a guessed pattern as a rule is worse than admitting ignorance.
The practical test is documentation, not intuition. If the issuing authority has published a check rule, there is something to implement. If it has published a shape, implement the shape. If it has published neither, the honest coverage level is none, and no amount of analysis over a sample of real values should be allowed to change that classification.
The examples in this article are illustrative shapes rather than real values. No genuine identifier is reproduced here, and structural descriptions describe public rules only.
Why some identifiers cannot be checked by arithmetic
A check digit needs two things: a rule that maps the body onto a single character, and confidence that the issuing register applies that rule. Where either is missing, arithmetic has nothing to work with.
History explains most of the gaps. Many registers predate software and were designed for clerks who copied values between forms, so their designers had no reason to build machine verification into the number. Others were introduced by legislation that specified what the number identifies and left the internal format to the agency, which then published nothing.
Privacy explains some of the rest. A published check rule is a public fact and reveals nothing about an individual, so it is rarely withheld for that reason — but the surrounding format sometimes is, and a scheme with no published format has no published check either.
The result is a landscape with real variety in coverage. That variety is the subject of the country-by-country picture, where the same three levels recur across registers of every size.
What does format only actually mean?
A format-only verdict says three specific things and one important non-thing. The three are that the string uses legal characters, that its length is one the scheme defines, and that any documented internal divisions are consistent with what was supplied. The non-thing is validity, because there is no arithmetic to confirm.
Saying this clearly is a communication problem before it is a technical one. Users read green ticks as approval, so a format-only result must not be dressed in the same successful styling as a passed check. It is not a lesser success; it is a different claim, and the interface should make the difference visible without implying that something went wrong.
It also matters for the systems downstream. An import job that receives format-only confirmations must not write them into the same column as algorithm-confirmed values, because the two have different error rates and will eventually be treated differently in an audit.
How should a format-only number be checked?
Check what the documentation supports, and stop there.
- Normalise the input — strip separators, collapse whitespace, fold case — and keep the original.
- Verify the character set, rejecting letters in a numeric scheme and symbols everywhere.
- Verify the length against the scheme’s documented sizes.
- Inspect any documented internal structure, such as a fixed prefix or a reserved position.
- Return a format-only verdict, worded so that it claims shape and nothing else.
Do not add a step six. Computing your own checksum for an unpublished scheme creates a rule that will disagree with the register the first time a genuine value crosses it, and the disagreement will be impossible to explain to a user.
Two details are easy to miss. Some schemes define more than one legal length, so the length check is a membership test rather than an equality test. And normalisation is not repair: removing formatting marks cleans the input, but it does not turn an approximation into a valid value.
Where a format check still earns its place
Format checks are cheap, and they catch the errors that actually dominate real traffic: a character dropped while copying, a value pasted from the wrong column, an alphabetised string pasted into a numeric field. Measured against those failures, a shape test pays for itself within a day of production use.
They also protect the systems behind the form. A field that rejects illegal characters before storage keeps a class of noise out of downstream processing, and a field that enforces a documented length keeps one truncation bug away from the data warehouse.
What a format check cannot do is anything that requires the register. Confirming that an identifier was issued, that it belongs to the person presenting it, or that it is still active are all lookup operations, and they belong beside the format check rather than inside it. Where such a lookup exists, treat it as a network dependency with timeouts and failures of its own, in the spirit of the boundary design discussed separately.
For developers: four verdicts and the words for them
Give the concept a type, and give each branch its own wording.
| Verdict | Meaning | Suggested wording |
|---|---|---|
| Valid | The published algorithm was applied and the closing character agrees | The check digit matches this scheme |
| Invalid | The algorithm was applied and the closing character disagrees | The format matches but the check digit does not |
| Format only | No algorithm is published; the shape was confirmed | The format is valid; validity cannot be confirmed |
| No rule | The input matches no scheme the tool implements | Not recognised — this does not mean the value is false |
Two words are worth banning from the codebase. The first is real, which none of these verdicts establishes. The second is fake, which none of them establishes either. A tool that uses them will eventually be believed, and the beliefs will be wrong. If a form needs to know something true about the world, that knowledge comes from a lookup, not from arithmetic; the three-layer view of validation explains why the layers cannot be collapsed into one another.
Next steps
Identify every numeric field in your product that currently returns a plain true or false, and check which of the four verdicts it is really expressing. Then take a format-only scheme and confirm that your interface says something different for it than for a passed check, using the number validation tool as the reference for that wording.