Reading Mexican documents with AI: why OCR alone is not enough

Optical character recognition (OCR) has been solving a specific problem for decades: turning the image of a document into text. For a know-your-customer (KYC) file in Mexico, that is only the first step. The documents received every day (voter ID cards, tax status certificates, articles of incorporation, proofs of address) have formats, quality levels and particularities that plain text does not capture. In this article we explain what makes them hard to read well and what is needed beyond OCR.

Each document has its own difficulties

• Voter ID card (INE). It is a small document that almost always arrives as a phone photo: with glare, tilt, cropping or the front and back in separate files. Several valid models with different designs coexist, and the key data (name, CURP, voter key, expiry) sit in different positions depending on the model. In some cases the address is not printed.
• Tax status certificate (constancia de situación fiscal). It is a document generated by the SAT, usually a PDF with embedded text, which makes it easier to read. Its difficulty lies elsewhere: the tax address must be distinguished from other data, tax regimes and obligations must be read correctly, and the issue date must be considered, because an old certificate may not reflect the taxpayer's current situation.
• Articles of incorporation (acta constitutiva). This is the most demanding case. They are notarial instruments dozens of pages long, sometimes scanned from old copies, with stamps, signatures, margin notes and typewritten text. The relevant information (company name, incorporation date, shareholders, management, attorneys-in-fact and their powers, public registry details) is scattered across long paragraphs, not in fields.
• Proof of address. Electricity, water or phone bills or bank statements, each issuer with its own design, which also changes over time. The correct address must be identified among several that may appear on the same page, along with the relevant date to know whether the proof is recent, according to each institution's policy.

Beyond text: structure and tables

OCR delivers lines of text, but not always in their logical order. In a two-column document, a shareholder table or a bill with side blocks, reading left to right mixes data that have nothing to do with each other. That is why, before extracting, it makes sense to rebuild the document's structure: what is a heading, what is a table, which lines form a row. With that structure, a language model can read the document in context and extract the fields of interest, even when they change position from one format to another.

How a long document is handled also matters. A fifty-page deed is not processed like an ID card; splitting it into sections and locating where each type of information lives reduces errors and lets each value keep a reference to the page and line it came from.

QR codes are also a source

Several Mexican documents include QR codes. The tax status certificate, for example, contains one with data that points to SAT verification, such as the RFC and the certificate's identifier, and digital tax invoices (CFDI) also include one with the fiscal folio. Recent models of the voter ID card include QR codes as well.

Reading these codes provides something OCR cannot: encoded data that does not depend on interpreting an image of text. That makes it possible to compare what the QR says with what is printed. If the RFC in the code does not match the visible RFC, there is a signal worth reviewing, whether due to an error, an altered document or a file that mixes pages from different documents.

OCR answers what the image says. A KYC file needs to answer whether what the documents say is consistent with each other.

The case file is reviewed as a whole

The real value appears when documents are read together. In a file for an individual or a company, the same data repeat across several documents and must match:

1. Name and company name, accounting for abbreviations, omitted surnames and company names written in different ways.
2. CURP and RFC, which must be consistent between the ID, the tax certificate and the other documents.
3. Address, comparing the one on the proof of address with the one on the tax certificate or the one declared by the client.
4. Validity and dates, such as the expiry of the ID or the age of the proof of address.
5. Powers, verifying that whoever signs for a company appears as attorney-in-fact or director in the deed or the corresponding power of attorney.

A system that only extracts fields leaves that cross-check to the reviewer. One that also compares the data and flags differences, with the source of each value, lets the reviewer focus on what truly requires judgment.

How we solve it

In Loony we combine OCR, document structure reconstruction, extraction with language models and QR code reading, and then we review the complete file: we cross-check names, CURP and RFC across documents, validate expiry dates and flag what does not match. Every value keeps its source document, page and line, and the final decision stays with the operator.

If your team assembles KYC files and wants to stop keying them in by hand, Write to us.