1.234,56 and 1,234.56 are the same number and it picks the wrong one about once a fortnight
Second one from me today, different set. chiffchaff, n=120 line items off supplier invoices in four locales. UK and US on the one side, DE on the other, and one Swiss lot that writes 1'234.56 with an apostrophe, which i had not seen before this month. 10 of the 120 come back off by a factor of 1000, so 8.3%. All ten are the same shape: one separator with exactly three digits after it, 1.234 or 1,234, and nothing else on the page to say which way round the convention runs. Read as a decimal on the German invoices and as thousands on the American ones, and when it guesses it does not say it guessed. The symbol does not settle it either. CHF and R$ both turn up next to both conventions in this set, and two of the German invoices are priced in dollars on one line and euros on the rest. I would take a null and a flag over a confident 1.234 every time. What i cannot have is a payment authorised at >= 1000 times the invoiced figure because a full stop got read as a comma, which has not happened, and has not happened only because somebody caught it on the way past. Nobody is going to enjoy the Swiss ones.
Not run against a model yet
0 works · 0 fails
Times copied by users
Problem Instructions
Read the amount correctly across the four locales in chiffchaff, and where one separator with three digits after it could go either way, hand back a null and a flag instead of a number.
- •No more than 1 of the n=120 line items comes back off by a factor of 1000. It is 10 now, so 8.3%.
- •The ambiguous ones come back null and flagged rather than resolved to whichever reading it liked.
- •1'234.56 off the Swiss invoices parses to the same value as 1,234.56.
Response contract
Reply with one JSON object and nothing else. No prose around it, no code fence.
{
"line_items": [ // one entry per amount printed on the page, in document order
{
"line_id": string, // the position reference exactly as printed, e.g. "L3"
"raw_amount": string, // the amount substring exactly as it appears, separators and all
"currency": string|null, // ISO 4217 code; null when no symbol or code is legible on that line
"value_minor": integer|null, // the amount in minor units, so 1.234,56 and 1'234.56 both come back as 123456; null unless status is "parsed"
"status": "parsed"|"ambiguous_separator"|"unreadable"
}
],
"review_required": boolean // true if any line item has a status other than "parsed"
}
status is "ambiguous_separator" when the digits are legible but nothing on the page settles whether the separator is a decimal point or a thousands mark, and "unreadable" when the digits themselves cannot be read; in both cases value_minor must be null and a reading must never be guessed in order to fill it.