DATEV-Automatisierung: Belege und Daten kontrolliert übertragen

Das Wichtigste in Kürze:

• DATEV bietet 3 Wege: Belegtransfer, DATEV-Format und DATEVconnect-APIs.
• Belege und Buchungsdaten sind getrennte Datenflüsse mit eigenen Schnittstellen.
• Ein hochgeladener Beleg wird nicht von selbst zum Buchungssatz.
• Fehler gehören in eine Prüfliste mit Ursache, nicht still verworfen.

Problem und Zielgruppe

In vielen KMU laufen operative Systeme und Buchhaltung nebeneinander her. Warenwirtschaft, CRM, Projekttool und E-Mail-Postfach sind nur durch Menschen verbunden, die Daten von Hand übertragen. Eine Rechnung entsteht im Vertriebstool, wird als PDF exportiert, per E-Mail an die Buchhaltung geschickt, dort geladen und in DATEV Unternehmen online abgelegt oder von Hand als Buchungssatz erfasst. So kommen schnell 5 manuelle Schritte zusammen. Bei jedem davon kann etwas verloren gehen, doppelt landen oder veralten.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU. Er zeigt, welche Schnittstellen DATEV für die automatische Übergabe von Belegen und Daten wirklich bietet, welche Daten sich darüber bewegen lassen und wo die Grenzen liegen. Es geht nicht um ein einzelnes Tool. Es geht um die Frage, welcher Weg 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 am Vermischen zweier Dinge. Belege (Dokumente) und Buchungsdaten (strukturierte Datensätze) sind zwei getrennte Flüsse mit eigenen Schnittstellen. Wer das nicht trennt, lädt Belege hoch und hofft auf automatische Buchungssätze. Das passiert nicht von selbst.

Begriffe kurz geklärt

DATEV Unternehmen online ist die Cloud-Plattform für den Austausch von Belegen und Dokumenten mit der Steuerkanzlei. Sie ist der übliche Zielpunkt für den automatischen Belegupload, nicht für Buchungssätze im engeren Sinn.

Belegtransfer meint den Weg digitaler Belege nach DATEV Unternehmen online, also gescannte Rechnungen, PDF-Dokumente und Quittungen. Er läuft auf 3 Wegen: per Upload-Ordner, per XML-Schnittstelle für schon 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 Kennzeichen (EXTF) und einer Header-Zeile. Diese nennt Formatversion, Erstellungsdatum, Wirtschaftsjahr und weitere Steuerangaben. Danach folgen die eigentlichen Datenzeilen, etwa ein Buchungsstapel mit Konten, Beträgen und Buchungstexten.

DATEVconnect steht für die programmatischen Schnittstellen (APIs) im DATEV Developer Portal. Über sie werden Drittsysteme direkt mit DATEV-Anwendungen und Stammdaten verbunden, anders als beim reinen Datei-Up- und -Download.

n8n ist eine Fair-Code-lizenzierte, selbst hostbare Workflow-Plattform. Laut eigener Doku verbindet sie Automatisierung mit KI-Fähigkeiten. Das hilft, wenn du Daten aus mehreren Quellsystemen bündeln willst, bevor sie DATEV erreichen.

Power Automate ist Microsofts Workflow-Plattform mit einem breiten Connector-Ökosystem. Es deckt Dateisync, Meldungen und Freigaben ab. Im DATEV-Kontext dient es meist als Schritt davor: Es sammelt Daten aus Microsoft- oder Drittsystemen und bereitet sie auf.

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

Welche Schnittstellen gibt es?

Für DATEV-Automatisierung sind praktisch 3 Wege relevant, jeder mit eigenem Zweck:

1. Belegtransfer nach DATEV Unternehmen online. Der Weg für Dokumente, nicht für Buchungssätze: üblich sind ein überwachter Upload-Ordner, eine XML-Schnittstelle für strukturierte Rechnungsdaten und eine DMS-Anbindung, aus der Belege direkt wandern.

