Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht

Navigation: Dokumentationen agorum core > agorum core Module und Plugins > Dokument | E-Rechnung


E-Rechnungen mit Dokument | E-Rechnung verarbeiten

Hinweis: Diese Dokumentation bezieht sich auf die aktuellste Version des Plugins. Aktualisieren Sie das hier beschriebene Plugin, um die Dokumentation verwenden zu können.

E-Rechnungen (elektronische Rechnungen) sind Rechnungen in einem strukturierten, maschinenlesbaren Format. Mit dem Plugin Dokument | E-Rechnung empfangen, erkennen, prüfen, lesen und erstellen Sie E-Rechnungen in agorum core und bauen daraus eigene Workflows.

Diese Seite richtet sich an Entwickler und Administratoren. Sie gibt einen Überblick über die Standards und den rechtlichen Rahmen und beschreibt typische Abläufe für eingehende und ausgehende E-Rechnungen.

Standards in Deutschland

In Deutschland sind vor allem drei Formate gebräuchlich. Alle beruhen auf der europäischen Norm EN 16931:

  • XRechnung: reines XML in der Syntax UBL oder CII, herausgegeben von der KoSIT. Standard für Rechnungen an öffentliche Auftraggeber und zunehmend im B2B-Bereich.
  • ZUGFeRD (in Frankreich Factur-X): hybrides Format aus einem lesbaren PDF/A-3 und einer eingebetteten CII-XML, herausgegeben vom FeRD. Vor allem im B2B-Bereich.
  • Peppol BIS Billing 3.0: UBL-Format für den Versand über das europäische Peppol-Netzwerk.

Welche Versionen und Profile Dokument | E-Rechnung liest, prüft und erstellt und wie Sie das ZUGFeRD-Profil steuern, beschreibt E-Rechnungsformate, Versionen und Profile.

Rechtlicher Rahmen

Die folgenden Punkte geben einen Überblick, Stand Oktober 2026. Sie ersetzen keine steuerliche Beratung.

  • Empfang: Seit dem 01.01.2025 müssen alle Unternehmen in Deutschland E-Rechnungen von anderen Unternehmen empfangen können.
  • Versand: Ab 2027 müssen Unternehmen mit mehr als 800.000 € Vorjahresumsatz E-Rechnungen ausstellen, ab 2028 alle Unternehmen. Bis dahin sind Papier- und (mit Zustimmung des Empfängers) PDF-Rechnungen noch zulässig.
  • Ausnahmen: Kleinbetragsrechnungen bis 250 € und Fahrausweise dürfen weiterhin als sonstige Rechnung ausgestellt werden.
  • Was als E-Rechnung gilt: XRechnung, Peppol und ZUGFeRD ab Version 2.0.1 – bei ZUGFeRD jedoch nicht die Profile MINIMUM und BASIC WL. Ein reines PDF ist keine E-Rechnung.
  • Hybride Rechnungen: Bei ZUGFeRD ist die eingebettete XML maßgeblich. Weicht das PDF davon ab, gelten die Angaben der XML.
  • Fehler: Nach dem BMF-Schreiben vom 15.10.2025 ist eine Rechnung mit Formatfehlern (etwa Schemafehler) keine E-Rechnung. Eine Rechnung, die nur gegen Geschäftsregeln verstößt, ist eine E-Rechnung, sollte aber korrigiert werden.
  • Aufbewahrung: Der strukturierte Teil der E-Rechnung muss acht Jahre lang (§ 14b UStG) unverändert und maschinell auswertbar aufbewahrt werden. Eine lesbare Ansicht ersetzt das Original nicht. Eine Übersicht aller Aufbewahrungsfristen finden Sie im Blogbeitrag Aufbewahrungsfristen nach AO, HGB und UStG.

Spezifikationen

Eingehende E-Rechnungen verarbeiten

Ein typischer Eingangsprozess besteht aus den folgenden Schritten. Zu jedem Schritt ist angegeben, welche Funktion des Plugins Sie dafür verwenden.

