Stripe Billing verschickt PDFs. Ab 2027 reicht das in Deutschland nicht mehr

Stripe Invoicing und Stripe Billing erzeugen ein PDF. Stripe schreibt in der eigenen Dokumentation unmissverständlich, dass beide Produkte ohne zusätzlich eingebundene E-Invoicing-App keine elektronischen Rechnungen erstellen oder versenden können, und verweist auf Partner im App Marketplace. Für einen inländischen deutschen B2B-Umsatz erfüllt dieses PDF ab 1. Januar 2027 die Ausstellungspflicht nicht mehr, bei größeren Anbietern, und ab 1. Januar 2028 bei allen anderen.

Die meisten Texte zu diesem Thema stammen von Steuerberatungen oder von Anbietern, die einen Formatkonverter verkaufen. Dieser hier ist von der Bauseite geschrieben. Die Frage lautet nicht "was sagt das Gesetz", sondern was ein Engineering-Team rund um einen Payment-Provider tatsächlich bauen muss und welche Teile es einkaufen kann. Das ist ein Engineering-Leitfaden, keine Steuerberatung. Die steuerlichen Beurteilungen bleiben bei deiner Steuerberatung.

Was sich wann tatsächlich ändert

Die relevanten Fristen sind kein einzelnes Datum, sondern eine Matrix. Die Empfangspflicht kam vor der Ausstellungspflicht, und jedes Nachbarland hat das Transportproblem anders gelöst.

Lies die Frankreich-Zeile noch einmal neben der Deutschland-Zeile. Deutschland schreibt ein Format vor und überlässt den Kanal den Parteien, deshalb ist E-Mail ein legitimer Zustellweg. Frankreich schreibt ein Netzwerk vor. Wenn deine Roadmap "E-Rechnung" als ein Feature führt, ist der Scope bereits falsch: Format, Transport und Meldung sind drei unabhängige Achsen, die jedes Land getrennt festlegt.

Was außerhalb des Anwendungsbereichs bleibt

• B2C. Rechnungen an Verbraucher sind von der deutschen Pflicht nicht berührt.
• Kleinbeträge. Rechnungen bis 250 Euro brutto sowie Fahrausweise dürfen unstrukturiert bleiben.
• Bestimmte steuerfreie Umsätze aus dem Befreiungskatalog des Umsatzsteuergesetzes.

Für ein typisches B2B-SaaS ist die 250-Euro-Grenze eher Falle als Erleichterung. Ein Seat-Plan zu 49 Euro im Monat liegt darunter, ein Jahresvertrag nicht, und Self-Serve-Upgrades verschieben Kunden unterjährig über die Grenze. "Fällt diese Rechnung unter die Pflicht" als Regel zu kodieren, die das Billing-System pro Dokument auswertet, schlägt jede Policy im Wiki.

Warum ein PDF keine E-Rechnung ist

EN 16931 beschreibt kein Dokument. Die Norm beschreibt ein semantisches Datenmodell: eine Liste von Geschäftsbegriffen wie Umsatzsteuer-Identifikationsnummer des Verkäufers, Nettobetrag der Rechnungsposition, Steuerkategoriecode und Fälligkeitsdatum, jeweils mit definierter Kardinalität und einem Satz Geschäftsregeln, die erfüllt sein müssen. Eine Datei ist dann eine E-Rechnung, wenn sie dieses Modell in einer der beiden zugelassenen XML-Syntaxen trägt, UBL oder UN/CEFACT CII, und die Regeln besteht.

Ein PDF trägt Pixel und bestenfalls eine Textebene. Eine Maschine kann nicht verlässlich wissen, ob "19%" in Zeile vier ein Steuersatz, ein Rabatt oder Teil eines Produktnamens ist. Genau darin liegt der Unterschied. "Maschinenlesbar" im rechtlichen Sinn heißt, dass das empfangende System jedes Pflichtfeld deterministisch extrahieren kann, ohne Heuristik und ohne ratendes LLM.

