Use caseDocument AIWorkflow automation
Receiving XRechnung, ZUGFeRD and Peppol invoices without retyping a single field
Receive XRechnung, ZUGFeRD and Peppol invoices, validate them against the KoSIT rules, show approvers a readable version, match to POs and post to DATEV.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
An intake pipeline for companies now receiving e-invoices as XRechnung, ZUGFeRD, Factur-X or Peppol documents. It detects the format, validates each file against EN 16931 and the KoSIT rules, removes PDF and XML duplicates, renders a readable view for approvers, matches lines to purchase orders, proposes the booking and posts to DATEV, Xero or the ERP, archiving the original XML. Most of it is plain code; the model proposes coding and reads the PDFs that still arrive, and people approve.
- Best for
- Companies in Germany, Belgium, France or Poland receiving a mix of e-invoices and PDFs, with the booking in DATEV, Xero or an ERP.
- Connects to
- Peppol access point, Outlook or Gmail AP inbox, KoSIT validator, DATEV, Xero, Business Central or another ERP
- The AI does
- Pairs free-text invoice lines with order lines, proposes GL accounts and cost centers with a reason, and reads the PDFs that still arrive without XML.
- People do
- Approve invoices from a readable view, decide when a supplier must reissue a faulty file, and own the booking rules.
- Built as
- AI Workflow Automation, usually $15K - $30K
Half the invoices are XML now. The work did not halve.
Consider a wholesaler in Germany receiving about 800 supplier invoices a month and posting them to DATEV through its tax adviser. Every German business has had to be able to receive e-invoices since 1 January 2025, and roughly half of this wholesaler's invoices now arrive as XRechnung files or ZUGFeRD PDFs. The rest are still PDFs, because suppliers may keep sending them until the end of 2026, and smaller ones until the end of 2027.
The XML removed the typing. It did not remove the rest. Nobody approves raw XML, so someone opens a viewer. The files still need checking, because a structurally valid invoice can carry the wrong VAT rate or a PO number that does not exist. Lines still have to be matched to orders, booked and archived in their original form. And plenty of suppliers send the same invoice twice, once as ZUGFeRD and once as a plain PDF 'for your records'.
The same shift is happening across Europe. Belgium's Peppol mandate for B2B invoices started on 1 January 2026, Poland's KSeF became mandatory in February and April 2026, and since 1 September 2026 every VAT-registered business in France must be able to receive e-invoices through an accredited platform. A company with suppliers or entities in several of these countries needs one intake that handles all of it.
Most of this is plain code, and I would build it that way. The model has a real job, but a small one: pairing free-text lines with order lines, proposing the booking, and reading the PDFs that still arrive without XML.
What arrives, and what the pipeline does with each
Format detection is the first step and it is entirely rules. Every file says what it is, if you look in the right place.
| What arrives | How it is recognized | What happens next |
|---|---|---|
| XRechnung, UBL syntax | XML with a UBL Invoice or CreditNote root, and a specification identifier (BT-24) naming XRechnung | Schema and business-rule validation with the KoSIT validator, then parsed straight into the internal invoice model |
| XRechnung, CII syntax | XML with a CrossIndustryInvoice root and the same identifier | The same validation, a different parser, the same invoice model |
| ZUGFeRD or Factur-X hybrid | A PDF/A-3 with an embedded XML file, usually factur-x.xml, whose guideline ID names the profile | The XML is extracted and validated; the PDF becomes the readable copy. MINIMUM and BASIC WL profiles are not full invoices under German rules and go to review |
| Peppol BIS Billing 3.0 | Delivered by the access point with sender and receiver participant IDs | Validated against the Peppol rules, then handled like any UBL invoice |
| Plain PDF or scan | No embedded XML at all | Read by a vision model as in invoice processing automation, followed by the same checks |
Intake, from file to booking
Six of these eight steps are ordinary code. The model appears where language is the problem, never where a rule already has the answer.
01 Trigger · Microsoft Graph, access point API
An invoice arrives by email or Peppol
The mailbox watcher and the access point's webhook feed one queue. Every file is stored unchanged, with a hash, before anything else touches it.
02 Plain code
Detect the format
Rules decide between UBL XML, CII XML, a PDF with embedded XML and a plain PDF. For hybrids, the XML is pulled out of the PDF/A-3 container.
03 Plain code · KoSIT validator
Validate
XRechnung files go through the KoSIT validator: schema first, then the EN 16931 and XRechnung business rules. Peppol files go through the Peppol rules. Then the checks no validator can do: is the buyer really this company, is the VAT ID the one in the supplier master, does the IBAN match.
04 Decision
Valid, and really ours?
A file that fails the format rules may not count as an e-invoice at all, so the pipeline never edits it.
- Schema or business-rule errors then a drafted request to the supplier to reissue; the file is kept exactly as received
- Valid, but addressed to another entity or with an IBAN that differs from the master then held for a person
- Valid and ours then continue
05 Plain code
Collapse the duplicates
The same invoice arriving as ZUGFeRD, as a separate PDF and again through Peppol becomes one record, keyed on supplier VAT ID, invoice number (BT-1) and issue date. The structured version is the one that counts.
06 AI model · Structured output
Pair lines and propose the booking
Where invoice lines carry no item number, the model pairs the supplier's descriptions with order lines, and code checks every pair on quantity and price. It then proposes GL account, cost center and tax key from the supplier's booking history, with a reason.
07 Person
Approve from a readable view
Approvers never see XML. They see a rendering built from it with KoSIT's XRechnung visualization: supplier, lines, VAT breakdown, payment terms and the match result, with approve, reject and query.
08 Result · DATEV Unternehmen online, Xero API
Book and archive
The booking goes to DATEV, Xero or the ERP with the invoice attached, and the original file goes to a write-once archive with its hash. The rendered PDF is a convenience copy, never the record.
Mostly code, and that is deliberate
An e-invoice is already data. The less a model touches it, the fewer ways it can go wrong.
The AI model
Pairing free-text lines with order lines
'Kabelbinder 4,8x200 schwarz, VE 100' against item 100-4820 is a language problem, not a lookup.
Booking proposals with a reason
Learned from how this supplier was booked before, and confirmed by a person until the proposals prove reliable.
Reading PDFs that arrive without XML
Some suppliers may send them until 2027, and they need extraction, not parsing.
Plain code
Format detection and parsing
The file declares its syntax and profile, so reading it is deterministic.
Schema and business-rule validation
The KoSIT validator gives the authoritative answer, and its report is kept with the invoice.
Duplicates across email, PDF and Peppol
Keys on supplier, invoice number and date, identical on every run.
A person
Approval, reissue requests and booking rules
Anything that commits money or changes how the books are kept.
One XRechnung, from XML to a booking proposal
A clean file and a faulty one from the same morning. The first is booked after approval; the second goes back to its supplier.
rechnungen@ mailbox, Tuesday 08:41
- detect_format(file: "INV-88213.xml")XML / CII syntax / BT-24 names XRechnung / type 380, commercial invoice
- kosit_validate(file: "INV-88213.xml")schema valid / business rules: 0 errors, 1 warning / recommendation: accept
- find_duplicates(vat_id: "DE13...", number: "88213", date: "2026-09-07")PDF copy arrived 07:58, forwarded by the buyer / linked as a copy, XML leads
- match_po(po: "PO-26-0917")4 of 5 lines matched on item number / 1 line has no item number
- pair_line(text: "Kabelbinder 4,8x200 schwarz, VE 100", candidates: 3)PO line 5, item 100-4820 cable tie 4.8 x 200 black, pack of 100 / qty 60 = 60 / price 7.40 = 7.40
- propose_booking(creditor: "70233")SKR03 3400 purchases 19% / cost center 200 warehouse / based on the last 12 invoices from this supplier
Intake · Approval view
Invoice 88213, net EUR 3,412.50 plus 19% VAT, matches PO-26-0917 on all five lines. One line was paired by description (cable ties, item 100-4820); quantity and price agree. Proposed booking: 3400 purchases 19%, cost center 200. The PDF copy that arrived earlier was linked as a copy, not booked.
- Same morning, a second supplier: a ZUGFeRD PDF with profile BASIC WL. It carries no invoice lines, so under German rules it is not a full e-invoice. Nothing was booked, and a reissue request asking for an EN 16931 or XRechnung version is waiting for AP to send.
The traps inside structured invoices
Structured does not mean correct. These are the cases the build handles on purpose.
Valid XML, wrong content
The validator checks structure and arithmetic. It cannot know that the supplier charged 19% on an item that takes 7%, or used last quarter's price. Those checks run after validation, against the supplier master and the purchase order.
A PDF and an XML that disagree
In a ZUGFeRD hybrid the picture and the data can say different things. The XML is the legally relevant part when they disagree, so the booking uses it, and the difference is raised with the supplier instead of being resolved quietly.
Credit notes and corrections
A credit note (type code 381) should reference the invoice it corrects in BT-25, and it is matched to that open item rather than paid. A correction to an e-invoice must itself be an e-invoice, so a PDF correction to an XML invoice is flagged.
Buyer references and the Leitweg-ID
Every XRechnung must carry a buyer reference in BT-10. Public bodies put their Leitweg-ID there; a private company can ask suppliers to put the requester's code or order number there instead, and the pipeline then uses it to route the invoice to the right approver.
Archiving the wrong file
GoBD requires the e-invoice to be kept in the form it arrived. For an XRechnung that is the XML, not a PDF rendering of it; for ZUGFeRD, the whole PDF with its embedded XML. The archive never substitutes the pipeline's own conversion, and the process goes into the company's Verfahrensdokumentation.
Several countries, several channels
A Belgian entity receives through Peppol, a French one through its accredited platform, a Polish one through KSeF and its own national XML schema. The intake normalizes all of them into one model, while the legal original stays whatever each channel delivered.
Does your accounting system already handle this?
Often, yes. DATEV Unternehmen online, lexoffice and sevDesk in Germany, Pennylane in France and most cloud accounting systems now receive e-invoices natively, render them readably and book them. For one entity, a few hundred invoices a month and no purchase orders to match, the native route is enough, and cheaper than anything I would build.
A custom intake earns its cost when volume and matching outgrow that: lines that must be matched to purchase orders and goods receipts in Business Central, SAP Business One or an industry ERP before booking, several entities in several countries with different channels, a legacy system in the middle that cannot read XML at all, or approval rules the accounting system cannot express. Dedicated AP suites cover much of this too, at a price and scope that suit larger teams.
The usual hybrid lets the accounting system or the access point receive and archive, and builds only the layer between it and the ERP: matching, routing and booking proposals. Whether that layer should be code or an automation platform is the question in integration layer or automation platform.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Share of invoices arriving structured
- By supplier and month, so AP knows whom to ask for XRechnung or ZUGFeRD and can watch the PDF share fall toward 2028.
- Validation failures by supplier and rule
- Which KoSIT rules fail most, and for whom. Most turn out to be one supplier's software setting, fixed with one email.
- Pairing and booking acceptance
- How often approvers accept the proposed line pairing and booking unchanged, per supplier.
- Arrival to booking time
- Measured separately for structured and PDF invoices, which shows what the structured share is actually worth.
What a build like this costs
This is built as AI Workflow Automation, which runs $3.5K - $60K overall. A build like this one usually lands in the multi-step workflow tier: $15K - $30K, 3-5 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Structured invoices cost almost nothing to process, because parsing and validation run on ordinary servers and the model is called only for line pairing, booking proposals and PDFs. Peppol access points charge per document or per month depending on the provider, and that is usually the largest external cost.
What moves the price
- How many channels deliver invoices: email only, or email plus Peppol, a French accredited platform or KSeF
- Whether lines must be matched to purchase orders and goods receipts, and which ERP holds them
- The share of invoices still arriving as PDFs, which need extraction rather than parsing
- How many entities and charts of accounts, and whether bookings go to DATEV, another accounting system or the ERP
- The archive: the existing DMS or DATEV, or a new GoBD-compliant store
Who this is for
- German companies posting to DATEV that now receive a mix of XRechnung, ZUGFeRD and PDF invoices
- Wholesalers and manufacturers whose invoices must be matched to purchase orders before they are booked
- Groups with entities in Germany, Belgium, France or Poland, each receiving through a different channel
- Accounting firms setting up e-invoice intake for clients on DATEV or Xero
- Companies whose ERP cannot read e-invoice XML and still expects someone to type each invoice in
Questions people ask about this
Do we still need OCR if suppliers send XRechnung or ZUGFeRD?
Not for those invoices. XRechnung files and the XML inside a ZUGFeRD PDF already contain every field in structured form, so they are parsed rather than read. OCR or a vision model is only needed for the PDFs that still arrive, which German suppliers may send until the end of 2026, and smaller suppliers until the end of 2027.
How do I validate an XRechnung?
With the KoSIT validator, the open-source tool from Germany's coordinating office for IT standards, configured for XRechnung. It checks the XML schema, then the EN 16931 and XRechnung business rules, and returns a report with an accept or reject recommendation. In this pipeline it runs as a local service on every incoming file, and the report is archived with the invoice.
Which part of a ZUGFeRD invoice counts when the PDF and XML differ?
The XML. In a hybrid invoice the structured part is the legally relevant one when the two disagree, so the pipeline books from the XML and raises the difference with the supplier. The PDF stays attached as the human-readable view, but it is never what the booking is based on.
How do we archive e-invoices under GoBD?
Unchanged, in the format they arrived, for the whole retention period. For an XRechnung that means the XML itself rather than a PDF rendering; for ZUGFeRD, the PDF with its embedded XML. The pipeline stores the original with a hash in a write-once archive or your document management system, and the process is written into the Verfahrensdokumentation.
Can AI process e-invoices on its own?
Only the parts that are language rather than rules. Parsing, validation, duplicate checks and posting are ordinary code that behaves the same way every time. The model pairs free-text invoice lines with order lines and proposes the booking with a reason, and a person approves until the proposals for each supplier have proven reliable.
Which European countries require businesses to receive e-invoices in 2026?
Germany has required every business to be able to receive e-invoices since 1 January 2025. Belgium's Peppol mandate for B2B invoices started on 1 January 2026, Poland's KSeF became mandatory in February and April 2026, and France has required every VAT-registered business to receive e-invoices through an accredited platform since 1 September 2026.
Sources