DATEV-Automatisierung: Belege und Daten kontrolliert übertragen

Problem und Zielgruppe

In vielen KMU laufen operative Systeme — Warenwirtschaft, CRM, Projekttool, E-Mail-Postfach — und die Buchhaltung nebeneinander her, verbunden nur durch Menschen, die Daten von einem System ins andere übertragen. Eine Rechnung wird im Vertriebstool erstellt, als PDF exportiert, per E-Mail an die Buchhaltung geschickt, dort heruntergeladen und in DATEV Unternehmen online hochgeladen oder händisch als Buchungssatz erfasst. Bei jedem dieser Schritte kann etwas verloren gehen, doppelt erfasst werden oder veralten, bevor es ankommt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die diesen Medienbruch kennen und wissen wollen, welche Schnittstellen DATEV für die automatisierte Übertragung von Belegen und Daten tatsächlich bietet, welche Daten sich darüber bewegen lassen und wo die Grenzen liegen. Es geht nicht um ein einzelnes Tool, sondern um die Frage, welcher Übertragungsweg zu welchem Datentyp passt — und wie du Fehler kontrolliert statt zufällig abfängst.

Meine Position aus Projekten: DATEV-Automatisierung scheitert seltener an der Technik als an der Vermischung zweier unterschiedlicher Dinge. Belege (Dokumente) und Buchungsdaten (strukturierte Datensätze) sind zwei getrennte Datenflüsse mit unterschiedlichen Schnittstellen. Wer das nicht sauber trennt, baut einen Workflow, der Belege hochlädt und hofft, dass daraus irgendwie automatisch Buchungssätze werden — das passiert nicht von selbst.

Begriffe kurz geklärt

DATEV Unternehmen online ist die Cloud-Plattform, über die Unternehmen Belege und Dokumente mit ihrer Steuerkanzlei austauschen. Sie ist der übliche Zielpunkt für automatisierten Belegupload, nicht für Buchungssätze im eigentlichen Sinn.

Belegtransfer bezeichnet den Weg, auf dem digitale Belege — gescannte Rechnungen, PDF-Dokumente, Quittungen — nach DATEV Unternehmen online gelangen: per Upload-Ordner, per XML-Schnittstelle für bereits strukturierte Rechnungsdaten, oder aus einer angebundenen Dokumentenverwaltung (DMS).

DATEV-Format ist ein CSV-basierter Standard für strukturierte Buchungsdaten. Jede Datei beginnt mit einem festen Kennzeichner (EXTF) und einer Header-Zeile, die Formatversion, Erstellungsdatum, Wirtschaftsjahr und weitere Steuerinformationen enthält, gefolgt von den eigentlichen Datenzeilen — etwa einem Buchungsstapel mit Konten, Beträgen und Buchungstexten.

DATEVconnect ist die Bezeichnung für die programmatischen Schnittstellen (APIs) im DATEV Developer Portal, über die Drittsysteme direkt mit DATEV-Anwendungen und Stammdaten verbunden werden können — im Unterschied zum reinen Datei-Up- und -Download.

n8n ist eine Fair-Code-lizenzierte, selbst hostbare Workflow-Automatisierungsplattform, die laut eigener Dokumentation Automatisierung mit KI-Fähigkeiten kombiniert — relevant, wenn du DATEV-relevante Daten aus mehreren Quellsystemen zusammenführen willst, bevor sie DATEV erreichen.

Power Automate ist Microsofts Plattform für Workflow-Automatisierung mit einem breiten Connector-Ökosystem für Dateisynchronisation, Benachrichtigungen und Freigabeprozesse — im DATEV-Kontext meist als vorgelagerter Schritt genutzt, der Daten aus anderen Microsoft- oder Drittsystemen sammelt und aufbereitet, bevor sie in ein DATEV-kompatibles Format überführt werden.

Diese Bausteine ersetzen sich nicht gegenseitig: n8n oder Power Automate übernehmen typischerweise das Sammeln, Aufbereiten und Auslösen, während der eigentliche Transport zu DATEV über Belegtransfer, DATEV-Format-Dateien oder DATEVconnect läuft.

Welche Schnittstellen gibt es?

Für DATEV-Automatisierung sind praktisch drei Wege relevant, die unterschiedliche Zwecke erfüllen:

