Die E-Rechnung-Verarbeitung von Bluebatch ist ein n8n-Workflow für Steuerkanzleien, der XRechnung und ZUGFeRD direkt aus dem XML parst, per KoSIT-Validator gegen EN 16931 prüft und als Buchungsvorschlag an DATEV übergibt. Die Vollkosten sinken von 11,50 Euro auf 0,10 Euro pro Rechnung, die Verarbeitung dauert 30 Sekunden statt 12 Minuten. Das Original-XML wird GoBD-konform archiviert.
XRechnung, ZUGFeRD und Peppol-EDI laufen über denselben n8n-Workflow. Egal welches Format der Lieferant nutzt, das Ergebnis ist ein strukturiertes, KoSIT-geprüftes JSON, das direkt in DATEV läuft.



Fünf Schritte vom Posteingang in den DATEV-Buchungsstapel. Der KoSIT-Validator entscheidet, welche Rechnung formal sicher ist. Confidence-Score entscheidet, welche ohne Touch durchgeht.
Bei Syntax-, Schematron- oder Geschäftsregelverstoß landet der Beleg nicht im DATEV-Stapel. Stattdessen geht automatisch eine strukturierte Reject-Mail mit KoSIT-Report an den Lieferanten, bevor der Vorsteuerabzug formal verloren geht.
KoSIT-grüne Rechnungen mit Confidence-Score > 90 Prozent fließen ohne Touch in DATEV. Darunter wird der Beleg zur Klärung ausgesteuert. Jede manuelle Korrektur fließt zurück ins RAG.
XRechnung-XML im Viewer ablesen und in DATEV abtippen ist fehleranfällig, langsam und juristisch riskant. Strukturiertes Parsen mit KoSIT-Validierung dauert Sekunden und schützt den Vorsteuerabzug.
Rechenbeispiel für eine Kanzlei mit 300 Eingangsrechnungen pro Monat. Die Vollkosten pro Rechnung sinken durch KI-Parsing und KoSIT-Validierung deutlich.
Automatisierung heißt nicht Blackbox. Diese drei Klärfälle landen mit vollem Kontext beim zuständigen Sachbearbeiter, jede manuelle Entscheidung fließt zurück ins RAG.

Steuersumme passt nicht zu Positionen, Bestellbezug fehlt oder USt-ID des Lieferanten ist seit Empfang erloschen. Der Workflow stoppt die Buchung, eskaliert an den zuständigen Sachbearbeiter und versendet automatisch eine begründete Reject-Mail an den Lieferanten.
Selten gebuchter Lieferant, neue Kostenstelle oder ungewöhnlicher Steuersatz: der RAG-Vorschlag liegt unter der Freigabeschwelle. Klärfall landet in Jira oder DATEV Aufgaben, Mensch entscheidet, das Ergebnis fließt zurück ins RAG.
Rechnungsnummer plus Betrag plus Datum matchen einen bereits verarbeiteten Beleg, oder PDF-Hash weicht vom eingebetteten XML ab. Der Workflow hält den Beleg an, dokumentiert den Verdacht im Audit-Log und übergibt zur Vier-Augen-Prüfung.
E-Invoicing ist in Deutschland kein Formatthema, sondern ein Compliance-Thema. Ob der Vorsteuerabzug hält, entscheidet sich an drei Fragen: Entspricht die Rechnung formal der EN 16931, kam sie über einen zulässigen Kanal an, und liegt das strukturierte Original unverändert im Archiv? Genau diese drei Prüfungen laufen bei uns als Automation im n8n-Workflow, statt als Checkliste im Kopf des Sachbearbeiters.
Der KoSIT-Validator ist die Referenzimplementierung des Bundes und prüft drei Ebenen: die Syntax des XML (CII oder UBL), die Schematron-Regeln der CIUS XRechnung und die Geschäftsregeln der EN 16931, also etwa die Konsistenz von Positionssummen, Steuersätzen und Gesamtbetrag. Fällt eine Rechnung durch, ist sie umsatzsteuerlich keine ordnungsgemäße Rechnung. Der Workflow blockt sie deshalb vor dem Buchungsstapel und schickt den Fehlerbericht zurück an den Lieferanten, statt sie zu buchen und später zu korrigieren.
Peppol arbeitet im Vier-Ecken-Modell: Sender und Empfänger sprechen nie direkt miteinander, sondern jeweils über einen zertifizierten Access Point. Empfangsseitig braucht die Kanzlei dafür eine eigene Teilnehmerkennung und ein Profil nach Peppol BIS Billing 3.0, das im Verzeichnis hinterlegt ist. Der Transport quittiert die Zustellung technisch, was den Zugang belegbar macht. Pflicht ist Peppol nicht, für den Empfang genügt auch ein E-Mail-Postfach; mit der gestaffelten Versandpflicht ab 2027 wird es aber der Kanal, den größere Mandanten und deren Kunden voraussetzen.
Aufzubewahren ist der strukturierte Teil, also das XML, nicht das PDF-Sichtbild. Die Frist für Rechnungen liegt seit dem Vierten Bürokratieentlastungsgesetz bei acht statt zehn Jahren (§ 14b Abs. 1 UStG, gilt für alle am 31.12.2024 noch nicht abgelaufenen Fristen) und beginnt mit Ablauf des Kalenderjahres, in dem die Rechnung ausgestellt wurde. Die GoBD verlangen zusätzlich Unveränderbarkeit und Nachvollziehbarkeit. Der Workflow legt das Original-XML deshalb mit Hashwert, Zeitstempel und Audit-Eintrag im revisionssicheren Archiv ab.
E-Invoice-Compliance endet nicht bei der strukturierten Rechnung. Dieselbe Prüf- und Archivlogik braucht jede Belegart, die in die Kanzlei läuft, nur ohne den Komfort maschinenlesbarer Felder. Wie das für Papier- und PDF-Belege aussieht, zeigt die automatisierte Belegprüfung in der Kanzlei. Vorgelagert steht die Frage, wie der Beleg überhaupt hereinkommt: per PDF-Upload, aus dem E-Mail-Postfach, aus einem Cloud-Drive oder vom Scanner. Wie diese vier Kanäle in denselben Klassifikator und denselben Audit-Trail laufen, beschreibt die Dokumentenverarbeitung in der Kanzlei. Und wenn Mandantendaten die Kanzlei aus Gründen des § 203 StGB gar nicht verlassen dürfen, läuft derselbe Workflow in der eigenen Umgebung, beschrieben unter Private AI für Steuerkanzleien.
Vertraut von führenden Unternehmen
















