E-Rechnungsprozesse mit Low-Code: Eingang und Ausgang flexibel automatisieren

Veröffentlicht am 29. Juli 2026

Eine E-Rechnung ist nicht erledigt, sobald eine XML-Datei empfangen oder erzeugt wurde. Im Rechnungseingang folgen Validierung, Visualisierung, fachliche Prüfung, Freigabe, Buchung und Aufbewahrung. Im Rechnungsausgang wird die vom ERP erzeugte E-Rechnung übernommen, validiert, bei Bedarf mit begleitenden Unterlagen ergänzt, über den passenden Kanal versendet und mit ihrem Versandstatus dokumentiert. Eine Low-Code-Plattform kann diese Schritte als zusammenhängenden Prozess abbilden und ohne starre Einzelprogrammierung an die Organisation anpassen.

Was Low-Code bei E-Rechnungen bedeutet

Low-Code beschreibt einen Ansatz, bei dem Prozesse überwiegend aus grafischen Bausteinen zusammengesetzt werden. Auslöser, Prüfungen, Entscheidungen, Schnittstellen und Ergebnisse bleiben als Ablauf sichtbar. Technische Details verschwinden dadurch nicht: Formate, Berechtigungen, Datenfelder und Fehlerwege müssen weiterhin sauber festgelegt werden. Änderungen lassen sich jedoch häufig konfigurieren, ohne für jede Variante ein eigenes Softwareprojekt zu beginnen.

Das ist bei E-Rechnungen besonders hilfreich. Lieferanten, Kunden, Übertragungswege und angebundene Systeme unterscheiden sich, während der fachliche Grundprozess ähnlich bleibt. Eine Regel kann beispielsweise festlegen, ob eine Rechnung über E-Mail oder Peppol verarbeitet wird, welche Prüfung folgt und welches ERP- oder FiBu-System die Daten erhält.

Rechnungseingang: vom Empfang bis zur Buchung

1. E-Mail, Peppol und weitere Eingangskanäle bündeln

E-Rechnungen können über ein E-Mail-Postfach, ein Portal, eine Schnittstelle, einen gemeinsamen Speicher oder ein Netzwerk wie Peppol eintreffen. Das Umsatzsteuerrecht schreibt keinen einzelnen Übertragungsweg vor. Eine Low-Code-Plattform kann mehrere Kanäle überwachen und eingehende Dokumente an denselben Verarbeitungsprozess übergeben.

Der Kanal bleibt trotzdem relevant: Eine E-Mail kann Anhänge, Begleittexte und weitere Dateien enthalten. Bei Peppol kommen standardisierte Adressierung und Übertragungsregeln hinzu. Der Workflow sollte deshalb neben der Rechnung auch Herkunft, Empfangszeitpunkt und verfügbare Transportinformationen erfassen.

2. Original sichern, Format erkennen und technisch validieren

Nach dem Eingang sollte die erhaltene Originaldatei unverändert gesichert werden. Anschließend kann der Prozess erkennen, ob beispielsweise eine XRechnung, eine ZUGFeRD- beziehungsweise Factur-X-Datei oder ein anderes vereinbartes Format vorliegt. Eine technische Validierung prüft Syntax, Pflichtfelder und maschinell abbildbare Geschäftsregeln.

Ein positives Validierungsergebnis bedeutet jedoch nicht, dass Leistung, Preise, Mengen, Bankverbindung oder Kontierung fachlich richtig sind. Ebenso wenig ersetzt die technische Prüfung eine steuerliche oder rechtliche Beurteilung. Der Workflow muss deshalb technische Fehler und fachliche Klärfälle getrennt behandeln.

3. Strukturierte Daten verständlich visualisieren

Menschen möchten eine Rechnung lesen, ohne XML-Strukturen interpretieren zu müssen. Eine Visualisierung bereitet die strukturierten Daten deshalb als verständliche Ansicht auf. Sie erleichtert Prüfung und Freigabe, ersetzt aber nicht die aufzubewahrende strukturierte Originaldatei. Bei hybriden Formaten sind bei Abweichungen die strukturierten Rechnungsdaten maßgeblich.