1. Belegtransfer nach DATEV Unternehmen online. Der Weg für Dokumente, nicht für Buchungssätze. Drei Varianten sind üblich: ein überwachter Upload-Ordner, in den automatisiert abgelegte Dateien hochgeladen werden; eine XML-Schnittstelle für bereits strukturierte Rechnungsdaten; und eine Anbindung an eine Dokumentenverwaltung (DMS), aus der Belege direkt übertragen werden.
2. DATEV-Format für Buchungsdaten. Der Weg für strukturierte Buchungssätze, Debitoren- und Kreditorenstammdaten. Dateien im DATEV-Format sind CSV-Dateien mit einem festen, spezifizierten Header (Formatkennzeichen EXTF, Formatversion, Zeitraum, Berater- und Mandantennummer) und einer definierten Spaltenstruktur je Datensatzart — etwa Buchungsstapel oder Stammdaten.
3. DATEVconnect-APIs. Der Weg für direkte, programmatische Anbindungen, dokumentiert im DATEV Developer Portal. Diese Online-Schnittstellen sind an eine DATEV-Partnerschaft gebunden: Wer sie nutzen will, muss als Softwarehersteller oder Dienstleister bei DATEV registriert und geprüft sein — es ist keine offene, frei nutzbare Schnittstelle wie eine öffentliche REST-API.

Für die meisten KMU ohne eigene Softwareentwicklung sind die ersten beiden Wege relevant: Belege über den Belegtransfer, Buchungsdaten über das DATEV-Format, oft ausgelöst und aufbereitet durch ein Automatisierungswerkzeug wie n8n oder Power Automate. Die DATEVconnect-APIs kommen typischerweise ins Spiel, wenn ein Softwareanbieter oder eine größere IT-Abteilung eine tiefere, dauerhafte Integration baut — nicht als Einstiegspunkt für die erste Automatisierung.

Welche Daten lassen sich übertragen?

Die beiden Datenflüsse aus dem vorigen Abschnitt transportieren unterschiedliche Dinge:

• Über den Belegtransfer: Dokumente mit Metadaten — PDF-Rechnungen, gescannte Quittungen, Verträge, Kontoauszüge. Diese landen als Belege in DATEV Unternehmen online, bleiben aber zunächst Dokumente, keine Buchungssätze.
• Über das DATEV-Format: strukturierte Datensätze — Buchungsstapel (Konto, Gegenkonto, Betrag, Buchungstext, Belegdatum), Debitoren- und Kreditorenstammdaten (Name, Adresse, Bankverbindung, Kontonummer im Kontenrahmen).

Der wichtigste Punkt, der in der Praxis oft übersehen wird: Ein automatisiert hochgeladener Beleg wird dadurch nicht automatisch zu einem gebuchten Vorgang. Beleg und Buchungssatz sind zwei getrennte Objekte, die erst durch eine Zuordnung miteinander verbunden werden — entweder automatisch über Metadaten, die beim Beleg mitgeliefert werden, oder manuell in der Kanzlei beziehungsweise Buchhaltung. Wer Automatisierung plant, sollte deshalb von Anfang an festlegen, ob das Ziel „Belege liegen vollständig und auffindbar in DATEV Unternehmen online” ist oder „Buchungssätze entstehen automatisiert” — das sind zwei unterschiedlich aufwändige Vorhaben.

Wie werden Belege zugeordnet?

Ein hochgeladener Beleg braucht Metadaten, damit er später mit dem passenden Buchungsvorgang verknüpft werden kann. In der Praxis sind das mindestens: Belegdatum, Lieferant oder Kunde, Betrag, Belegart (Eingangsrechnung, Ausgangsrechnung, Quittung) und im besten Fall eine eindeutige Belegnummer.

Diese Metadaten entstehen auf zwei Wegen:

• Strukturiert mitgeliefert. Bei E-Rechnungsformaten wie XRechnung oder ZUGFeRD sind die relevanten Felder bereits als maschinenlesbare Daten im Dokument enthalten — die Zuordnung ist dadurch deutlich zuverlässiger, weil nichts erraten werden muss.
• Nachträglich extrahiert. Bei einer unstrukturierten PDF- oder Scan-Rechnung muss ein vorgelagerter Automatisierungsschritt (etwa eine Extraktions-Engine mit OCR, wie im Artikel zur Rechnungsverarbeitung beschrieben) die Felder zuerst herauslesen, bevor sie als Metadaten mit dem Beleg mitgeschickt werden.

