## 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

```text
agent's amount parser broke on european decimal commas
```

## Steps

1. Detect the locale signals on the receipt: country, currency symbol, and vendor address. Expected: a likely number format.
2. Normalize: take the last comma or period as the decimal separator and remove all other separators. Expected: a plain digits-and-decimal string.
3. Parse the normalized string to a decimal type, never a float. Expected: an exact amount.
4. Sanity-check the result against the receipt total's magnitude (a coffee is not 123,456). Expected: absurd values get flagged.
5. 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