4. Rechnungen nach Inhalt und Status routen

Routing bedeutet, dass der Prozess anhand festgelegter Regeln den nächsten Schritt auswählt. Kriterien können Lieferant, Gesellschaft, Kostenstelle, Bestellbezug, Betrag, Währung, Validierungsstatus oder ein fehlendes Pflichtdatum sein. Eine Rechnung mit Bestellbezug kann direkt zum Abgleich gehen; eine Rechnung ohne Zuordnung landet in einem Klärprozess.

Für Ausnahmen sind Benachrichtigungen wichtig. Der Workflow kann zuständige Personen per E-Mail oder innerhalb einer Anwendung informieren, Fristen überwachen und nach einer Korrektur erneut an der passenden Stelle fortfahren. So bleibt ein Fehlerfall Teil des Prozesses, statt in einem allgemeinen Postfach zu verschwinden.

5. ERP, Finanzbuchhaltung und Archiv verbinden

Nach Prüfung und Freigabe können Rechnungsdaten an ERP oder Finanzbuchhaltung übergeben werden. Dafür kommen dokumentierte REST-Schnittstellen, Webhooks, Datenbankzugriffe oder vereinbarte Dateiübergaben infrage. Rückmeldungen wie Belegnummer, Buchungsstatus oder Fehlertext sollten wieder in den Vorgang einfließen.

Aufzubewahren ist mindestens der strukturierte Teil der E-Rechnung unversehrt in seiner ursprünglichen Form. Zusätzlich können Visualisierung, Validierungsbericht, Freigaben und Übergabeprotokolle gemeinsam mit dem Geschäftsvorfall gespeichert werden. Das erleichtert spätere Recherchen, ohne die Originaldatei durch eine Sichtkopie zu ersetzen.

Rechnungsausgang: vom ERP bis zum dokumentierten Versand

1. Vom ERP erzeugte E-Rechnung übernehmen

Das ERP, die Warenwirtschaft oder eine andere führende Fachanwendung erzeugt die Ausgangsrechnung einschließlich Rechnungsnummer, Beträgen, Steuerangaben und Kundenstammdaten. Der Workflow übernimmt die fertige XRechnung, ZUGFeRD- beziehungsweise Factur-X-Datei oder ein anderes vereinbartes strukturiertes Format über eine API, einen Webhook oder eine Dateiübergabe. Die kaufmännische Verantwortung für die Rechnungsdaten bleibt im führenden System.

2. Validieren und begleitende Unterlagen ergänzen

Vor dem Versand prüft der Workflow die vom ERP erzeugte E-Rechnung technisch. Fehler werden an das führende System oder eine zuständige Person zurückgemeldet, statt die Rechnung ungeprüft zu versenden. Anhand von Bestellnummer, Auftrag, Projekt oder anderen Referenzen kann der Prozess anschließend passende Lieferscheine, Leistungsnachweise oder weitere Begleitdokumente suchen und ergänzen. Je nach Format und Vereinbarung werden sie in die E-Rechnung eingebettet oder gemeinsam mit ihr bereitgestellt. Die umsatzsteuerlichen Pflichtangaben müssen weiterhin im strukturierten Rechnungsteil enthalten sein.

3. Versandweg regelbasiert auswählen

Der passende Übertragungsweg kann aus Kundenstammdaten, Leitweg-ID, Peppol-ID oder einer individuellen Vereinbarung abgeleitet werden. Der gleiche Ausgangsprozess kann dadurch Rechnungen je nach Empfänger über E-Mail, Peppol, Portal oder Schnittstelle bereitstellen. Voraussetzung sind gepflegte Stammdaten und klar definierte Ausweich- und Fehlerwege.

4. Versandstatus, Fehler und Archivierung zurückführen

Nach dem Versand sollte der Prozess die tatsächlich versendete strukturierte Rechnung sichern und verfügbare Statusinformationen dokumentieren. Bei einem Übertragungsfehler kann er eine erneute Zustellung anstoßen, den Vorgang zur Klärung routen und zuständige Personen per E-Mail benachrichtigen. Eine erfolgreiche technische Übertragung ist dabei nicht automatisch ein Nachweis für die fachliche Annahme oder Zahlung durch den Empfänger.

