The 13th digit of a South African ID number is a Luhn checksum. When teams ask for SA ID checksum explained in plain language, they usually want to know why two numbers that look almost identical can produce different validation outcomes — and whether checksum failure always means fraud.
Checksum failure usually means a typo, transposed digit, or fabricated number that does not satisfy the published formula. It is a fast hygiene signal, not proof of identity theft and not a government database result.
The algorithm CheckID uses
Given a 13-digit string, treat positions 1–12 (zero-indexed: digits at indices 0–11) as the payload and digit 13 (index 12) as the check digit:
- For even positions (2nd, 4th, 6th … 12th digits), double the digit. If the result is two digits, add those digits together (for example 18 → 1 + 8 = 9).
- Sum all transformed even-position values.
- Sum all odd-position digits (1st, 3rd, 5th … 11th) without doubling.
- Add both sums. The check digit is
(10 − (total mod 10)) mod 10. - The ID is checksum-valid only when digit 13 equals that calculated value.
This matches the implementation in CheckID's validator and API — the same rules described in our ID number structure guide.
Worked example: 8001015009087
The first twelve digits are 800101500908 (positions 1–12). Splitting by position:
- Even positions (2, 4, 6, 8, 10, 12): digits 0, 1, 1, 0, 9, 8. After doubling and digit-summing (for example 9×2=18 → 1+8=9, 8×2=16 → 1+6=7), the transformed sum is 20.
- Odd positions (1, 3, 5, 7, 9, 11): digits 8, 0, 0, 5, 0, 0 — summed unchanged = 13.
- Check digit: 20 + 13 = 33 →
(10 − 3) mod 10 = 7, matching digit 13.
So 8001015009087 passes checksum validation (subject also to date and citizenship rules).
Change the final digit to 6 while leaving the first twelve unchanged. The birth date segment still decodes to 1980-01-01, but isValid becomes false because the checksum no longer matches. That pattern appears frequently when applicants mistype the last digit on mobile keyboards.
Common real-world failure patterns
- Transposed adjacent digits in the birth date segment (for example 801011 vs 800101).
- Wrong citizenship digit (using 1 when the holder is an SA citizen encoded as 0).
- Copied test numbers from outdated examples that fail current date rules even when the checksum once looked valid in a blog post.
- Spreadsheet scientific notation mangling leading zeros — always import ID columns as text, then run structural validation.
Checksum validation in your workflow
Manual calculation does not scale. Use the Free South African ID checker for spot checks, the South African ID validator API guide for live forms, or bulk ID validation API for South African teams for imports. Full request and response field names live in the South African ID validation API; compare plan limits on CheckID pricing for API and bulk plans.
For the full digit map including gender sequence and citizenship codes, read understanding SA ID numbers. Language-specific implementations live in Validate a South African ID in JavaScript, Validate a South African ID in C#, Validate a South African ID in PHP, and Validate a South African ID in Python.