Schritt Was passiert Umsetzung mit Dokument | E-Rechnung
1. Empfangen Rechnungen kommen per E-Mail, Upload, Portal oder über einen Peppol-Zugangspunkt in agorum core an. Ablage in einem Eingangsordner, etwa über einen E-Mail-Adapter oder einen Aktiven Ordner. Dokument | E-Rechnung empfängt selbst keine Rechnungen über Peppol; dafür ist ein Zugangspunkt-Anbieter nötig, der die Dateien in agorum core ablegt.
2. Erkennen E-Rechnungen werden von sonstigen Rechnungen getrennt; das Format wird bestimmt. check bzw. Knoten E-Rechnung prüfen; Skript check-and-move.js im Aktiven Ordner
3. Prüfen Die XML wird gegen Schema und Geschäftsregeln geprüft (KoSIT-Validator). Zusätzlich werden Positionsbeträge auf Plausibilität geprüft. validateInvoice bzw. Knoten E-Rechnung validieren; parse mit validate: true
4. Anzeigen Die XML-Daten werden in ein lesbares PDF- oder Office-Dokument überführt. createView bzw. Knoten Dokument aus E-Rechnung erstellen; Kontextmenü E-Rechnung > PDF-Ansicht erzeugen
5. Rückmelden Bei einer fehlerhaften Rechnung wird der Rechnungssteller informiert und um Korrektur gebeten. Ausgang false des Validierungsknotens und der Prüfbericht; die Benachrichtigung selbst richten Sie im Workflow ein (siehe Rückmeldung an den Rechnungssteller).
6. Daten übernehmen Die Rechnungsdaten werden in einheitliche Metadaten überführt und weiterverarbeitet, etwa für Freigabe und Buchung. parse bzw. Knoten E-Rechnung normalisieren; eingebettete Anhänge werden dabei extrahiert
7. Archivieren Original, Prüfbericht und Ansicht werden gemeinsam aufbewahrt. Ablage in agorum core; das Original bleibt unverändert

Hinweis: parse und der Knoten E-Rechnung normalisieren liefern die normalisierten Daten in einer Variable zurück. Sie werden nicht automatisch als Metadaten am Dokument gespeichert. Wenn Sie die Daten am Dokument brauchen, etwa für eine Suche, speichern Sie sie in einem nachfolgenden Schritt.

Rückmeldung an den Rechnungssteller

Dokument | E-Rechnung bewertet die Rechnung und liefert einen Prüfbericht. Eine automatische Antwort an den Rechnungssteller, etwa eine E-Mail oder eine Peppol-Statusmeldung, versendet das Plugin nicht. Diese Rückmeldung richten Sie im Workflow ein:

  1. Validieren Sie die Rechnung mit dem Knoten E-Rechnung validieren und geben Sie eine Ausgabevariable an, damit ein HTML-Prüfbericht entsteht.
  2. Werten Sie das Ergebnis aus:
    • Ausgang true: Die Rechnung ist gültig oder enthält nur Warnungen. Sie läuft in den normalen Freigabeprozess.
    • Ausgang false: Die Rechnung verstößt gegen Schema oder Geschäftsregeln. Leiten Sie sie an eine Prüfaufgabe weiter, etwa für die Buchhaltung.
  3. Entscheidet die Buchhaltung, die Rechnung zurückzuweisen, senden Sie dem Rechnungssteller eine Nachricht mit dem Prüfbericht und der Bitte um eine korrigierte Rechnung. Verwenden Sie dazu die E-Mail-Funktionen von agorum core; bei Eingang über Peppol die Statusmeldungen Ihres Zugangspunkt-Anbieters.
  4. Legen Sie Prüfbericht und Entscheidung zusammen mit der Rechnung ab, damit die Zurückweisung nachvollziehbar bleibt.

