EZD mit KSeF-Anbindung ist noch kein Rechnungsworkflow

Dieser Beitrag richtet sich an Sekretäre (sekretarz) und Treasurer (skarbnik), die vom Anbieter hören „unser EZD unterstützt KSeF“, und sich fragen, ob damit das Thema Rechnungsworkflow erledigt ist.

Was die Integration von EZD mit KSeF wirklich leistet

Seit dem 1. Februar 2026 empfangen Behörden strukturierte Rechnungen über das polnische nationale E-Rechnungssystem (KSeF). Ein Teil der Systeme der EZD-Klasse, darunter EZD RP, kann eine solche Rechnung abrufen und als eingehendes Dokument anzeigen. Das ist ein echter Vorteil: Die Rechnung geht nicht im E-Mail-Postfach unter, trägt eine KSeF-Nummer und ein Eingangsdatum und ist im System sichtbar. In der Regel gelangt sie jedoch nicht sofort in den Vorgang. Zunächst sieht sie die Einlaufstelle, die sie an die fachlich zuständige Organisationseinheit weiterleitet, und erst diese Einheit fügt die Rechnung dem Vorgang hinzu. Und weiß die Einlaufstelle von vornherein, welcher Organisationseinheit eine solche Rechnung zuzuordnen ist? Zu bedenken ist auch, dass die Metadaten der Rechnung die Rechnung selbst beschreiben: Positionen, Netto- und Bruttobeträge, Umsatzsteuersätze. Das deckt sich nicht immer mit dem, was im Formular zur Erfassung des Posteingangs steht, dessen Metadatenumfang in der Kanzleiordnung (instrukcja kancelaryjna) festgelegt ist.

Hier endet die Integration jedoch bereits. Die Rechnung befindet sich im System, sogar im Vorgang, aber niemand hat sie bislang beschrieben, freigegeben, geprüft oder verbucht. Der weitere Weg hängt davon ab, wie die Behörde den Workflow für Buchhaltungsbelege organisiert hat. In vielen Behörden sieht das genauso aus wie vor KSeF: Ausdruck, Unterschriften auf der Rückseite oder auf dem Stempel, Mappe zur Finanzabteilung, manuelle Erfassung im Finanz-Buchhaltungssystem.

Der Weg der Rechnung vom Eingang bis zur Zahlung

Jede Behörde hat diesen Weg in ihrer Anweisung zum Umlauf und zur Kontrolle von Buchhaltungsbelegen festgelegt. Die Details unterscheiden sich, doch die Schritte ähneln sich meist.

