Automating supplier invoice processing with AI

Why supplier invoices are still handled by hand

In many organisations, a supplier invoice has followed the same path for years. A PDF lands in a shared mailbox, someone opens it, copies the number, date, net amount, VAT and supplier into the accounting software, then goes looking for the purchase order. If the order exists, they still need to check that the goods were received or the service delivered. Then comes a manager's signature, often obtained after a reminder, and finally payment.

Each step is simple. The cost lies in the chain: switching between the mailbox, the ERP and the tracking spreadsheet, duplicate invoices, forgotten credit notes, disputes discovered at payment time. Accounts payable spends its time looking for information instead of checking it.

AI can take on a good share of that searching. It replaces neither internal control nor the accountant's responsibility. This article shows where it fits in the chain, what it must produce, and what must stay with deterministic software or a person.

What mandatory e-invoicing changes

The question now comes with a regulatory constraint. According to impots.gouv.fr, from 1 September 2026 all French companies, whatever their size, must receive their invoices in electronic form whenever their supplier is required to issue them in that format. From that same date, large companies and mid-sized companies must issue their invoices electronically and transmit their transaction and payment data to the tax authority electronically. From 1 September 2027, the issuing and transmission obligation extends to small and medium-sized companies and micro-enterprises.

In practice, a growing share of your supplier invoices already arrives in a structured, machine-readable form. That is good news for automation: when data arrives clean, there is nothing left to read off an image. But the switch is gradual. For a while you will receive structured e-invoices, PDFs emailed by foreign or out-of-scope suppliers, and some paper. Whatever you build must accept all three inputs and bring them into one internal format.

To know exactly what applies to your company, the French administration offers a four-question check (size, customer base, type of activity, VAT regime). Do it before designing anything: it sets your obligations, not your tool.

Step one: collect through a single entry point

The first source of disorder is dispersion. Some invoices reach the buyer, others the executive assistant, others go straight to the accountant. Before any AI, set a rule: every supplier invoice enters through one channel. That can be the reception platform chosen for e-invoicing, a dedicated email address, or a drop folder for scans.

Behind that entry point, a first automated pass does three things:

• Identify the document type: invoice, credit note, reminder, quote sent by mistake, delivery note. A language model sorts these very well from a PDF or an email.
• Detect duplicates: same supplier, same number, same amount. This rule is deterministic and needs no AI.
• Timestamp and archive the original before any transformation. That document is the reference, not what the machine extracted from it.

This first level looks modest. Yet it removes many of the "did we receive it?" questions and gives everyone a single queue to look at.

Step two: extract the fields, and know when extraction is reliable

For a structured e-invoice, extraction is a file read: the fields are already named. For a PDF or a scan, this is where AI adds the most. A multimodal model reads the invoice as a person would and returns a structure: supplier, number, date, due date, lines, quantities, unit prices, VAT rates, totals, bank details, order reference.

Three precautions separate a prototype from a production tool:

• A strict output schema. The model fills typed fields, with an empty value allowed when information is missing. Never free text to be interpreted later.
• Server-side arithmetic checks. Line totals must add up to the net amount, VAT must match the rates applied, the gross total must be consistent. Your code does these calculations, not the model. If the extraction fails these checks, the invoice goes to human review.
• A check against the supplier master data. The extracted VAT number, company ID and above all the IBAN are compared with the existing supplier record. An IBAN that differs from the known one must never pass automatically, however confident the model is. This is the classic bank detail change fraud.

This is the rule we apply everywhere: whatever commits the company is calculated or verified by the system, the model only proposes. We explained it for prices in why an AI agent must never quote a price; it holds just as well for an amount to be paid.

Step three: check consistency with the order and the receipt

Matching is the heart of supplier control. People often speak of three-way matching: the invoice is compared with the purchase order (what was requested, at what price) and with the receipt (what was actually delivered or confirmed). Done by hand, it is often partial for lack of time.

Automated, it breaks down like this:

• Find the order. If the invoice carries an order reference, this is an exact lookup. Otherwise AI can suggest candidate orders from the same supplier based on descriptions and amounts. It suggests, a person confirms the first time, and the link is remembered.
• Compare line by line. Invoiced quantities against ordered and received quantities, unit prices against negotiated prices. These comparisons are rules, with tolerances you set yourself according to your purchasing policy.
• Describe the gap. When there is a gap, AI is useful to explain it in plain language: partial delivery, unplanned shipping costs, forgotten discount, price increase. That explanation travels with the invoice to the person who decides.

For invoices without an order (subscriptions, overheads, recurring services), matching is done against a contract or a history. Again, the rule detects the gap and AI describes it.

All this assumes your order and receipt data are accessible. If receipts are not recorded, or live in a separate spreadsheet, that is the first job. It is data integration work before it is AI work.

Step four: an approval flow that no longer depends on reminders

An invoice that matches its order and receipt often needs no new signature: the order was already approved. That is a management decision to make with your finance team, not a technical setting. Many organisations approve the same spend twice out of habit.

For the rest, the flow is built on explicit rules:

• who approves by cost centre, supplier or type of spend;
• above which amount a second signature is required;
• who stands in for an absent approver;
• how long before a reminder, then an escalation.

The approver receives the invoice with everything needed to decide without opening another tool: the original document, the linked order, any gap explained in one sentence, the supplier's history. They approve, reject or ask a question, and the answer is recorded. AI approves nothing. It prepares the file.

