We had no Dutch euro receipt to test against, so we rendered 40
Our Dutch-language test set has 74 receipts in it. When we actually checked them line by line this week, 67 of them print “TOTAAL … $42.36” — they're from Bonaire. Dutch-language, but US dollars. Which meant that after more than a year of building this app, we had never once tested our Dutch reading logic against an actual euro receipt from the Netherlands.
So we rendered 40 of our own: checkout receipts styled after Albert Heijn, Jumbo, Lidl, HEMA, Kruidvat and Action, with the bonus discounts, statiegeld (bottle/can deposits) and BTW (VAT) tables printed the way real Dutch receipts print them. Deliberately rendered, not photographed — that distinction matters and we come back to it at the end. One test pass in, we found three silent bugs. All three were fixed the same day and reach every copy of the app on its next scan, no update required.
Bug 1: the tax table that impersonated the total
Albert Heijn-style receipts print a BTW breakdown near the bottom, headed like this:
BTW OVER BTW TOTAALThat bare word TOTAAL sitting in the header was sometimes read as the total line itself, letting a tax figure from that table replace the real total. We now recognize “TE BETALEN” (“amount due”) as the total keyword and skip the tax table entirely. Five of the six wrong totals in our first test run came from exactly this.
Bug 2: the discount that didn't count
Dutch receipts print discounts with the minus sign in front of the amount:
KORTING -1,50STATIEGELD RETOUR -0,75EMBALLAGEBON -0,25
Our price recognition expected the minus sign after the number, not before it — so none of those lines were read as amounts at all. Zero of the 40 receipts with a line like this had it recognized, before the fix. The total at the bottom was still correct, so nothing looked broken; the discount just quietly vanished from the item list.
Bug 3: the discount that disappeared into the price
Even once the line was visible, our item-to-price pairing did something unhelpful: it subtracted the discount before showing you anything, and kept only what you actually paid.
GOUDSE KAAS BELEGEN 500G 10.47Korting -1.25
Before the fix, that became one item priced at 9.22 — a number that appears nowhere on the receipt. Now the item keeps its printed price, and the discount shows up as its own negative line underneath, exactly as printed.
What it moved
Across the 40 rendered receipts: exact-match item lists went from 13 to 29 of 40. Of the 17 receipts with a discount or refund line, that line was visible in the item list on 0 before the fix, and 14 after. Totals: 40 of 40, with one exception — a receipt where the photo-recognition step reads €2.49 as €2.79, a digit misread no downstream logic can recover.
Our release gate now runs 471 receipts across ten country sets: 391 photographs of real receipts, plus 80 rendered ones (40 Taiwanese uniform invoices and these 40 Dutch receipts).
What this doesn't prove
A rendered receipt proves the reading logic is right. It doesn't prove the app holds up against an actual crumpled receipt from your pocket — faded thermal paper, an angled photo, bad supermarket lighting. That's exactly why we're writing this up instead of quietly shipping it: the next step is a real photo of an Albert Heijn or Jumbo receipt, and we don't have one yet.
We're not asking anyone to send us receipts here. If ReceiptIQ misreads one of yours, there's a “Report a Problem” button in Settings that sends it straight to us.
Related: how ReceiptIQ handles Dutch receipts is covered on Bonnetjes Scannen (our Dutch-language page). For the broader testing story and where it still falls short, see testing against real receipts from four countries and a Sydney receipt stored as Thai baht.