Ohne diese Zuordnung landet ein Beleg zwar im System, bleibt für die Buchhaltung aber ein loses Dokument ohne Kontext — jemand muss ihn manuell dem richtigen Vorgang zuweisen. Genau das ist der Punkt, an dem viele Automatisierungsprojekte den größten Zeitgewinn liegen lassen: Der Upload ist automatisiert, die Zuordnung nicht, und der eigentliche manuelle Aufwand bleibt bestehen, er verschiebt sich nur.

Wie behandelt man Fehler?

Ein Automatisierungsworkflow, der DATEV-relevante Daten überträgt, braucht definierte Stopppunkte statt stillem Weiterlaufen. In der Praxis bewähren sich drei Prüfebenen vor der eigentlichen Übertragung:

• Formatprüfung. Entspricht die Datei der erwarteten Struktur — bei DATEV-Format-Dateien etwa dem korrekten EXTF-Header und der passenden Formatversion? Fehlerhafte Header führen sonst dazu, dass eine ganze Datei beim Import abgelehnt wird, nicht nur der fehlerhafte Datensatz.
• Feldprüfung. Sind Pflichtfelder wie Betrag, Datum, Konto tatsächlich befüllt und plausibel (kein negativer Betrag, kein Datum außerhalb des Buchungszeitraums)?
• Zuordnungsprüfung. Passt der Beleg zu einem bekannten Lieferanten oder Konto, oder handelt es sich um einen neuen, noch nicht angelegten Stammdatensatz?

Datensätze, die eine dieser Prüfungen nicht bestehen, sollten nicht verworfen, sondern in eine Fehlerliste mit Ursache geleitet werden — Formatfehler, fehlendes Feld, unbekannter Lieferant. Diese Liste ist der Ort für die manuelle Nacharbeit, nicht der komplette Workflow. Ein Workflow, der bei jedem Fehler komplett abbricht, ist unpraktisch; einer, der Fehler stillschweigend überspringt, ist gefährlich, weil Belege oder Buchungen ohne Spur verschwinden. Wichtig ist außerdem ein Protokoll: Wer hat wann welche Datei mit welchem Ergebnis übertragen — das ist im Streitfall (etwa bei einer fehlenden Zahlung) oft die einzige Nachvollziehbarkeit.

Aus meiner Erfahrung lohnt sich zusätzlich eine klare Trennung zwischen zwei Fehlerarten: technischen Fehlern (Datei lässt sich nicht lesen, Header stimmt nicht) und fachlichen Fehlern (Datei ist technisch korrekt, aber ein Betrag oder ein Konto sieht falsch aus). Technische Fehler gehören zur IT oder zum Automatisierungsverantwortlichen, fachliche Fehler zur Buchhaltung oder Kanzlei. Wer beide in dieselbe Fehlerliste ohne Kennzeichnung wirft, erzeugt unnötige Rückfragen zwischen den Beteiligten, weil niemand auf Anhieb weiß, wer zuständig ist.

Welche Abstimmung ist nötig?

DATEV-Automatisierung ist kein rein internes IT-Projekt — sie berührt immer eine zweite Partei, die Steuerkanzlei, und oft einen dritten, den DATEV-Partnerstatus. Vor dem Aufsetzen gehören folgende Punkte geklärt:

