Belgian eID Card MRZ: TD1 Format and 12-Digit Document Number

At first glance, a Belgian eID looks like a fairly standard TD1 identity card.

Then you try to parse its document number.

The Belgian ID card number contains 12 digits. But the standard TD1 MRZ allocates only nine character positions for the document number before its check digit.

So where do the remaining digits go?

They don't disappear. They continue into the MRZ's optional data area.

This small detail is a good example of why reliable document OCR is more than simply reading characters from an image.

A document parser cannot reliably understand an ID card by applying one universal MRZ template. It needs to understand the document type and, sometimes, the issuing country's implementation.

Belgian eID at a Glance

A Brief History of the Belgian eID

Belgium introduced its electronic identity card under the BELPIC program, with a pilot phase starting in March 2003 in eleven municipalities. The national rollout began in September 2004, and by the end of 2009 the transition from the old paper-based Belgian identity card to the Belgian eID was essentially complete.

The card has since gone through design and security updates. A new generation was introduced on 16 November 2021, bringing the Belgian ID card in line with EU Regulation 2019/1157 — a polycarbonate body, laser engraving and additional optical security features. Both generations remain in circulation, since each card stays valid until its own expiry date, which is why a Belgian ID OCR pipeline needs to handle either design.

Is the Belgian eID a TD1 Document?

TD1 defines the structure. It does not mean every TD1 document behaves identically.

That gap between "same format" and "same behavior" is where Belgian eID MRZ parsing gets interesting — and where a generic TD1 MRZ parser can quietly produce the wrong answer.

How the 12-Digit Document Number Fits Into the MRZ

In the standard TD1 layout, the document number sits in the first MRZ line, in a fixed 9-character field, followed immediately by a check digit. A parser that assumes every TD1 document follows the simplest nine-character pattern can therefore extract an incomplete document number.

ICAO 9303 anticipates this. When a national document number is longer than 9 characters, the standard defines an extension mechanism: the check-digit position for the 9-character field is replaced with a filler (<), the remaining digits continue into the optional data field that follows, and a new check digit — this one covering the complete number — is placed right after the continuation.

The Belgian eID uses exactly this country-specific extension within the TD1 MRZ structure. It isn't a broken or non-standard document; it's ICAO's own long-document-number handling, applied by Belgium:

The complete Belgian document number — 482910733045 in this synthetic example — is therefore reconstructed from two separate MRZ fields, not read off as one contiguous string.

Why Belgian ID Cards Can Break a Standard TD1 MRZ Parser

Most TD1 MRZ parsers are written against the simple case: nine-character document number, one check digit, done. Point them at a long Belgian document number and one of two things typically happens — the parser flags a checksum failure on a perfectly valid card, or it reads only the first 9 digits and silently returns a truncated document number that still looks plausible.

This isn't merely a theoretical edge case. The same Belgian ID format has caused parsing problems in real, open-source MRZ libraries. In a documented, still-open GitHub issue on the mrz library (Arg0s1080/mrz, issue #4), a developer reported that the parser failed to verify Belgian ID cards specifically because of the check digit at that position — testing three different Belgian ID cards and finding the same behavior on all three. The fix, as the reporter describes it, is exactly the continuation logic above: when the document-number check digit reads as <, the real check digit has to be read from later in the optional data field, not treated as missing.

That's a good storytelling shortcut for the underlying lesson: a real parser, written by someone who clearly understood MRZ well enough to build a library around it, still had to special-case Belgian ID cards after the fact — because TD1 compliance alone didn't cover it.

How the Belgian eID Check Digit(s) Work

This is worth being precise about, because there are two separate checksums involved in a Belgian ID card number, not one:

1. The check digit built into the printed card number itself. The visible Belgian card number follows the format xxx-xxxxxxx-yy, where yy is a check digit equal to the remainder of the first 10 digits divided by 97 (if that remainder is 0, the check digit is set to 97). This is a Belgian administrative rule, unrelated to ICAO or the MRZ.

2. The check digit added by the MRZ itself. Per ICAO 9303, MRZ check digits use a mod-10 algorithm: each character gets a numeric value (digits as themselves, A–Z as 10–35, < as 0), weighted 7-3-1 repeating, summed, and taken mod 10. For the synthetic example above, 482910733045 weighted 7-3-1 sums to 198, and 198 mod 10 = 8 — matching the check digit shown in the diagram.

In other words, the same 12-digit Belgian document number is protected by two independently computed checksums, stored in two different places: one on the face of the card, one only inside the MRZ. A Belgian ID OCR pipeline that validates against just one of them is only half-checking the number.

Don't Confuse the Card Number With the National Register Number

A Belgian eID carries more than one important identifier, and they shouldn't be treated as interchangeable fields in an OCR or identity-verification workflow:

• Card / document number — 12 digits, identifies this specific physical card. It changes every time the card is renewed or replaced.
• National Register number — 11 digits, in the form yy.mm.dd-xxx.cd, where the first six digits encode the birth date, xxx is a sequential number, and cd is its own check digit. It's assigned once, usually at birth, and held for life.

A person keeps the same National Register number across every card they're ever issued. The card number is different on every card. Extracting the wrong one — or conflating them — breaks downstream KYC, onboarding or record-matching logic that assumes a document number identifies a person rather than a piece of plastic.

Why Belgian eID Is a Good Test Case for ID OCR

Belgian eID is a useful example of a broader problem in identity document processing. A generic OCR engine can recognize the characters in an MRZ. That doesn't necessarily mean it understands the document.

A production document parser has to answer additional questions:

• Which document type is this?
• Which country issued it?
• Which MRZ format does it use?
• Where does the document number start and end?
• Which check digit validates it?
• Are there country-specific extensions?
• Does the visible document number match the MRZ-derived value?
• Are there multiple document generations still in circulation?

How Misfora Handles Belgian eID and Other TD1 Edge Cases

Misfora's document OCR pipeline doesn't treat every ID card as a generic image. It first identifies the document type and MRZ format, then applies document-specific parsing and validation rules to extract structured fields.

For Belgian eID cards, this includes handling the TD1 extension for the 12-digit document number and cross-checking the MRZ-derived value against the printed card number — rather than reading only the first nine MRZ characters and stopping there.

This matters when document data feeds directly into a PMS, CRM, KYC workflow or onboarding system, where a silently truncated document number is worse than a rejected scan.

TD1 Is a Format, Not a Universal Parsing Template

Belgian eID is only one example. Other TD1 documents can use the same MRZ structure while introducing different field conventions, optional-data usage and document-number rules of their own — a long TD1 document number turns out to be its own small parsing category, not a Belgium-only quirk.

It's a documented category, too: the same open-source mrz library has a second, separate open issue (#35) reporting that Estonian ID cards also set the document-number checksum position to < — a different country, a related but distinct non-standard behavior, reported independently by a different developer.

We are documenting these country-specific cases as we encounter them.

For the current list of countries and document types Misfora has been tested against, see the supported documents page.