Your Invoice API Returns Text. We Return the Finished Document.

Short version: most invoice APIs stop at extraction, they hand you fields and leave the joining, checking and formatting to you. We hand back a document that is already structured, already checked against the country's format rules, and already ready for your accounting system. That is a different product, and it is priced differently.


What "extraction" actually means in practice

Ask a typical invoice API for an invoice and you get something like this:

{
  "vendor": "Fitzpatrick and Sons",
  "invoice_no": "12847181",
  "date": "2026-03-03",
  "total": "6860.45",
  "line_items": [...]
}

Clean JSON. Now look at what you still have to do before this is usable:

  1. Match it to your chart of accounts. The API does not know your account numbers. You map "Fitzpatrick and Sons" to a ledger account yourself.
  2. Get it into your accounting system's format. DATEV, your ERP, your bookkeeping tool — the API does not speak those.
  3. Check it against the format rules of the country. Is this a valid ZUGFeRD? Does the Italian e-invoice carry the required SDI code? Does the VAT number match its country format?
  4. Decide what to do with uncertain fields. The API gave you a number. Is it right? It does not tell you.
  5. Handle duplicates, storage, retention, all yours.

That is the real work. Extraction is perhaps a third of the effort of actually booking an invoice.

What we hand back instead

The finished document.

One flow: upload, we analyse, you export. No intermediate collection step. No "now go build the mapping."

Why the source matters more than the model

Most invoice APIs, at the core, do one thing: look at a picture and try to read it. That is why their accuracy plateaus around 90–95%, pictures of invoices are hard.

But a large share of business invoices in Europe are not pictures. They are structured files that already contain every number as data:

Format Country What it is
ZUGFeRD / Factur-X DE, FR PDF with embedded XML, data is inside
XRechnung DE pure XML for public sector
UBL / Peppol EU-wide the BIS standard format
FatturaPA IT mandatory Italian e-invoice
Russian UPD RU ФНС format 5.03

When an invoice arrives in one of these, there is nothing to recognise. The numbers are in the file. Reading structured data gives you 100% on key fields, not 95%.

And that is free with us. Electronic invoices do not consume your quota,, only scans and photos do, because only those actually require recognition. If most of your suppliers invoice electronically, your real costs drop sharply.

The price, plainly

€0.07 per scanned page through the API (the same figure in US dollars for the American market). That is:

Pages You pay
1 000 €70
3 000 €210
30 000 €2 100
100 000 €7 000

An average invoice is about three pages, so an average scanned invoice costs roughly 21 euro cents, and it arrives ready for your accounting system rather than as a bag of fields.

Electronic invoices: no charge.

API access: minimum top-up €8. (For the US market the same numbers apply in dollars: minimum top-up $8.) They cost us nothing to read, so we do not charge for them.

When this is worth paying for

Honestly: if you only need raw text and fields for your own processing, a cheaper extraction API will serve you and cost a fraction. Use it. We are not competing on being the cheapest way to get text.

This is worth paying for when:

What we do not do

The short version, again

An extraction API gives you fields. We give you the document that goes into your books.

Try it: duebuddy.work/api, five pages free, no card required.

Next steps

Related reading

Features

Read also