2. DATEV-Format für Buchungsdaten. Der Weg für Buchungsstapel sowie Debitoren- und Kreditorenstammdaten, als CSV-Dateien mit festem Header (Kennzeichen EXTF, Formatversion, Zeitraum, Berater- und Mandantennummer) und definierter Spaltenstruktur je Datensatzart.

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. Eine offene, frei nutzbare REST-API sind sie nicht.

Für die meisten KMU ohne eigene Entwickler zählen die ersten beiden Wege. Belege laufen über den Belegtransfer, Buchungsdaten über das DATEV-Format, ausgelöst und aufbereitet oft durch ein Tool wie n8n oder Power Automate. Die DATEVconnect-APIs kommen ins Spiel, wenn ein Softwareanbieter oder eine größere IT-Abteilung eine tiefe, dauerhafte Integration baut. Als Einstieg in die erste Automatisierung taugen sie selten.

Welche Daten lassen sich übertragen?

Die beiden Datenflüsse aus dem vorigen Abschnitt bewegen verschiedene Dinge:

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

Der wichtigste Punkt wird in der Praxis oft übersehen: Ein automatisch hochgeladener Beleg wird dadurch nicht zum gebuchten Vorgang. Beleg und Buchungssatz sind 2 getrennte Objekte. Verbunden werden sie erst durch eine Zuordnung, entweder automatisch über mitgelieferte Metadaten oder von Hand in Kanzlei oder Buchhaltung. Wer Automatisierung plant, sollte das Ziel deshalb früh festlegen, denn “Belege liegen vollständig in DATEV Unternehmen online” und “Buchungssätze entstehen automatisch” sind zwei verschieden aufwändige Vorhaben.

Wie werden Belege zugeordnet?

Ein hochgeladener Beleg braucht Metadaten, damit er später zum passenden Buchungsvorgang findet. In der Praxis heißt das mindestens: Belegdatum, Lieferant oder Kunde, Betrag und Belegart (Eingangsrechnung, Ausgangsrechnung, Quittung). Im besten Fall kommt eine eindeutige Belegnummer dazu.

Diese Metadaten entstehen auf 2 Wegen:

• Strukturiert mitgeliefert. Bei E-Rechnungsformaten wie XRechnung oder ZUGFeRD stecken die Felder schon als maschinenlesbare Daten im Dokument. Die Zuordnung ist damit deutlich verlässlicher, weil nichts erraten werden muss.
• Nachträglich extrahiert. Bei einer unstrukturierten PDF- oder Scan-Rechnung liest ein Schritt davor die Felder aus, etwa eine Extraktions-Engine mit OCR wie im Artikel zur Rechnungsverarbeitung beschrieben. Erst danach gehen die Felder als Metadaten mit dem Beleg mit.

Ohne diese Zuordnung landet ein Beleg zwar im System. Für die Buchhaltung bleibt er aber ein loses Dokument ohne Kontext, das jemand von Hand zuweisen muss. Genau hier lassen viele Projekte den größten Zeitgewinn liegen. Der Upload läuft, die Zuordnung nicht. Der manuelle Aufwand bleibt, er verschiebt sich nur.

Wie behandelt man Fehler?

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

• Formatprüfung. Entspricht die Datei der erwarteten Struktur, bei DATEV-Format-Dateien etwa mit korrektem EXTF-Header und passender Formatversion?
• Feldprüfung. Sind Pflichtfelder wie Betrag, Datum und Konto gefüllt und plausibel, ohne negativen Betrag oder Datum außerhalb des Buchungszeitraums?
• Zuordnungsprüfung. Passt der Beleg zu einem bekannten Lieferanten oder Konto, oder ist es ein neuer, noch nicht angelegter Stammdatensatz?

Datensätze, die eine dieser Prüfungen nicht bestehen, gehören nicht in den Papierkorb. Sie gehören in eine Fehlerliste mit Ursache: Formatfehler, fehlendes Feld, unbekannter Lieferant. Diese Liste ist der Ort für die manuelle Nacharbeit, nicht der ganze Workflow. Ein Workflow, der bei jedem Fehler komplett abbricht, ist unpraktisch; einer, der Fehler still überspringt, ist gefährlich, weil Belege oder Buchungen ohne Spur verschwinden.

