Inhalt

Welche DATEV-Schnittstellen es gibt

DATEV hat über die Jahre mehrere Wege gebaut, Daten rein und raus zu bekommen. Nicht alle sind gleich gut für Automatisierung geeignet:

  • DATEV Unternehmen online (DUO) API — moderner REST-Endpoint, OAuth-basiert, mit guter Doku. Erste Wahl für Belegtransfer und kleinere Stammdaten-Flows.
  • DATEVconnect online — webservices-basiert, eher für ERP-zu-DATEV-Anbindung gedacht. Solide aber sperrige Auth.
  • ASCII-Schnittstelle (postversand-format) — der Klassiker. Liefert Buchungssätze als CSV-Export, der vom Steuerberater eingelesen wird. Nicht echtzeit-fähig, aber bombensicher.
  • Belegtransfer — direkter Upload von Belegen als PDF mit Metadaten. Funktioniert über DUO API.
  • DATEVconnect (klassisch) — der alte SOAP-Pfad, läuft noch in vielen Kanzleien. Nicht empfohlen für Neuprojekte.
Faustregel: Wenn der Steuerberater es noch nicht digital macht, ist der ASCII-Export plus Sharepoint-Übergabe der schnellste Weg zu Wirkung. „API zum Steuerberater“ klingt schicker, scheitert aber oft am Steuerberater.

Typische Anwendungsfälle

  • Belegtransfer aus dem Shop — Eingangsrechnungen aus Shopware, JTL oder einem Lieferanten-Portal landen automatisch in DATEV Unternehmen online, mit Buchungsvorschlag.
  • Ausgangsrechnungen aus dem CRM — Verkaufsbelege aus HubSpot oder Salesforce werden samt Kontakt-, Leistungs- und Steuerdaten an DATEV übergeben.
  • Reisekostenabrechnung — App-Belege werden klassifiziert, mit Kostenstelle und Projekt versehen, und in den Belegtransfer geschoben.
  • Mahnwesen — offene Posten aus DATEV werden in den Workflow geholt, Kunden bekommen automatisch ein abgestuftes Mahnschreiben.

n8n-Workflow-Pattern

Ein robuster DATEV-Workflow hat fast immer dieselbe Struktur:

  • Trigger: Webhook aus dem Quellsystem, Cron, oder neuer Eintrag in einer DB
  • Validate: Pflichtfelder, Steuerschlüssel, Konten, Belegdatum-Plausibilität
  • Transform: Mapping ins DATEV-Format (ASCII oder DUO-JSON)
  • Submit: API-Call mit OAuth-Token, mit Retry und Fehler-Routing
  • Confirm: Erfolg / Fehler kommt zurück, wird im Quellsystem markiert
  • Notify: bei dauerhaftem Fehler eine Slack-Nachricht an die Buchhaltung

Was üblicherweise bricht

In der Praxis sind es immer dieselben Stolpersteine:

  • OAuth-Token läuft nach 12 Monaten ab. Workflow steht still. → Token-Rotation als eigener Workflow mit Vorlauf-Reminder.
  • Steuerschlüssel ändert sich (z. B. UStG-Anpassung). → Steuerschlüssel als Mapping-Tabelle, nicht hartcodiert.
  • Beleg ist zu groß oder im falschen Format. → Pre-Check vor Upload, mit klarer Fehlerausgabe.
  • Steuerberater ändert Kanzleisoftware. → ASCII-Format bleibt stabil, API-Endpoints können sich ändern.
  • Mehrere Mandanten, gleicher Beleg-Typ. → Mandant explizit im Workflow auswählen, nie aus dem User-Account ableiten.

Welche DATEV-Strecke ist bei Ihnen heute manuell?

Wir prüfen Schnittstelle, Mandanten-Setup und Token-Lebenszyklus, bevor wir bauen. Dauer für Audit + Vorschlag: 5 Werktage.

DATEV-Anbindung anfragen

Fazit

DATEV via n8n ist machbar und stabil, wenn man sich für den richtigen Schnittstellen-Pfad entscheidet und Token, Mappings und Fehler-Logik nicht als Detail behandelt. Wer das ignoriert, bekommt einen Workflow, der drei Monate läuft und dann nachts kollabiert.