• Mit Steuerberatung oder DATEV-Partner: Welches Format und welcher Übertragungsweg passt zum bestehenden Kanzleisetup? Nicht jede Kanzlei nutzt jeden Weg gleich, und ein Format, das die Kanzlei nicht erwartet, führt zu Rückfragen statt Zeitersparnis.
• Zugang und Berechtigung: DATEVconnect-Online-Schnittstellen sind laut DATEV Developer Portal an eine DATEV-Partnerschaft gebunden — für den reinen Belegtransfer oder DATEV-Format-Export braucht es das nicht zwingend, wohl aber die passenden Zugangsdaten und Berechtigungen in DATEV Unternehmen online.
• Intern: Wer ist verantwortlich, wenn die Automatisierung eine Fehlerliste produziert? Wie oft wird sie geprüft? Welche Fristen (Monatsabschluss, Umsatzsteuervoranmeldung) hängen von einer pünktlichen Übertragung ab?
• Rechtlich, im Rahmen der E-Rechnungspflicht. Seit dem 1. Januar 2025 gilt in Deutschland schrittweise die Pflicht zur elektronischen Rechnung im inländischen B2B-Geschäft; laut FAQ des Bundesministeriums der Finanzen dürfen Rechnungsaussteller in den Jahren 2025 und 2026 noch zwischen E-Rechnung und sonstiger Rechnung wählen, ab 2027 gilt die Pflicht für Unternehmen mit einem Vorjahresumsatz über 800.000 Euro, ab 2028 grundsätzlich für alle. Die Empfangspflicht für E-Rechnungen gilt dagegen bereits seit 2025 ohne Übergangsfrist. Als zulässige Formate nennt das BMF insbesondere XRechnung und ZUGFeRD ab Version 2.0.1. Dieser Absatz ersetzt keine steuerliche Beratung; Stand ist Juli 2026, Details gehören vor einer Umstellung mit Steuerberatung abgeglichen.

Eigene Entscheidungsmatrix: Welcher Übertragungsweg passt?

Aus Projekten hat sich bei mir folgende Faustregel bewährt, um vor dem ersten Automatisierungsschritt den passenden Weg einzugrenzen:

Ausgangslage	Passender Weg	Typischer Aufwand
Belege liegen als PDF/Scan vor, sollen zuverlässig in DATEV Unternehmen online landen	Belegtransfer über Upload-Ordner, ggf. mit vorgelagerter Extraktion für Metadaten	Gering bis mittel
Lieferanten liefern bereits strukturierte E-Rechnungen (XRechnung/ZUGFeRD)	Belegtransfer über XML-Schnittstelle, Metadaten kommen direkt mit	Gering
Buchungssätze aus einem operativen System (Kasse, Warenwirtschaft, CRM) sollen automatisiert in die Buchhaltung	Export ins DATEV-Format als Buchungsstapel, danach Import in der Kanzlei oder direkt in DATEV	Mittel bis hoch
Dauerhafte, tiefe Anbindung eines eigenen Softwareprodukts an DATEV-Stammdaten	DATEVconnect-API über DATEV Developer Portal	Hoch, an Partnerschaft gebunden
Mehrere Quellsysteme sollen vor der Übertragung zusammengeführt und geprüft werden	Vorgeschalteter Workflow (n8n, Power Automate) plus einer der drei DATEV-Wege als letzter Schritt	Mittel bis hoch, abhängig von Quellenzahl

Eigene Entscheidungshilfe Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten. Kein Ersatz für die technische Abstimmung mit Steuerberatung oder DATEV-Partner im Einzelfall.

Umsetzung: realistische Reihenfolge

1. Datenfluss trennen. Zuerst klären, ob Belege, Buchungsdaten oder beides automatisiert werden sollen — und das getrennt planen, nicht als ein Projekt.
2. Kanzlei einbeziehen. Vor jeder technischen Entscheidung mit der Steuerkanzlei abstimmen, welches Format und welcher Weg dort ankommen kann und erwartet wird.
3. Quellsystem und Trigger festlegen. Woher kommen die Daten (E-Mail-Postfach, ERP-Export, Kassensystem), und was löst die Übertragung aus — ein Zeitplan, ein neues Dokument, ein Monatsabschluss?
4. Aufbereitung bauen. Mit einem Automatisierungswerkzeug die Rohdaten in das Zielformat bringen: Metadaten für den Belegtransfer ergänzen, oder Buchungssätze ins DATEV-Format mit korrektem Header exportieren.
5. Prüfregeln vor der Übertragung einbauen. Format-, Feld- und Zuordnungsprüfung wie oben beschrieben, mit einer Fehlerliste statt eines stillen Abbruchs.
6. Pilotzeitraum mit Stichproben. Einen Monat lang parallel automatisiert und manuell prüfen, ob die übertragenen Daten in der Kanzlei tatsächlich ankommen und korrekt zugeordnet werden, bevor die manuelle Kontrolle reduziert wird.

