Eine Rechnung kommt als XML-Datei, die nächste als PDF mit eingebetteten Daten. Im Büro wird beides ausgedruckt, geprüft und anschließend wieder eingescannt. Damit entsteht zwar ein gewohnter Papierstapel, aber der Vorteil strukturierter Rechnungen geht verloren. Für einen Handwerks- oder Dienstleistungsbetrieb im Rhein-Main-Gebiet lohnt sich deshalb zuerst ein Blick auf den Ablauf: Wer nimmt die Datei entgegen, wer prüft sie und wann darf sie weiterverarbeitet werden?
Das Bundesfinanzministerium unterscheidet seit dem 1. Januar 2025 zwischen strukturierten E-Rechnungen und sonstigen Rechnungen. Ein einfaches PDF erfüllt die neue Definition einer E-Rechnung nicht. Für Ausstellungspflichten bestehen Übergangs- und Ausnahmeregelungen. Dieser Beitrag behandelt die technische Organisation des Eingangs, nicht die steuerliche Einordnung eines einzelnen Umsatzes.
Erst den Prozess bestimmen, dann die Hardware
Ein einzelnes Rechnungsprogramm benötigt nicht automatisch einen eigenen Server. Wichtig sind zunächst unterstützte Formate, Zuständigkeiten und die Anbindung an die Buchhaltung. Wer für einen lokalen Betrieb nach „server kaufen“ sucht, sollte deshalb vorher festhalten, welche Anwendungen darauf laufen und wie viele Dokumente gleichzeitig bearbeitet werden. Mehr Arbeitsspeicher behebt weder fehlende Formatunterstützung noch einen ungeklärten Freigabeprozess.
Als Rechenbeispiel dient ein Betrieb mit 80 Eingangsrechnungen pro Woche. Die Zahl ist frei gewählt und keine regionale Statistik. Ein zentraler Eingang, eine fachliche Prüfung und eine geregelte Übergabe sollen verhindern, dass Rechnungen in persönlichen Postfächern liegen bleiben oder zweimal erfasst werden.
Die Originaldatei erhalten und lesbar darstellen
Eine XRechnung ist strukturiert und muss für die menschliche Prüfung geeignet dargestellt werden. ZUGFeRD verbindet dagegen eine PDF-Darstellung mit eingebetteten strukturierten Daten. Das BMF nennt die in Deutschland üblichen Formate XRechnung und geeignete ZUGFeRD-Profile als Beispiele. Nicht jedes PDF und nicht jede beliebige ZUGFeRD-Ausprägung sind damit gleichzusetzen.
Die Anwendung sollte die eingegangene Datei unverändert übernehmen und die Anzeige daraus erzeugen. Ein Ausdruck allein ist kein technischer Ersatz für den strukturierten Datensatz. Welche Bestandteile im konkreten Fall aufzubewahren sind, wird mit der Steuerberatung und dem eingesetzten Archivsystem geklärt. Eine bloße Netzwerkfreigabe ist noch kein vollständig geregeltes Archiv.
Praktisch hilft eine eindeutige interne Vorgangsnummer. Sie verbindet die Eingangsdatei mit Darstellung, Prüfergebnis und Buchung. Der Dateiname des Absenders reicht dafür nicht: Mehrere Lieferanten können ihre Dokumente schlicht „Rechnung.pdf“ nennen, und eine korrigierte Rechnung kann unter demselben Namen eintreffen.
Technische und sachliche Prüfung trennen
Eine technische Validierung kontrolliert beispielsweise Struktur und Formatregeln. Sie bestätigt nicht, dass die berechnete Leistung tatsächlich erbracht wurde. Umgekehrt kann eine sachlich plausible Rechnung technisch nicht verarbeitbar sein. Beide Ergebnisse gehören deshalb getrennt in den Status des Vorgangs.
Die sachliche Prüfung vergleicht Bestellung, Lieferung oder Leistungsnachweis mit der Rechnung. Bei einer fiktiven Bestellung über zwölf Teile zu je 45 Euro ergibt sich ein Nettobetrag von 540 Euro. Stehen nur zehn gelieferte Teile im Wareneingang, muss die Abweichung sichtbar werden, bevor der Vorgang zur Zahlung freigegeben wird.
Auch eine neue Bankverbindung verdient einen eigenen Kontrollschritt. Dass sie in einer formal gültigen Datei steht, macht sie nicht automatisch vertrauenswürdig. Änderungen werden über einen bekannten, unabhängigen Kontaktweg bestätigt. Die dafür verwendeten Kontaktdaten sollten nicht allein aus der fraglichen Nachricht stammen.
Ein Status muss eine Handlung auslösen
Sinnvolle Zustände sind etwa „eingegangen“, „technisch geprüft“, „Rückfrage“, „sachlich freigegeben“ und „übergeben“. Zu jedem Zustand steht fest, wer den nächsten Schritt übernimmt. Eine Markierung „in Bearbeitung“ ohne verantwortliche Person führt sonst dazu, dass das Dokument zwar digital sichtbar, aber organisatorisch weiterhin verloren ist.
Für Rückfragen werden Grund, Zeitpunkt und zuständige Person festgehalten. Muss der Lieferant eine Korrektur senden, bleibt die Verbindung zum ursprünglichen Vorgang erhalten. Die neue Datei überschreibt nicht stillschweigend die alte. So lässt sich später erklären, auf welcher Grundlage die Buchhaltung gearbeitet hat.
Doppelte Eingänge erkennen, ohne falsche Treffer zu erzeugen
Eine Rechnung kann per E-Mail kommen und zusätzlich über ein Portal heruntergeladen werden. Zur Erkennung möglicher Doppelungen eignen sich mehrere Merkmale zusammen, etwa Lieferantenkennung, Rechnungsnummer und weitere Dokumentdaten. Ein identischer Betrag allein genügt nicht: Monatliche Leistungen können regelmäßig denselben Preis haben.
Ein technischer Hash kann identische Dateien erkennen. Er beantwortet jedoch nicht, ob zwei unterschiedlich erzeugte Dateien dieselbe Rechnung enthalten. Umgekehrt sollten ähnliche Nummern nicht automatisch zusammengeführt werden. Der Prozess braucht einen prüfbaren Verdacht auf Doppelung und eine Entscheidung, wie damit umzugehen ist.
Testen lässt sich das mit einem kleinen Satz bekannter Fälle: dieselbe Datei zweimal, dieselbe Rechnung in zwei Übermittlungen, zwei echte Rechnungen mit gleichem Betrag und eine Korrektur. Das System sollte diese Fälle unterscheiden, statt jeden ähnlichen Datensatz einfach zu verwerfen.
Aufwand und Speicherbedarf realistisch rechnen
Angenommen, die bisherige Erfassung dauert fünf Minuten pro Rechnung. Bei 80 Dokumenten sind das 400 Minuten pro Woche. Benötigt der neue Ablauf im Mittel drei Minuten einschließlich Kontrolle, sinkt der Aufwand auf 240 Minuten. Die Differenz beträgt 160 Minuten. Das ist ein Rechenbeispiel, kein versprochener Automatisierungsgewinn.
Zur Messung gehören auch fehlerhafte Eingänge, Rückfragen und manuelle Nacharbeit. Werden nur problemlos importierte Dokumente gezählt, erscheint der neue Prozess besser, als er im Alltag ist. Aussagekräftig sind Bearbeitungszeit pro abgeschlossenem Vorgang und die Zahl der am Wochenabschluss offenen Rechnungen.
Bei angenommenen zwei Megabyte je Dokument einschließlich Anlagen entstehen aus 80 Rechnungen pro Woche und 52 Wochen etwa 8,32 Gigabyte im Jahr. Darstellungen, Datenbank, Protokolle und Sicherungen kommen hinzu. Entscheidend für die Hardware können deshalb eher Anwendung und Verfügbarkeit sein als die reine Größe der Rechnungsdateien.
Den Ausfall einer Schnittstelle mitprüfen
Die Übernahme in die Buchhaltungssoftware muss einen bestätigten Abschluss liefern. Ein erfolgreicher Dateiexport beweist nicht, dass die Zielanwendung die Buchung übernommen hat. Der Status sollte erkennen lassen, ob der Vorgang nur bereitgestellt, übertragen oder tatsächlich angenommen wurde.
Ein Wiederholungsversuch darf nicht unbemerkt eine zweite Buchung erzeugen. Vor dem produktiven Einsatz wird daher mit Testdaten geprüft, was bei Zeitüberschreitung, unterbrochener Verbindung und erneutem Import geschieht. Produktive Zahlungen oder Buchungen sind für einen solchen Versuch ungeeignet.
Ein überschaubarer Pilot reicht für den Anfang
Für den Start eignen sich ein Eingangskanal, wenige Lieferanten und ein festgelegter Zeitraum. Erfasst werden erfolgreiche Übernahmen, Fehlerarten, Rückfragen und Bearbeitungszeiten. Anschließend entscheidet der Betrieb, welche Regeln angepasst werden müssen und ob die vorhandene Infrastruktur ausreicht.
Der Nutzen besteht dann in einem nachvollziehbaren Weg vom Eingang bis zur Übergabe. Rechnungen liegen nicht mehr in verstreuten Postfächern, und offene Fragen bleiben sichtbar. Eine größere Serverkonfiguration wird erst dann sinnvoll, wenn der geprüfte Ablauf tatsächlich zusätzliche Ressourcen benötigt.