Wichtig ist zudem ein Protokoll: Wer hat wann welche Datei mit welchem Ergebnis übertragen? Das klingt banal, ist es aber nicht. Im Streitfall, etwa bei einer fehlenden Zahlung, ist das oft die einzige Spur.

Aus meiner Erfahrung lohnt sich zusätzlich die Trennung von 2 Fehlerarten. Technische Fehler: Die Datei lässt sich nicht lesen, oder der Header stimmt nicht. Fachliche Fehler: Die Datei ist technisch korrekt, aber ein Betrag oder ein Konto sieht falsch aus. Technische Fehler gehören zur IT oder zu dem, der den Workflow baut, fachliche zur Buchhaltung oder Kanzlei. Wer beide ohne Kennzeichnung in dieselbe Liste wirft, erzeugt Rückfragen. Dann weiß niemand, wer dran 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 als dritten Faktor den DATEV-Partnerstatus. Vor dem Aufsetzen gehören 3 Punkte geklärt:

• Mit Steuerberatung oder DATEV-Partner: Welches Format und welcher Weg passt zum bestehenden Kanzleisetup? Ein Format, das die Kanzlei nicht erwartet, bringt Rückfragen statt Zeitersparnis.

• Zugang und Berechtigung: DATEVconnect-Online-Schnittstellen sind laut DATEV Developer Portal an eine DATEV-Partnerschaft gebunden. Für Belegtransfer oder DATEV-Format-Export braucht es das nicht zwingend, wohl aber passende Zugangsdaten und Rechte in DATEV Unternehmen online.

• Intern: Wer ist zuständig, wenn der Workflow eine Fehlerliste produziert? Wie oft wird sie geprüft? Welche Fristen wie Monatsabschluss oder Umsatzsteuervoranmeldung hängen an einer pünktlichen Übergabe?

Dazu kommt die rechtliche Ebene, die 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 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 im Grundsatz für alle.

Die Empfangspflicht für E-Rechnungen gilt dagegen schon seit 2025 ohne Übergangsfrist. Als zulässige Formate nennt das BMF insbesondere XRechnung und ZUGFeRD ab Version 2.0.1. Dieser Abschnitt ersetzt keine steuerliche Beratung. Stand ist Juli 2026; Details gehören vor einer Umstellung mit der Steuerberatung abgeglichen.

Eigene Entscheidungsmatrix: Welcher Weg passt?

Aus Projekten hat sich bei mir eine Faustregel mit 5 typischen Ausgangslagen bewährt:

• Belege liegen als PDF oder Scan vor und sollen verlässlich in DATEV Unternehmen online landen. Passender Weg: Belegtransfer über den Upload-Ordner, bei Bedarf mit Extraktion für Metadaten davor. Aufwand: gering bis mittel.

• Lieferanten liefern schon strukturierte E-Rechnungen (XRechnung/ZUGFeRD). Passender Weg: Belegtransfer über die XML-Schnittstelle, Metadaten kommen direkt mit. Aufwand: gering.

• Buchungssätze aus Kasse, Warenwirtschaft oder CRM sollen automatisch in die Buchhaltung. Passender Weg: Export ins DATEV-Format als Buchungsstapel, danach Import in der Kanzlei oder direkt in DATEV. Aufwand: mittel bis hoch.

• Ein eigenes Softwareprodukt braucht eine dauerhafte, tiefe Anbindung an DATEV-Stammdaten. Passender Weg: DATEVconnect-API über das DATEV Developer Portal. Aufwand: hoch, an Partnerschaft gebunden.

• Mehrere Quellsysteme sollen vorher zusammengeführt und geprüft werden. Passender Weg: vorgeschalteter Workflow (n8n, Power Automate) plus einer der 3 DATEV-Wege als letzter Schritt. Aufwand: mittel bis hoch, je nach 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. Beides getrennt planen, nicht als ein Projekt.

