WooCommerce DATEV Schnittstelle für Buchhaltung und Steuerberater

#WooCommerce DATEV Schnittstelle für Buchhaltung und Steuerberater

Wenn Sie Bestand, Einkaufspreise und Lager synchronisieren wollen, führt der Weg über eine Warenwirtschaftsanbindung wie JTL-Wawi, die auf der Übersichtsseite WooCommerce-Integrationen mit ERP- und Großhandels-APIs beschrieben ist. Hier geht es ausschließlich um den Fluss der buchhalterisch relevanten Daten Richtung DATEV.

#Was DATEV ist und warum das für den Shop wichtig ist

DATEV eG ist eine Genossenschaft mit Sitz in Nürnberg und der De-facto-Standard, über den in Deutschland Steuerberater und Kanzleien mit ihren Mandanten arbeiten. Für einen Onlineshop bedeutet das: Die Zahlen aus WooCommerce müssen am Ende in einer Form ankommen, die Ihr Steuerberater in seiner DATEV-Umgebung einlesen und in die Finanzbuchhaltung übernehmen kann.

Anders als bei einer Warenwirtschaft interessiert DATEV nicht, wie viele Einheiten eines Artikels im Lager liegen. DATEV interessiert, welcher Betrag mit welchem Steuersatz auf welches Konto gebucht wird, gegen welchen Debitor, mit welchem Beleg. Genau diese Übersetzung leistet eine WooCommerce-DATEV-Schnittstelle. Sie nimmt eine abgeschlossene Bestellung und macht daraus einen sauberen Buchungssatz.

#Was die Schnittstelle wirklich bewegt

Eine DATEV-Anbindung transportiert Daten aus WooCommerce hinein in DATEV, im Regelfall in eine Richtung. Konkret sind das:

• Rechnungs- und Belegdaten: Rechnungsnummer, Rechnungsdatum, Leistungsdatum, Netto- und Bruttobeträge je Steuersatz.
• Steuerinformationen: der zugeordnete Steuerschlüssel je Position und der jeweilige Steuersatz.
• Kontenzuordnung: das Erlöskonto je Steuerfall und das Debitorenkonto des Kunden.
• Zahlungsdaten: Zahlungsart, Zahlungseingang und die Gebühren der Zahlungsdienstleister.

Die üblichen Übergabewege sind der DATEV-Rechnungsdatenservice 1.0 und 2.0, DATEV Unternehmen online als Portal, in das Belege und Buchungsstapel hochgeladen werden, sowie DATEVconnect für einen direkten, programmatischen Import in der Kanzlei. Welcher Weg passt, hängt davon ab, wie Ihr Steuerberater arbeitet, nicht davon, was technisch am elegantesten wäre.

#GoBD-konforme, revisionssichere Belege

Der Kern jeder ernsthaften DATEV-Anbindung ist die belegbasierte Buchung nach den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (GoBD). Praktisch heißt das drei Dinge.

Erstens sind Belege unveränderbar und nachvollziehbar. Zu jeder Buchung gehört genau ein Beleg, und jede Buchung lässt sich zur ursprünglichen WooCommerce-Bestellung zurückverfolgen. Zweitens laufen Rechnungsnummern lückenlos und ohne Dubletten. Eine Schnittstelle, die bei einem Timeout blind erneut sendet und dabei einen zweiten Beleg mit neuer Nummer erzeugt, verletzt genau dieses Prinzip. Drittens werden Korrekturen als Storno oder Gutschrift gebucht, nie durch Überschreiben eines bestehenden Belegs.

Wir vergeben deshalb pro Bestellung eine stabile externe Referenz und prüfen vor jedem erneuten Versand, ob der Beleg bereits in DATEV angekommen ist. Die tatsächliche Aufbewahrungsfrist der Belege wird ausdrücklich mit der Kanzlei festgelegt, nicht im Shop stillschweigend angenommen.

#Steuerschlüssel und Kontenrahmen richtig mappen

Hier entscheidet sich, ob eine Anbindung taugt. WooCommerce kennt Steuerklassen (Standard 19 Prozent, ermäßigt 7 Prozent, steuerfrei und individuell definierte Klassen). DATEV kennt Steuerschlüssel und Erlöskonten. Die Schnittstelle ist die Übersetzungstabelle dazwischen.

Zuvor muss der Kontenrahmen feststehen. SKR03 ist prozessgliederungsorientiert, SKR04 abschlussgliederungsorientiert. Welcher gilt, gibt Ihre Kanzlei vor. Dieselben Steuerfälle landen je nach Rahmen auf anderen Kontonummern.

