Lire en français →

DOCUMENT TYPES

Proof of address extraction

By Sygnet Research. Written by Sygnet, sourced, checked before publication.

A proof of address is any document a person or business uses to show where they live or operate: a utility bill, a bank statement, a lease agreement, or a local tax notice. Utility companies, banks, landlords, and tax authorities issue these documents, and compliance teams at banks, insurers, telecom providers, and property managers process them constantly during onboarding. Most of these teams still check addresses by eye, comparing a scanned PDF against whatever a customer typed into a form. Automated extraction turns that manual comparison into a structured, auditable step that runs in seconds rather than minutes.

Fields to extract

FieldFormat / exampleValidation check
Document type"Electricity bill"Must match an allowed list (utility, bank, tax, lease)
Issuer name"Ondia Energy SA"Cross-check against known issuer registry
Account holder name"Marta Delgado Ruiz"Match against KYC applicant name
Full address"12 Rue des Lilas, 75011 Paris"Parse into street, postal code, city; validate postal code format
Postal code"75011"Must match national postal code pattern
Country"France"Must be an ISO 3166 country name or code
Issue date"2024-03-05"Must be a valid calendar date, not in the future
Document age"42 days"Recompute from issue date; flag if older than policy threshold (often 90 days)
Account or contract number"FR-9931-204471"Format check against issuer's known numbering pattern
Billing period"01/02/2024 - 29/02/2024"End date must follow start date; period length plausible
Amount due (if present)"€87.42"Numeric, non-negative, currency consistent with country
Issuer logo/letterhead presencebooleanFlag documents with no detectable letterhead for manual review
Language of document"French"Must be a supported language or route to translation step

Why this document is hard to process

Proof of address documents come from thousands of different issuers, each with its own layout, logo placement, and terminology. A utility bill from a regional gas company looks nothing like a bank statement header, and a tax notice from a foreign jurisdiction may use a completely different address format, sometimes with the postal code before the city name, sometimes after. There is no single template to anchor on, which rules out simple template-based extraction for anything but a handful of the largest issuers.

Scan quality varies wildly too. Customers photograph bills on their phones, screenshot PDFs at odd angles, or submit faxed copies with visible creases. Multi-page bank statements bury the address on page one and other relevant data on page three. Handwritten annotations, stamps, and watermarks add noise that confuses naive OCR.

There is also a fraud dimension. Because a proof of address is often the weakest link in identity checks, some applicants edit PDFs to change a date or address field. Detecting this requires looking at font consistency, metadata, and layout artifacts, not just reading the text. Add multilingual documents, inconsistent date formats, and issuers that rebrand or merge, and the extraction problem stops being a simple text-read task and becomes a structured reasoning problem.

How Sygnet processes it

Sygnet classifies the incoming file first, distinguishing a utility bill from a bank statement or lease agreement before extraction even starts. It then infers the right schema for that document type rather than forcing every issuer into one fixed template, which matters given how much formats vary (see OCR vs VLM for why layout-aware models outperform plain OCR here).

Each extracted field carries a confidence score and a bounding box that ties the value back to its exact location on the page, so a compliance officer can see precisely where "issue date" came from without hunting through the document (this is field-level provenance). Validation rules run automatically: date logic, postal code formats, and cross-checks against the applicant's stated name and address.

Where extraction confidence is low, whether from a blurry scan or an unfamiliar issuer, the document routes to human review instead of getting silently accepted. High-confidence documents flow straight through to your onboarding or claims system as structured JSON, ready for downstream systems. This mirrors the same approach Sygnet applies to KYC onboarding and identity document extraction.

Validation rules worth applying

  • Recompute document age from the issue date and reject anything older than your policy threshold
  • Confirm the account holder name matches the applicant name on file, allowing for minor transliteration differences
  • Validate postal code format against the stated country's national pattern
  • Flag documents where the billing period end date precedes the start date
  • Check issuer name against a maintained list of known utility, bank, and tax authority names
  • Compare the extracted address against any address already on file and flag mismatches for review
  • Detect font or spacing inconsistencies that suggest digital editing of dates or amounts

FAQ

Can proof of address extraction detect a forged or edited PDF?

It can flag strong indicators: inconsistent fonts within a single field, metadata that shows recent editing software, or layout spacing that doesn't match the issuer's known template. It cannot prove intent on its own. Suspicious documents should route to human review and, where relevant, dedicated document fraud detection checks rather than automatic rejection.

How old can a proof of address be and still count as valid?

There is no universal rule. Banks and regulators typically set their own threshold, often somewhere between 30 and 90 days, and some accept older tax notices as an exception since those are annual documents. The extraction system should read the issue date and let your policy engine, not the extraction step, decide validity.

Does this replace manual KYC review entirely?

No. It removes the repetitive part, reading dates, addresses, and names off inconsistent documents, so reviewers only look at cases where confidence is genuinely low or a validation rule fails. That is a smaller, higher-value workload, not a replacement for judgment on edge cases or fraud signals.

NEXT STEP

See it on your own documents

One email when we publish something worth your time.