Parseur Multilingual Invoice Benchmark 2026. Tested in October 2026. Six tools, five invoices, four languages, 200 fields.
In the Parseur Multilingual Invoice Benchmark 2026, which compared six intelligent document processing (IDP) tools on German, French, Japanese and Korean invoices, Parseur extracted all 200 fields correctly, the only tool with zero errors. Docsumo extracted 196 and Airparser 194. Nanonets (168), Docparser (165) and Klippa (163) were 32 to 37 fields behind. We checked each result field by field against the printed invoice. The benchmark covers IDP tools only. General-purpose AI chatbots such as ChatGPT were not part of this test.
Key Takeaways
- Parseur was the only tool with zero errors in an October 2026 test of six invoice extraction tools across German, French, Japanese, and Korean invoices, a two-page invoice, and a phone photo.
- Japanese and Korean invoices separated the tools most. Klippa extracted 133 of 135 French and German fields correctly, but only 30 of 65 Japanese and Korean fields. Only Parseur and Docsumo got every Japanese and Korean field right.
- Number formats caused the most damaging errors. Docsumo read the German quantity "1.200" (one thousand two hundred) as 1.2, and Klippa read the Japanese and Korean "86,000" as 86.
- Half of the tools invented data. Airparser, Nanonets and Klippa returned values that are not printed on the invoice.
- Correct is not the same as usable. Only Parseur and Klippa returned standard dates and plain numbers that an accounting system can import without cleanup.
- Language support claims say little. Every tool processed all five invoices, yet scores ranged from 163 to 200 fields.
Multilingual invoice extraction by the numbers
Multilingual invoice extraction, by the numbers
Six IDP tools, five invoices, four languages, 200 fields
- fields Parseur extracted correctly, the only perfect score of six tools
- 200 of 200
- tools made at least one extraction error on five invoices
- 5 of 6
- average accuracy of the five tools other than Parseur
- 88.6%
- tools extracted every field on both the Japanese and the Korean invoice
- 2 of 6
- tools returned values not printed on the invoice
- 3 of 6
- tools assigned a value to the wrong party, supplier or customer
- 3 of 6
- size of the error when a tool misread a thousands separator, in two of six tools
- 1,000×
- tools returned import-ready output, with standard dates and plain numbers
- 2 of 6
Why are multilingual invoices hard to extract?
Multilingual invoices are hard to extract because the same characters mean different things in different countries, not because the characters are hard to read. "1.200" is 1,200 in Germany and 1.2 in the US. "03/09/2026" is 3 September in France and 9 March in the US. A Japanese due date can be written in the imperial era calendar.
Most document processing tools say they support 100 or more languages, but a tool can read every character correctly and still deliver wrong numbers to an accounting system. We built five invoices to test exactly these traps and scored every field.
Which tool extracted multilingual invoices most accurately?
Parseur was the most accurate tool in our October 2026 multilingual invoice test, with 200 of 200 fields correct. Docsumo (98%) and Airparser (97%) followed closely.
Multilingual invoice extraction ranking
Fields extracted correctly, out of 200
- 1 Parseur 200/200 · 100%
- 2 Docsumo 196/200 · 98%
- 3 Airparser 194/200 · 97%
- 4 Nanonets 168/200 · 84%
- 5 Docparser 165/200 · 82.5%
- 6 Klippa 163/200 · 81.5%
The top three tools are within 6 fields of each other. The bottom three are within 5 fields of each other, too close to rank reliably on five invoices.
How did each tool do in each language?
In our test, only Parseur and Docsumo extracted every field on both the Japanese and the Korean invoice, while every tool scored 34 or 35 out of 35 on the French invoice.
Fields extracted correctly per invoice and tool
Green is every field correct, red is under 75%
| Tool | French /35 | German PDF /55 | German photo /45 | Japanese /35 | Korean /30 | European total /135 | Asian total /65 |
|---|---|---|---|---|---|---|---|
| Parseur | 35 | 55 | 45 | 35 | 30 | 135 | 65 |
| Docsumo | 35 | 53 | 43 | 35 | 30 | 131 | 65 |
| Airparser | 35 | 53 | 42 | 35 | 29 | 130 | 64 |
| Nanonets | 35 | 43 | 36 | 28 | 26 | 114 | 54 |
| Docparser | 34 | 40 | 43 | 32 | 16 | 117 | 48 |
| Klippa | 35 | 54 | 44 | 16 | 14 | 133 | 30 |
The two-page German invoice was the hardest European document. Docparser lost 15 fields there, most of them on page 2. Nanonets lost 12, from missing line positions and totals.
What goes wrong when extracting multilingual invoices?
In our test, extraction errors on multilingual invoices fell into six patterns: misread number separators, invented values, unreadable Asian scripts, swapped supplier and customer, local punctuation and multi-page invoices. Each one is a real risk when invoices from many countries feed the same system.
1. Which tools misread thousands and decimal separators?
Two of six tools misread number separators in our October 2026 invoice test, producing amounts 1,000 times wrong. Germany writes one thousand two hundred as "1.200". Japan and Korea write eighty-six thousand as "86,000".
- Docsumo read "1.200 Stk" on the German invoice as a quantity of 1.2, so an order of 1,200 boxes became 1.2 boxes. The same line's total came back as "1.416.00", which is neither German nor English format.
- Klippa read every unit price and line total on the Japanese and Korean invoices 1,000 times too small: 86,000 became 86, and 18,400 became 18.4.
Neither error is visible unless someone checks the line items against the original, so both would pass straight into an accounting or ERP system.