Die Kontonummern in dieser Tabelle sind der übliche Standard und dienen zur Orientierung. Verbindlich ist immer der individuelle Kontenplan Ihrer Kanzlei. Genau deshalb klären wir das Mapping vor der Entwicklung gemeinsam mit dem Steuerberater und nicht danach.

Eine zweite Entscheidung betrifft die Debitorenseite. Ein Endkundenshop führt selten für jeden einzelnen Käufer ein eigenes Debitorenkonto. Üblich ist ein Sammeldebitor je Zahlungsart oder Verkaufskanal, auf dem die Umsätze gebündelt gebucht werden, während echte Stammkunden im B2B-Geschäft ein Einzeldebitorenkonto erhalten. Die Schnittstelle muss wissen, welcher Fall wann gilt, damit die offene-Posten-Verwaltung in DATEV nicht mit tausenden Einmalkäufern überläuft. Auch das legen wir mit der Kanzlei fest, bevor der erste Beleg fließt.

#OSS und grenzüberschreitende Umsatzsteuer

Für viele Shops ist der One-Stop-Shop der eigentliche Grund, eine Schnittstelle statt eines CSV-Exports zu bauen. Seit Juli 2021 gilt bei B2C-Verkäufen in andere EU-Länder oberhalb der EU-weiten Lieferschwelle der Umsatzsteuersatz des Bestimmungslandes. Ein Verkauf nach Frankreich trägt französische Umsatzsteuer, einer nach Österreich österreichische.

Diese Fälle müssen in DATEV sauber getrennt von inländischen Umsätzen erscheinen, damit die vierteljährliche OSS-Meldung stimmt. Die Schnittstelle erkennt dazu die Kombination aus Zielland, Kundentyp und USt-IdNr und leitet daraus den richtigen Fall ab:

• B2C in ein anderes EU-Land: OSS-Steuerschlüssel für den Satz des Ziellandes, gebucht auf ein separates OSS-Erlöskonto.
• B2B mit gültiger, geprüfter USt-IdNr: steuerfreie innergemeinschaftliche Lieferung im Reverse-Charge-Verfahren.
• Inland: normaler deutscher Satz auf das reguläre Erlöskonto.

Wenn diese Logik im Shop fehlt, landet ein französischer B2C-Umsatz mit deutschem Steuerschlüssel in der Buchhaltung, und der Fehler fällt erst bei der OSS-Meldung auf, oft Wochen später.

Konkret führt die Schnittstelle je EU-Bestimmungsland einen eigenen Satz und eine eigene Länderkennung. Ein Verkauf nach Frankreich wird mit dem französischen Regelsatz von 20 Prozent bewertet, einer in die Niederlande mit 21 Prozent, einer nach Italien mit 22 Prozent, und jeder Betrag wird über den Länderschlüssel eindeutig zuordenbar auf ein OSS-Erlöskonto gebucht. Der Grund ist die vierteljährliche OSS-Meldung: Sie verlangt die Bemessungsgrundlage und die geschuldete Steuer je Bestimmungsland getrennt. Setzt die Schnittstelle nur einen pauschalen OSS-Schlüssel, muss die Kanzlei die Länderaufteilung am Quartalsende von Hand aus den Bestellungen rekonstruieren. Deshalb mappen wir Zielland auf Satz und Länderkennung bereits im Beleg und nicht erst bei der Meldung. Ein weiterer Fallstrick ist die Lieferschwelle: Unterhalb des EU-weiten Schwellenwerts darf weiter mit deutschem Satz fakturiert werden, und die Schnittstelle muss den Umschaltpunkt kennen, statt pauschal jeden Auslandsverkauf über OSS zu buchen.

#Der Übergabe-Workflow zum Steuerberater

Eine Schnittstelle ist erst dann gut, wenn sie sich in den Arbeitsrhythmus der Kanzlei einfügt. Drei Varianten sind üblich, und der Unterschied ist organisatorisch, nicht nur technisch.

• DATEV Unternehmen online: Der Shop schiebt Belege und Buchungsstapel in das Portal. Der Mandant sieht seine Belege selbst, die Kanzlei greift auf denselben Datenbestand zu. Passt, wenn Sie einen laufenden, engen Austausch mit der Kanzlei wollen.
• Rechnungsdatenservice: Rechnungsdaten und Belegbilder werden strukturiert übergeben und in der Kanzlei automatisch weiterverarbeitet. Passt für hohe Belegzahlen mit wenig manueller Nacharbeit.
• Direkter Import in der Kanzlei über DATEVconnect: Die Kanzlei liest die aufbereiteten Daten direkt in ihre DATEV-Installation ein. Passt, wenn die Kanzlei den Prozess vollständig steuern will.