Zwei Implementierungsdetails kosten Teams je ein Release, wenn sie spät auffallen. Erstens: nicht jedes ZUGFeRD-Profil erfüllt die Anforderung. Die Profile MINIMUM und BASIC WL enthalten keine Rechnungspositionen und genügen der deutschen Pflicht daher nicht, ein Bibliotheks-Default auf MINIMUM liefert also eine Datei, die konform aussieht und es nicht ist. Zweitens ist im hybriden Format der strukturierte Teil das verbindliche Original. Wenn das XML 1.190,00 Euro sagt und das gerenderte PDF 1.180,00 Euro, gewinnt das XML, und das System deines Kunden bucht das XML. Das PDF aus derselben Datenstruktur zu rendern, die das XML erzeugt hat, statt aus einem parallelen Template, ist der einzig verlässliche Weg, diese Fehlerklasse auszuschließen.

Gilt die deutsche Pflicht für ein österreichisches, Schweizer oder US-SaaS?

Meistens nicht, und das ist der am häufigsten falsch gelesene Punkt des ganzen Themas.

Die deutsche Ausstellungspflicht greift bei Umsätzen zwischen zwei Unternehmen, die beide im Inland ansässig sind, wobei Ansässigkeit Sitz, Geschäftsleitung oder eine umsatzsteuerliche Betriebsstätte bedeutet. Eine österreichische GmbH ohne deutsche Betriebsstätte, die einen Berliner Kunden abrechnet, fällt nicht unter die Ausstellungspflicht. Die Leistung ist ohnehin in der Regel ein Reverse-Charge-Fall, bei dem der deutsche Kunde die Umsatzsteuer schuldet.

Drei Einschränkungen verhindern, dass daraus ein Grund zum Nichtstun wird:

1. Eine deutsche Gesellschaft oder Betriebsstätte holt dich hinein. Viele ausländische Gruppen haben eine und vergessen, dass die abrechnende Einheit zählt, nicht die Muttergesellschaft.
2. Empfangen ist etwas anderes als Ausstellen. Wer eine deutsche Gesellschaft hat, muss strukturierte Eingangsrechnungen bereits verarbeiten können. Das ist ein Kreditoren- und Integrationsthema, kein Billing-Thema.
3. Deine Kunden fragen trotzdem. Sobald die Kreditorenbuchhaltung eines deutschen Käufers auf strukturiertem Eingang läuft, wird das PDF eines ausländischen Anbieters zum Sonderfall, den ein Mensch bearbeitet, nachfasst und spät bezahlt. Unstrukturiert zu sein kostet kommerziell, lange bevor es rechtlich kostet.

Dieselbe Logik gilt umgekehrt beim Verkauf nach Frankreich oder Belgien, wo nicht ein Dateiformat, sondern eine Netzwerkanbindung verlangt wird. Viele unserer Kunden fakturieren aus Österreich nach Deutschland und weiter, also genau in der Konstellation, in der rechtliche und praktische Antwort auseinandergehen. Die breitere Variante dieses Musters haben wir in DSGVO und AI Act im Stapel für ein DACH-SaaS beschrieben.

Was Stripe liefert und was nicht

Stripe ist sehr gut in dem, was es abdeckt. Die Lücke ist konkret und gehört präzise benannt statt in eine Klage über die Plattform verwandelt.

Nichts in dieser Tabelle spricht gegen Stripe. Sie spricht gegen die Annahme, der Payment-Provider sei das führende System für Compliance. Zahlung und Fakturierung sind zwei Produkte, die sich zufällig eine Datenbank teilen.

Das Format ist der kleinste Teil: vier Systeme, die kein Konverter für dich baut

1. Steuerermittlung, die auf EN-16931-Felder abbildet

Deine Billing-Engine entscheidet bereits zwischen Regelsteuersatz, ermäßigtem Satz, Reverse Charge, innergemeinschaftlicher Lieferung und OSS-Behandlung. EN 16931 verlangt, dass diese Entscheidung als codierte Steuerkategorie, Satz, Bemessungsgrundlage und, für alles außerhalb des Regelsatzes, als maschinenlesbarer Befreiungsgrund ausgedrückt wird. Ein Konverter bekommt, was dein System ihm übergibt. Steht die Entscheidung upstream als Freitextnotiz "Reverse Charge", entsteht eine strukturell gültige Rechnung mit falscher steuerlicher Aussage. Das ist der schlechteste beider Ausgänge: Sie besteht die Validierung und fällt in der Prüfung durch.