2. Kanzlei einbeziehen. Vor jeder technischen Entscheidung mit der Steuerkanzlei klären, welches Format und welcher Weg dort ankommt und erwartet wird.

3. Quellsystem und Trigger festlegen. Woher kommen die Daten, etwa E-Mail-Postfach, ERP-Export oder Kassensystem? Und was löst die Übergabe aus: ein Zeitplan, ein neues Dokument, ein Monatsabschluss?

4. Aufbereitung bauen. Mit n8n, Power Automate oder einem ähnlichen Tool die Rohdaten ins Zielformat bringen. Also Metadaten für den Belegtransfer ergänzen oder Buchungssätze mit korrektem Header ins DATEV-Format exportieren.

5. Prüfregeln einbauen. Format-, Feld- und Zuordnungsprüfung wie oben beschrieben, mit Fehlerliste statt stillem Abbruch.

6. Pilotzeitraum mit Stichproben. 4 Wochen lang parallel automatisch und von Hand prüfen, ob die Daten in der Kanzlei korrekt ankommen. Erst danach die manuelle Kontrolle senken.

Zum zeitlichen Rahmen: Ein reiner Belegtransfer mit Extraktion davor steht oft in wenigen Wochen, sofern DATEV Unternehmen online schon läuft und die Kanzlei den Weg kennt. Ein DATEV-Format-Export aus einem gewachsenen operativen System dauert aus Erfahrung deutlich länger, weil Kontenzuordnung und Feldabbildung sorgfältig mit der Kanzlei abgestimmt werden müssen. Das braucht Zeit. Eine DATEVconnect-Anbindung ist ein eigenes, an die Partnerschaft gebundenes Vorhaben und für die meisten KMU kein sinnvoller erster Schritt.

Einen Punkt spreche ich in Projekten regelmäßig an: Der Workflow sollte nicht am ersten Tag den ganzen Beleg- oder Buchungsfluss übernehmen. Sinnvoller ist ein kleiner, klar umrissener Ausschnitt, etwa nur die Belege eines Lieferanten oder eines Kostenbereichs. Der läuft vollständig durch, bevor die nächste Gruppe folgt. So werden Fehler früh sichtbar und korrigierbar, statt in großer Zahl gleichzeitig aufzulaufen.

Risiken und Grenzen

• Belegupload ist keine Buchungsautomatisierung. Wer nur Dokumente automatisch hochlädt, hat Zuordnung und Kontierung nicht abgeschafft, sondern nur verschoben.

• Falsche Header oder Formatversionen führen zu Komplettausfällen. Eine fehlerhafte EXTF-Kopfzeile kann die ganze Datei zum Import-Abbruch bringen, 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. Für eine direkte API-Anbindung braucht es den DATEV-Partnerstatus. Das ist ein eigener organisatorischer Vorlauf, keine reine Technikfrage.

• Die 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 sauberer 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 oft personenbezogene und geschäftskritische Angaben. Welche Daten über welches Tool fließen dürfen, gehört vorher geklärt, im Zweifel mit Datenschutzbeauftragten.

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

Checkliste: DATEV-Automatisierung

• Geklärt, ob Belege, Buchungsdaten oder beides automatisiert werden sollen.

• Passenden Weg gewählt: Belegtransfer, DATEV-Format oder DATEVconnect.

• Format und Weg mit Steuerberatung oder DATEV-Partner abgestimmt.

• Zugänge und Rechte in DATEV Unternehmen online eingerichtet.

• Metadaten-Zuordnung für Belege definiert (Datum, Lieferant, Betrag, Belegnummer).

• Format-, Feld- und Zuordnungsprüfung vor der Übergabe eingebaut.

• Fehlerliste mit Ursache statt stillem Abbruch oder stillem Verwerfen.

• Protokoll über übertragene Dateien und Ergebnisse vorhanden.

• Pilotzeitraum mit parallelen manuellen Stichproben durchgeführt.

• Zuständigkeit für die laufende Prüfung der Fehlerliste benannt.

• Zeitplan für die E-Rechnungspflicht (2026/2027/2028) mit der Steuerberatung abgeglichen.