← Tous les articles

AI in e-invoicing: why the hype can be dangerous in accounting

Publié 15 March 2026

Every second product announcement in the finance space now leads with AI. Some of it is genuinely useful; some of it quietly introduces data-quality problems that nobody notices until a tax audit. The distinction is not the technology — it is where in the pipeline you allow probabilistic output.

Where AI genuinely earns its keep

Some invoice tasks are a great fit for a model, because a human — or a later deterministic check — reviews the result before anything depends on it:

  • Extraction from messy inbound PDFs. Turning a scanned or oddly laid out supplier document into a structured draft is exactly the kind of fuzzy pattern task models are good at.
  • Field-mapping suggestions. Proposing which column is the net amount, which code is the VAT category — as a suggestion the user confirms.
  • Anomaly flagging. “This invoice is 10× the usual amount for this supplier” is a helpful nudge, not a decision.

In each case the model proposes; something else disposes. Mistakes are caught early and cheaply.

Where it must never be allowed to decide

The opposite case is arithmetic and conformance: computing totals, deriving the VAT breakdown, or asserting that a document conforms to EN 16931 and PDF/A-3. Here a model is the wrong tool, and not because it is “not smart enough”. It is because the failure mode is invisible.

The “confidently wrong” problem

A traditional bug tends to fail loudly — a crash, an obviously empty field. A language model fails plausibly: it returns a number that looks right, is formatted right, and is wrong. Downstream, nothing re-checks it, because it looked fine. In accounting a confident wrong value is more harmful than an obvious failure, because it propagates silently into filings and payments.

Determinism is the compliance boundary

This is why eunormia keeps the compliance boundary strictly deterministic. Totals are recalculated server-side from the line items and must reconcile. Every generated invoice must pass a veraPDF check (PDF/A-3) and the EN 16931 business-rule Schematron; anything that would not pass is never delivered. No model is asked to believe the result is valid — it is mechanically proven against the standard, or it is rejected.

A sane architecture

The two ideas are not in conflict; they belong in different places. Let AI do the fuzzy work at the edges — extraction, suggestions, triage — where a human still signs off. Keep a deterministic gate at the core, where correctness is proven, not predicted. Used that way, AI is a capable assistant. It just never gets to sign off on correctness.

Essayer dans le navigateur