Für den zeitlichen Rahmen gilt: Ein reiner Belegtransfer mit vorgelagerter Extraktion lässt sich oft in wenigen Wochen aufsetzen, unter der Annahme, dass DATEV Unternehmen online bereits im Einsatz ist und die Kanzlei den Weg kennt. Ein Export von Buchungsdaten im DATEV-Format aus einem gewachsenen operativen System dauert erfahrungsgemäß deutlich länger, weil die Kontenzuordnung und Feldabbildung sorgfältig mit der Kanzlei abgestimmt werden muss. Eine DATEVconnect-Anbindung ist ein eigenständiges, an die Partnerschaft gebundenes Vorhaben und für die meisten KMU kein sinnvoller erster Schritt.

Ein Punkt, den ich in Projekten regelmäßig anspreche: Die Automatisierung sollte nicht am ersten Tag den gesamten Beleg- oder Buchungsfluss übernehmen. Sinnvoller ist ein einzelner, überschaubarer Ausschnitt — etwa nur die Belege eines Lieferanten oder eines Kostenbereichs — der vollständig durchläuft, bevor die nächste Gruppe folgt. Das macht Fehler in der Anfangsphase sichtbar und korrigierbar, statt sie in großer Zahl gleichzeitig zu produzieren.

Risiken und Grenzen

• Belegupload ist keine Buchungsautomatisierung. Wer nur Dokumente automatisiert hochlädt, hat die eigentliche manuelle Arbeit — Zuordnung und Kontierung — nicht abgeschafft, sondern nur verschoben.
• Falsche Header oder Formatversionen führen zu Komplettausfällen. Eine fehlerhafte EXTF-Kopfzeile kann dazu führen, dass die gesamte Datei abgelehnt wird, nicht nur einzelne Datensätze — deshalb gehört die Formatprüfung an den Anfang der Kette, nicht ans Ende.
• DATEVconnect ist nicht frei zugänglich. Wer eine direkte API-Anbindung plant, braucht einen DATEV-Partnerstatus; das ist ein eigener organisatorischer Vorlauf, keine reine Technikfrage.
• Rechtliche Lage ist in Bewegung. Die E-Rechnungspflicht wird bis 2027/2028 schrittweise verschärft; wer heute Übertragungswege aufbaut, sollte sie an den offiziellen Übergangsfristen ausrichten. Dies ist keine Rechtsberatung.
• Automatisierung ersetzt keine Abstimmung mit der Kanzlei. Ein technisch funktionierender Export, den die Kanzlei nicht erwartet oder nicht verarbeiten kann, erzeugt mehr Rückfragen als der bisherige manuelle Weg.
• Vertrauliche und personenbezogene Daten. Buchungs- und Belegdaten enthalten häufig personenbezogene und geschäftskritische Informationen; welche Daten über welches Automatisierungswerkzeug fließen dürfen, sollte vor dem Aufsetzen geklärt sein, im Zweifel mit Datenschutzbeauftragten.

Mehr Grundlagen zu benachbarten Themen findest du auf der Übersichtsseite Backoffice-Automatisierung. Wenn du wissen willst, welcher Übertragungsweg zu deinem bestehenden DATEV- und Kanzleisetup passt, ist das ein typischer Fall für eine unverbindliche Ersteinschätzung — oder du meldest dich direkt über das Kontaktformular. Wenn dein Team die Prüfregeln und Fehlerlisten künftig selbst pflegen soll, helfen unsere Schulungen beim Aufbau des nötigen Know-hows.

Checkliste: DATEV-Automatisierung

• Geklärt, ob Belege, Buchungsdaten oder beides automatisiert werden sollen
• Passender Übertragungsweg gewählt: Belegtransfer, DATEV-Format oder DATEVconnect
• Format und Weg mit Steuerberatung oder DATEV-Partner abgestimmt
• Zugänge und Berechtigungen in DATEV Unternehmen online eingerichtet
• Metadaten-Zuordnung für Belege definiert (Datum, Lieferant, Betrag, Belegnummer)
• Format-, Feld- und Zuordnungsprüfung vor der Übertragung eingebaut
• Fehlerliste mit Ursache statt stillem Abbruch oder stillem Verwerfen
• Protokoll über übertragene Dateien und Ergebnisse vorhanden
• Pilotzeitraum mit paralleler manueller Stichprobenprüfung durchgeführt
• Verantwortlichkeit für die laufende Prüfung der Fehlerliste benannt
• Zeitplan für E-Rechnungspflicht (2026/2027/2028) mit Steuerberatung abgeglichen