Invalid check digit: the last digit isn't decoration
UPCs, GTINs, and SSCC-18s all end in a check digit — computed from every other digit via GS1's mod-10 algorithm. Receivers recompute it; if it doesn't match, your identifier is rejected as corrupt, because it is.
The algorithm, worked
From the right (excluding the check digit), multiply digits alternately by 3 and 1, sum, and subtract from the next multiple of 10:
Identifier body: 0 0 8 1 2 3 4 5 6 0 0 0 0 0 0 0 1 1 Weights (from →): 3 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 3 1 … Sum of products = 73 → next multiple of 10 is 80 → check digit = 7
Every GS1 identifier family (GTIN-12/13/14, SSCC-18) uses this same scheme over different lengths.
Where bad check digits actually come from
| Root cause | How to spot it |
|---|---|
| Excel ate your digits — long numbers become scientific notation or get rounded (…000 endings) | Columns of identifiers ending in 0s, or values like 8.82E+12. Fix: format columns as text before pasting |
| Truncation/padding — a GTIN-14 crammed into a 12-digit field, or zero-padded on the wrong side | Length is right but leading/trailing digits differ from the GS1 certificate |
| Typo in one digit | Mod-10 exists precisely to catch this — recompute and compare |
| Made-up SSCCs — serials invented without computing the final digit | Every carton fails, not just one |
Fixing it
- Recompute the check digit with our free SSCC/GTIN check digit calculator (in-browser, instant)
- Trace the identifier back to its source — GS1 certificate for GTINs, your allocation log for SSCC serials
- Audit the spreadsheet pipeline for Excel number-mangling (the most common root cause by far)