decimal separator confusion: 1.234,56 vs 1,234.56

TL;DR

European invoices write 1.234,56 where US invoices write 1,234.56, and misreading the convention shifts amounts by 100x. Determine the convention from the vendor country and the invoice's own formatting: the last separator before the final two digits is the decimal mark. Normalize to a canonical decimal representation before any arithmetic, and flag amounts where both readings are plausible.

Error

Extracted amount: 1.234 (ambiguous: 1234.00 US vs 1.234 EU)

Steps

1. Take the vendor country as the prior: EU implies comma-decimal, US/UK implies point-decimal. Expected: A prior convention.

2. Inspect the invoice's own numbers: the separator before the last two digits is the decimal mark. Expected: Document-level evidence.

3. Normalize all amounts to canonical decimal form. Expected: Comparable numbers.

4. Run arithmetic validation on normalized amounts. Expected: Catches 100x errors immediately.

5. Flag any amount where both conventions produce plausible values. Expected: Human decides the ambiguous cases.

When to use

• International invoices with ambiguous separators
• Amounts that look 100x too large or small
• EU vendor invoices in AP

When not to use

• Single-convention vendor bases
• Currency symbol misreads
• Post-normalization arithmetic

Compatibility

Extractor-agnostic; implement in the normalization layer before validation.

Variant phrasings

comma vs dot decimal invoice

European number format invoice

1.234,56 parsing

Root cause

Decimal conventions are cultural, and OCR reads the characters correctly while the meaning depends on locale. A single misassigned separator multiplies or divides the amount by a hundred.

Edge cases

• Swiss invoices use apostrophes as thousands separators (1'234.56); include in patterns
• Some invoices mix conventions; document-level majority wins
• Indian numbering (lakh/crore grouping) needs its own pattern

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ubc0SfulWJ15NyWMIYa0dg