This is often where teams gain the most comfort, because reminders become automatic and accounting can see where every invoice stands at any time. Which tool should carry this flow depends on your environment: we discussed it in Make, Zapier or custom.

Step five: posting to accounting

Once approved, the invoice must become a journal entry. Two questions arise: coding (expense account, supplier account, VAT code, analytical axis) and how it gets into your accounting software or ERP.

For coding, AI can suggest an account and an axis from descriptions and the supplier's history. This helps when the chart of accounts is detailed and descriptions vary. It should stay a suggestion until the correction rate you observe is judged acceptable by the head of accounting. For recurring suppliers, a fixed rule does better and costs less than a model call.

For posting, favour your software's official interfaces (API, import in the vendor's format) over simulated screen entry. Every generated entry carries a reference to the original invoice and to the approval trail. If your software has no interface, a structured export reviewed by the accountant before import remains a sound option.

One often overlooked point: payment. The transfer file must never be built from data extracted by the model. It relies on the verified supplier record and the approved amount.

Exceptions, where quality is decided

An automation is judged less on simple invoices than on how it handles the rest. List them from the start and give each one a human review queue:

• New supplier: record created with document checks, never automatically.
• Bank detail change: verification outside the invoice channel, for example a call back to the known contact.
• Credit notes: matched against the original invoice, not an order.
• Multi-order or multi-site invoices: split suggested, confirmed by a person.
• Foreign currencies and VAT reverse charge: tax rules applied by code, reviewed by the accountant.
• Unreadable or incomplete documents: sent back to the supplier with a precise request, which AI can draft.

The general rule is simple: when the system is unsure, it says so and hands over. A false negative (an invoice sent to review unnecessarily) costs a few minutes. A false positive (an invoice paid wrongly) costs far more. Set your thresholds accordingly and revise them based on what you observe. We cover this cautious approach in automating a repetitive task without breaking anything.

Traceability: being able to replay everything

Accounts payable gets audited. Your auditor, internal control or the tax authority must be able to understand why an invoice was paid. An automated setup must therefore produce a full trail for each invoice:

• the original document, timestamped, kept unchanged;
• the extracted fields, with the model version and rules used;
• the outcome of each check, passed or failed;
• every human action: who, when, which decision, which comment;
• the reference of the journal entry and of the payment.

This trail also improves the system. Corrections made by accountants are the best source for adjusting rules and model instructions, provided they are recorded in a usable way.

On the data side, invoices contain information about your suppliers and sometimes about individuals. Choose hosting and a model provider that meet your requirements, and document the flows. Our approach is set out on the responsible AI page.

Where to start, in practice

A project like this is run in stages, in production as early as possible, on a narrow scope. Here is the sequence we follow most often:

• Observe the real flow for a few days with the accounting team: where invoices come from, where they get stuck, which errors recur.
• Pick a first scope: a family of recurring suppliers, with orders and receipts available.
• Build single collection and extraction, without posting anything to accounting. Compare results with manual entry.
• Add matching and the approval flow, then posting once the team trusts the checks.
• Widen supplier by supplier, adding exceptions as they come.

This is exactly the kind of engagement an engineer deployed on your premises can carry, working directly with accounting. We describe that role for finance on the finance FDE page, and the overall method on the workflow automation page. If you are torn between a quick prototype and a production tool, read business POC: isolating production prerequisites.

The mistakes we see most often

• Automating extraction and stopping there. Data entry disappears, but matching and approval stay manual. The gain is small and the team wonders why.
• Letting the model calculate. A total recomputed by a language model can be confidently wrong. Calculations are code.
• Ignoring supplier master data. Without a clean reference, no IBAN or company ID check is possible.
• Handling exceptions later. They show up in the first week, and they decide how much the team trusts the tool.
• Building without the accountant. They know the traps of the flow better than anyone, and they will sign off the go-live.

Taking stock of your flow

E-invoicing forces you to rethink how you receive invoices anyway. It is the right time to decide how far you want to automate what follows: matching, approval, posting. If you would like an outside view of your current flow and of what can be automated without losing control, start with our AI diagnostic: we look at your real flows and you leave with clear priorities.

Sources

• impots.gouv.fr: When am I affected by the e-invoicing reform? (in French)
• impots.gouv.fr: What does e-invoicing change for me? (in French)

Frequently asked questions

Should we wait until all our suppliers send e-invoices before automating?

No. The setup should accept structured invoices, PDFs and scans from day one and bring them into a single internal format. E-invoices simply make extraction more reliable. Starting early also lets you use the transition period to clean up your supplier master data.

Can AI replace our e-invoice reception platform?

No, they are two different things. The platform handles regulatory reception of invoices. The automation we describe plugs in behind it to process those invoices through to accounting and payment.

Our ERP already has a matching module. What does AI add?

The module applies rules to data that is already clean. AI works upstream and alongside: reading unstructured documents, suggesting the order when the reference is missing, explaining a gap in plain language, drafting a request to the supplier. Often the right setup keeps matching in the ERP and feeds it better data.

How do we stop a fraudulent invoice from being paid automatically?

By forbidding any payment based on bank details extracted by the model. The IBAN used always comes from the verified supplier record, and any mismatch with the invoice blocks the file. Bank detail changes follow a separate verification procedure, outside the invoice channel.

Who should own this project internally?

The finance department, with the head of accounting as day-to-day lead. Purchasing must be involved, since matching depends on the quality of orders and receipts. IT handles access and integration without being the main owner.