Tipp: Weisen Sie Rechnungen mit Formatfehlern zurück und bitten Sie um eine neue Rechnung. Bei reinen Geschäftsregel-Fehlern oder Warnungen kann eine Annahme mit Korrekturbitte genügen. Der Prüfbericht des KoSIT-Validators enthält dazu eine Empfehlung, siehe Mit E-Rechnungen arbeiten.

Beispielworkflows für die Verarbeitung von E-Rechnungen

Beispielworkflow zum Verarbeiten von E-Rechnungen

In diesem Beispielworkflow passiert Folgendes:

  1. Die Dokumente eines Eingangsordners werden vom find-Knoten gefunden und an den nächsten Knoten übergeben.
  2. Der check-Knoten prüft, ob ein Dokument eine E-Rechnung ist (siehe Knoten "E-Rechnung prüfen"). E-Rechnungen werden an den parse-Knoten übergeben, für andere Dokumente wird eine Log-Meldung ausgegeben.
  3. Der parse-Knoten liest die XML-Rechnungsdaten und überführt sie in die normalisierten agorum-Daten (siehe Knoten "E-Rechnung normalisieren").
  4. Der createView-Knoten stellt die Daten mit einer Dokumentvorlage in einem Word- oder PDF-Dokument dar (siehe Knoten "Dokument aus E-Rechnung erstellen").
  5. Die erstellten Dokumente werden gespeichert und können weiterverwendet werden.

Wenn Sie vor der Anzeige und Weiterverarbeitung sicherstellen wollen, dass die Rechnungen gültig sind, bauen Sie eine Prüfung ein:

Beispielworkflow zum Verarbeiten von E-Rechnungen mit Prüfung der Rechnungsstruktur

Der validateInvoice-Knoten prüft die eingehenden E-Rechnungen mit dem KoSIT-Validator (siehe Knoten "E-Rechnung validieren"). Außerdem zeigt der Workflow, dass eine E-Rechnung Dokumente als Anhänge enthalten kann. Der parse-Knoten extrahiert und decodiert diese Anhänge, sodass sie als eigene Dokumente abgelegt werden können.

E-Rechnungen erstellen

Ausgehende E-Rechnungen entstehen aus den normalisierten Rechnungsdaten:

  1. Daten zusammenstellen: aus dem ERP-System, aus Metadaten oder durch Neuerfassung.
  2. Vollständigkeit prüfen und ergänzen: fehlende Pflichtangaben nachtragen.
  3. Erzeugen und prüfen: XML im gewählten Format erzeugen und mit dem KoSIT-Validator prüfen.
  4. Einbetten (nur ZUGFeRD): XML in ein PDF/A-3 einbetten.
  5. Versenden und ablegen: über den vereinbarten Kanal, etwa E-Mail, Rechnungsportal oder Peppol.

Eine Schritt-für-Schritt-Anleitung für beide Ausgangslagen – vorhandene Rechnungsdaten und Neuerfassung – finden Sie in E-Rechnungen erstellen.

Beispielworkflow für die Erstellung von E-Rechnungen

Beispielworkflow zum Erstellen von E-Rechnungen

Dieser Workflow erhält die normalisierten Daten von außen und erzeugt daraus die E-Rechnung:

  1. Der find-Knoten wählt das PDF-Dokument aus, das bei ZUGFeRD als Träger dient. In dieses PDF wird die XML eingebettet.
  2. Der create-Knoten erzeugt die E-Rechnung im angegebenen Format und bei ZUGFeRD im gewählten Profil (siehe Knoten "E-Rechnung aus normalisierten Daten erstellen"). Der Knoten prüft die Pflichtfelder, validiert das erzeugte XML und bricht bei einer ungültigen Rechnung ab.
  3. Der validate-Knoten prüft die XML erneut (siehe Knoten "E-Rechnung XML validieren"). Das ist nicht zwingend, weil der create-Knoten bereits validiert, liefert aber einen Prüfbericht für die Ablage.
  4. Die erstellten Rechnungsdokumente werden abschließend gespeichert.