E-invoice receiving: what automation must do before posting

An e-invoice rarely arrives as an invoice. It arrives as a mailbox attachment, a file pulled from a supplier portal, a PDF in a shared folder, or a structured document pushed at an endpoint — and until receiving establishes who sent it and what it refers to, no rule downstream can be trusted. E-invoice receiving process automation turns those arrivals into one record with a known state. Skip it and every later stage inherits the ambiguity.

Why does receiving decide whether invoice automation works?

Posting, matching and approval assume a stable record: one supplier, one order reference, one currency, one set of lines. An automated invoice management system does not get that record from the document; receiving builds it. When receiving is a mailbox a clerk opens in the morning, the record is what the clerk remembered to type.

The test is short. Ask which supplier sent last month's invoice, which order it belongs to, and whether a copy exists. If the system cannot answer from stored data, nothing was automated.

What are the arrival paths an invoice actually takes?

Most businesses run three or four paths at once, each failing differently. Treating them as one inbox is the first mistake, because the same document arriving twice looks like two invoices.

Arrival path	What arrives	What breaks first
Email to a shared mailbox	an attachment, often a scan	no owner, no link to the supplier record
Supplier portal download	the right file, pulled by hand	nobody notices the portal is holding an invoice
PDF dropped in a folder	an export, no context	the file name is the only metadata, and it is wrong
Structured file to an endpoint	named fields, on arrival	the endpoint accepts anything, including a truncated file

A supplier uses whichever path is easiest and changes it without notice, so receiving has to cover the paths that exist.

What has to be read off the document before anything else happens?

Six things, each failing later:

• Supplier identity. Legal name, tax identifier and bank details are separate facts. Matched on name alone, two similar suppliers merge and the wrong one is paid.
• The order reference. The buyer's number, not the supplier's document number. Without it, matching becomes a search by amount — a guess dressed as a rule.
• Issue date and due date. Separate fields: the first drives the accounting period, the second the payment run.
• Currency and its basis. An invoice in another currency needs the rate and its source recorded at receiving, not rebuilt from a table that has moved.
• Tax breakdown. Tax per rate, and which lines carry which rate. A single total can be checked against nothing.
• Lines. Description, quantity, unit price, line total. Price and quantity exceptions are found here, so lines must not collapse into a total.

What is not read here is rebuilt by a person during a dispute — the hidden cost of a scanner-scoped receiving step.

What is the difference between a structured e-invoice and a scan?

A structured e-invoice carries its fields under agreed names, which is what the OASIS UBL invoice standard exists for: the document becomes business terms — supplier party, order reference, tax total, invoice line — rather than a layout to interpret. Receiving one is a parsing job against a schema, and a failure is a named missing term.

A scan has no field names. Extraction guesses, and every guess carries a confidence. Receiving holds that confidence per field and routes on it: a supplier name read with certainty proceeds, a total read with doubt waits for a person. Flattening confidence into a "processed" flag discards the signal that would have stopped a wrong posting.

A structured file can be re-validated against its schema later; a scan can only be compared with the image it came from, which is why that image is kept unchanged.

Why do duplicate supplier invoices still get paid?

Because the check compares the wrong thing. Amounts catch almost nothing, since one supplier may legitimately issue several invoices for the same amount in a week. File names catch nothing at all.

Two keys are needed. A fingerprint of the file catches an attachment forwarded twice. A business key built from the supplier's tax identifier, invoice number, issue date and total catches what a supplier cannot repeat without issuing a duplicate. Both are computed at receiving, before approval.

The hard cases look like duplicates and are not: a credit note mirroring an invoice, a corrected invoice replacing one posted under the same number, a supplier who restarts numbering in a new year. A step that cannot separate these either blocks legitimate documents or lets a duplicate through.

How should the receiving step be built?

1. List the arrival paths and name an owner for each. A mailbox without an owner is a queue nobody measures.
2. Give every path one entry point that writes a single record, so the pipeline never learns where the document came from.
3. Fix the minimum field set, and decide in writing what happens when a field is absent: reject with a reason, or hold.
4. Store the source document immutably, with its fingerprint, apart from the extracted data. The document is evidence; the fields interpret it.
5. Version the extracted data, keeping what changed and what caused it. That provenance is what the W3C data on the web best practices describe, and what makes a correction explainable.
6. Route on state, not on inbox. Received, validated, waiting on the supplier, ready to post — each state visible to whoever owns the next step.

That last step sounds like reporting; it is the constraint, since without stored state every question is an email search.

Where this goes wrong

Treating extraction as receiving. Pointing a recognition service at the accounting system is the shortest demo and the weakest build: fields with no supplier record, no duplicate key, no state.

Matching supplier names as strings. One supplier appears as a Latin name, an Arabic name, an abbreviation and a name with another legal suffix. Without a master with aliases and a review step, it is recreated every quarter.

Accepting whatever the endpoint receives. A receiver that parses any file will accept a truncated document and post a partial invoice. Validate at the door, naming the missing term.

What this does not cover

This is a technical structure, not a compliance position. What is acceptable, what makes a tax identifier valid and when an invoice may be deducted belong to the accounting and legal side in each country, and those rules change; nothing here states a national e-invoicing requirement. The EU e-invoicing building block is a reference for what a receiving service exposes at its edge, not a template to copy. A paper invoice with no usable digital copy stays manual.

We build the receiving step before the matching rules, because a pipeline starting from an unverified record spends its budget correcting data instead of removing work.