1. Eingang. Die Rechnung kommt über KSeF – aber nicht nur. Bis Ende 2026 dürfen einige kleinere Lieferanten noch Rechnungen außerhalb von KSeF ausstellen, und ausländische Lieferanten stellen sie auch danach weiterhin außerhalb des Systems aus. Rechnungen gehen weiterhin per E-Mail und in Papierform ein, und Papierrechnungen müssen gescannt und per Texterkennung (OCR) ausgelesen werden, damit die Daten nicht manuell abgeschrieben werden. In KSeF gibt es in der Regel keinen Platz für Anhänge (die Struktur FA(3) sieht nur einen begrenzten Anhang in Form von Daten vor, dessen Verwendung gemeldet werden muss), weshalb der Lieferant häufig dieselbe Rechnung zusätzlich per E-Mail zusammen mit den begleitenden Dokumenten versendet: Abnahmeprotokoll, Leistungsaufstellung oder Spezifikation. Es kommt auch vor, dass er einen Ausdruck oder ein PDF der bereits in KSeF befindlichen Rechnung ohne jegliche Anhänge schickt. Bei einem KSeF-Ausfall oder im Offline-Modus gelangt die Rechnung mit QR-Code früher in die Behörde als in das System. Die Behörde muss daher wissen, dass sie eine bestimmte Rechnung bereits erhalten hat, um sie nicht doppelt zu bearbeiten. Die Rechnung ist zudem nicht das einzige Kostendokument. Versicherungspolicen, Honorarabrechnungen zu zivilrechtlichen Verträgen, Gutschriften, Gebühren und Bescheide über Forderungen durchlaufen einen ähnlichen Weg: Beschreibung, Freigabe, Klassifikation, Verbuchung, Zahlung. Alle Kostendokumente sollten unabhängig vom Eingangskanal und von der Art in einen einzigen Workflow gelangen. Sonst hat die Behörde einen gesonderten Weg für Rechnungen aus KSeF und einen zweiten, papierbasierten, für alles Übrige.
2. Verknüpfung mit Vertrag oder Bestellung. Die Rechnung betrifft einen konkreten Vertrag, Auftrag oder eine Bestellung. Manchmal genügt es, sie dem Vertrag zuzuordnen. Manchmal der Bestellung, die keinen eigenen Vertrag hat. Und es kommt auch vor, dass zu einem Rahmenvertrag weitere Bestellungen hinzukommen und die Rechnung eine davon betrifft, sodass sie mit der Bestellung und über diese mit dem Vertrag verknüpft werden muss. Eine gute Verknüpfung zeigt sofort die fachlich zuständige Organisationseinheit, den abzurechnenden Betrag und an, wie viel von der Bestellung und vom Vertrag noch übrig ist. Ohne Vertragsregister und Bestellevidenz muss jemand danach manuell suchen.
3. Beschreibung und Freigaben. Die Organisationseinheit, die bestellt hat, bestätigt, dass die Dienstleistung erbracht bzw. die Ware geliefert wurde, gemäß Vertrag oder Bestellung. Damit ist es oft nicht getan. Wurde der Einkauf aus mehreren Haushaltsposten finanziert, für die verschiedene Organisationseinheiten zuständig sind, sollte jede Einheit den Teil der Rechnung freigeben, der ihr Budget belastet. Handelt es sich um eine IT-bezogene Ausgabe, verlangt die Umlaufanweisung in der Regel zusätzlich die Freigabe der IT-Abteilung, selbst wenn eine andere Abteilung fachlich zuständig ist. Ähnlich verhält es sich bei Investitionsausgaben, EU-Projekten oder öffentlichen Vergabeverfahren. Eine einzige Rechnung kann daher drei, vier Freigaben erfordern, und das Einholen all dieser Freigaben – besonders in Papierform – gehört oft zum mühsamsten Teil des Workflows: Die Rechnung wartet auf dem Schreibtisch einer Person im Urlaub, kommt wegen einer fehlenden Unterschrift zurück, und niemand weiß, wo sie sich gerade befindet.
4. Finanzierungsquelle und Haushaltsklassifikation. Es müssen Abteilung, Kapitel und Paragraf angegeben werden, die Maßnahme aus dem Finanzplan, und manchmal auch das Projekt und die Förderquelle. Jemand prüft, ob im Plan hierfür Mittel vorhanden sind.
5. Kontrolle, Kontierung und Freigabe zur Auszahlung. Die Buchhaltung prüft die Rechnung in formaler und rechnerischer Hinsicht, und der Hauptbuchhalter (bei JST der Treasurer/skarbnik) bestätigt die Vorkontrolle. Der Beleg wird zur Erfassung in den Büchern qualifiziert. Nach der Prüfung durch den Treasurer verlangt die Umlaufanweisung häufig noch die Freigabe durch ein Vorstandsmitglied, das die Aufsicht über die fachlich zuständige Einheit ausübt (in der Gemeinde durch den Wójt, Bürgermeister bzw. Stellvertreter), und in dessen Abwesenheit durch ein anderes Vorstandsmitglied. Das ist eine weitere Person, eine weitere Unterschrift und ein weiterer Ort, an dem die Rechnung liegen bleiben kann, wenn der Workflow nicht weiß, wer wen vertritt.
6. Erfassung im Finanz-Buchhaltungssystem. Die freigegebene Rechnung muss in die Buchhaltung gelangen. Dies ist der wichtigste Berührungspunkt zwischen den Systemen: Fehlt hier die Verbindung, schreibt jemand die Daten aus der Rechnung, die als strukturierte Datei eingegangen ist, vom Ausdruck ab.
7. Zahlung. Die Zahlung ist ein eigenständiger Prozess, der mit der Rechnung verknüpft, aber nicht Teil von ihr ist. In der Regel übernimmt sie das Finanz-Buchhaltungssystem: In ein einziges Überweisungspaket fließen Zahlungen aus mehreren Rechnungen ein, mit Fristenkontrolle und – soweit erforderlich – geteilter Zahlung (split payment). Der Rechnungsworkflow sollte der Buchhaltung lediglich den vollständigen Datensatz liefern und danach erfahren, dass die Rechnung bezahlt wurde.
8. Archivierung. Die Rechnung mit Beschreibung, Freigaben und Zahlungsbestätigung soll an einem einzigen Ort verbleiben, bereit für eine Prüfung.

KSeF mit EZD deckt den ersten Schritt und einen Teil des achten ab. Die übrigen sechs Schritte finden nebenher statt.

Ein Beispielprozess in einer Abbildung

