DEV Community

Cover image for Automating Invoice Intake With Checks a Person Can Verify
Taha Echakiri for NeticsLabs

Posted on Originally published at blog.neticslabs.com

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.

Capture of the impots.gouv.fr page on the 2026 e-invoicing reform, showing the obligation to be able to receive electronic invoices since 1 September 2026 and the approved-platform requirement for issuing.

Capture of the impots.gouv.fr page on the e-invoicing reform (impots.gouv.fr, retrieved 2026-10-11): the state's own description of what changed in September 2026 and which platforms are approved to carry invoices.

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.

AWS's architecture diagram for the AnalyzeExpense flow, showing a document in Amazon S3 triggering a function that calls Amazon Textract and writes extracted invoice data onward to storage.

AWS's own architecture diagram from its AnalyzeExpense walkthrough (aws.amazon.com/blogs/machine-learning, retrieved 2026-10-11): a stored document, a triggered function, the extraction call and the extracted output.

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.

AWS's illustration of the fields returned for a processed invoice, listing extracted line items with their quantities and prices.

AWS's own illustration of line-item output from the AnalyzeExpense walkthrough (retrieved 2026-10-11): the extracted quantities, prices and line text that a verification step then recomputes.

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.

Netics editorial checklist of the four checks that turn extracted invoice fields into a postable entry: supplier identity against the printed SIREN and the vendor record, line totals recomputed and compared, tax treatment matched to the supplier, and duplicate detection with a named approver above the threshold.

Netics editorial diagram: the verification steps that sit between an extraction result and an entry in the ledger, ordered as an accounts payable team works through them.

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.


Originally published on the Netics blog.

Top comments (0)