Reading a first name, surname, document number and birth date from an ID or passport photo can speed up front-desk data entry, but saving OCR output directly to the guest profile creates new accuracy and security risks. Glare, a tilted camera, low resolution, another alphabet or a worn document can change a single character. A misread document number may then flow into reporting, invoicing or guest matching. A safe solution uses layered controls: image-quality checks, MRZ validation, visible warnings for low-confidence fields and no unnecessary retention of the raw image.

What you will learn in this article
  • General OCR reads visible text, while MRZ processing uses machine-readable lines and check digits. The two results can be compared to validate each other.
  • Scanning results should enter the form as suggestions; critical fields should not be finalised automatically without showing confidence and MRZ check results.
  • The ID image, extracted fields and transaction logs do not have the same retention needs; define purpose, access and deletion periods separately.

Separate the roles of OCR and MRZ

OCR converts writing in an image into machine-processable text. Fields such as name, surname, document number or address on the visible face of an ID can be found through general OCR and document-layout analysis. PaddleOCR documentation provides separate components for text detection, text recognition, document preprocessing and, when needed, key-information extraction. This is flexible, but model output alone does not prove that the document was read correctly.

An MRZ consists of fixed-format lines on machine-readable travel documents. ICAO Doc 9303 defines YYMMDD date representation, document and nationality codes, and check-digit calculations for selected fields. Tools such as PassportEye can locate and parse the MRZ on passports, visas and suitable ID documents. This path cannot be used for a document without an MRZ; general OCR and human verification are then required.

  • The document was first classified by whether it contained an MRZ.
  • General OCR was used for visible fields and an MRZ parser for MRZ lines.
  • OCR text was not presented as equivalent to document validation.
  • Unsupported document types were clearly reported to staff.

Check capture quality before sending the image to the server

The first requirement for successful reading is not the right model but a usable image. The mobile screen should keep the document edges inside a frame, while blur, glare, darkness, cropped corners and tilt should be measured on the device where possible. Instead of only saying 'could not read', give specific guidance such as 'place the document on a flat surface', 'reduce reflections' or 'capture the back as well'. This reduces unnecessary uploads and failed images retained on the server.

Higher photo resolution does not automatically produce a better result. Very large files slow transfer, while excessive compression damages characters. Detect the document boundary, correct perspective and resize to a safe dimension without losing readability. If front and back are required, link both images to the same temporary transaction ID and show staff which side is missing.

  • Document-edge, blur, glare and cropping checks were performed.
  • The error message gave specific recapture guidance.
  • Perspective correction and safe resizing were applied.
  • Front and back images were matched in the same temporary transaction.

Identify the document type and route it to the correct reading pipeline

Rather than trying to read every document with one OCR configuration, first identify the type: passport, ID with MRZ, ID without MRZ, residence document or another unsupported document. When an MRZ is detected, compare its line count and length with possible TD1, TD2, TD3 or visa formats. PassportEye's parser also infers the MRZ type from line structure and extracts fields accordingly.

A missing MRZ does not have to end the process. Continue with general OCR, a document template or controlled manual entry. The system must record which method produced the result. 'MRZ validated', 'visible field read by OCR' and 'entered manually' should not display the same assurance level. Staff should be able to correct a misclassified document type, and that correction should become a model-quality metric.

  • Document type and reading method were stored in separate fields.
  • Controlled OCR or manual entry was offered when no MRZ was found.
  • TD1, TD2, TD3 and visa line structures were kept distinct.
  • Staff corrections to document type were added to quality metrics.

Use MRZ check digits as a genuine validation signal

The strength of an MRZ is not just its structured text; it also contains check digits for specific fields. Under ICAO Doc 9303, these digits are calculated with defined weights over fields such as document number, birth date, expiry date or a composite. If a value recalculated from the recognised characters does not match the document's check digit, at least one character may have been misread. This signal is valuable and independent of OCR confidence.

A passing check digit still does not prove that the document is genuine or valid; it only shows that the relevant line was read consistently. The system can show document-number, birth-date and expiry-date checks separately. If one field fails, highlight the questionable character and ask for comparison with the visible face or a new capture instead of silently filling the entire form.

  • MRZ check digits were recalculated field by field.
  • Failed fields were shown clearly to the user.
  • A passing check digit was not presented as proof of document authenticity.
  • Common fields in the MRZ and visible face were cross-checked.

Autofill the form, but leave the final decision to staff