Nachfolgend derselbe Weg in BPMN-Notation, einer Standarddarstellung für Prozesse. Jede Spur steht für eine Rolle in der Behörde. Schwarze Pfeile zeigen, wer nach wem arbeitet, gestrichelte Linien stehen für den Datenaustausch mit Systemen, die neben dem Workflow stehen: KSeF, dem Geschäftspartnerstammdatenregister, dem Vertrags- und Beschaffungsregister sowie dem Finanz-Buchhaltungssystem. Aufgaben mit einem Zahnrad-Symbol kann das System ohne Mitwirkung eines Menschen ausführen. Ein beweglicher Marker zeigt den Weg einer einzelnen Rechnung: von KSeF über die einzelnen Freigaben bis zur Erfassung in der Buchhaltung, kleinere Markierungen stehen für Daten, die unterwegs mit den Systemen ausgetauscht werden. Dies ist ein Beispiel, kein Vorbild: In jeder Behörde werden Spuren, Freigaben und Verbindungen etwas anders aussehen.

Eine solche Abbildung lohnt es sich für die eigene Behörde zu erstellen, bevor man sich für ein Werkzeug entscheidet. Sofort wird sichtbar, wie viele Freigaben nötig sind, wo die Rechnung liegen bleiben kann und an wie vielen Stellen Daten zwischen Systemen wechseln.

Wie viele Systeme berührt eine einzige Rechnung

Zeichnet man den Weg der Rechnung nach, zeigt sich, dass sie KSeF, ein System der EZD-Klasse, das Geschäftspartnerstammdatenregister, das Vertragsregister und die Bestellevidenz (sofern vorhanden), den Finanzplan und das Haushaltssystem, das Finanz-Buchhaltungssystem, das Online-Banking und manchmal auch ein gesondertes System für Projekte oder öffentliche Vergabeverfahren durchläuft. Hinzu kommen Tabellen, in denen Organisationseinheiten eigene Übersichten über Verträge und Mittelbindungen führen.

Jeder Übergang zwischen Systemen, den niemand verbunden hat, ist eine manuelle Tätigkeit: Abschreiben einer Nummer, Kopieren eines Betrags, Ausdrucken, Scannen, ein Anruf mit einer Nachfrage. Diese Tätigkeiten erfordern keine Entscheidung, nehmen aber mehreren Personen in mehreren Organisationseinheiten Zeit. Niemand sieht sie im Ganzen, da jeder nur seinen eigenen Abschnitt ausführt.

Wo tatsächlich Zeit verloren geht

Die fachliche Freigabe oder die Prüfung durch den Treasurer sind Entscheidungen und sollten bei Menschen verbleiben. Zeit geht an anderer Stelle verloren, bei Hilfstätigkeiten:

• Feststellen, ob die Rechnung nicht bereits über einen anderen Kanal eingegangen ist,
• Abschreiben von Papierrechnungen und aus E-Mails sowie anderer Kostendokumente, die nicht über KSeF eingegangen sind,
• Suche nach Vertrag oder Bestellung und der bestellenden Organisationseinheit,
• Nachtragen der Haushaltsklassifikation, die sich aus dem Vertrag auslesen ließe,
• Einholen von Freigaben aus mehreren Organisationseinheiten, Umhertragen von Mappen und Klären, bei wem sich die Rechnung gerade befindet,
• Doppeltes Anlegen desselben Geschäftspartners in zwei Systemen,
• Abschreiben der Rechnungsdaten in das Finanz-Buchhaltungssystem.

Gerade diese Tätigkeiten lohnt es sich zu automatisieren. Nicht weil sie schwierig wären, sondern weil sie sich bei jeder Rechnung wiederholen – und eine Behörde hat davon Tausende pro Jahr.

Wie man den Rechnungsworkflow mit Verstand angeht

Die Reihenfolge ist entscheidend. Erst der Prozess, dann das Werkzeug.

Ziel ist nicht die Einführung eines elektronischen Rechnungsworkflows. Ziel ist die Veränderung der Art und Weise, wie mit Kostendokumenten umgegangen wird, in einer Welt, in der wiederkehrende Hilfstätigkeiten Systeme übernehmen können. Das verändert die Arbeitsweise vieler Menschen, und eine Veränderung der Arbeitsweise beginnt damit, sich vorzustellen, wie es anders aussehen könnte. Darum geht es bei der digitalen Transformation, und daran sollte man sich bei jeder Investition in IT-Systeme orientieren. Der bloße Kauf eines Systems ist noch keine Veränderung.

Den Workflow vom Eingang bis zur Zahlung beschreiben. Unter Beteiligung des Treasurers, der Buchhaltung, des Sekretärs und mehrerer fachlich zuständiger Organisationseinheiten. Wer tut was, in welchem System, wie lange dauert es, wo bleibt die Rechnung liegen. Eine solche Beschreibung zeigt oft Schritte, die noch aus Zeiten der Papierbearbeitung in der Anweisung verblieben sind und von denen niemand mehr weiß, warum sie dort stehen. Wie eine solche Beschreibung vor der Systemauswahl erstellt wird, beschreibe ich auf der Seite zur Bedarfsanalyse.