Hier finden Sie die Antworten auf häufig gestellte Fragen.
Genau das verhindert die KoSIT-Validierung in unserem Workflow. Jede E-Rechnung wird vor dem DATEV-Upload gegen die EN-16931-Schematron-Regeln und die CIUS XRechnung geprüft. Bei Syntax- oder Geschäftsregelverstoß bekommt der Lieferant automatisch eine Reject-Mail mit dem KoSIT-Fehlerbericht, die Rechnung läuft nicht in den Buchungsstapel. So bleibt der Vorsteuerabzug formal sicher (BMF-Schreiben 10/2025).
Die DATEV E-Rechnungsplattform ist stark für den Versand und das reine Empfangs-Postfach. Beim Empfang und der KI-gestützten Verarbeitung in DATEV Rewe gibt es Lücken: KoSIT-Bericht erscheint im Belegbild, muss aber manuell ausgewertet werden, Buchung wird nicht automatisch angelegt. Wir setzen einen n8n-Workflow-Layer dazwischen, der automatisch validiert, klassifiziert und den fertigen Buchungsstapel an DATEV übergibt.
Beides geht parallel. Wir bündeln E-Mail-Postfach, Peppol-BIS-3.0-Adresse, TRAFFIQX und die DATEV E-Rechnungsplattform an denselben n8n-Trigger. So musst du Lieferanten nicht zwingen, ihren Kanal zu wechseln. Mittelfristig empfehlen wir Peppol für deine Top-Lieferanten, weil die Zustellung dort technisch sauberer ist als E-Mail mit XML-Anhang.
GoBD verlangt unveränderbare, jederzeit lesbare Speicherung des Originals. Wir schreiben das Original-XML in ein revisionssicheres DMS deiner Wahl (ecodms, d.velop, DATEV DMS oder kanzleieigenes System), mit Hashwert, Zeitstempel und Audit-Log. Das PDF dient ausschließlich als Lesehilfe und ersetzt das XML nicht. Damit erfüllen wir die GoBD-Anforderungen und du bist bei Betriebsprüfung sauber aufgestellt.
Setup bei uns ab 8.000 €, plus Wartung zwischen 500 und 2.500 € pro Monat je nach Mandantenzahl und Volumen. Vollkosten pro verarbeiteter Rechnung liegen bei rund 0,10 €. xSuite und ELO for DATEV starten bei 20.000 € Setup, kommen meist auf 50.000 € plus mit Customizing, plus laufende DMS-Lizenz. Wir sind also schneller live, billiger im Setup und ohne DMS-Lock-in.
Beides. Der Workflow erkennt automatisch, ob eine reine XRechnung (XML CII oder UBL) oder eine ZUGFeRD-PDF/A-3 mit eingebettetem XML reinkommt. Für ZUGFeRD nutzen wir factur-x, um die embedded XML auszupacken, für XRechnung python-drafthorse. Das PDF dient nur als visuelle Anzeige für den Sachbearbeiter, die Buchungsdaten kommen immer aus dem XML.
Faustregel: ab 300 Rechnungen pro Monat amortisiert sich das Setup in 6 bis 9 Monaten. Bei 5.000 Rechnungen pro Monat (typischer Mittelstandsmandant) liegt der Break-Even bei 3 bis 4 Monaten, der jährliche Nettonutzen bei 309.500 bis 421.000 € (bonpago). Bei kleineren Mandanten (100 Rechnungen pro Monat) lohnt sich Bluebatch über die Bündelung mehrerer Mandanten auf einen Workflow.
