E-Invoice Fraud in Germany: The Email Channel Is the Weak Point
Germany's format mandate left the pipe to the parties. Most parties chose email. That is where invoice interception and bank-detail substitution now sit. Here is the fraud pattern and the verification duty.
E-Invoice Fraud in Germany: The Email Channel Is the Weak Point
Poland's KSeF authenticates the invoice at the state node. Spain's five-corner model puts a platform, and a copy to the AEAT, on every B2B send. Germany authenticated the format and left the transport to the market. The market defaulted to email.
That is now the fraud surface.
What Attackers Actually Do
The payload is still an invoice the buyer is expecting. The crime is substitution, not invention.
Mailbox interception. A supplier mailbox or a forwarding rule is compromised. Outgoing invoices are diverted. The buyer receives a file that looks like the supplier's ZUGFeRD: logo, line items, due date. The IBAN is the attacker's. Because ZUGFeRD shows a PDF layer, the human reads the PDF. Few AP clerks open the XML. If the XML and the PDF disagree, the PDF wins the payment.
Lookalike domains. rechnung@lieferant-gmbh.com is not rechnung@lieferantgmbh.com. SMTP will deliver both. The attachment can be a valid-looking XRechnung with a different PaymentMeans IBAN (BT-84) and a different payee name.
Fake structured files. After 1 January 2025 every German business must accept EN 16931 files. Attackers know AP teams were told "XML is the real invoice." A well-formed XRechnung that fails no schema check can still name the wrong creditor. Schema validity is not identity.
Callback fraud on the back of a real send. The genuine invoice arrives. A second mail, minutes later, "corrects the bank details" because of an "audit" or a "new factoring partner." The second mail is the crime. The first mail was bait.
This is the same family as bank-detail substitution on Polish PDF invoices, described in our earlier note on that pattern. The German twist is that the legal invoice is now structured data, so the IBAN lives in a field AP software will happily import.
What Is Not a Control
| Artefact | What it proves | What it does not prove |
|---|---|---|
| Email read receipt or open pixel | Someone rendered a message | Sender identity, file integrity, the right IBAN |
| DKIM / SPF pass | The sending domain authorised the SMTP session | That the domain owner intended this invoice, or that the XML is unaltered after send |
| Pretty PDF layer of a ZUGFeRD | Human-readable presentation | That BT-84 matches the supplier master data |
| "Please confirm you received our invoice" thread | Conversation | Payment instruction |
Internal control procedures, a qualified electronic signature, or an EDI agreement are the BStBK-listed methods for authenticity and integrity. Peppol adds a participant identity at the Access Point. Email adds none of those unless you layer them on.
Recipient Duties That Actually Move Money
Input VAT deduction still requires a proper invoice. Paying the wrong IBAN is your loss, not the tax office's. Build the check into AP, not into a training slide.
- Pay against master data, not against the invoice. The IBAN on the invoice is a proposal. The IBAN in the approved vendor record is the instruction. A change to BT-84 or to the payee name is a vendor-change request. It needs a second channel: a known phone number, a Peppol metadata update, not a reply to the invoice mail.
- Diff the XML, not the PDF. For ZUGFeRD, compare
PaymentMeansin the embedded XML with the vendor record. If you only look at the PDF layer, you are reading the advertisement. - Dedicated invoice mailbox, no public forwarding.
rechnungen@with two people who own it. Do not let invoices land in a shared Gmail and a personal inbox "for speed." - First-time and changed-payee holds. New vendors and IBAN changes wait. Recurring invoices to an unchanged IBAN can auto-post.
- Peppol or EDI for anyone you pay every month. If a buyer represents more than a trivial share of your disbursements, take them off SMTP.
Issuers have a symmetric duty. Put payment means in the structured fields, keep them aligned with the PDF layer, and do not send "updated bank details" from a marketing mailbox. If you factor receivables, the new payee must appear as a documented assignment, not as a footnote in an email.
Why a Portal or Access Point Shrinks the Window
A Peppol send is addressed to a participant ID, not to an inbox the internet can guess. The Access Point relationship is contractual. Swapping BT-84 still possible if the issuer is compromised, but the attacker no longer sits on the wire between two consumer mail hosts. EDI is the same idea with older plumbing.
Email will remain in the mix through 2027 and 2028 for small counterparties. Treat it as a low-assurance channel: extra holds, no IBAN changes via that thread, XML diff against master data. Do not buy a product whose only fraud story is "we track whether they opened the mail."
Plandesk stores payee IBANs on the vendor record, writes them into the e-invoice from that record, and flags a send when the structured payment means do not match. Channel choice is per buyer. Open tracking is not part of the evidence pack.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.