Entscheiden, wo die Freigabe stattfindet. Das muss nicht EZD sein. Freigaben können in einem System der EZD-Klasse ablaufen, in einem eigenständigen Workflow-Tool oder in einem Modul des Finanz-Buchhaltungssystems. Wichtig ist, dass sie an einem einzigen Ort erfolgen, mit vollständiger Nachverfolgbarkeit, und dass das Ergebnis ohne Abschreiben weitergeht. Ein gut aufgebauter Workflow legt den Freigabepfad selbst anhand der Haushaltsposten, aus denen die Ausgabe finanziert wird, und ihrer Art fest, lässt Freigaben dort parallel laufen, wo die Reihenfolge keine Rolle spielt, und sieht Vertretungen für Urlaubszeiten vor. Den Unterschied zwischen einem Prozesssystem und einem Buchhaltungssystem beschreibe ich im Beitrag über BPM und Fachsysteme.

Den Workflow mit dem Finanz-Buchhaltungssystem verbinden. Dies ist die wichtigste Integration: Die Daten der freigegebenen Rechnung, mit Beschreibung, Klassifikation und Freigaben, sollen als fertiges Dokument in die Buchhaltung gelangen, nicht als Ausdruck. Das lässt sich auf drei Arten umsetzen. Am besten ist eine vom Systemanbieter bereitgestellte Programmierschnittstelle (API). Die zweite Möglichkeit ist der direkte Schreibzugriff auf die Datenbank des Buchhaltungssystems, der die Zustimmung und Mitwirkung des Anbieters erfordert, da ein Fehler bei einem solchen Zugriff später schwer zu entdecken ist. Die dritte Möglichkeit, wenn das System über keine Schnittstelle verfügt, ist ein Roboter (RPA): ein einfaches Programm, das im Namen des Benutzers die Rechnung über den Bildschirm einträgt, so wie es ein Mensch tun würde. Ein Roboter ist oft schnell und günstig im Einstieg, aber anfällig, da eine Änderung der Bildschirmoberfläche nach einem Update ihn stoppen kann. Er sollte als Übergangslösung betrachtet werden, bis der Anbieter eine Schnittstelle bereitstellt. Zahlungen und Überweisungspakete können dort bleiben, wo sie heute sind – im Finanz-Buchhaltungssystem.

Das Geschäftspartnerstammdatenregister abstimmen. Die Rechnung muss in der Buchhaltung dem richtigen Geschäftspartner zugeordnet werden, daher müssen Workflow und Finanz-Buchhaltungssystem von denselben Einheiten sprechen. In einem System der EZD-Klasse gibt es in der Regel deutlich mehr Geschäftspartner: Bürger, Antragsteller und Institutionen, die an die Behörde schreiben, ihr aber niemals eine Rechnung stellen werden. Im Finanz-Buchhaltungssystem stehen nur die Einheiten, mit denen die Behörde Abrechnungen hat. Deshalb braucht es von Anfang an klare Regeln für den Lebenszyklus der Geschäftspartnerdaten in den Systemen der Behörde: Wer legt wann und in welchem System einen Geschäftspartner an, wer aktualisiert wann dessen Daten, und wie überträgt sich eine Änderung in einem System auf die übrigen. Hinzu kommt eine Methode, denselben Lieferanten wiederzuerkennen, etwa anhand der Steuernummer (NIP), damit ein neuer Lieferant aus der Rechnung in die Buchhaltung gelangt, ohne ein zweites Mal manuell angelegt zu werden.

Die Rechnung mit dem Vertrags- und Beschaffungsregister verknüpfen. Eine solche Verknüpfung liefert Hinweise zur fachlich zuständigen Organisationseinheit, zur Haushaltsklassifikation und dazu, wie viel vom Vertrag noch zur Abrechnung übrig ist.

Die Umlaufanweisung aktualisieren. Eine elektronische Freigabe, die in der Anweisung nicht vorgesehen ist, führt am Ende doch dazu, dass die Rechnung „ordnungshalber“ ausgedruckt wird. Bei der Überarbeitung von Prozessen und Anweisung lohnt es sich, sich zunächst den Idealzustand vorzustellen: eine Arbeitsweise der Menschen, bei der niemand mehr unnötige Hilfstätigkeiten ausführt. Erst danach werden die Formulierungen der Anweisung angepasst, nicht umgekehrt.

Quellen

• Finanzministerium: Umfang des verpflichtenden KSeF
• Gesetz vom 29. September 1994 über die Rechnungslegung, ISAP (Art. 21, 22)
• Gesetz vom 27. August 2009 über öffentliche Finanzen, konsolidierter Text der Kanzlei des Sejm (Art. 54)
• Pflichtenkalender von Krogis: KSeF, e-Doręczenia, EZD

Rechtsstand: 30. Oktober 2026.