Transfer recognised data to the guest form as a draft. Show the source and confidence beside every field: MRZ, visible-field OCR, previous guest profile or manual entry. Fields with high confidence and passing check digits can appear normally, while low-confidence fields should carry a warning. Do not finalise the record until staff compare it with the document and approve it.

Name and surname separation, Turkish characters, multiple given names, date centuries and country codes require particular care. Because MRZ dates use two-digit years, birth and expiry dates must be assigned to the correct century using context. The system may suggest existing profiles that resemble the person, but should not merge them automatically on name similarity alone. Show old and new values side by side on the approval screen and log staff corrections.

  • Field source and confidence were displayed in the form.
  • Critical fields were not finalised without staff approval.
  • Date, country-code and name normalisation were checked separately.
  • Existing guest profiles were matched under staff control, not automatically.

Separate purpose, access and retention under KVKK

An ID image and information extracted from it are personal data. KVKK's general principles require processing for specific, explicit and legitimate purposes; keeping processing relevant, limited and proportionate; maintaining accuracy where necessary; and retaining data only as long as required. It is therefore not appropriate to assume that all document images may be stored indefinitely because they might be useful later. The property should define each collected field, its business purpose and legal basis in its data inventory.

Different retention periods may apply to the raw image, structured guest fields and security log. If the image is no longer needed after recognition and staff approval, consider secure deletion; if a legal or operational requirement applies, define the period and access role explicitly. KVKK's data-security guide addresses technical measures including access management, logs, masking, backup and deletion or destruction together. Confirm the final policy with legal and KVKK owners.

  • Purpose and legal basis were defined for every processed field.
  • Separate retention periods were defined for raw images, extracted data and logs.
  • Unauthorised roles could not access document images, and sensitive fields were masked.
  • Deletion, backup and logging policies were tested together.

Build a secure and traceable processing pipeline

The recommended flow covers capture on a phone or reception camera, on-device quality checks, encrypted transfer, temporary processing, document classification, OCR/MRZ parsing, field validation, staff approval and controlled deletion. If the model runs on another server, give it short-lived access only to the required file and never use a public URL. Temporary filenames should not contain document numbers or guest names.

Logs should not repeat the full identity text. A transaction ID, model version, reading method, field-level confidence or validation result, approving user, corrections and deletion time cover most audit needs. Prevent raw images and full document numbers from entering error logs. During an outage, staff should be able to fall back to safe manual entry, and queued images should be visible and time-limited.

  • Transfer and temporary storage were encrypted with time-limited access.
  • Filenames and error logs did not carry personal data.
  • Model version, validation result and staff correction were logged.
  • Outage and queue-cleanup scenarios were tested.

Set quality thresholds and a pilot plan with realistic hotel documents

Free and open-source tools can reduce prototype cost, but they do not guarantee the same result for every camera, issuing country and lighting condition. PassportEye is a focused starting point for MRZ extraction, while PaddleOCR provides a broader toolkit for general OCR and document processing. Do not make a production decision from a sample screenshot alone; measure against a lawfully prepared and, where possible, masked test set covering document types the hotel frequently encounters.

A pilot should measure more than the percentage of documents read. Track field-level accuracy, MRZ check success, recapture rate, staff-correction rate, average processing time and unsupported-document rate. False positives carry greater risk in critical fields, so keep any automatic-save threshold high. Begin with limited users and devices, then update templates and guidance as errors are corrected.

  • The test set represented real usage conditions and document diversity.
  • Field accuracy, recapture rate and staff-correction rate were measured.
  • Higher confidence and validation thresholds were used for critical fields.
  • The pilot started with limited devices and users and expanded based on metrics.
Short answers

FAQ

Is PaddleOCR alone enough to read passports and Turkish ID cards?

General OCR can extract visible text, but additional layers are needed to map document fields, parse the MRZ, validate check digits and show low-confidence results to the user. Run field-level tests under real operating conditions before production.

Does PassportEye verify that a passport is genuine?

No. PassportEye can read the MRZ and evaluate structured fields and check digits. Passing checks show that the line was read consistently; they do not by themselves prove physical authenticity or official validity.

Must the ID image be retained after scanning?

Do not assume retention is required in every case. Based on purpose, legal basis, statutory obligations and operational need, the property should set separate retention and deletion periods for raw images and extracted fields and confirm the policy with legal and KVKK owners.

Sources and updates

Operational recommendations should be adapted to the property's own conditions. Information about identity-document processing and privacy was checked against the official documents below on 23 September 2026.