First the twist, because it rearranges everything
The international write-ups say invoice scanning is worth it because it turns paper into data. In the European Union that is only half true — and how true depends on which country you are in, not on which software you buy.
One question decides everything: does the tax authority give you back your supplier's data, or only your own. Where it does, OCR is largely wasted work on domestic invoices. Where it does not, OCR is the input itself, and there is nothing to replace it with. The two situations exist side by side on the same continent, in the same year. Open the one that applies to you:
Hungary — the tax authority already has your supplier invoice data
According to the Hungarian tax authority's own guidance, the benefits of the electronic VAT system include direct access to the transaction-level data held by the authority — online invoice data, till receipts, customs documents — and that as the recipient of an invoice you are exempt from the separate domestic summary reporting (VAT Act, Annex 10, point 15).
And this is not only available through a web portal. The authority's material on the machine-to-machine interface says that the transaction data it holds can be reached inside the taxpayer's own company system. The machine interface is not reserved for the largest either: according to the authority it is open to those with fewer than one hundred thousand invoices in a reporting period, provided their bookkeeping is already digital.
Two further benefits from the same direction, both measurable in money and in risk: no self-revision surcharge is payable where a taxpayer filing through the machine interface submits the self-revision within fifteen days of filing, or at the latest of the due date; and the authority may not audit a reliable taxpayer's VAT return filed through the machine interface for fifteen days (the moratorium does not apply in cases of concealed revenue or false documents).
Two recent dates belong here too: on 3 August 2026 the authority introduced a new machine-interface schema, and from 1 September 2026 data must also be reported on receipts that were not issued by an online or electronic till.
What does that mean in practice? The data on a domestic, VAT-registered supplier invoice is already with the authority, because your supplier sent it. The value of OCR here is not producing the VAT data, but three other things: the documents that are neither domestic nor VAT-registered (foreign supplier, pro forma invoice, receipt, a document that is not an invoice), the line items at the level of detail your own accounting needs, and the information that stays with the document — contract number, project code, delivery note reference.
Worth knowing that Hungary ran ahead here: the other member states are building now what has been live there since 2018.
Spain — the tax authority hands back your own ledger, not your supplier's
What is already in force is the SII. Since 1 July 2017, anyone filing VAT monthly — turnover above 6,010,121.04 euros, the REDEME register or a VAT group — sends their invoice records to the tax agency in near real time. In exchange, two annual returns disappear. Most SMEs, however, are not in the SII, and that decides everything that follows.
And here is the twist, because it works the other way round from what you would assume. The SII has a machine-to-machine query service, not only a submission one — but what it returns is your own, already declared ledger, a matching status (from "not applicable" to "reconciled"), and, where there is a difference, your counterparty's aggregate amounts. What it never returns: your supplier's full invoice, its line items, or an invoice you have not yet recorded.
Two consequences follow, both measurable in money and in risk: the authority's data does not replace data entry — in Spain you cannot build your received-invoice ledger from what the agency holds, only audit it; and matching only works if your supplier is in the SII too — if they are not, and most SMEs are not, the status of that invoice is "not applicable" and the administration says nothing about it.
Two clocks that have both moved. Verifactu (RD 1007/2023) was postponed twice: corporate income tax payers now have until 1 January 2027 and everyone else until 1 July 2027 — and it does not reach anyone already in the SII. The B2B e-invoice under the Crea y Crece act finally has its implementing decree (RD 238/2026), but the clock starts with a ministerial order that has not been published to date.
What does that mean in practice? In Spain invoice reading is not redundant: it is the input. And it pays off most in three specific places: receipts and simplified invoices, which are only deductible if they carry your tax number, your address and the VAT amount separately — spotting the one that will not do while you can still ask for a full invoice is worth more than typing it in; the line items, which the administration never gives you; and the information that stays with the document.
And there is one Spanish element that enters the calculation directly and does not exist in most neighbouring countries: certified digitisation. With software approved by the tax agency (Orden EHA/962/2007) you may dispose of the paper originals, and the agency publishes and maintains the list of approved products. If you keep boxes of paper today because you have to, that cost disappears — and it is the only line in this article that is pure saving, with no argument about accuracy.
The direction of travel, though, is one-way. Under the VAT in the Digital Age package — Council Directive (EU) 2025/516 — cross-border B2B digital reporting starts on 1 July 2030, and the alignment of domestic systems runs until 1 January 2035.
Until then, two things are worth keeping in mind anywhere: these interfaces change — schema versions get replaced with a transition window measured in months, so whatever you build against one, build it so the schema can be swapped — and the scope widens rather than narrows: obligations that started with invoices get extended to other documents, receipts among them, usually with a few months' notice. Before you plan a year ahead, check what is being added in your own country.
What exactly it reads out
Odoo's documentation — unusually — lists the recognised fields one by one:
| Where | Fields |
|---|---|
| Header | vendor, invoice reference, invoice date, payment reference (Belgian format only), recipient bank, due date, currency |
| Line items | product name or description, quantity, unit price, tax, net amount, total |
Three things follow from that list:
The VAT number is not on it. The vendor field means vendor identification, but the documentation does not claim it reads out a tax identification number. That matters, because the VAT number is mandatory content for deducting input VAT — treat it as missing rather than assuming it is there.
It does recognise line items — but that is the part where the literature says most of the errors are (see below).
With a new vendor there is always a manual step. According to the documentation, if the vendor is not in the database, the field is left empty.
Three of the practical settings matter:
- Input routes: dragging a file onto the journal, an email alias, or the document manager's alias. Format limit: through the alias only PDF and XML are processed, JPEG only goes through the document manager's alias.
- Automatic posting per vendor: always, never, or — and this is the best setting — "ask after three flawless checks". That is the vendor's own recommendation, and it is precisely one built-in human approval gate.
- The "one line per tax" setting: if you switch it on, one line is created per tax rate regardless of how many lines the invoice has. It speeds things up, but you lose the line-level data.
How accurate is it? The vendor does not say
Having gone through the official documentation and the service catalogue: Odoo publishes no measured accuracy, error rate or benchmark anywhere for invoice reading. That is itself information.
What the independent literature says about the task:
The task splits in two. The academic benchmark that defines this field (6,700 annotated real business documents, 55 annotation classes) treats header field extraction and line item recognition as separate tasks, describing the latter as an "extremely practical information extraction task" where the key information has to be assigned to the elements of a table. The line item is the hard case.
Even the best model is not flawless. On a continuously updated document understanding leaderboard — and this has to be written out: the operator of the list appears on it with its own model, in first place, so this is not an independent measurement — the leaderboard's top score overall is 85.9 and the twenty-sixth place is 41.9. A two-fold difference. The sentence "AI reads the invoice" means nothing on its own: it depends on the model.
And what you cannot derive from this: that "Odoo's OCR is X per cent". The service behind it is classical image recognition, not a multimodal language model, and it does not appear on that leaderboard. The two are not comparable.
The arithmetic — this is the backbone of the article
There is no sourced number for "AI speeds up accounting by X per cent". What there is: a formula you put your own numbers into.
N = incoming invoices per month [pcs]
t_man = time to key one invoice by hand [min]
t_check = time to review one extracted invoice [min]
p = share of invoices that need a fix [0..1]
t_fix = the EXTRA time of one fix [min]
B = hourly cost of the person keying [€/hour]
C = unit price of the credit [€/document]
Saving per invoice: Δt = t_man − (t_check + p · t_fix)
Hours saved per month: H = N · Δt / 60
Net saving per month: M = H · B − N · C
The first surprise: the price of the credit does not matter
[Own calculation] The minimum time saving that pays for the credit: Δt_min = 60 · C / B.
| Hourly cost | €0.15/doc | €0.12/doc | €0.10/doc | €0.05/doc |
|---|---|---|---|---|
| €10/hour | 54 s | 43 s | 36 s | 18 s |
| €15/hour | 36 s | 29 s | 24 s | 12 s |
| €20/hour | 27 s | 22 s | 18 s | 9 s |
| €30/hour | 18 s | 14 s | 12 s | 6 s |
If the extraction saves more than a minute per invoice, the credit has paid for itself in every combination in the table. So the question is not the price. The question is whether checking is faster than keying.
The second surprise: the tolerance is surprisingly wide
[Own calculation] Let manual keying be three minutes on a simple invoice. How far is extraction still worth it? The threshold: p_max = (t_man − t_check) / t_fix.
| Review | Extra time of a fix | Max. error rate where it still pays |
|---|---|---|
| 1 min | 2 min | always worth it |
| 1 min | 4 min | 50% |
| 1 min | 8 min | 25% |
| 1.5 min | 4 min | 37.5% |
| 2 min | 4 min | 25% |
| 2 min | 8 min | 12.5% |
Two lessons. One: even at a 25–50% fix rate you can gain time — provided the fix is cheap, that is, rewriting one field. Two: line items kill the calculation. If the error is in the line items and has to be reconciled against a purchase order, the fix is not 2–4 minutes but 8–15 — and there the threshold drops to 12–25%. That is why header fields and line items have to be treated separately.
And the worked example
[Own calculation] Assumptions: 200 invoices a month, manual keying 3 minutes, review 1 minute, fix rate 30%, fix 4 minutes, hourly cost €15, credit €0.12.
Δt = 3 − (1 + 0.30 · 4) = 0.8 min/invoice
H = 200 · 0.8 / 60 = 2.67 hours/month
M = 2.67 · 15 − 200 · 0.12 = 40.00 − 24.00 = €16.00/month
Over a year that is 32 hours and 192 euros. Four working days and the price of a mid-range subscription. That is not much.
Now fix two numbers — let the extraction be more accurate (10%) and the reviewer more practised (half a minute):
Δt = 3 − (0.5 + 0.1 · 4) = 2.1 min → H = 7 hours/month → M = €81/month ≈ €972/year
A five-fold difference, and all that changed was the accuracy and the discipline of the review. That is the message of this article: the tool does not decide, the amount of reaching back in does.
The honesty point: this calculation does not include the one-off cost of adoption — configuration, cleaning up the vendor master, learning — nor the fact that the error rate is higher in the first months. At a company doing 200 invoices a month, the lower scenario does not pay for itself in the first year.
The measurement scheme you can actually run
- Baseline, without AI: key 20 invoices by hand, with a stopwatch. That is the median manual time.
- Switch the digitisation on — on request, not automatically.
- 20 invoices with extraction: measure the review time separately, and note how many needed fixing and for how long.
- Note what went wrong, field by field — vendor, date, amount, tax, line item.
- Work out the saving. If it is negative, switch it off — and that is a result too.
Bank reconciliation and anomaly detection: less AI than you would think
Bank matching is a chain of rules, not machine learning. If the transaction has no partner assigned, the system compares the payment reference against the numbers and references of existing documents; if there is a partner, it matches on amount, in a defined order: exact match, then discounted match (where an early payment discount applies), then looking for the amount in the payment reference. The additional rule models also use regular expressions, and their order matters: if several models would match, the first one runs.
I found no measured automatic matching rate — neither from the vendor nor independently. Success depends on the quality of your own data: on whether the invoice reference is in the payment reference at all. That, however, is measurable in your own system.
Duplicate detection is rule-based too: amount, date and invoice number, or with a bank synchronisation the transaction identifier.
For "unusual amount" style anomaly detection, on the other hand, there is no documented built-in feature. That is worth saying out loud, because many write-ups imagine AI there.
What you can build yourself, though: an AI server action. The logic is the same as with every agent: the AI decides which tool to call; the tool is a conventional server action you wrote, which does the actual checking. You write the checking rule into the code — for example: an amount above twice the twelve-month average for that vendor, or an invoice reference already seen in the last 90 days. Two things have to be declared by hand: the tool's schema (what the AI gets to pass) and the rule itself. Whatever you do not declare in the schema, the AI cannot pass on. On the division of roles, AI Inside Your ERP goes into more depth.
Who is responsible when the machine read it?
The question is legally misframed. VAT law does not ask who typed the data in.
Article 233 of the VAT Directive requires that from the moment the invoice is issued until the end of the storage period, the authenticity of its origin, the integrity of its content and its legibility be ensured. And it says how: by any business controls which create a reliable audit trail between the invoice and the supply of goods or services. And this has to be satisfied by the issuer and the recipient alike, independently of each other.
The point of a business control is that the invoice is checked inside the business and accounting process, not as a standalone document — and what it primarily looks at is whether the transaction on the invoice actually took place, in the quantity and quality stated. That is the reading tax administrations across the Union publish, and it follows straight from the words "reliable audit trail between an invoice and a supply".
The AI cannot do that. It cannot check whether the goods arrived. Only the person who took delivery can. OCR replaces the keying, not the checking. Anyone who switches on automatic posting without someone comparing the invoice against the supply is not saving time, they are skipping a legal requirement.
That is why the "ask after three flawless ones" setting is good: it does not trust the extraction, it trusts the process.
On storage, briefly: an electronic invoice has to be kept in electronic form, by issuer and recipient alike. And a detail many people do not know: where national law prescribes a data structure for handing over stored invoice data during a tax audit, that rule generally applies to every invoice kept in electronic form, not only to electronic invoices — so to the scanned paper invoice as well. The storage period and the technical rules of digital archiving are national law; look them up, they are not in the directive.
Two methods are accepted by the directive itself for the authenticity of origin and the integrity of content: an invoice carrying a qualified electronic signature, and an invoice created and transmitted as EDI. With those, no separate business control is needed to satisfy those two conditions.
What to take away
Invoice scanning does not save where the international marketing claims it does: where real-time reporting is in force, the domestic VAT data is already at the authority, and EU law is moving everyone that way. Where it really does save: on foreign and non-VAT documents, on line items, and on the information that stays with the document.
The price of the credit is practically never the deciding factor — half a minute of saving already covers it. The deciding factor is the error rate and the discipline of the review: the same process shows a five-fold difference in return depending on how much you have to reach back in. And the vendor will not measure it for you: the five-step scheme above gives you your own number from forty invoices.
Responsibility, on the other hand, cannot be shared with the machine. The business control stays yours — the AI only takes the typing off you.