2. Käuferstammdaten und Routing-Kennungen

Eine strukturierte Rechnung braucht einen echten Käufer: Firmenname laut Register, Anschrift, Umsatzsteuer-Identifikationsnummer und bei vielen Enterprise- und öffentlichen Kunden eine Routing-Kennung wie eine Leitweg-ID oder eine Peppol-Teilnehmerkennung. Self-Serve-Registrierungsformulare erheben davon nichts zuverlässig. Teams stellen beim Go-live fest, dass in einem erheblichen Teil der B2B-Datensätze ein Personenname im Firmenfeld steht und die USt-IdNr. nie geprüft wurde. Umsatzsteuer-Identifikationsnummern beim Checkout zu validieren und die Routing-Kennung für Enterprise-Pläne zum Pflichtfeld zu machen, ist heute eine Änderung von zwei Wochen und im Dezember 2026 ein Datenmigrationsprojekt.

3. Ein unveränderbares Archiv des strukturierten Originals

Das XML ist das rechtliche Original, also ist das XML das, was unverändert und maschinenlesbar über die gesetzliche Frist aufbewahrt werden muss. Für Rechnungen, die ab 2025 ausgestellt oder empfangen wurden, gilt in Deutschland eine achtjährige Aufbewahrungsfrist. "Liegt in Stripe" ist kein Archiv, sondern eine API eines Dritten, deren Lebenszyklus du nicht kontrollierst. Ein tragfähiges Muster ist Objektspeicher mit Versionierung und Object-Lock-Retention, ein beim Schreiben erfasster Inhalts-Hash und ein Index, der Rechnungsnummer auf Storage-Key abbildet. Daneben brauchst du eine Verfahrensdokumentation, die beschreibt, wie Rechnungen entstehen, validiert, versendet, gespeichert und korrigiert werden. Prüfer lesen dieses Dokument, bevor sie deinen Code lesen.

4. Der Korrekturlebenszyklus

Hier unterscheiden sich Abo-Produkte von Einmalverkäufern, und hier landet der Großteil des Aufwands. Zeitanteilige Abrechnung, Planwechsel mitten im Zyklus, Dunning-Retries, Teilrückerstattungen, Guthaben und Währungswechsel erzeugen Finanzereignisse, aus denen Korrekturdokumente werden müssen, keine Änderungen am Bestand. Unter dem Grundsatz der Unveränderbarkeit stornierst du und stellst neu aus, du überschreibst nicht. Eine Rückerstattung ist nicht automatisch eine Gutschrift, und ein verworfener Entwurf ist nicht dasselbe wie eine stornierte Rechnung. Diese Abbildung als Zustandsautomat aufzuschreiben, mit einer Zeile je Stripe-Event-Typ, ist das wertvollste Artefakt des ganzen Projekts.

Das BMF-Schreiben 2025 macht Validierung zur Pipeline-Anforderung

Das zweite Anwendungsschreiben des Bundesfinanzministeriums vom 15. Oktober 2025 sortiert Fehler in E-Rechnungen in drei Klassen. Für ein Engineering-Team liest sich das weniger wie Steuerguidance und mehr wie eine Spezifikation für ein Validierungsgate.

Die technische Konsequenz ist eindeutig. Validiere jedes Dokument vor dem Versand gegen die Geschäftsregeln der EN 16931, blockiere bei Format- und Geschäftsregelfehlern, und leite Inhaltsfehler in eine menschliche Queue, weil kein Validator sie erkennt. Validierung als ausgehendes Gate statt als Monitoring-Dashboard zu behandeln, ist der Unterschied zwischen einem Fehler in der Queue und einem Fehler, den die Steuerabteilung deines Kunden entdeckt. Es ist dieselbe Disziplin, die wir in einem Mandat für Software Quality Assurance anwenden: Die Prüfung gehört in den Pfad, nicht daneben.

