agent's amount parser broke on european decimal commas error
Fixes amount parsing on European decimal commas with locale-aware number normalization. Use when an agent misparses amounts like 1.234,56. Not for currency-symbol problems.
TL;DR
European receipts write 1.234,56 where US receipts write 1,234.56, and a naive parser reads the wrong value. Normalize amounts using the receipt's locale: treat the last separator as the decimal mark, strip the thousand separators, then parse.
Error
agent's amount parser broke on european decimal commasSteps
- Detect the locale signals on the receipt: country, currency symbol, and vendor address. Expected: a likely number format.
- Normalize: take the last comma or period as the decimal separator and remove all other separators. Expected: a plain digits-and-decimal string.
- Parse the normalized string to a decimal type, never a float. Expected: an exact amount.
- Sanity-check the result against the receipt total's magnitude (a coffee is not 123,456). Expected: absurd values get flagged.
- Log the raw and normalized forms for every parsed amount. Expected: an audit trail for the normalization.
When to use
- Amounts with European decimal commas parse wrong.
- Parsed totals are off by orders of magnitude.
When not to use
- The currency symbol is misread (a symbol-mapping problem).
- The amount is missing (an OCR problem).
Tool compatibility
- Custom agent amount parsing; decimal arithmetic libraries.
Variant phrasings
Decimal comma misparsed
Same failure, shorter wording.
European number format broke parser
Names the format directly.
Why it happens
Separators swap roles across locales: the comma groups thousands in the US and marks decimals in Europe. A parser with one assumption inverts the value.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_9Yzr2vycvMOgbfnGwGRIgg