Stripe und DATEV: So kommen deine SaaS-Umsätze GoBD-konform in die Buchhaltung
Am Monatsende steht auf dem Bankkonto eine Auszahlung von Stripe. Ein Betrag, ein Buchungstag, dahinter mehrere hundert Transaktionen, bereits verrechnet mit den Gebühren. Für die Buchhaltung beginnt an dieser Stelle die Arbeit: Aus dem Sammelbetrag müssen Einzelumsätze, Gebühren, Gutschriften und Erstattungen werden, jede Position mit Beleg, Steuerschlüssel und Debitorenzuordnung. Der Steuerberater fragt nach Einzelbelegen, das Team exportiert CSV-Dateien, und der Monatsabschluss dauert Tage statt Stunden.
Die naheliegende Diagnose lautet: Es fehlt ein Export. Die zutreffende Diagnose ist unbequemer. Stripe liefert Zahlungsdaten, DATEV braucht Belege und Buchungssätze, und zwischen diesen beiden Kategorien übersetzt kein Export der Welt verlustfrei. Wer den Abgleich am Ende der Kette repariert, mit Tabellen, Konvertern oder manueller Nacharbeit, verlagert das Problem nur dorthin, wo es am teuersten ist. Und mit der E-Rechnungspflicht ab 2027 bekommt derselbe Kategorienfehler eine zweite, terminierte Konsequenz.
Stripe ist ein Zahlungssystem, kein Buchhaltungssystem
Das ist keine Kritik an Stripe, sondern eine Beschreibung des Produkts. Stripe verarbeitet Zahlungen: Charges, Auszahlungen, Gebühren, Erstattungen, Rücklastschriften. Das tut es zuverlässig und weltweit. Eine deutsche Buchhaltung braucht aber etwas anderes: Buchungssätze mit Soll und Haben auf Konten eines Kontenrahmens wie SKR 03 oder SKR 04, Debitorenkonten mit offenen Posten, Steuerschlüssel für jede Umsatzart und zu jeder Buchung einen Beleg, der den Anforderungen des § 14 UStG genügt.
Einen nativen DATEV-Export bietet Stripe nicht an. Die Anbindung läuft über Drittanbieter oder über selbstgebaute Exporte, und beide Wege haben dieselbe strukturelle Grenze: Sie können nur übersetzen, was in den Zahlungsdaten enthalten ist. Die buchhalterische Logik, also welcher Umsatz auf welches Konto gehört, welche Leistung in welchen Zeitraum fällt und welcher Kunde welchen offenen Posten hat, steckt dort nicht drin.
Fünf Stellen, an denen der Monatsabschluss bricht
Auszahlung ist nicht Umsatz
Stripe zahlt netto aus, die Gebühren sind bereits abgezogen. Handelsrechtlich gilt aber das Verrechnungsverbot des § 246 Abs. 2 HGB: Umsätze sind brutto zu buchen, Gebühren separat als Aufwand. Wer die Auszahlung als Erlös bucht, hat Umsatz und Kosten gleichzeitig falsch.
Der Beleg fehlt oder genügt nicht
Wer Stripe über Checkout oder Payment Links nutzt, erzeugt Zahlungsbestätigungen, keine Rechnungen. Eine Rechnung mit allen Pflichtangaben nach § 14 UStG entsteht nur, wenn Stripe Invoicing vollständig und korrekt konfiguriert ist, und bleibt auch dann ein PDF.
Steuerlogik endet an der Berechnung
Stripe Tax berechnet Steuersätze zum Zeitpunkt der Zahlung. Die Zuordnung zu Steuerschlüsseln und Erlöskonten, Reverse-Charge-Fälle nach § 13b UStG bei EU-Geschäftskunden und die saubere Trennung von B2B und B2C bleiben Aufgabe der Buchhaltung.
Zahlung ist nicht Leistung
Ein im Januar bezahlter Jahresvertrag ist im Januar kein Jahresumsatz. Die Vorauszahlung muss über passive Rechnungsabgrenzung nach § 250 HGB auf die Leistungsperioden verteilt werden. Stripe kennt den Zahlungszeitpunkt, nicht die Abgrenzungslogik dahinter.
Keine Debitorenführung
Teilzahlungen, Rücklastschriften, Zahlungsziele und offene Posten brauchen eine Debitorenbuchhaltung. Stripe führt Kunden und Zahlungsvorgänge, aber keine offene-Posten-Logik, aus der sich ein Debitorensaldo im Sinne der Buchführung ergibt.
Jeder dieser fünf Punkte lässt sich einzeln umgehen, mit Auswertungen, Nebenrechnungen und Erfahrung. Zusammen ergeben sie den Zustand, den viele Finance-Teams kennen: Der Abschluss stimmt am Ende, aber niemand kann ohne Vorbereitung sagen, warum.
Was die GoBD daraus machen
Die GoBD, festgehalten in einem BMF-Schreiben aus dem November 2019 und zuletzt im Juli 2025 aktualisiert, verlangen von der Buchführung Nachvollziehbarkeit und Nachprüfbarkeit, vollständige und zeitgerechte Erfassung der Geschäftsvorfälle, Unveränderbarkeit der Aufzeichnungen und eine Verfahrensdokumentation, die den gesamten Prozess von der Entstehung des Belegs bis zur Buchung beschreibt.
An zwei Stellen wird das für ein Stripe-Setup konkret. Erstens gehört zu jeder Buchung ein Beleg, und der Beleg für einen Umsatz ist die Rechnung, nicht die Zahlung. Zweitens muss die Verfahrensdokumentation die tatsächliche Kette abbilden. Ein Prozess, der aus CSV-Export, Tabellenbearbeitung und manuellem Import besteht, ist dokumentationspflichtig, fehleranfällig und bei jeder Personalveränderung ein Risiko.
Die Zahlung ist kein Beleg
Eine Stripe-Transaktion belegt, dass Geld geflossen ist. Sie belegt nicht, wofür. Grundlage der Buchung ist die Rechnung mit den Pflichtangaben des § 14 UStG. Wo keine Rechnung entsteht, etwa bei reiner Checkout-Nutzung, fehlt der Buchführung ihr zentrales Dokument, unabhängig davon, wie sauber die Zahlungsdaten sind.
E-Rechnung: Die Pflicht verlangt XML, Stripe liefert PDF
Derselbe Kategorienfehler hat eine zweite Konsequenz, und die hat einen Termin. Für Umsätze ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Gesamtumsatz im Vorjahr inländische B2B-Rechnungen als E-Rechnung nach EN 16931 ausstellen, ab dem 1. Januar 2028 gilt das unabhängig vom Umsatz. Die Details, insbesondere die Sonderregeln für Dauerrechnungen im Abo-Geschäft, haben wir im Beitrag zur E-Rechnungspflicht 2027 aufgeschrieben.
Stripe Billing und Stripe Invoicing erzeugen PDF-Rechnungen, keine strukturierten E-Rechnungen nach EN 16931. Für XRechnung und ZUGFeRD verweist Stripe in den eigenen Ressourcen auf Partner-Anwendungen. Es gibt inzwischen einen eigenen Markt von Konvertern, die Stripe-Rechnungen nachträglich in E-Rechnungsformate wandeln.
Konverter haben allerdings eine Eigenschaft, die selten mitgenannt wird: Sie erben die Datenqualität ihrer Quelle. Eine E-Rechnung ist erst dann eine E-Rechnung, wenn Leistungszeitraum, Vertragsbezug und Steuerangaben als strukturierte Felder vorliegen. Was in Stripe nur als Positionstext oder gar nicht erfasst ist, kann kein Konverter erfinden. Aus einer unvollständigen PDF wird dann eine formal valide, inhaltlich unvollständige XRechnung, und die Reklamation kommt vom Kunden, dessen Vorsteuerabzug an der ordnungsgemäßen Rechnung hängt.
Formatpflege ist keine einmalige Aufgabe
Parallel zur Ausstellungspflicht steht ein Formatwechsel an: Die überarbeitete Norm EN 16931-1:2026 und die darauf aufbauende XRechnung 4.0 sind als grundlegende Weiterentwicklung des Datenmodells angekündigt. Wer die E-Rechnung über eine Konverter-Kette löst, übernimmt damit eine dauerhafte Wartungsaufgabe: Jede Formatrevision muss in jedem Glied der Kette nachgezogen werden.
Drei Wege, und was sie wirklich lösen
CSV und manuelles Nachbuchen
Funktioniert bei geringem Volumen und einfacher Steuerlage. Kostet jeden Monat Zeit, skaliert nicht, und der Prozess muss in der Verfahrensdokumentation beschrieben und gelebt werden. Für die E-Rechnungspflicht liefert dieser Weg nichts.
Connector und Konverter
Drittanbieter übertragen Zahlungsdaten Richtung DATEV, andere wandeln PDFs in E-Rechnungsformate. Das löst die Übertragung, nicht die Datenqualität, und es sind zwei getrennte Werkzeuge für zwei Symptome desselben Problems, beide mit laufender Format- und Schnittstellenpflege.
Billing-Schicht vor Stripe
Die Rechnung entsteht vor der Zahlung, aus der Vertragslogik heraus, mit Leistungszeitraum, Steuerlogik und Debitorenzuordnung als strukturierten Daten. DATEV-Export und E-Rechnung sind dann zwei Ausgaben derselben Quelle. Stripe bleibt als Zahlungsweg angebunden.
Fair bleibt die Einordnung nur mit dem Zusatz: Nicht jedes Unternehmen braucht den dritten Weg sofort. Wer eine Handvoll Rechnungen im Monat schreibt und überwiegend an Verbraucher verkauft, kommt mit den ersten beiden Wegen eine Weile aus. Die Rechnung dreht sich an drei erkennbaren Punkten: wenn das B2B-Geschäft wächst und damit die E-Rechnungspflicht greift, wenn Jahresverträge und Upgrades die Abgrenzung komplex machen, und wenn der Monatsabschluss zum wiederkehrenden Projekt wird.
Stripe behalten, die Rechnungsquelle verlagern
Der dritte Weg wird oft missverstanden als Abschied von Stripe. Das Gegenteil ist gemeint. Stripe ist als Zahlungsinfrastruktur schwer zu schlagen, als Rechnungsquelle war es nie gedacht. Plattformen wie Fynn setzen deshalb eine Ebene früher an: Der Vertrag ist die Quelle, daraus entstehen Rechnungen mit allen Pflichtangaben, GoBD-konform und als E-Rechnung ausgabefähig, mit nativem DATEV-Export für den Abschluss. Stripe bleibt als Zahlungsmethode angebunden und tut das, was es am besten kann. Wie sich die beiden Ansätze im Detail unterscheiden, zeigt der direkte Vergleich.
Der Export war nie das Problem
Buchhaltung und E-Rechnungspflicht scheitern bei Stripe-Setups an derselben Stelle: Die Daten, die eine Rechnung und ein Buchungssatz brauchen, entstehen nicht dort, wo die Zahlung verarbeitet wird. Man kann diese Lücke jeden Monat von Hand schließen, man kann sie mit Werkzeugen überbrücken, oder man kann sie an der Quelle schließen. Neu ist nur, dass die dritte Option jetzt einen Termin hat. Ab Januar 2027 ist die strukturierte Rechnung für einen wachsenden Teil der deutschen B2B-Unternehmen keine Kür mehr, und ein fester Termin ist im Zweifel das beste Argument, eine seit Jahren aufgeschobene Aufräumarbeit einmal richtig zu machen.
Häufige Fragen zu Stripe, DATEV und GoBD
Die Frage stellt sich so nicht. Die GoBD richten sich an deine Buchführung, nicht an den Zahlungsdienstleister. Entscheidend ist, ob aus den Stripe-Daten nachvollziehbare, unveränderbare Belege und Buchungen entstehen und ob der Weg dorthin in einer Verfahrensdokumentation beschrieben ist. Genau dieser Weg ist bei reinen Zahlungsdaten der aufwendige Teil.
Nein, nicht nativ. Stripe Billing und Stripe Invoicing erzeugen PDF-Rechnungen. Für strukturierte E-Rechnungen nach EN 16931 verweist Stripe auf Partner-Anwendungen, die Rechnungen nachträglich konvertieren.
Brutto. Der Umsatz wird in voller Höhe gebucht, die Gebühren separat als Aufwand, so verlangt es das Verrechnungsverbot des § 246 Abs. 2 HGB. Die Sammel-Auszahlung wird über ein Verrechnungskonto aufgelöst, auf dem Einzelumsätze, Gebühren und Erstattungen gegenläufig erfasst werden.
Formal ja, wenn das Ergebnis der EN 16931 entspricht. Praktisch nur dann, wenn die Quelldaten vollständig sind: Leistungszeitraum, Vertragsbezug und Steuerangaben müssen strukturiert vorliegen, sonst entsteht eine valide Datei mit unvollständigem Inhalt. Dazu kommt die laufende Formatpflege, etwa beim angekündigten Wechsel auf XRechnung 4.0.
Gerade dann. Die Anbindung ersetzt nicht den Steuerberater, sie ersetzt die CSV- und PDF-Sammlungen, mit denen er heute arbeitet. Strukturiert übergebene Belege und Buchungsdaten senken den Aufwand auf beiden Seiten und reduzieren Rückfragen im Abschluss.
Rechnungen, die Buchhaltung und E-Rechnungspflicht gleichzeitig erfüllen
Fynn erzeugt Rechnungen aus der Vertragslogik, exportiert nativ nach DATEV und stellt E-Rechnungen aus demselben Datensatz aus. Stripe bleibt als Zahlungsmethode angebunden. In einer Demo zeigen wir dir das an einem Setup mit Jahresvertrag, Upgrade und Gutschrift.