E-invoicing mandates are an AP architecture change

Most AP automation programmes were built to solve a document problem: invoices arrive as PDFs and paper, so you buy capture software, train extraction models, and staff a validation queue for whatever the OCR got wrong. The European e-invoicing mandates quietly remove the premise. When an invoice arrives as a structured, EN-compliant payload, there is nothing to capture. The header, the line items, the tax categories, and the payment references are already machine-readable fields.

That sounds like a simplification, and in one sense it is. But an AP pipeline designed around document interpretation does not automatically get better when the document disappears. It gets bypassed. The mandates are best read as a forced re-architecture of the intake and coding layers, on a timetable set by tax authorities rather than by your roadmap.

Germany makes the timetable concrete. Since 1 January 2025, all domestic B2B recipients must be able to receive structured e-invoices. Issuance stays transitional through 31 December 2026, then becomes mandatory from 1 January 2027 for businesses with prior-year turnover above €800,000, and from 1 January 2028 for all businesses in domestic B2B. France is moving through its own reform toward mandatory structured exchange and e-reporting, and the EU’s ViDA package pushes the same direction at transaction level: structured invoice data validated for reporting readiness, not only for AP posting.

Intake stops being capture and becomes ingestion

The German market runs on two practical formats. XRechnung is pure structured XML. ZUGFeRD is a hybrid: a PDF/A-3 container with the structured invoice embedded inside it. Both demand that your intake layer parse line-level, tax, and master-data fields directly rather than reconstructing them by OCR from a rendered page.

The architectural consequence is a split pipeline:

• A parser lane for structured payloads. Schema validation against the EN standard, syntax checks, and field-level plausibility checks run at the moment of ingestion. A schema failure is a rejection with a precise reason, not a low-confidence extraction sent to a human.
• A capture lane for everything else. Paper, free-form PDFs, and cross-border invoices from jurisdictions without a mandate still need extraction. This lane shrinks over time but does not vanish, and it should share downstream validation with the parser lane so the two paths converge on one canonical invoice record.
• One canonical record. Whatever the source, the pipeline should emit the same internal representation, with provenance recorded per field: parsed from XML, extracted with a confidence score, or keyed by a human. Downstream coding and matching logic should never care which lane the invoice came through, but auditors will care how each field got its value.

The hybrid format deserves a specific control. A ZUGFeRD invoice carries two representations of the same transaction, and they can disagree. Decide explicitly that the XML is authoritative, verify the PDF against it on the fields that matter, and route divergences to review. Approving from one representation while posting from the other is how a clean mandate turns into a reconciliation problem.

Coding gets deterministic, so make it rules-first

Structured invoices carry standardised supplier and buyer identifiers, VAT amounts and tax categories, payment terms, line items, and order references. Fields that an extraction model used to guess at are now asserted by the sender. That moves a large share of AP coding from probabilistic to deterministic:

• GL coding and cost-centre mapping can key off supplier identity, line-level item data, and structured references instead of description-string heuristics.
• Tax code assignment can read the standardised tax attributes directly, including splitting mixed tax treatments across lines rather than averaging them at header level.
• PO and goods-receipt matching improves because the order reference arrives as a field, not as text an extractor may have found in the wrong corner of the page.
• Duplicate detection tightens when invoice numbers, supplier IDs, and amounts are exact values rather than OCR output with occasional character substitutions.

The design principle worth enforcing: where the mandate gives you a reliable field, write a rule, and reserve models for what is genuinely ambiguous. Non-PO invoices with vague line descriptions, unusual cost allocations, and cross-border edge cases still benefit from learned coding suggestions. Domestic structured invoices with clean references mostly do not, and putting a model in that path adds variance where none is needed.

Exceptions move to the front door

In a document-centric pipeline, problems surface late: at approval, at posting, sometimes at payment. With structured intake, most defects are detectable in the first second. An invalid VAT ID, a schema failure, an unsupported invoice type, a supplier record that does not match master data, a missing mandatory reference, a tax rate inconsistent with the line’s category: all of these can bounce at ingestion, before anyone approves anything.

This is a workflow change as much as a technical one. The AP exception queue shifts from “the extraction was unclear” to “the sender’s data is wrong”, and the resolution path shifts from internal rework to supplier communication. Rejecting a non-compliant invoice back to the sender with a machine-generated, specific reason is faster for everyone than accepting it and reconciling later, and under the mandates the sender has a legal reason to fix it. ViDA sharpens the incentive further: invoice data that will feed near-real-time digital reporting has to be right at the transaction, because a posting-time correction may already be a reporting error.

Supplier onboarding becomes the other half of the compliance project. Segment the vendor base by domestic versus cross-border, by exposure to the €800,000 issuance threshold, and by format readiness across XRechnung, ZUGFeRD, and network exchange over Peppol. The 2027 deadline is the supplier shock point: expect structured volume from larger German vendors to jump, and plan the capture lane’s staffing down accordingly.

The operational reality

Budget the work in three layers, because the parser is the cheap part. Master data is the expensive part: deterministic coding only works if supplier records, VAT registrations, and bank details are clean enough to match against, so a cleansing effort usually has to precede or accompany the intake rebuild. ERP mapping is the slow part: consuming invoice XML fields directly means revisiting posting logic, tax determination, and interface contracts that were designed around keyed or extracted data.

Keep the audit trail per field, not per document. When a regulator or auditor asks why an invoice posted with a particular tax code, the answer should trace to a named field in a validated payload, a specific rule version, and a timestamp. That lineage is straightforward to build now, while the pipeline is being rebuilt anyway, and painful to retrofit after 2028 when structured invoicing is universal in German domestic B2B and the PDF intake path has become the exception rather than the default.

The mandates will be sold internally as a compliance deadline. Treat them as the forcing function to retire interpretation-based AP: the organisations that only bolt a format parser onto an OCR-era pipeline will be compliant and still slow.