"Teams budgetieren das XML und werden vom Archiv und von den Gutschriften überrascht. Das Format ist ein Bibliotheksaufruf. Der Korrekturlebenszyklus ist ein Zustandsautomat, den jemand die nächsten acht Jahre verantworten muss."

Eine Referenzarchitektur für einen Stripe-basierten Billing-Stack

1. Billing-Events. Konsumiere Stripe-Webhooks in ein eigenes, dauerhaftes Event-Log. Behandle den Provider nie als führendes System für buchhalterische Aufzeichnungen.
2. Rechnungsdatenmodell. Projiziere diese Events auf eine normalisierte Rechnungsentität, die jeden Pflichtbegriff der EN 16931 explizit hält, inklusive Käuferkennungen und codierter Steuerbehandlung. Dieses Modell ist dein eigentliches Liefergut, nicht das PDF.
3. Nummernkreis und Unveränderbarkeit. Vergib die Rechnungsnummer in dem Moment, in dem das Dokument final wird, aus genau einem Writer, und mache den Datensatz ab dann append-only.
4. Rendering. Erzeuge XML und menschenlesbare Darstellung in einem Schritt aus demselben Modell, damit sie nicht auseinanderlaufen können.
5. Validierungsgate. Schema- plus Geschäftsregelprüfung. Bei Fehlern blockieren. Das Prüfergebnis mit dem Dokument speichern.
6. Transport. Kanal je Ziel wählen: E-Mail-Anhang für Deutschland, ein Peppol-Access-Point für Belgien und Skandinavien, eine zugelassene Plattform für Frankreich. Halte den Transport hinter einem Interface, damit ein neues Land ein neuer Adapter ist und keine neue Codebasis.
7. Archiv und Abgleich. Schreibe das strukturierte Original mit Hash in gesperrten Speicher und gleiche das Archiv turnusmäßig gegen das Ledger ab. Ein Archiv, das niemand abgleicht, ist eine Annahme, keine Kontrolle.

Etwa ein Viertel dieser Liste ist von der Stange kaufbar. Der Rest ist dein Domänenmodell, und genau dort sammeln sich technische Schulden, wenn die Arbeit gegen eine gesetzliche Frist gehetzt wird.

Bauen, kaufen oder anflanschen

Der ehrliche Standard für die meisten B2B-SaaS-Unternehmen ist ein Hybrid: Formaterzeugung und Transport kaufen, Rechnungsdatenmodell, Validierungsgate und Archiv selbst bauen. Diese Aufteilung folgt derselben Logik wie jede andere Entscheidung zwischen Individualsoftware und Standardlösung. Kaufe die Commodity, besitze das, was deine Geschäftslogik wirklich berührt. Als wir die institutionelle Bond-Analytics-Plattform von null auf Enterprise-Reife gebracht haben, galt dasselbe Prinzip: Ein regulierter Output ist nur so vertrauenswürdig wie das Modell, das ihn erzeugt.

Acht Fehlermuster, die wir in Billing-Pipelines sehen

1. Zwei führende Quellen. Das PDF entsteht aus einem Template, das XML aus der Datenbank. Innerhalb eines Releases laufen sie auseinander.
2. MINIMUM als Default. Ein Bibliotheks-Default erzeugt eine Datei, die als ZUGFeRD validiert und die gesetzliche Anforderung verfehlt.
3. Rundung auf der falschen Ebene. Die Geschäftsregeln der EN 16931 prüfen, dass Positionssummen, Steuerteilsummen und Dokumentsumme zusammenpassen. Pro Position anders zu runden als pro Dokument verletzt die Regeln.
4. Gemischte Steuersätze in einem Dokument. Ein Bundle aus 19%-Lizenz und 7%-Position braucht korrekte Steuerteilsummen je Kategorie, nicht einen Mischsatz.
5. Ungeprüfte Käuferdaten. Fehlende Umsatzsteuer-Identifikationsnummern und Personennamen im Firmenfeld, entdeckt beim Go-live.
6. Löschen statt Stornieren. Ein Support-Workflow, der eine falsche Rechnung entfernt, zerstört genau den Prüfpfad, den Unveränderbarkeit verlangt.
7. Testdaten im Produktivnummernkreis. Ein Lasttest, der 4.000 Rechnungsnummern verbrennt, hinterlässt eine Lücke, die drei Jahre später niemand erklären kann.
8. Keine ausgehende Validierung. Fehler tauchen in der Kreditorenbuchhaltung des Kunden auf, dem teuersten denkbaren Detektor.

