Scanning the driver qualification card instead of typing it

The card is more machine-readable than it looks

The German driver qualification card (Fahrerqualifizierungsnachweis, FQN) follows an official model (Annex 3 BKrFQV), and almost every field carries a number: 1 surname, 2 first name, 3 date and place of birth, 4b expiry date, 5b serial number, 9 categories. For text recognition, that's a gift: the numbers tell you what goes where.

BKF Manager reads seven values from it. We ignore the photo and the signature. Birth name and gender aren't part of the model at all, so they're added by hand.

Recognition runs on the device, not on a server

In the beginning, the apps sent the photo to our web app's text recognition, and on the iPhone the card had to be held upright. Today BKF Manager recognizes the text right on the device: with Apple's Vision framework on the iPhone, with Google ML Kit on Android. The live scanner's camera image is analyzed and discarded, it never leaves the device. For a card full of personal data, that's the nicer default.

The most important setting is an inconspicuous one. Language correction helps with prose, but it gets in the way with numbers and dates – those should stay verbatim. So off it goes:

let request = VNRecognizeTextRequest(completionHandler: parseFQN)
request.recognitionLevel = .accurate
request.usesLanguageCorrection = false  // numbers and dates verbatim
request.recognitionLanguages = ["de-DE", "en-US"]

On Android, Google ML Kit takes over with its recognizer for Latin script, which is all a German card needs. One quirk worth knowing: ML Kit doesn't rotate the image by itself. For single photos, the app therefore tries all four orientations and keeps the best result.

Field numbers beat guessing positions

Instead of guessing coordinates on the card, we sort the recognized lines top to bottom and look for “1.”, “4b.” and friends. If the value only shows up on the next line, that line comes along. If a number is missing, rules step in: a date with a year between 1930 and fourteen years ago is a date of birth, one from last year up to ten years ahead is an expiry date.

The serial number comes with a text-recognition classic: O instead of 0, L instead of 1. In the number part, both apps therefore turn O into 0, I and L into 1 and B into 8. Sounds like nitpicking, but it's exactly the digit the whole record hinges on.

The scanner waits for two good frames

In the live scanner the card lies sideways so the text gets more pixels, and a frame in ID card format shows where it goes. Capture is automatic, but only once two frames deliver surname, date of birth, serial number and expiry date. Until then, the screen shows what's still missing.

After that, nothing lands in the database unasked. The values are pre-filled in an ordinary form, and nothing is saved until someone presses the button. If a serial number is already in the system, the server says no. No duplicate participants that way.

What we take away

Official models are half a parser. Where fields are numbered, read the numbers, not the layout.

Numbers need rules, not spell-checking. Language correction off, plausibility on: date format, year ranges, typical mix-ups. Both apps apply the same rules. Whether Apple Vision or ML Kit delivers the lines is then almost a detail.

One hit is luck, two are a result. A person still has the last word. How the recorded attendance then reaches the KBA is covered in Module 95 goes digital.