E-Invoicing Automation: Receive, Validate, Send
XRechnung and ZUGFeRD files get read, checked against the rules that apply and turned into something legible – in both directions. The check happens before dispatch, not afterwards at the recipient, and an error here reads “the Leitweg-ID is missing”, not BR-DE-15.
The deadline is a date. The change is something else
Receiving structured invoices is already mandatory for German businesses; the duty to issue them phases in across 2027 and 2028 by turnover. Those dates get the attention, and they are the easy part. What changes is what an invoice is. It used to be a document a person reads; it becomes a record that software either accepts or rejects. A colleague reads past a missing order number and picks up the phone. A validator does neither.
That is where the difficulty sits. Valid or invalid is no longer your accounts team's call; it belongs to software on the other side. Two invoices that look identical on paper end up differently – one carries a unit of measure that is not in the official code list, the other a tax category without the wording that has to go with it. The rejection turns up days later, out of a portal, written in abbreviations. And while it sits in an inbox no payment term runs, because as far as the buyer is concerned nothing was ever delivered.
The receiving side is the same shift in reverse. An XRechnung is an XML file with no layout, and in a ZUGFeRD document the record behind the visible PDF is the one that counts – not the picture. Carry on typing from the picture and you will post something the file does not say. So we build the validation first and the converter last. Producing a format is a day's work; knowing the rules it fails on afterwards is the job.
Where e-invoicing lands in daily work
We start with the direction that is already mandatory: receiving. What follows depends on who your customers are – public authorities ask for different things than companies do.
Making incoming e-invoices readable
The XML file nobody in the building can open today turns up on screen as a document – next to it the fields it is made of, and the log that goes with them.
Outgoing invoices in the required format
Your invoicing software stays the source: approved data becomes the file this particular recipient accepts – in the version and the profile they ask for.
Invoices to public authorities
Federal and state government run their own invoicing portals, some larger councils too. We connect the route your buyers actually use and supply the Leitweg-ID with it.
Recipient profiles instead of case-by-case calls
Recorded once per customer: which format travels which route, plus the details they insist on – order number, cost centre, named contact.
Archiving the structured original
What has to be kept is the file, not the printout. Original, readable view and log belong together and have to stay findable for the retention period.
What does not have to be an e-invoice
Small amounts, travel tickets, consumers and recipients abroad fall outside the same duty. Which of your documents belong in that group we go through beforehand; they stay PDFs but use the same filing.
The validation log of an XRechnung
An outgoing invoice to a public authority, checked before dispatch. Twelve rows from the log, two errors, one notice.
- 1 · SyntaxFile is well-formed XML in the UBL formatpassed
- 2 · SchemaStructure, data types and code lists per EN 16931passed
- 3 · Business rulesBR, BR-CO and BR-DE rule set, run with the KoSIT validator2 errors, 1 notice
- 4 · Commercial reviewTax rate, coding, whether the content is right – done by your accounts team, not by the softwarenot started
| Mandatory field | Value in the file | Result |
|---|---|---|
| BT-1Invoice number | 2026-1184 | fine |
| BT-2Invoice date | 2026-07-14 | fine |
| BT-3Invoice type code | 380commercial invoice | code allowed |
| BT-5Invoice currency | EUR | fine |
| BT-10Buyer referencethe Leitweg-ID for public buyers | empty | error BR-DE-15 |
| BT-27Seller name | Metzler Elektrotechnik GmbH | fine |
| BT-31Seller VAT identifier | DE264117385 | format valid |
| BT-44Buyer name | Stadt Herten, property department | fine |
| BT-84Payee account (IBAN) | DE73 4265 0150 0000 3391 07 | fine |
| BT-20Payment terms | “30 days net, 2 % discount until 24 July”free text instead of the prescribed notation | notice BR-DE-18 |
| BT-109 BT-110Net total, VAT amount |
€2,032.40 · €386.16 | fine |
| BT-112Gross total | €2,418.54calculated: €2,418.56 | error BR-CO-15 |
-
BR-DE-15
The buyer reference is missing. For public authorities this field holds the Leitweg-ID, the routing reference that tells the invoicing portal which office receives the document. Without it the portal refuses the file – the invoice counts as never delivered, and no payment term starts running.
-
BR-CO-15
The gross total does not match the sum. The rule says gross total equals net total plus VAT amount. The file states €2,418.54, the calculation gives €2,418.56. Two cents, caused by rounding each line separately in the source system. A person reads past it; the recipient's validator does not.
Neither error is a format error. One sits in the customer's master data, the other in how the source system rounds each line.
Example data from an electrical contracting business. Which rules fire in your case depends on the version of the format and on the recipient; the shape of the log stays the same.
From the file to the posting
-
Pool the intake, identify the format
Invoices from the central mailbox, from supplier portals and, where one exists, from the Peppol access point arrive in one intake. What gets identified is what is actually there: XRechnung in UBL or CII, ZUGFeRD with its profile, or a PDF with no record.
-
Validate formally, log it in plain language
Whatever a machine can decide, a machine decides: syntax, schema, business rules and the extra details your own house insists on. The log names field, value and rule without the abbreviations, so whoever reviews the document afterwards knows where to begin.
-
Build the readable view and match it up
The readable document is rendered from the XML, never from the attached PDF, so the two cannot drift apart. The supplier is identified by VAT identifier and IBAN, the purchase order by the reference the file carries.
-
Hold outgoing invoices rather than get them back
Whatever your source system approves runs through the rules that would fire at the recipient, and only a log without errors releases the dispatch. The invoice number stays reserved while that happens, so no gap appears in the number sequence.
-
Hand over, dispatch, archive
Checked documents go to DATEV, Lexoffice or your ERP; outgoing invoices leave by portal, Peppol or email with proof of delivery. Filing gives each document one reference, so file, view and log stay findable together.
What changes day to day
Today
- An XRechnung arrives and cannot be read on screen
- Posting happens from the PDF although the record governs
- Outgoing invoices go out as PDFs and come back
- A rejection arrives as a code nobody can interpret
- Which customer needs which format lives in one head
With validated e-invoicing
- Every e-invoice appears as a readable view and a checked record
- Posting happens from the structured original, not from the picture
- An invoice that fails the check never leaves the building
- Errors read in plain language, with field, reason and owner
- Format, route and Leitweg-ID sit in the recipient profile
Where this automation does not help
Four points we settle before quoting. The first is a reason not to spend money here:
- At small volumes this does not pay for itself. If you raise twenty outgoing invoices a month, have no public authorities as customers and use an invoicing package that already produces XRechnung files, you do not need us; free viewers exist for reading incoming ones. €1,900 only starts to make sense once formats, routes and target systems diverge – several source systems, public buyers, a volume nobody checks one document at a time any more. Where that line falls in your case we work out in the intro call with your figures, and if you are below it we will tell you so.
- Formal validation is not tax review. An invoice can pass every rule and still carry the wrong tax rate, a wrong description of what was supplied, or a reverse charge note that does not apply. The validator knows structure and arithmetic, not your circumstances. Input tax deduction, coding and factual accuracy stay with your accounts team and your tax adviser.
- The software does not fix your master data. The rejections we come across rarely originate in the format and usually in a detail missing on the customer record: no Leitweg-ID, an out-of-date VAT identifier, an order number the buyer insists on that nobody captured. We build the check that surfaces this early and with a name attached. Typing it in is still somebody's job at your end – whose, you decide; we put a suggestion on the table in the intro call.
- This is not finished at go-live. Which transition period applies to you, whether a document falls under the small-amount threshold, how long an existing EDI arrangement may continue – we give the general position, your tax adviser gives the binding answer. Nor do the formats stand still: XRechnung ships new versions, code lists change, portals change what they accept, and keeping up with that is maintenance rather than part of the fixed price. Either you book a support package or somebody at your end owns it; if you want neither, do not start here.
Fits your accounting
Scope and price
The entry price covers one intake, the machine validation and one route for outgoing invoices. What moves the price, we say before the quote.
- One intake for one mailbox plus one portal or Peppol route
- Recognition of XRechnung in UBL and CII, ZUGFeRD from profile BASIC
- Machine validation against EN 16931 and the German rule set, with a log
- Readable view and record, rendered from the structured original
- Outgoing invoices from one source system, checked before dispatch
- Handover to one accounting system, unalterable filing with the log
- Documentation, handover session and 30 days of support
What increases the price
- A second source system, or several legal entities
- Connection to a federal or state invoicing portal
- Your own Peppol access point instead of a provider
- Recipient profiles with many formats, routes and per-customer rules
- Progress and final invoices, discount terms in the prescribed notation
Several legal entities, your own Peppol access point and progress invoicing typically land in the range of our Workflow Advanced package from €2,490 or Workflow Enterprise from €5,900. We quote the binding fixed price after the intro call.
All prices excl. VAT · operation and further development optionally via a support package
What you get
-
A production route in both directions
Receipt, validation, readable view, generation and dispatch – signed off on real invoices
-
A validation log for every invoice
Which stage checked what, which rule fired, what happened next
-
Recipient profiles and a documented rule set
Format, route, Leitweg-ID and mandatory fields per customer, editable later
-
Training for accounts and order processing
How an error is dealt with and who maintains which detail
Frequently asked questions about e-invoicing
These solutions fit alongside
Accounts Payable Automation
The step after: matching the checked invoice against order and goods receipt.
Automatic Invoice Creation & Sending
The step before: turning approved order data into an invoice at all.
Automated Dunning & Payment Reminders
When the invoice arrived properly and still is not paid.
AI Document Processing
For everything without a structured format: scans, paper, loose PDFs.
What happens at your desk when an XRechnung arrives?
Send us five real documents – two incoming, three outgoing. We run the validation and show you the log. Afterwards you know which fields are missing at your end, and whether this is worth doing at your volumes.
Book a free intro callWhere e-invoicing automation creates value in everyday work
XRechnung and ZUGFeRD documents are received, validated, approved and handed to accounting or ERP without format breaks.
Three concrete operating scenarios to compare with your own process.Validate formats automatically
Required fields, structure and technical readability are checked before business approval.
Centralise intake
Email, portal and API records enter the same traceable validation process.
Create outbound e-invoices
Approved order data is converted into the required format and sent with a traceable record.
A strong fit when …
Documents, amounts and approvals follow explicit rules; exceptions must remain visible instead of being decided silently.
- You handle recurring e-invoices using repeatable rules.
- The intake, target system and accountable business role can be named clearly.
- Exceptions are allowed to remain visible and move to people deliberately.
Deliberate automation boundary
Format validation does not replace tax review; discrepancies, exceptions and unclear coding remain with accounting.
Explore the technical approach and platformsEstimate time savings with your own volume
The calculator uses 9 minutes today and 2 minutes after automation as fixed example assumptions. It does not replace process analysis.
Illustrative estimate based on the visible assumptions — not a guarantee.