Integrating E-Invoicing into SaaS: XRechnung, ZUGFeRD and DATEV as a Product Feature

For B2B SaaS providers, e-invoicing has gone from a nice feature to an expectation: receiving structured invoices is already mandatory in German B2B, sending follows in stages. Whoever has invoicing logic in their product cannot avoid the topic.

The expensive misconception is treating e-invoicing as a checkbox — a PDF with XML stapled on. An invoice that fails validation is worse than no feature: it looks done and is not.

E-invoicing is not "PDF plus attachment"

A real e-invoice is a structured, machine-readable record to a defined standard — XRechnung as pure XML, ZUGFeRD as a hybrid of PDF and embedded XML. Germany's Federal Ministry of Finance defines bindingly what counts as an e-invoice and what does not. A pretty PDF does not.

Four hard parts that really count

1. Format correctness and validation

XRechnung and ZUGFeRD have strict schemas. An invoice must not "look like" but be formally valid — checked against the official specifications, not by feel. Validation is product logic, not an afterthought.

2. The DATEV handoff

Many German companies expect invoice data to arrive cleanly in DATEV. A SaaS invoicing feature without a thought-through DATEV path solves only half the problem — and creates manual rework at the customer.

3. Audit-proof archiving

An e-invoice must be kept unchanged, findable and available over the legal retention period. Archiving is not storage space but a compliance function with requirements for integrity and access.

4. User guidance that prevents errors

The most common mistake arises not in the technology but at input: missing mandatory fields, wrong routing ID, unclear recipient. Good user guidance prevents the invalid invoice before it exists — cheaper than any later correction.

E-invoicing is integration plus compliance

Structured invoices rarely flow alone: they come from a process and go into accounting, archive and DATEV. That is the same discipline as any clean system connection (see API integration for companies). And because invoice data is personal and subject to retention, the data-protection frame belongs with it (see Developing SaaS in Germany).

Checklist before the e-invoicing feature

Do we produce valid XRechnung/ZUGFeRD, not a PDF with XML look?
Is it validated against the official specifications, not by feel?
Is the DATEV path thought through, not left to the customer?
Is archiving audit-proof (integrity, retention, access)?
Does user guidance prevent invalid invoices upfront?
Is receiving structured invoices solved as well as sending?
Is the data-protection/retention frame part of the architecture?

Frequently asked questions

Is a PDF with attached XML enough? Only if the XML is formally valid and standard-compliant (ZUGFeRD). A PDF with any XML is not an e-invoice, even if it looks like one.

Must we support sending and receiving? In German B2B, receiving structured invoices is already mandatory; sending follows in stages. A future-proof feature plans both.

Is DATEV really necessary? Not for every customer — but for many German companies the standard path into accounting. Without it, manual work remains.

What is the most common mistake? Skipping validation. An invoice that is only noticed as invalid at the recipient is more expensive than one that never goes out.

Conclusion

E-invoicing in SaaS is not a checkbox but a product feature with four hard parts: valid formats, checked validation, a thought-through DATEV handoff, audit-proof archiving — guided by a UX that prevents errors upfront. Whoever takes this seriously ships a feature that holds up in the audit and at the recipient.

Next step

You want to build invoicing features into your product properly? Start with a short assessment of your requirements. We cut an e-invoicing feature with validation, a DATEV path and audit-proof archiving.

Sources

Federal Ministry of Finance (BMF), FAQ on mandatory e-invoicing — bundesfinanzministerium.de
XStandard Einkauf, XRechnung — xeinkauf.de
FeRD, ZUGFeRD FAQ — ferd-net.de