Automating Invoice Intake With Checks a Person Can Verify

TL;DR

• Invoice intake automation is the process of reading incoming supplier invoices with software that extracts the fields, then routing each document to a posting or to a person using rules you can inspect.
• French companies now receive invoices in a structured format: since 1 September 2026 every company must be able to receive electronic invoices through a state-approved platform, and large and mid-sized companies must issue through one.
• An extraction model returns the fields of the document with a confidence score for each one, which is a reading of the page and a starting point for checks.
• Four checks carry the weight: supplier identity against the SIREN and the vendor record, line arithmetic recomputed, tax treatment matched to the supplier, and duplicate detection before payment.
• Human approval sits above a threshold on the amount, with a named approver looking at the extracted values beside the source page.
• The measurements that tell you whether it works come from the rejection queue and the corrections, which is where the flow's real accuracy shows up.
• Netics builds this kind of flow as automatic document and invoice processing, and the checks below are the part of the design that decides whether it holds up.

What the French 2026 mandate changes for incoming invoices

The operating context shifted on 1 September 2026. According to impots.gouv.fr, large and mid-sized companies must issue their invoices through a platform approved by the state, and every company must be able to receive electronic invoices. The service-public.fr article on the reform sets the rest of the calendar: small and micro companies must issue electronically from 1 September 2027, invoices travel through an approved platform that each company designates, and four new mandatory mentions appear on the documents.

Structured invoices change the intake problem. The FNFE-MPE explains the format French companies now meet most often: Factur-X is a Franco-German hybrid, readable as a PDF for people and carrying structured data for automated processing, and it is the first implementation of the European semantic standard EN 16931. The reference page records the release the two national forums published on 4 August 2026, Factur-X 1.09.2 / ZUGFeRD 2.5.2, and lists the reference profiles from MINIMUM to EXTENDED. Germany has required business-to-business electronic invoicing since 1 January 2025, so the format is not a French experiment.

A structured payload removes the guesswork about which figure is the total. Suppliers send paper, ordinary PDFs and scans for years to come, so an intake design that reads structured data when it arrives and extraction when it does not covers both worlds.

What an extraction model returns for a supplier invoice

Amazon Textract documents the shape of the answer its AnalyzeExpense operation returns, and that shape is typical of the category. A document produces normalized summary fields, including the invoice identifier, the vendor name, the due date, a purchase order number, the total and the subtotal, and each one carries a confidence score beside the text found on the page. Line items arrive separately with item, quantity and price as normalized fields, and any remaining text on the line stays attached as an expense row. AWS notes that the service works with any style of invoice or receipt with no templates or configuration.

Two details in that design reward attention. The first is the confidence score: it describes how the model read a value, which helps ordering a queue and carries no accounting authority. The second shows up in the walkthrough's treatment of labels: a vendor name can be recognised without an explicit key, which is how the service finds the supplier when the name appears inside a logo at the top of the page. Nice for recall, awkward for verification, because the value arrives without a label to compare against.

The four checks that decide whether a field becomes a posting

Extraction produces a reading; a posting needs evidence. Four checks connect the two, and each one compares an extracted value against a record the company already holds.

Supplier identity comes first, because everything downstream inherits it. The extracted name is matched against the vendor record, and the SIREN printed on the document is compared with the one held for that supplier. A mismatch sends the document to a review queue.

Arithmetic comes second, and it is the cheapest check available. Quantity multiplied by unit price has to equal the line, and the lines have to add up to the total the supplier claims. Recomputing that in code catches the transcription errors that extraction introduces and the price disagreements that suppliers introduce, and it needs no model at all.

Tax treatment comes third. The extracted rate is compared with the treatment held for that supplier, and the reform's new mandatory mentions give that check more to work with: the client SIREN, the delivery address when it differs from the billing address, the category of the operation and the VAT-on-debits option.

Duplicates come last and matter most, because a duplicate that reaches the payment run costs cash. Supplier, invoice number and amount give a stable key, and a flagged match goes to a person with the earlier entry attached.

Where the human approval sits in the flow

Approval belongs at the amount, and it works when the approver sees the extracted values next to the source page. A threshold expressed as a value turns the review step into a decision about money, and the reviewer can compare the two images side by side.

