E-Rechnungen und bestehende Geschäftsabläufe verbinden
Bestehende Werkzeuge gezielt ergänzen und technische Ergebnisse von fachlichen Entscheidungen unterscheidbar halten.
Eine Rechnung kommt als strukturierte Datei an. Die Software kann sie lesen und ihr Prüfbericht zeigt keine Formatfehler. Trotzdem kennt niemand die zugehörige Bestellung. Wird dieser Zustand mit „erledigt“ bezeichnet, entsteht ein fachliches Problem hinter einer technisch erfolgreichen Verarbeitung. Genau deshalb braucht die Einführung einen Blick auf den gesamten Vorgang.
Dieser Leitfaden betrachtet einen fiktiven mittelständischen Betrieb mit Einkauf, Fachabteilung und Buchhaltung. Er entwickelt ein eigenständiges Arbeitsmodell und begrenzte technische Beispiele. Die rechtliche Einordnung bezieht sich auf die am 9. November 2026 geprüften Quellen. Einzelfälle, Steuerbehandlung und konkrete Aufbewahrungsanforderungen müssen zum jeweiligen Geschäftsvorgang passen.
1. Formatanforderung und Geschäftsentscheidung unterscheiden
§ 14 UStG beschreibt elektronische Rechnungen als strukturierte, elektronisch verarbeitbare Rechnungen. Ein gewöhnliches PDF ohne entsprechende strukturierte Rechnungsdaten ist deshalb nicht allein durch seinen elektronischen Versand eine E-Rechnung in diesem Sinne. Die Prüfung beginnt beim tatsächlichen Inhalt und Format, nicht beim Dateinamen.
Für die erfassten inländischen Unternehmensumsätze sind Grundsatz, Ausnahmen und Übergangsregeln gemeinsam zu prüfen. § 27 Absatz 38 UStG enthält unter anderem die Übergänge bis Ende 2026 sowie bis Ende 2027 bei einem Vorjahresgesamtumsatz des Ausstellers von höchstens 800.000 Euro. Das ist keine pauschale Verlängerung für sämtliche Sachverhalte.
Eine technische Einführung kann schon unabhängig von einer konkreten Ausstellungsfrist sinnvoll sein. Der Empfang und die Weiterverarbeitung benötigen einen geeigneten Weg. Entscheiden Sie deshalb nicht nur nach dem spätesten möglichen Termin, sondern nach den tatsächlich eingehenden Formaten und den bestehenden Fähigkeiten Ihres Betriebs. Öffentliche Auftraggeber und grenzüberschreitende Vorgänge können zusätzliche Fragen aufwerfen.
Danach folgt die Geschäftsentscheidung: Gehört die Rechnung zu einer bekannten Lieferung? Stimmen Leistungsumfang und vereinbarte Konditionen? Wer darf die Freigabe erteilen? Diese Fragen werden nicht dadurch beantwortet, dass ein XML-Dokument formal korrekt ist. Sie benötigen Informationen aus Ihrem eigenen Betrieb und eine dafür verantwortliche Person.
2. Einen vorhandenen Vorgang vollständig aufnehmen
Verfolgen Sie zunächst eine Rechnung vom Eingang bis zur Übergabe an die Buchhaltung. Notieren Sie Postfach oder Portal, Ablage, zuständige Person und die verwendeten Systeme. Halten Sie auch Medienwechsel fest: Wird eine Datei ausgedruckt, eine Nummer in Excel erfasst oder eine Rückfrage per Nachricht gestellt?
Untersuchen Sie zusätzlich einen schwierigen Fall. Eine fehlende Bestellreferenz oder ein abweichender Betrag zeigt oft mehr über den Ablauf als ein sauberer Standardbeleg. Fragen Sie, wie eine Klärung sichtbar wird und wo der Beleg währenddessen bleibt. Eine Rechnung darf nicht aus dem Blick geraten, nur weil sie noch nicht freigegeben ist.
Trennen Sie gewünschte Kontrolle von historisch gewachsenen Umwegen. Ein fachlicher Vergleich mit der Bestellung kann erforderlich sein. Dreifaches Abschreiben derselben Rechnungsnummer bringt dagegen möglicherweise keinen zusätzlichen Nachweis. Ziel ist ein verständlicher Vorgang, in dem notwendige Entscheidungen erhalten bleiben und überflüssige Übertragungen entfallen.
Die Bestandsaufnahme endet mit einer kleinen Vorgangskarte. Sie enthält Eingang, zugehörige Originaldatei, Datenübernahme, technische Prüfung, Zuordnung, sachliche Prüfung, Freigabe und Übergabe. Jeder Schritt erhält ein Ergebnis und eine Zuständigkeit. So lässt sich später gezielt bestimmen, welcher Teil durch vorhandene Software bereits abgedeckt ist.
3. Den Eingang als kontrollierte Übergabestelle gestalten
Ein zentraler Eingang erleichtert die Übersicht, wenn er zu den tatsächlich vereinbarten Übermittlungswegen passt. Dazu kann ein geeignetes Postfach gehören. Ein Portal oder ein anderes Transportverfahren kann weitere Informationen mitliefern. Der Empfangsweg sollte nachvollziehbar beschreiben, wie eine neue Datei zu einem eindeutigen internen Vorgang wird.
Bewahren Sie das empfangene Material unverändert auf und erzeugen Sie Arbeitsansichten getrennt davon. Notieren Sie Herkunft und Eingangszeit soweit diese verlässlich verfügbar sind. Ein selbst vergebenes Datum ist nicht automatisch der Nachweis eines externen Eingangszeitpunkts. Die technische Ablage muss deshalb zwischen erhaltenen Angaben und intern erzeugten Metadaten unterscheiden.
Eine unbekannte Datei wird nicht allein wegen einer passenden Endung bedenkenlos geöffnet oder weiterverarbeitet. Beschränken Sie Dateigröße und unterstützte Formate passend zum Betrieb. Die technische Verarbeitung benötigt geeignete Schutzmaßnahmen für nicht vertrauenswürdige Inhalte. Solche Maßnahmen gehören in die Implementierung und werden durch den folgenden vereinfachten Ablauf nicht vollständig beschrieben.
Zu einem Eingang gehört außerdem ein Fehlerweg. Wer sieht eine nicht lesbare oder unvollständig übertragene Datei? Wie wird eine Rückfrage gestellt und der erneute Eingang zugeordnet? Ein allgemeiner Fehler im Protokoll genügt nicht, wenn anschließend niemand weiß, ob die Rechnung noch bearbeitet werden muss.
4. Format und Profil gezielt erkennen
Eine XRechnung und eine hybride Rechnung haben unterschiedliche technische Hüllen. Die FeRD-FAQ zu ZUGFeRD beschreibt PDF/A-3 mit eingebetteten XML-Daten als hybrides Format. Menschenlesbare Darstellung und strukturierte Daten müssen zusammenpassen. Ein beliebiges PDF mit irgendeinem angehängten XML-Dokument erfüllt diese Beschreibung nicht automatisch.
Ermitteln Sie deshalb das tatsächlich verwendete Format und gegebenenfalls das Profil. Ein Produktname allein ist zu ungenau, weil verschiedene Profile unterschiedliche Inhalte und Anforderungen betreffen können. Für einen kontrollierten Betrieb halten Sie fest, welche Kombinationen unterstützt werden und wie mit unbekannten Varianten umgegangen wird.
Trennen Sie dabei Erkennung, Extraktion und Prüfung. Das Auffinden einer eingebetteten Datei bedeutet nur, dass Daten vorhanden sind. Eine erfolgreiche XML-Verarbeitung bedeutet noch keine Konformität mit dem geforderten Rechnungsstandard. Die Bearbeitungsschritte benötigen deshalb unterschiedliche Ergebnisse, statt unter einer einzigen grünen Statusanzeige zu verschwinden.
Erstellen Sie für die Einführung ein kleines Formatregister. Es nennt einen geeigneten gültigen Beispielfall, einen absichtlich fehlerhaften Fall und die erwartete Behandlung. Verwenden Sie keine echten Geschäftsdaten in frei zugänglichen Prüfangeboten, nur um eine Formatfrage bequem zu untersuchen. Die benötigte Prüfung kann gegebenenfalls in einer geeigneten eigenen Umgebung stattfinden.
5. Validierung mit dokumentierten Regeln betreiben
Die KoSIT-Dokumentation zum Validator beschreibt Prüfungen mit XML Schema und Schematron sowie getrennte Konfigurationen. Für einen reproduzierbaren Nachweis gehören Werkzeug, Regelkonfiguration und Bericht zusammen. „Validator erfolgreich“ ist unvollständig, wenn sich später nicht mehr feststellen lässt, welche Regeln angewendet wurden.
Bewahren Sie den Prüfbericht mit Bezug zum richtigen Original auf. Bei einer erneuten Prüfung kann eine andere Regelkonfiguration ein anderes Ergebnis liefern. Überschreiben Sie deshalb den früheren Bericht nicht stillschweigend. Der Verlauf soll erklären, ob sich die Datei geändert hat oder nur die angewandte Prüfung.
Eine Fehlermeldung braucht eine geeignete Erläuterung. Eine technisch benannte Geschäftsregel kann für die Buchhaltung schwer verständlich sein. Ordnen Sie sie einer bearbeitbaren Aufgabe zu, etwa einer fehlenden Referenz oder einer unpassenden Angabe. Die technische Meldung bleibt erhalten, während die zuständige Person eine verständliche Arbeitsanweisung erhält.
Ein bestandener Formatlauf ist eine Eingangsinformation für den nächsten Schritt. Er genehmigt keine Zahlung und bestätigt keine tatsächlich erbrachte Leistung. Prüfen Sie mit absichtlich unterschiedlichen Beispielfällen, ob diese Trennung in der Anwendung erhalten bleibt. Eine technisch korrekte, fachlich unpassende Rechnung muss sichtbar weiter geprüft werden.
6. Strukturierte Angaben auf den eigenen Bestand abbilden
Eine externe Lieferantennummer ist nicht automatisch dieselbe Kennung wie im eigenen System. Erstellen Sie eine begründete Zuordnung und behandeln Sie unbekannte Werte gesondert. Eine scheinbar ähnliche Schreibweise darf nicht unbemerkt zum eindeutigen Treffer werden. Besonders bei mehreren Standorten oder verbundenen Unternehmen kann eine einfache Namenssuche irreführend sein.
Bestellbezug, Kostenstelle und verantwortliche Person können aus unterschiedlichen Quellen stammen. Beschreiben Sie für jedes Zielattribut, ob es aus der Rechnung übernommen, aus einem eigenen Register ergänzt oder durch eine Person entschieden wird. Diese Herkunft hilft später bei der Klärung widersprüchlicher Angaben.
Für unsichere Zuordnungen eignet sich eine gesonderte Warteschlange. Sie zeigt, welche Information fehlt und wer sie klären kann. Wenn Vorschläge automatisch erzeugt werden, müssen sie von bestätigten Zuordnungen unterscheidbar bleiben. Eine gute Trefferwahrscheinlichkeit rechtfertigt nicht automatisch eine verbindliche Buchungsentscheidung.
Prüfen Sie die Abbildung mit Fällen, die ähnliche Namen und unterschiedliche Kennungen besitzen. Kontrollieren Sie außerdem geänderte Stammdaten. Eine neue Bankverbindung oder Adresse kann eine gesonderte Prüfung verlangen. Die Rechnung allein sollte nicht automatisch sämtliche bestehenden Stammdaten überschreiben, nur weil sich die Angaben technisch auslesen lassen.
7. Dubletten auf mehreren Ebenen untersuchen
Dieselbe Datei kann mehrfach eingehen. Ein Vergleich ihrer Bytefolgen oder Prüfsummen kann einen identischen Inhalt erkennen helfen. Dieselbe Rechnung kann jedoch auch mit geänderter Darstellung oder über einen anderen Übermittlungsweg ankommen. Dafür reicht ein reiner Dateivergleich nicht aus, obwohl der Geschäftsvorgang möglicherweise derselbe ist.
Definieren Sie deshalb eine passende fachliche Verdachtsregel. Lieferantenzuordnung und Rechnungsnummer können dabei wichtig sein, müssen aber zum betrachteten Nummernkreis und Geschäftsvorgang passen. Berichtigungen und Gutschriften benötigen ebenfalls eine nachvollziehbare Behandlung. Ein gleicher Betrag oder ein ähnlicher Dateiname sind für sich keine sichere Dublettendefinition.
Ein Verdacht führt zunächst zu einer Klärung. Bewahren Sie beide Eingänge und ihren Zusammenhang auf, statt einen davon automatisch zu löschen. Die zuständige Person kann entscheiden, ob ein erneuter Versand, eine Berichtigung oder ein tatsächlich anderer Vorgang vorliegt. Das Ergebnis wird Teil der weiteren Bearbeitung.
Die technische Umsetzung sollte eine wiederholte Verarbeitung kontrolliert behandeln. Nach einer Zeitüberschreitung darf ein erneuter Versuch nicht unbemerkt zwei Übergaben oder Zahlaufträge erzeugen. Eine geeignete Vorgangskennung und klar bestätigte Übergabe helfen bei dieser Aufgabe. Das ist von der Frage zu unterscheiden, ob zwei unterschiedliche Dateien fachlich dieselbe Rechnung darstellen.
8. Den nächsten Bearbeitungsschritt eindeutig bestimmen
Ein kleiner Prüfstand kann den nächsten offenen Schritt sichtbar machen. Das folgende JavaScript nutzt fest definierte Lehrdaten. Jede Prüfstufe ist offen, bestanden oder abgelehnt; ein Dublettenverdacht wird getrennt erfasst. Die Funktion priorisiert Aufgaben. Sie führt keine Buchung aus und ist keine vollständige Zustandsmaschine für eine Rechnungsanwendung.
function naechsterSchritt(eingang) {
const erlaubt = new Set(['offen', 'bestanden', 'abgelehnt']);
const felder = ['format', 'zuordnung', 'sachlich', 'freigabe'];
if (!felder.every(feld => erlaubt.has(eingang?.[feld])) ||
typeof eingang?.dublette !== 'boolean') {
throw new TypeError('Vollständigen Prüfstand angeben.');
}
if (eingang.format !== 'bestanden') return 'Format klären';
if (eingang.dublette) return 'Dublettenverdacht klären';
if (eingang.zuordnung !== 'bestanden') return 'Zuordnung klären';
if (eingang.sachlich === 'abgelehnt') return 'Fachliche Abweichung klären';
if (eingang.sachlich === 'offen') return 'Sachlich prüfen';
if (eingang.freigabe === 'abgelehnt') return 'Freigabe abgelehnt';
if (eingang.freigabe === 'offen') return 'Freigabe einholen';
return 'Zur Übergabe bereit';
}
const eingang = {
format: 'bestanden', dublette: false, zuordnung: 'bestanden',
sachlich: 'offen', freigabe: 'offen'
};
console.log(naechsterSchritt(eingang)); // Sachlich prüfenDer fiktive Eingang bleibt nach bestandener Formatprüfung und Zuordnung in der sachlichen Prüfung. Erst wenn diese abgeschlossen und eine Freigabe vorhanden ist, wird die Übergabe möglich. Eine ausdrücklich abgelehnte Freigabe wird nicht wie eine noch ausstehende Zustimmung behandelt. Unbekannte oder unvollständige Statusangaben werden zurückgewiesen.
In einer wirklichen Anwendung gehören Berechtigungen, gleichzeitige Bearbeitung, dauerhafte Speicherung und nachvollziehbare Änderungen hinzu. Ein Statusfeld darf nicht von beliebigen Beteiligten auf „bestanden“ gesetzt werden. Die Lernfunktion macht lediglich die Reihenfolge der fachlichen Fragen sichtbar und verhindert bestimmte Verwechslungen im dargestellten Beispiel.
9. Dateiintegrität ergänzend dokumentieren
Eine Prüfsumme kann erkennen helfen, ob dieselben Bytes weiterhin vorliegen. Die Node.js-Dokumentation zu Crypto beschreibt dafür unter anderem Hash-Funktionen. Der folgende kurze Ausschnitt verwendet nur einen erfundenen Text als Demonstration und verarbeitet ausdrücklich keine gültige Rechnung.
import { createHash } from 'node:crypto';
function dateiHash(bytes) {
if (!Buffer.isBuffer(bytes) || bytes.length === 0) {
throw new TypeError('Nichtleere Dateibytes erforderlich.');
}
return createHash('sha256').update(bytes).digest('hex');
}
const bytes = Buffer.from('Fiktiver Rechnungseingang', 'utf8');
console.log(dateiHash(bytes));Speichern Sie eine solche Prüfsumme zusammen mit dem zugehörigen Vorgangsbezug und der verwendeten Datei. Sie beweist für sich weder die Identität des Ausstellers noch eine fachliche Richtigkeit oder eine ordnungsgemäße Aufbewahrung. Ein sinnvolles Kontrollverfahren verbindet mehrere Nachweise, deren jeweilige Aussage verständlich bleibt.
Auch ein identischer Hash ist nur eine technische Information über den geprüften Inhalt. Wenn ein geänderter Rechnungscontainer dieselben fachlichen Rechnungsdaten enthält, kann sein Hash abweichen. Ein Hashvergleich und eine fachliche Dublettenprüfung erfüllen deshalb unterschiedliche Aufgaben und sollten im Bearbeitungsprotokoll nicht gleich benannt werden.
10. Übergabe und Aufbewahrung zusammen planen
Die Übergabe an eine Buchhaltungsanwendung braucht eine klare Bestätigung. Welche Datensätze wurden angenommen, welche zurückgestellt und welche abgewiesen? Ein fehlerfreier Dateiversand ist noch kein bestätigter Import. Halten Sie den Bezug zwischen internem Vorgang, Original, Prüfberichten und Ergebnis der Zielanwendung fest.
§ 14b UStG enthält Aufbewahrungsvorgaben für Rechnungen. Die tatsächliche Umsetzung ist im Zusammenhang mit weiteren einschlägigen Regeln und dem konkreten Fall zu bestimmen. Eine zusätzliche Lesefassung ersetzt dabei nicht automatisch die benötigten strukturierten Originalinformationen. Stimmen Sie Ablage, Zugriff und Wiederauffindbarkeit mit den fachlich Verantwortlichen ab.
Testen Sie eine Wiederherstellung mit einem geeigneten Beispielsatz. Kann die zuständige Person Rechnung, zugehörige Prüfung und Freigabe wiederfinden und verständlich zuordnen? Ein Verzeichnis mit vielen Dateien ist noch kein brauchbarer Nachweis eines abgeschlossenen Vorgangs. Auch während eines Softwarewechsels muss der Zusammenhang nachvollziehbar bleiben.
Beachten Sie unterschiedliche Rollen. Nicht jede Person, die einen Beleg sachlich prüft, benötigt sämtliche Buchhaltungsfunktionen. Gleichzeitig darf eine notwendige Klärung nicht daran scheitern, dass niemand Zugriff auf die relevante Information hat. Die passende Berechtigungsstruktur folgt den Aufgaben und wird mit den tatsächlichen Bearbeitungswegen geprüft.
11. Mit einem begrenzten Pilotprozess beginnen
Wählen Sie einen überschaubaren Rechnungseingang mit bekannten Zuständigkeiten. Prüfen Sie gültige Formate, Fehler, fehlende Referenzen, Dublettenverdacht und abgelehnte Freigaben. Vereinbaren Sie erwartete Ergebnisse, bevor die Fälle durchlaufen werden. Der Pilot soll die Übergänge zwischen den Schritten untersuchen, nicht nur ein einzelnes Werkzeug vorführen.
Vergleichen Sie nach dem Versuch offene Aufgaben und tatsächliche Rückfragen. Ein nützlicher Befund lautet beispielsweise, dass unklare Lieferantenzuordnungen jetzt sichtbar einer Person zugewiesen werden. Behaupten Sie daraus keine allgemeine Einsparungsquote. Wenige Fälle können konkrete Schwächen zeigen, aber keine zuverlässige Aussage über sämtliche zukünftigen Rechnungen liefern.
Erweitern Sie den Prozess erst nach Klärung der gefundenen Grenzen. Bestehende Excel-Auswertungen oder Fachanwendungen können erhalten bleiben, wenn ihre Rolle eindeutig beschrieben ist. Die entscheidende Verbesserung ist ein durchgängiger verlässlicher Zusammenhang zwischen Eingang und Bearbeitung. Ein vollständiger Softwarewechsel ist dafür nicht automatisch erforderlich.
12. Pilotfälle als überprüfbare Entscheidungen beschreiben
Ein erster Prüffall enthält eine formal passende Rechnung ohne bestätigten Bestellbezug. Die erwartete Aufgabe lautet „Zuordnung klären“. Erfassen Sie, welche Person den Bezug ergänzt und welche Information dafür benötigt wird. Erst danach darf derselbe Vorgang weiterlaufen. Damit wird geprüft, ob eine fehlende interne Information tatsächlich sichtbar bleibt und nicht durch eine erfolgreiche Formatprüfung verdeckt wird.
Ein zweiter Fall hat eine bekannte Bestellung, aber eine fachlich abgelehnte Position. Die Bearbeitung muss eine Abweichung zeigen. Eine erneute technische Prüfung der unveränderten Datei löst diesen Einwand nicht. Dokumentieren Sie, wie eine Rückfrage, Berichtigung oder begründete neue Entscheidung zugeordnet wird. Der ursprüngliche Einwand bleibt Teil des verständlichen Vorgangsverlaufs.
Ein dritter Fall wird nach einer unterbrochenen Übergabe erneut gestartet. Prüfen Sie, ob bereits eine Bestätigung der Zielanwendung vorliegt und wie ein unklarer Zustand behandelt wird. Die Erwartung ist eine kontrollierte Klärung statt einer ungeprüften zweiten Übernahme. Dieser Versuch untersucht einen konkreten Übergang, der in reinen Normalfalldemonstrationen häufig unsichtbar bleibt.
Checkliste für den zusammenhängenden Rechnungsprozess
- Tatsächliche Formate, Geschäftsfälle und rechtlichen Rahmen geprüft.
- Eingang und interne Vorgangskennung nachvollziehbar verbunden.
- Originaldatei von Arbeitsansichten getrennt erhalten.
- Format, Profil und Regelkonfiguration dokumentiert.
- Technische Prüfung von sachlicher Freigabe unterschieden.
- Lieferant, Bestellung und Verantwortliche begründet zugeordnet.
- Dateidubletten und fachlichen Verdacht getrennt untersucht.
- Unklare und abgelehnte Fälle sichtbar bearbeitet.
- Wiederholte Übergaben kontrolliert behandelt.
- Annahme in der Zielanwendung bestätigt.
- Aufbewahrung, Wiederauffindbarkeit und Wiederherstellung geprüft.
Häufige Fragen zu E-Rechnungsabläufen
Reicht ein PDF per E-Mail?
Eine gewöhnliche PDF-Datei ohne passende strukturierte Rechnungsdaten ist nicht allein wegen ihres Versandwegs eine E-Rechnung im hier beschriebenen gesetzlichen Sinne. Ob eine sonstige Rechnung im konkreten Fall zulässig ist, hängt unter anderem von Anwendungsbereich und Übergangsvorschriften ab.
Ist eine formal gültige Rechnung automatisch zahlungsbereit?
Nein. Die Formatprüfung beantwortet andere Fragen als Zuordnung, sachliche Kontrolle und Freigabe. Das Arbeitsmodell hält diese Ergebnisse deshalb getrennt. Ein technisch einwandfreier Eingang kann weiterhin eine fehlende Bestellung oder fachliche Abweichung enthalten.
Muss die gesamte vorhandene Software ersetzt werden?
Nicht automatisch. Prüfen Sie zuerst, welche Schritte bereits verlässlich funktionieren und wo eine konkrete Lücke besteht. Ein geeigneter Empfang, eine ergänzte Prüfung oder eine kontrollierte Schnittstelle kann genügen. Der vollständige Ablauf muss anschließend gemeinsam untersucht werden.
Erkennt ein Dateihash alle doppelten Rechnungen?
Er hilft beim Vergleich identischer Dateiinhalte. Derselbe Geschäftsvorgang kann aber in verschiedenen Dateien auftreten. Eine fachliche Verdachtsregel und die Behandlung von Berichtigungen bleiben deshalb notwendig. Ein Hash ersetzt keine Bewertung der zugrunde liegenden Rechnung.
Quellen und nächste Schritte
Quellenstand: 9. November 2026. Prozess, Statusmodell und Quellcode sind eigenständige Lernbeispiele für die Abstimmung zwischen Fachverantwortlichen und technischer Umsetzung.