Ein 90-Tage-Plan

1. Woche 1 bis 2, Scope. Klär je Rechtsträger, ob du unter die Ausstellungspflicht fällst, und je Kundensegment, ob die Kleinbetragsgrenze greift. Ergebnis ist eine Entscheidung auf einer Seite, kein Memo.
2. Woche 3 bis 4, Datenaudit. Miss, wie viele B2B-Datensätze eine geprüfte Umsatzsteuer-Identifikationsnummer, einen Firmennamen laut Register und eine vollständige Anschrift tragen. Diese Zahl bestimmt deinen Zeitplan stärker als jede technische Entscheidung.
3. Woche 5 bis 7, Modell und Mapping. Definiere die Rechnungsentität, bilde jeden Stripe-Event-Typ auf ein Rechnungs- oder Korrekturdokument ab und mappe deine Steuerlogik auf EN-16931-Kategoriecodes.
4. Woche 8 bis 10, erzeugen und validieren. Erzeuge ZUGFeRD aus dem Modell, verdrahte das Validierungsgate und lass die letzten zwölf Monate Rechnungen als Backtest durchlaufen. Die Fehlerquote auf historischen Daten ist deine echte Reifekennzahl.
5. Woche 11 bis 12, Archiv und Verfahrensdokumentation. Stell gesperrten Speicher mit Hashing und Abgleich bereit und schreib die Verfahrensdokumentation, solange die Entscheidungen frisch sind.
6. Danach: Transport je Land. Peppol oder eine zugelassene Plattform nur für die Märkte ergänzen, die es verlangen.

Zwölf Wochen setzen voraus, dass jemand die Entscheidungen verantwortet. Fehlt diese Person, bleibt die Arbeit in Woche drei stehen. Das ist ein häufiger Grund, warum Unternehmen für ein befristetes Regulierungsprogramm einen Fractional CTO holen, statt dafür einzustellen.

Vier Mythen, die eine Korrektur verdienen

• "Rechnungsnummern müssen lückenlos sein." Das Umsatzsteuergesetz verlangt eine fortlaufende Nummer, die zur Identifizierung einmalig vergeben wird. Eine lückenlose Folge ist nicht zwingend. Lücken ziehen in der Prüfung aber Fragen nach sich, also dokumentiere, warum sie existieren.
• "Ein PDF mit XML darin ist ein Workaround." ZUGFeRD ist ein vollwertiges konformes Format. Der PDF-Container ist nicht das Problem, ein PDF ohne die strukturierten Daten schon.
• "Für Deutschland brauchen wir Peppol." Deutschland schreibt das Format vor, nicht den Kanal. E-Mail genügt. Peppol wird nötig wegen deiner Kunden, nicht wegen des deutschen Rechts.
• "Unsere Buchhaltungssoftware macht das." Sie macht die Rechnungen, die sie selbst erzeugt. Rechnungen, die dein Produkt in deiner Billing-Engine auf deinem Nummernkreis erzeugt, gehören dir.

Primärquellen

• Bundesfinanzministerium, zweites Anwendungsschreiben zur obligatorischen E-Rechnung, 15. Oktober 2025
• Bundesfinanzministerium, FAQ zur obligatorischen E-Rechnung ab 1. Januar 2025
• § 14 UStG, Ausstellung von Rechnungen und die fortlaufende Nummer
• Stripe, obligatorische E-Rechnung in Deutschland
• Stripe, E-Rechnungen über Partner im App Marketplace versenden
• FeRD, ZUGFeRD-FAQ zu Versionen und Profilen
• EU-Kommission, eInvoicing-Länderfactsheet Österreich
• EU-Kommission, eInvoicing-Länderfactsheet Frankreich
• EU-Kommission, VAT in the Digital Age