2. Which tools returned values that are not on the invoice?
Three of six tools returned invoice values that are not printed on the document: Airparser, Nanonets and Klippa. Parseur, Docsumo and Docparser left those fields empty.
The German phone photo shows only page 1 of a two-page invoice, so it has no totals and the correct answer is an empty field.
- Airparser returned a subtotal of 4,454.45, the sum of the visible lines.
- Nanonets returned 3,985.25 as both the subtotal and the total due, a figure that matches nothing on the page.
- Klippa, on the full German invoice, returned an early-payment discount of 122.13. The invoice only says "2% Skonto" in its payment terms. The amount is never printed.
An invented total is worse than a missing one, because nothing flags it for review.

3. Which tools can read Japanese and Korean invoices?
Parseur and Docsumo extracted every field on both Japanese and Korean invoices in our test. Airparser missed one Korean field and Nanonets several, while Docparser and Klippa each lost more than a quarter of the Japanese and Korean fields.
- Docparser could not read Japanese or Korean characters. Labels came back as "AB" and "EX", Korean dates as "2026 09 12%", and Korean product descriptions as fragments of Latin characters.
- Klippa read the characters but not the structure. It returned the document titles 請求書 ("invoice") and 거래명세서 ("statement of transaction") as the supplier name, "1" as the Japanese invoice number and "0.01" as the Japanese total.
Parseur also converted the Japanese era date 令和8年9月30日 to 2026-09-30 (Reiwa 8 is 2026), a conversion the other tools did not make.


