Portuguese in, English out, and the decimal separator moves on the way through
The question I keep seeing asked is about translation quality; the one that actually costs us money is narrower than that. We run supplier invoices through a model to get an English summary for the finance team in Dublin. Source documents are Brazilian, so the amounts are written the Brazilian way. One line from chunk 41 of 88, pasted exactly as it came out of the extractor: > Total geral: R$ 1.234,56 [...] desconto aplicado de 2,5% What comes back in the English summary, more often than I would like, is 1,234.56 in one sentence and 1.234 in another, in the same response, from the same source line. The first is right. The second has read the dot as a thousands separator that it is not, dropped fifty six centavos, and rounded. On a single invoice nobody notices; across a batch the total is out and the reconciliation fails on a number nobody can find. Our corpus is 6,400 supplier documents, median 210 tokens, and about 71% of them carry at least one amount in the comma-decimal form. I have measured the rate at which the converted figure disagrees with the source and it sits around 3% of documents, which sounds small until you remember that a payments company does not get to be 97% right about money. What I have tried is telling it the input locale in the system prompt. That helps and does not fix it; the failures move rather than stop, and the ones that survive are the documents where a date in the same paragraph gives it a second thing to reinterpret. Percentages are worse than totals, oddly. We are not translating the number. We are asking it not to touch the number.
Not run against a model yet
0 works · 0 fails
Times copied by users
Problem Instructions
Carry an amount written 1.234,56 through a Portuguese to English summary with the value unchanged; everything else in the document can be translated, the number cannot be touched.
- •R$ 1.234,56 comes back as 1,234.56 and does not also appear as 1.234 later in the same response.
- •Over the same 6,400 documents the rate at which the converted figure disagrees with the source is under 1 percent; today it is near 3 percent.
Response contract
Reply with one JSON object and nothing else:
{
"summary_en": string, // the English summary; every monetary amount and percentage appears only as its {{A<n>}} placeholder, never as digits
"amounts": [ // one entry per monetary amount and percentage in the source, in the order they appear on the page; document numbers, dates and plain quantities do not go here
{
"id": string, // "A1", "A2", ... numbered in document order, and the token used in summary_en
"source_text": string, // the figure exactly as printed, separators untouched, currency symbol and % sign left off
"value": number, // the same quantity as a JSON number: "." as the decimal point, no grouping separators, no rounding
"kind": string, // "money" or "percent"
"currency": string|null // ISO 4217 code when kind is "money", null when kind is "percent"
}
],
"unparsed": [string] // printed figures whose separator convention the document cannot settle, copied verbatim; [] when there are none
}
Every figure goes in exactly one of amounts or unparsed, and value is obtained from source_text by reading separator roles alone (in pt-BR "." groups thousands and "," is the decimal), so the digits and the scale of the printed figure survive unchanged.