Ebenso wichtig wie der Weg ist die Taktung. Ein täglicher Export hält die Buchhaltung aktuell, ein monatlicher reicht kleinen Shops. Wir legen die Frequenz so fest, dass sie zum Belegvolumen passt und die Kanzlei nicht in unregelmäßigen Schüben Belege nachbuchen muss.

#Rechnungsdatenservice 1.0 und 2.0 im Detail

Der Formatunterschied zwischen den beiden Versionen des Rechnungsdatenservice entscheidet, wie viel Steuerlogik im Shop und wie viel in der Kanzlei liegt. Version 1.0 überträgt im Kern das fertige Buchungsergebnis: pro Rechnung Betrag, Steuerschlüssel, Konto und Gegenkonto, dazu das PDF als Bildbeleg. Die Kontenfindung und das Steuerschlüssel-Mapping passieren dabei vollständig in der Middleware des Shops, und DATEV übernimmt den fertigen Buchungssatz. Version 2.0 transportiert die Rechnung zusätzlich als strukturierten Datensatz auf Positionsebene, sodass einzelne Rechnungspositionen, Steuersätze und Beträge maschinenlesbar in der Kanzlei ankommen und nicht aus einem Sammelbetrag rekonstruiert werden müssen. Das erlaubt, einen Teil der Kontenlogik in der DATEV-Umgebung der Kanzlei zu belassen, statt sie im Shop hart zu verdrahten.

Praktisch heißt das: Wollen Sie die Steuerhoheit vollständig im Shop halten und der Kanzlei nur das Ergebnis liefern, genügt 1.0. Soll die Kanzlei auf Positionsebene prüfen und Konten teils selbst zuordnen, ist 2.0 der bessere Weg. Wir klären das, bevor wir das Belegformat festlegen, denn ein späterer Formatwechsel berührt die gesamte Mapping-Schicht und nicht nur eine Einstellung.

#Zahlungsabgleich: PayPal, Stripe und Klarna

Der am meisten unterschätzte Teil ist der Zahlungsabgleich. Zahlungsdienstleister zahlen nicht pro Bestellung aus, sondern gesammelt und nach Abzug ihrer Gebühren. Eine PayPal-Auszahlung von einem Betrag, der zehn Bestellungen abzüglich Gebühren entspricht, lässt sich nicht ohne Weiteres einzelnen Rechnungen zuordnen.

Die Schnittstelle löst das, indem sie die Auszahlung des Zahlungsdienstleisters gegen die zugrundeliegenden Bestellungen aufschlüsselt, die Gebühr als eigenen Aufwand trennt und den Nettobetrag dem Geldkonto zuordnet. Ergebnis: Das Bankkonto in DATEV stimmt am Ende mit dem tatsächlichen Zahlungseingang überein, und die Kanzlei muss die Sammelauszahlung nicht manuell zerlegen. Ohne diesen Schritt entsteht eine Dauerbaustelle, in der Zahlungseingänge und Rechnungssummen nie ganz zusammenpassen.

#Sonderfälle beim Zahlungsabgleich

Teilerstattungen, Rückbelastungen und verzögerte Auszahlungen sind die Fälle, an denen ein naiver Abgleich scheitert. Eine Teilerstattung darf nicht den ganzen Beleg stornieren, sondern erzeugt eine anteilige Gutschrift mit dem passenden Steuerschlüssel, damit die ausgewiesene Umsatzsteuer anteilig sinkt und nicht der komplette Umsatz aus der Buchhaltung verschwindet. Eine Rückbelastung ist weder Verkauf noch Gutschrift, sondern ein eigener Vorgang: Die ursprüngliche Forderung bleibt bestehen, während das Geld vom Konto abgeht, häufig zusätzlich mit einer Rückbuchungsgebühr des Zahlungsdienstleisters, die separat als Aufwand gebucht wird.

Der praktisch heikelste Fall ist der zeitliche Versatz. Bei Klarna und ähnlichen Diensten entsteht die Rechnung am Bestelltag, die Auszahlung kommt aber Wochen später und gesammelt. Belegdatum und Zahlungseingang fallen also auseinander, und wer beide gleichsetzt, bucht den Umsatz doppelt. Die Schnittstelle bucht deshalb die Forderung zum Belegdatum gegen ein eigenes Debitorenkonto des Zahlungsdienstleisters und behandelt die spätere Sammelauszahlung als Ausgleich dieser offenen Posten abzüglich Gebühr, nicht als neuen Erlös. So bleibt die offene-Posten-Liste über den Monat hinweg sauber.