Technische Offenheit entscheidet über den Nutzen

Eine Low-Code-Plattform ist nur dann hilfreich, wenn sie die vorhandene Systemlandschaft erreicht. Für E-Rechnungsprozesse sind vor allem REST-APIs, Webhooks, Datenbanken, E-Mail-Zugriff, Netzlaufwerke, FTP beziehungsweise SFTP, SMB, WebDAV und S3-kompatible Speicher relevant. Peppol kann als standardisierter Übertragungsweg hinzukommen.

Nicht jede Anbindung benötigt einen eigenen Produkt-Connector. Hat eine Anwendung eine dokumentierte API, kann ein generischer HTTP- oder REST-Baustein Daten abrufen, Aktionen auslösen und Status zurückschreiben. Vorgefertigte Connectoren bleiben sinnvoll, wenn ein System besondere Authentifizierung, Datenmodelle oder Transaktionslogik verlangt.

Was Low-Code nicht automatisch löst

Unklare Zuständigkeiten: Eine grafische Oberfläche ersetzt keine Entscheidung darüber, wer prüft, freigibt oder einen Fehler klärt.
Schlechte Stammdaten: Fehlende Lieferanten-, Kunden- oder Routingdaten führen auch in einem automatisierten Prozess zu Ausnahmen.
Fachliche Prüfung: Technische Validierung bestätigt weder die erbrachte Leistung noch Kontierung, Zahlungsfreigabe oder steuerliche Anerkennung.
Fehlende Schnittstellen: Ein grafischer Workflow kann keine Daten austauschen, wenn das angebundene System weder API noch einen anderen verlässlichen Übergabeweg bietet.
Ungetestete Regeln: Betragsgrenzen, Vertretungen, Fehlerwege und Berechtigungen müssen mit realistischen Testfällen geprüft werden.

Praxisbeispiel: Workflow Designer NG

Workflow Designer NG ist die Low-Code-Prozessplattform innerhalb von inoxision NG. Abhängig von Version, Lizenz und Konfiguration können Workflows E-Rechnungen über E-Mail, Peppol, Dateiablagen oder Schnittstellen übernehmen, validieren und visualisieren, nach Regeln verteilen, an ERP oder Finanzbuchhaltung übergeben und zusammen mit Prozessinformationen archivieren. Für Ausgangsrechnungen lassen sich die Übernahme aus dem ERP, technische Validierung, Zuordnung begleitender Dokumente, Versandweg, Rückmeldung und Aufbewahrung in einem Ablauf verbinden.

Für Integrationen stehen unter anderem REST und Webhooks, Datenbankzugriffe, FTP/FTPS, SFTP, SMB, WebDAV, S3-kompatible Speicher, IMAP, Microsoft 365 und eine Anbindung an SoftENGINE WEBWARE zur Verfügung. Mail-Benachrichtigungen, Bedingungen, Schleifen, Teil-Workflows, Simulation und Ausführungsprotokolle ergänzen die technische Verarbeitung.

Die ausführliche Produktvorstellung mit Screenshots finden Sie im inoxision Knowledge Center: Workflow Designer NG: Prozesse auf der inoxision NG Plattform gestalten.

Fazit

Low-Code kann E-Rechnungsprozesse vor allem dort verbessern, wo viele Systeme, Regeln und Ausnahmefälle zusammentreffen. Der Nutzen entsteht nicht durch eine grafische Oberfläche allein, sondern durch die Verbindung von Empfang und Versand, technischer Validierung, Visualisierung, fachlichem Routing, Benachrichtigungen, Schnittstellen und nachvollziehbarer Aufbewahrung. Eingang und Ausgang werden so nicht zu zwei Insellösungen, sondern zu steuerbaren Teilen desselben Rechnungsprozesses.

Weiterlesen

Quellen und weiterführende Informationen

Informationsstand: 29. Juli 2026.