E-invoices for building managers: XRechnung and ZUGFeRD

The supplier invoice has had the same journey for twenty years: it arrives as a PDF in the manager’s inbox, someone reads the amount off the screen, retypes it into a spreadsheet or an accounting tool, files the PDF in a folder, and hopes the two stay in sync. Multiply by every elevator contract, cleaning company, insurance policy, and one-off repair across a portfolio of buildings, and retyping invoices is a real fraction of a Hausverwaltung’s back office.

That era is ending, by law. Since January 2025, every German business must be able to receive structured electronic invoices for domestic B2B transactions, with the obligation to issue them phasing in through 2027 and 2028. Building managers sit squarely inside this: managing a building’s money is business, suppliers are businesses, and they will increasingly send XML whether the receiving side is ready or not.

Most coverage frames this as a compliance burden. It is the opposite. The mandate forces suppliers to send invoices in a machine-readable format, which means the retyping era can end, if the receiving workflow is built right. Here is what the formats actually are, and what a correct receiving workflow looks like.

The PDF is not the invoice anymore

An e-invoice, in the legal sense, is not a PDF of an invoice. It is a structured data file conforming to the European standard EN 16931: the seller, the amounts, the dates, the payment details, all as machine-readable fields. Two formats dominate in Germany:

• XRechnung is the pure form: an XML file, no visual layer at all. Open it in a viewer and you see angle brackets. It is unreadable by design, because it is meant for machines.
• ZUGFeRD (internationally: Factur-X) is the hybrid: a normal-looking PDF with the XML embedded inside it. The human sees an invoice; the machine sees data. Crucially, the embedded XML is the authoritative part, not the pixels.

The hybrid format hides a trap worth knowing about. A ZUGFeRD invoice processed the old way, by reading the PDF with human eyes and retyping, silently ignores the structured layer. The numbers on the visual layer and in the XML are supposed to match, but the machine-readable part is the invoice. A workflow that only ever touches the pixels is processing a picture of an invoice and discarding the invoice itself.

Receiving done right: parse, show, confirm

The correct receiving workflow has three steps, and only one of them involves a human.

First, the file goes in, XRechnung XML or ZUGFeRD PDF, and the machine reads the structured fields: who sent it, the invoice number, the issue and due dates, the net, tax, and gross amounts, the IBAN to pay. No retyping, no reading numbers off a screen.

Second, those parsed fields are shown to you in plain, human-readable form. This matters most for XRechnung, which without this step is a wall of XML nobody can act on, but it matters for hybrids too: what you see is what the machine layer actually says, not what the PDF happens to display.

Third, you confirm, once, and the invoice becomes a draft expense in the building’s books, carrying the parsed amount and supplier. From that point it lives the normal life of an expense: it waits for the bank statement, the payment row gets linked to it, and its status computes itself the way every building cost should.

One file in, one confirmation, one booked expense. That is the entire manual surface of the workflow.

Why the confirmation step is not optional

A fair question: if the machine reads everything, why confirm at all? Why not book invoices automatically the moment they arrive?

Because parsing is reliable and accountability is not delegable. An invoice can be machine-perfect and still wrong: a duplicate, an amount that does not match the contract, a service never ordered, or outright fraud. Invoice fraud with altered payment details is a real and growing pattern, and the confirmation screen is exactly where it dies: the parsed IBAN sits in front of a human who knows what the elevator company’s account has always been. A workflow that auto-posts strips out the one moment where the manager’s judgment, the thing the building actually pays for, gets applied.

So the right design is deliberate: the machine does all the reading, the human makes the one decision. Anything more automatic optimizes away the point.

Archive the original, not the rendering

German record-keeping rules require invoices to be retained for eight years, and here the same logic applies as with the hybrid format: what must be preserved is the original file, the XML or the hybrid PDF exactly as received, not a screenshot, not the human-readable rendering, not a re-export. The rendering is a convenience for today; the original is the record for the auditor in year seven.

So the receiving tool should store the original immutably, alongside the expense it became, and always be able to hand back the exact bytes that arrived. If a tool re-generates or “cleans up” stored invoices, it is archiving its own artwork instead of the document.

Where the invoice flows next

The quiet payoff of receiving invoices as data is everything downstream. The confirmed expense joins the building’s transaction chain, which means:

• The owners can see it. The invoice takes its place in the building’s voucher list, the Belegeinsicht, where an owner reviewing the year’s statement can open the actual document behind every line.
• The annual statement absorbs it. Year-end stops requiring an invoice hunt, because every supplier invoice already sits categorized in the books. The whole cycle is covered in the owner accounting playbook.
• The accountant gets clean data. A booking export carries the expense with its categories to the tax advisor, with the original document retrievable on demand.

Count the human touches across that entire journey: one. The invoice was confirmed once, and every later consumer, owner, assembly, accountant, auditor, reads records derived from that single confirmed fact.

What is not here yet, and why to start anyway

Two delivery channels are still maturing across the market: invoices arriving by email being ingested automatically, and the Peppol network for structured invoice exchange. Today, the dependable baseline is upload: the invoice file, however it reached you, goes into the tool and the workflow above takes over.

That baseline is already the whole win. The cost of e-invoicing was never the upload click, it was the retyping, the mismatched folders, the invoice hunt every January. Those end the day the receiving workflow starts reading the XML instead of you. The mandate made suppliers do the hard half; the receiving half is now a choice.