Two rules keep that step honest. Every automated decision keeps its inputs, so a posting can be explained months later from the extracted values, the records compared and the rule applied. Every rejection carries a reason, which turns the queue into a source of corrections.

What to measure in the first quarter

The numbers worth tracking come from the exceptions. Count how many documents clear all four checks with no human touch, how many need a correction, and how many the flow refuses. A rate near the top of a vendor's accuracy claim usually counts characters or fields, and the useful version counts documents that reached a posting without a person fixing something.

Keep the SIREN check on a maintained vendor record, because its value depends on the data behind it. Track the corrections by field, since a queue that fills with tax disagreements points at a supplier master-data problem and one that fills with amounts points at document quality. Read supplier complaints as signal as well: a supplier whose invoices keep landing in the queue is telling you something about its own templates.

None of that needs a large project. A single intake flow with four checks, one queue and one threshold covers most of what a small finance team meets, and it grows one added check at a time. The Netics approach to automatic document and invoice processing follows the same order: read the document, verify against records you hold, and leave the decision above the threshold with a person.

If you want a second opinion on where those checks should sit for your volumes, book a free 30-minute audit and bring the document types that cause the most rework. That conversation is usually enough to tell which checks earn their place in the first release.

Sources

Source: Analyzing Invoices and Receipts — docs.aws.amazon.com/textract, Amazon Textract developer guide, retrieved 2026-10-11 (invoices and receipts are processed with the AnalyzeExpense operation and the operation returns the entire set of results; normalized summary fields including INVOICE_RECEIPT_ID, VENDOR_NAME, DUE_DATE, PO_NUMBER, TOTAL and SUBTOTAL; a confidence score beside each value).

Source: Announcing expanded support for extracting data from invoices and receipts using Amazon Textract — aws.amazon.com/blogs/machine-learning, AWS Machine Learning Blog, retrieved 2026-10-11 (any style of invoice or receipt processed with no templates or configuration required; responses containing ExpenseDocuments, each with SummaryFields and LineItemGroups; ExpenseIndex associating fields and line items to one expense; LabelDetection as an optional key, with implied values such as a vendor name recognised without an explicit key, including a name inside a logo; Type carrying the normalized category, with OTHER for values outside the taxonomy; ValueDetection holding the value; line items exposing ITEM, QUANTITY and PRICE with the remaining line text returned as EXPENSE_ROW; a published parser library for reading the response in application code).

Source: Je passe à la facturation électronique — impots.gouv.fr, Direction générale des Finances publiques, retrieved 2026-10-11 (since 1 September 2026 large companies and mid-sized companies issue their invoices through an approved platform, and all companies must be able to receive electronic invoices; each company designates the platform it uses to issue and receive invoices or to report its data).

Source: Facturation électronique : c'est pour bientôt ! — entreprendre.service-public.gouv.fr, retrieved 2026-10-11 (the obligation to receive electronic invoices applies to all companies from 1 September 2026, the obligation to issue to large and mid-sized companies from 1 September 2026 and to small and micro companies from 1 September 2027; invoices transmitted through a platform approved by the state, directly or through a compatible solution; four new mandatory mentions covering the client's SIREN, the delivery address when it differs from the billing address, the category of the operation, and the VAT-on-debits option).

Source: Factur-X — fnfe-mpe.org, FNFE-MPE reference page, retrieved 2026-10-11 (a Franco-German hybrid electronic invoice standard, readable as a PDF for people with structured data for automated processing, and the first implementation of the European semantic standard EN 16931 published by the European Commission on 16 October 2017; the same standard as ZUGFeRD 2.5; the release published on 4 August 2026 as Factur-X 1.09.2 / ZUGFeRD 2.5.2 by the FNFE-MPE and the German FeRD forum; reference profiles including MINIMUM, BASIC_WL, BASIC, EN 16931 and EXTENDED; German business-to-business electronic invoicing mandatory since 1 January 2025).

Source: Amazon Textract, impots.gouv.fr, service-public.fr and the FNFE-MPE — documentation and public pages on invoice extraction and the French e-invoicing reform, retrieved 2026-10-11. Figures from those pages; images are AWS's own diagrams and a capture of the impots.gouv.fr page, plus two Netics editorial diagrams.