Data Normalization for Extracted Documents: What to Standardize and How

Data normalization for extracted documents means converting each extracted value into one consistent, machine-readable form: dates as ISO 8601, amounts as a number plus a currency code, phone numbers in E.164, and so on. OCR can read every character correctly and still leave you with "May 12, 2025", "05/12/2025" and "2025-05-12" in the same column. Normalization is the step that turns that column into data a system can sort, match and sum.

This guide covers the eight field types that need it, the rule for each, a working date parser, and the checks to run afterwards. If you are new to document AI, start with the optical character reader guide and come back when downstream systems start rejecting your OCR output.

What does normalization look like for each field type?

Every field type has its own messy inputs and its own clean target. The table shows the common cases.

Field type	Raw extracted values	Normalized form	Watch out for
Date	"May 12, 2025", "12-May-2025", "2025-05-12"	2025-05-12 (ISO 8601)	"05/04/2025" is ambiguous without the document's locale
Amount	"$1,234.56", "1.234,56 €", "1234.56 USD"	1234.56 plus the code USD or EUR	The decimal mark differs by country
Phone	"(555) 123-4567", "+1 555 123 4567"	+15551234567 (E.164)	Local numbers need a default country
Address	"123 Main St.", "123 Main Street"	Structured street, city, region, postal code	Abbreviations and word order vary by country
Name	"John Smith", "Smith, John"	Separate given name, family name and suffix	Name order is not the same in every culture
Account or ID number	"1234-5678", "1234 5678"	Digits only, then validated	Strip separators only when they carry no meaning
Yes or no	"Yes", "Y", "true", a ticked box	true or false	An empty box is not the same as an unreadable one
Document type	"Invoice", "Invoice (Original)", "INV"	One canonical label such as invoice	Map every variant explicitly

How do you normalize dates?

Dates are the hardest, because the same string can mean two different days. "05/04/2025" is May 4 in the United States and April 5 in most of Europe. Pick the order from the document's context, such as the vendor country, the language and the document type, then store the result as ISO 8601 (YYYY-MM-DD), which sorts correctly and reads the same in every locale.

Here is a small parser. It takes the order as an input instead of guessing, and it returns nothing when the value does not parse, so the caller can send it for review:

from datetime import datetime

def parse_date(raw, day_first):
    formats = ["%d/%m/%Y", "%d/%m/%y"] if day_first else ["%m/%d/%Y", "%m/%d/%y"]
    for fmt in formats:
        try:
            return datetime.strptime(raw.strip(), fmt).date().isoformat()
        except ValueError:
            continue
    return None  # do not guess: route to review

parse_date("05/04/2025", day_first=False)  # "2025-05-04"
parse_date("05/04/2025", day_first=True)   # "2025-04-05"

Two-digit years need a rule too. Python's %y reads 69 to 99 as 1969 to 1999 and 00 to 68 as 2000 to 2068, so "01/01/01" becomes 2001. If your documents can be older than that, flag two-digit years instead of trusting the default.

How do you normalize amounts and currencies?

Store the amount as a decimal number and the currency as a separate three-letter ISO 4217 code. Never store the formatted string, because "1.234,56" and "1,234.56" mean different numbers in different countries. Use a decimal type, not a floating-point one, so cents do not drift. Read the currency from the symbol or the code on the document, and when only a symbol such as "$" appears, use the document's country or the vendor's record to choose between dollars. The same rule applies to invoices in several currencies, covered in multi-currency invoice OCR.

How do you normalize phones, addresses and names?

• Phones. Use Google's libphonenumber, which exists for every major language, and store the E.164 form such as +15551234567. Pass a default country for numbers written without a prefix.
• Addresses. Parse into structured fields rather than cleaning the string. libpostal handles many countries. For US addresses, the USPS publishes its own standard abbreviations and an address service.
• Names. Store given name, family name and suffix separately, and keep the original string too. Do not assume the first word is the given name, because name order differs across cultures. A library such as python-nameparser handles the common Western patterns.

How do you normalize IDs, account numbers and yes-or-no fields?

For identifiers, strip spaces and dashes, then validate against the format you expect. Many identifiers have a built-in check you can use: an IBAN passes a mod-97 test, a payment card number passes the Luhn test, and a US bank routing number has a check digit. A US Social Security number does not have a checksum, so check only its length and pattern. For yes-or-no fields, map every variant ("Yes", "Y", "true", a ticked box) to true or false, and keep a third state for a box you could not read, so unreadable never turns into false.

What makes normalization hard?

• Ambiguity needs context. A one-size-fits-all pattern cannot settle "05/04/2025". Build the parser around the document's origin.
• OCR errors carry through. If OCR reads "5/4/2025" as "5/A/2025", normalization will fail or, worse, produce a wrong value without warning. Always validate after normalizing, and flag anything that does not look right.
• Edge cases are common. "01/01/01" has several readings, and "$1.00" is not always a US dollar. Use conservative defaults and send anything ambiguous to a person.
• Rules change. New currency codes, address formats and date styles appear. Treat the rules as code that needs maintenance.

Where does normalization fit in the pipeline?

Work in three layers, in this order:

1. Extract raw strings. Keep exactly what the document says. Do not clean during extraction, and store the raw value next to the clean one so you can audit it.
2. Normalize. Apply the rule for each field type, using a library for the hard cases and the document's context for the ambiguous ones.
3. Validate. Check that the result is sensible: the date is in a plausible range, the amount is positive where it should be, and the identifier passes its check. If validation fails, route the field to review. See real-time document validation for how this step fits a wider pipeline.

What goes wrong when you skip it?

The failures are quiet, which is what makes them costly. Nothing throws an error. The reports are just wrong.

• Dates that sort as text, so an invoice from December lands before one from February.
• Amounts that add up to the wrong total because one was read with the wrong decimal mark.
• The same supplier spread over several rows, such as "Acme Inc" and "Acme, Inc.", which understates spend with that vendor and weakens duplicate invoice detection.
• Phone numbers and addresses that downstream systems reject.

The same discipline shows up in compliance work, where amounts have to be numbers before monitoring can use them. See AML document checks.

What should you do first?

If extracted data feeds other systems, build the normalization layer before you scale up OCR, because cleaning up later is harder. If you already have messy data, start with the field that causes the most downstream bugs, usually dates or vendor names, and fix that one first. When you evaluate a document AI vendor, ask what normalization it does, whether it is locale-aware, and whether it returns the raw value next to the clean one. For the wider limits of OCR itself, see the honest guide to OCR.