Home›Guides›The check digit your printer silently rewrites
Guides › The check digit your printer silently rewrites
The check digit your printer silently rewrites
Published:
Ask for 8691234567895 and you get
8691234567890. No error, no warning from the printer, a barcode
that scans perfectly — carrying a number nobody asked for.
The measurement
We rendered ^BEN,140,Y,N^FD8691234567895^FS and read the
resulting symbol back with a software decoder. It decodes as
8691234567890. The last digit we sent was replaced.
This is not a bug in the renderer, and not a Zebra quirk either: the check
digit of an EAN/UPC symbol is derived from the preceding digits. The
encoder computes it. If you supply a thirteenth digit, it is not used as data —
it is overwritten by the computed one. Both behave the same way, which is
exactly why the mistake survives testing: every tool agrees, and every tool is
silently wrong about your intent.
Why it costs more than it looks
A wrong check digit almost always means a wrong number earlier in the
string — a transposed pair of digits, a truncated GTIN, an off-by-one in a
serialisation counter. The symbol is valid, so nothing downstream rejects it.
The label goes on a product; the till at the other end reads a GTIN that
belongs to another item, or to nothing at all. The point of failure is the
customer, not your test bench.
Two honest options
Send twelve digits and let the encoder compute the
thirteenth. There is nothing to disagree about.
Send thirteen and verify. If you keep the check digit in
your data (most ERP systems do), compare it with the computed one before
printing and stop the job on a mismatch.
Our renderer takes the second path on your behalf: it does not change the
output — Zebra would compute the same digit — but it breaks the silence and
returns a warning naming both digits and the number that will actually be
printed. That warning appears in the viewer's linter panel and in the API
response, which is where an automated gate can see it.
The same rule, other symbologies
EAN-8, UPC-A and UPC-E share the modulo-10 rule with different lengths;
ITF-14 has one too. Code 128 and Code 39 have internal check characters that
are not part of your data at all — there is nothing for you to supply, and
nothing to get wrong.
Paste a label into the ZPL viewer to see
the warning, run diagnostics in the pipeline that
generates the label, or read back a printed sample with
barcode verification — that last one is the
only check that sees what the scanner sees.
Frequently asked questions
Why did my EAN-13 print a different number than I sent?
Because the check digit is derived, not carried: the encoder computes it from the preceding twelve digits and overwrites the one you supplied. We measured it — 8691234567895 in, a symbol that decodes as 8691234567890 out.
Should I send 12 or 13 digits?
Twelve is the safe answer: there is nothing to disagree about. If your system stores thirteen, compare the last digit with the computed one before printing and stop the job when they differ.
Does the renderer fix the number for me?
No, and it should not — Zebra would compute the same digit, so changing the output would hide the difference between tools. It returns a warning instead, naming both digits and the number that will actually be printed.