#Zwei Fehlerbilder aus der Praxis

Fall 1 - der falsche Steuerschlüssel bei OSS. Ein Modehändler verkaufte über WooCommerce EU-weit, hatte den One-Stop-Shop aktiviert, aber die Steuerklassen im Shop nie auf getrennte DATEV-Schlüssel gemappt. Alle EU-B2C-Umsätze liefen mit dem deutschen 19-Prozent-Schlüssel in die Buchhaltung. Die inländische Umsatzsteuervoranmeldung war dadurch zu hoch, die OSS-Meldung unvollständig. Die Korrektur bestand nicht darin, mehr zu exportieren, sondern das Mapping zwischen Zielland und OSS-Steuerschlüssel überhaupt erst einzuziehen und die betroffenen Belege neu zu bewerten.

Fall 2 - doppelte Belege nach Timeout. Ein Shop übergab Rechnungen ohne stabile Referenz an DATEV Unternehmen online. Bei einem API-Timeout wiederholte das Skript den Versand blind und erzeugte einen zweiten Beleg mit neuer Rechnungsnummer für denselben Verkauf. Über Monate summierten sich Dutzende Dubletten, die Umsätze doppelt auswiesen. Die GoBD verlangt lücken- und dublettenfreie Nummern, also war das kein Schönheitsfehler, sondern ein Ordnungsmangel. Die Lösung war eine idempotente Übergabe: stabile externe Referenz je Bestellung und eine Prüfung, ob der Beleg schon angekommen ist, bevor erneut gesendet wird.

Fall 3 - ungeprüfte USt-IdNr beim B2B-Verkauf. Ein Großhandelsshop buchte jeden Verkauf mit angegebener USt-IdNr automatisch steuerfrei als innergemeinschaftliche Lieferung, ohne die Nummer gegen das qualifizierte Bestätigungsverfahren zu prüfen. Einige Nummern waren ungültig oder gehörten nicht zum angegebenen Kunden. Bei der Prüfung stufte das Finanzamt diese Umsätze als steuerpflichtig ein, und die nicht erhobene Umsatzsteuer wurde nachgefordert. Die Korrektur bestand darin, die USt-IdNr vor der steuerfreien Buchung qualifiziert zu bestätigen und im Zweifel mit deutschem Satz zu fakturieren, statt sich auf die bloße Existenz einer Nummer im Bestellformular zu verlassen. Der reine Datenfluss nach DATEV war hier korrekt; falsch war die Steuerentscheidung davor.

#Wann Sie das brauchen und wann nicht

Ehrlich gesagt braucht nicht jeder Shop eine gebaute Schnittstelle. Die Grenze verläuft entlang von Volumen und Steuerkomplexität.

Ein einfacher Export reicht oft, wenn:

• Sie wenige Bestellungen pro Monat haben und rein im Inland verkaufen.
• Ihre Kanzlei mit einem monatlichen CSV- oder DATEV-Export gut arbeiten kann.
• Nur ein Zahlungsweg im Einsatz ist und der Abgleich manuell in Minuten erledigt ist.

Eine echte Schnittstelle zahlt sich aus, wenn:

• Das Belegvolumen so hoch ist, dass manueller Export und Nachbearbeitung spürbar Zeit kosten.
• Sie EU-weit an Endkunden verkaufen und OSS korrekt getrennt buchen müssen.
• Mehrere Zahlungsdienstleister mit Sammelauszahlungen und Gebühren im Spiel sind.
• Die Kanzlei laufend aktuelle Zahlen braucht, statt einmal im Monat einen Stapel zu erhalten.

Wir sagen Ihnen im Scoping klar, auf welcher Seite dieser Linie Ihr Shop steht. Wenn ein Export genügt, empfehlen wir keinen Schnittstellenbau.

#Was in Ihre Anfrage gehört

Damit wir ein abgegrenztes Angebot statt einer Schätzung liefern können, helfen uns: der Shop-Link, der von Ihrer Kanzlei genutzte Kontenrahmen (SKR03 oder SKR04), die relevanten Steuerfälle (Inland, EU-B2C mit OSS, EU-B2B, Drittland), die eingesetzten Zahlungsdienstleister, der bevorzugte Übergabeweg (Rechnungsdatenservice, DATEV Unternehmen online oder direkter Import) sowie ein Ansprechpartner in der Kanzlei. Für komplexe Fälle mit hohem Volumen und Headless-Architektur beschreiben wir das Vorgehen unter Enterprise-Lösungen; geht es Ihnen zunächst um Aufbau und Pflege des Shops selbst, beginnen Sie bei WooCommerce-Entwickler.