4. Which tools mixed up supplier and customer?
Three of six tools assigned an invoice value to the wrong party in our test: Nanonets, Klippa and Airparser.
- Nanonets swapped supplier and customer on the Japanese invoice.
- Klippa swapped the supplier's and the customer's VAT numbers on the German photo, though it got them right on the clean PDF of the same invoice.
- Airparser returned the Korean customer's business registration number as its customer number, a field the invoice does not have.
A swapped supplier sends the invoice to the wrong vendor record, which is harder to catch than a blank field.
5. How did a German quotation mark break an extraction?
German uses „low-high" quotation marks. On the line „Zerbrechlich", Airparser cut the description short and moved the quantity into an extra column, on both German documents. One punctuation mark corrupted a whole line item.
6. Which tools struggled with multi-page invoices?
Two of six tools lost data on the two-page German invoice: Docparser and Nanonets. The invoice has 9 line items across two pages, with totals on page 2.
- Docparser read page 1 only, losing 2 line items and all three totals.
- Nanonets processed each page separately. It returned the page 2 line items but never extracted the totals printed there.
Did any tool recalculate the printed tax?
No. The German invoice prints a tax amount of €975.08, which is 10 cents off a recalculation of 19% VAT. All three tools that returned the tax (Parseur, Docsumo and Airparser) reported €975.08 as printed. For accounting, that is the right behavior: extraction should report the document, not correct it.
Which tools return invoice data ready for accounting systems?
Only Parseur and Klippa returned both standard dates and plain numbers in our October 2026 test, the formats an accounting or ERP system can import without cleanup. We checked three output formats separately from accuracy.
| Tool | Standard dates (2026-09-30) | Plain numbers (1416.00) | Currency codes (EUR) |
|---|---|---|---|
| Parseur | Yes | Yes | No: EUR, € and "Euro (EUR)" mixed |
| Klippa | Yes | Yes, except the 1,000× error on Japanese and Korean | Yes |
| Docsumo | No | Partly (the "1.200" error) | No |
| Airparser | No | No: "1.416,00 €" | Yes |
| Nanonets | Mixed: French and Korean only | No | No: €, ¥, 원, "Euro" |
| Docparser | No | No | No |
Parseur's currency field returned whatever the invoice printed, so it varied from one invoice to the next. A one-line field instruction fixes it, but we kept the result as tested. Two other issues affect usability: Nanonets inserted spaces into reference numbers ("RE - 2026-04417"), which breaks automatic matching against orders, and Docsumo flagged correct Japanese and Korean dates for manual review.
Tool-by-tool results
Parseur: 200/200. Parseur is an intelligent document processing platform for operations teams that receive documents from many senders and need the data in their own systems. It delivers the extracted data to accounting software, ERPs, spreadsheets and other business systems through integrations, webhooks or its API. It has run in production since 2016, has processed more than 100 million documents, is hosted in the EU and is SOC 2 Type II compliant. In this test it made no errors in any language, on the two-page invoice or on the photo. It converted the Japanese era date, returned standard dates and plain numbers, and left missing totals empty. Its one weakness was an inconsistent currency format.
Docsumo: 196/200. It read both German pages, kept the Japanese and Korean text intact, and left missing fields empty. It misread the German quantity "1.200" as 1.2 on both German documents, and returned dates and currency as printed.
Airparser: 194/200. The richest default field set of the six (22 fields, including bank details, VAT numbers and payment terms). It missed a German line item because of a quotation mark, invented a subtotal in the photo, and pulled a customer number from the wrong party on the Korean invoice.
Nanonets: 168/200. Correct Japanese and Korean totals, a perfect French invoice and a confidence score per field. It returned no line positions except on the French invoice, no totals on the German PDF, invented totals on the photo, and swapped supplier and customer on the Japanese invoice.
Docparser: 165/200. Strong on the French invoice and the photo. It could not read Japanese or Korean, read only page 1 of the German PDF, and reformatted company and bank numbers as phone numbers. Its output is generic tables that still need mapping to fields.
Klippa: 163/200. The best output format (standard dates, plain numbers, currency codes) and near-perfect on French and German. On Japanese and Korean, numbers came back 1,000 times too small, document titles became supplier names, and the Japanese total was 0.01.
How we tested
Test documents
| Document | What it tests | Fields scored |
|---|---|---|
| German invoice (PDF) | 2 pages, 9 line items, thousands separators ("1.200 Stk"), German quotation marks, a printed tax amount 10 cents off a recalculation | 55 |
| German invoice (phone photo) | Skewed photo of page 1 only, 7 line items, no totals visible | 45 |
| French invoice | 5 line items, 5% discount before VAT, day/month/year dates | 35 |
| Japanese invoice | 5 line items, Japanese era due date (令和8年9月30日), yen | 35 |
| Korean invoice | 4 line items, Korean date format (2026년 10월 12일), won | 30 |
Each invoice was scored on 10 header fields (invoice number, invoice date, customer number, order number, due date, supplier name, currency, net amount, tax amount, total) and 5 line-item fields (position, description, quantity, unit price, line total).
Scoring rules
- The ground truth is the value printed on the invoice, including the €975.08 tax.
- Numbers were compared as values (German "1.200" = 1,200) and dates as calendar dates. Typographic differences such as × and x were not errors.
- A field that is not on the invoice had to come back empty. An invented value counted as an error.
- Any unambiguous currency answer counted (EUR, €, "Euro (EUR)").
- Docparser returns generic tables rather than named fields. A correct value next to its label was credited, which favors Docparser.
- Fields outside this common set, such as bank details and addresses, were not scored.
Limitations
This is a small hands-on test, not a statistical benchmark, and Parseur ran it as one of the tools tested.
- Sample size: five synthetic invoices, each processed once per tool. A gap of a few fields is within what one more invoice could change.
- Accounts: tools were tested on free, trial or demo accounts. Paid plans or custom training may perform differently.
- Setup: Klippa could not be customized in its demo, and Docparser was tested without custom rules. Both could likely improve on European invoices with more setup.
- Scoring: we scored results from screenshots of each tool's output, checked against the source invoices.
How to test an invoice extraction tool on your own invoices
The errors in this test only showed up when we checked line items against the original invoice. Before choosing a tool, run your own invoices through it and check:
- Invoices from your actual suppliers and countries, not one clean sample.
- At least one multi-page invoice and one phone photo or scan.
- Every line item, not just the total: quantities and unit prices are where separator errors hide.
- That fields missing from the invoice come back empty rather than estimated.
- That supplier and customer are not swapped.
- That dates, numbers and currency arrive in the format your system imports.
For the fields worth checking on any invoice, see our guide to invoice OCR.
Test it on your own invoices
Five invoices show where tools break, but your suppliers' documents are the real test. Run your own multilingual invoices through Parseur and check the line items against the originals.
Last updated on





