How to normalize Japanese 和暦 (era) dates for invoice systems

The era offset table

Each Japanese era maps to a Gregorian start year. The conversion is gregorian = era_start_year + era_year − 1.

元年 (gannen) — the "first year" trap

The first year of an era is written 元年 (gannen), not 1年. 令和元年 means Reiwa year 1 = 2019. A converter that only parses digits will fail on 元年 entirely, or worse, treat it as a missing value. Always map 元 → 1 before the arithmetic.

A minimal, correct conversion

The approach in ~20 lines: normalize width, map 元 to 1, look up the era offset, and add. Pseudocode:

ERA = {
  "令和": 2018, "平成": 1988, "昭和": 1925,
  "大正": 1911, "明治": 1867,
  "R": 2018, "H": 1988, "S": 1925, "T": 1911, "M": 1867,
}

def wareki_to_iso(s):
    s = to_halfwidth(s)                 # ２０２４ → 2024, remove commas
    s = s.replace("元年", "1年")         # gannen → year 1
    m = match(r"(令和|平成|昭和|大正|明治|[RHSTM])\s*(\d+)\s*年\s*(\d+)\s*月\s*(\d+)\s*日", s)
    if not m: return None               # not a wareki date — let the caller decide
    era, y, mo, d = m.groups()
    year = ERA[era] + int(y)
    return f"{year:04d}-{int(mo):02d}-{int(d):02d}"

# 令和6年5月12日   → 2024-05-12
# 令和元年5月1日   → 2019-05-01
# 平成31年4月30日  → 2019-04-30  (last day of Heisei)

Edge cases that break naive converters

• →The Heisei→Reiwa boundary (2019). 平成31年 runs 1 Jan–30 Apr 2019; 令和元年 starts 1 May 2019. Both map into the same Gregorian year. Never assume one era per calendar year.
• →Full-width digits and abbreviations. Invoices mix ２０２４, R6, 令和6, and 令06. Normalize width and expand single-letter era codes first.
• →Mixed 和暦 and 西暦. A single document can carry both the era date and a Gregorian date. Extract both and reconcile rather than trusting the first match.
• →OCR noise. 令和 misread as 令知, or a dropped 年. In a production pipeline, a low-confidence date is flagged for human review, not guessed.

Why this belongs in the pipeline, not the prompt

You can ask an LLM to convert a date, but for invoices you want the conversion to be deterministic, testable, and logged. We run 和暦 normalization as a rule step after extraction: the LLM reads the field, the rule converts and validates it, and any date that fails the pattern or scores low on confidence is routed to a human-review queue. That is how the Japanese invoice AI-OCR pipeline handles dates — you can watch it on the live demo.