Fiskalizacija 2.0: So binden Sie ein bestehendes ERP oder einen Web-Shop an die kroatische eRačun-Pflicht an
Fiskalizacija 2.0 besteht aus zwei Integrationen, nicht aus einer: AS4-Austausch plus eine separate Fiskalisierungs-Schnittstelle. So binden Sie ein ERP oder einen Web-Shop an, den Sie bereits betreiben.
Zwei-Kanal-Architektur für kroatische eRačun-Rechnungen: AS4-Austausch und Fiskalisierung
Wenn Sie ein ERP, einen Web-Shop oder ein individuell entwickeltes System betreiben und damit kroatische eRačun-Rechnungen erzeugen müssen, sollten Sie zuerst eines verstehen: Sie bauen zwei Integrationen, nicht eine.
Die erste ist der Austausch. Ihre Rechnung verlässt das Haus als UBL 2.1 XML über eine AS4-Verbindung zum Access Point des Käufers. Die zweite ist die Fiskalisierung und Meldung an die Porezna uprava, die kroatische Steuerverwaltung, und die läuft über eine andere Schnittstelle mit eigenen Schemata und eigener Nachrichtensignatur. Die Porezna uprava stellt ausdrücklich klar, dass der Aussteller eine ausgestellte eRačun-Rechnung getrennt vom Austauschverfahren fiskalisiert, und zwar im Moment der Ausstellung, bei Selbstfakturierung spätestens fünf Arbeitstage nach Ausstellung.
Zwei Kanäle, zwei Arten von Fehlerbildern. Eine Rechnung kann beim Käufer ankommen und trotzdem nicht fiskalisiert sein, oder umgekehrt. Das meiste, was zu Fiskalizacija 2.0 veröffentlicht wird, richtet sich an Unternehmer, die wissen wollen, was sie schulden. Dieser Text richtet sich an diejenigen, die es technisch umsetzen müssen.
Wie die Fristen tatsächlich stehen
Das Fiskalisierungsgesetz (NN 89/2025) ist am 1. September 2025 in Kraft getreten und gilt ab dem 1. Januar 2026.
Seit dem 1. Januar 2026 stellen umsatzsteuerlich registrierte Steuerpflichtige eRačun-Rechnungen im inländischen B2B aus und fiskalisieren sie. Alle anderen müssen eRačun-Rechnungen empfangen und den Empfang fiskalisieren können. Ab dem 1. Januar 2027 müssen auch Steuerpflichtige außerhalb des Umsatzsteuersystems ausstellen und fiskalisieren.
Wenn Sie umsatzsteuerlich registriert sind, und das sind die meisten Unternehmen, die ein ERP oder einen Shop mit nennenswertem Volumen betreiben, gelten beide Pflichten bereits seit Januar 2026. Die noch offene Frist betrifft Aussteller außerhalb des Umsatzsteuersystems. So oder so ist das Ausstellen die Seite, die Ihre Software berührt.
Diesen Punkt unterschätzen Entwickler regelmäßig. Der Pravilnik o eRačunu (NN 11/2026), erlassen auf Grundlage von Artikel 64 des Gesetzes und seit dem 31. Januar 2026 in Kraft, definiert als technische Spezifikation die Dokumentation, die auf dem Fiskalizacija-2.0-Portal der Porezna uprava veröffentlicht ist, und erklärt sie für verbindlich.
CEO von Neviox Digital mit einem Ingenieurabschluss in Informatik von der Universität Split sowie mehreren Zertifizierungen. Meine Kernkompetenzen umfassen Frontend- und Backend-Technologien, mit besonderem Fokus auf LangChain, Next.js und AWS.
Neviox Digital
Haben Sie eine Vision für eine digitale Lösung? Möchten Sie Ihr technisches Know-how teilen oder Ihre Marke bewerben? Lassen Sie uns zusammenarbeiten und gemeinsam die Zukunft gestalten!
Was wir gebaut haben, was schiefging und was wir heute anders machen würden. Keine Linksammlungen.
Eine Überarbeitung dieser Dokumentation ist damit eine Änderung Ihrer gesetzlichen Pflicht und kein Punkt, den jemand im Backlog liegen lassen kann. Behandeln Sie die Version der Spezifikation wie eine gepinnte Abhängigkeit. Halten Sie fest, gegen welche Version Sie entwickelt haben, und prüfen Sie sie erneut, sobald eine neue erscheint.
Zum Zeitpunkt der Erstellung dieses Textes ist die veröffentlichte technische Spezifikation Version 1.8 vom 12. März 2026, mit UBL 2.1 als Syntax. Prüfen Sie vor dem Start die Seite mit den Spezifikationen auf die aktuelle Version.
Die nationalen Regeln setzen auf dem europäischen Standard EN 16931 auf, statt ihn zu ersetzen: eine nationale Core Invoice Usage Specification plus kroatische Erweiterungen. Eine konforme Rechnung trägt eine CustomizationID in dieser Form, als eine durchgehende Zeichenkette:
Übernehmen Sie sie nicht fest verdrahtet aus einem Blogbeitrag. Gleichen Sie sie gegen die Version der Spezifikation ab, gegen die Sie entwickeln.
Auf der Austauschseite gilt das Access-Point-Profil eRačun-AS4, das dem CEF eDelivery AS4 Profile v1.15 folgt und Attribute einschränkt, die das CEF-Profil offen lässt. Daneben stehen der Verzeichnisdienst, der auflöst, wer für einen bestimmten Steuerpflichtigen empfängt, und der Metadatendienst.
Vier Wege, die Ausstellungspflicht zu erfüllen
MIKROeRAČUN über ePorezna
Passt, wenn: Sehr geringes Volumen, Rechnungen werden ohnehin manuell geschrieben. Prüfen Sie zuerst Voraussetzungen und Grenzwerte. Was es Sie kostet: Kein Entwicklungsaufwand. Wo es wehtut: Manuelles Abtippen. Ihr eigenes System erfährt nie, dass die Rechnung rausgegangen ist.
Rechnungs-SaaS als führendes System
Passt, wenn: Ihr aktuelles System ist gar nicht der Ort, an dem Rechnungen entstehen. Was es Sie kostet: Ein Abonnement und eine Migration. Wo es wehtut: Zwei Produktkataloge, die synchron bleiben müssen, und das SaaS besitzt Ihre Rechnungsdaten.
Ihr System an einen Informationsvermittler anbinden
Passt, wenn: Rechnungen entstehen in Software, auf die Sie ohnehin angewiesen sind. Was es Sie kostet: Ein Integrationsprojekt plus die Gebühren des Vermittlers. Wo es wehtut: Feldzuordnung und Fehlerbehandlung liegen bei Ihnen.
Einen eigenen Access Point betreiben
Passt, wenn: Sie sind eine Plattform und stellen im Namen vieler Unternehmen aus. Was es Sie kostet: Implementierung des AS4-Profils und Nachverfolgung jeder Revision. Wo es wehtut: Die Einhaltung der Spezifikation wird Teil Ihres Produkts.
Für die meisten Unternehmen mit einem funktionierenden ERP oder Shop ist die dritte Zeile die ehrliche Antwort. Ein funktionierendes System zu ersetzen, nur um ein XML-Format zu bedienen, ist ein teurer Weg, ein Mapping-Problem zu lösen. Beachten Sie: Das Gesetz verlangt nicht, dass die Leistung eines Vermittlers kostenpflichtig ist, sondern nur, dass die Beziehung vertraglich geregelt wird. Vergleichen Sie also die Konditionen, statt von einem einheitlichen Marktpreis auszugehen.
Was Ihrem Datenmodell fehlt
Genau das macht aus einer Integration von zwei Wochen eine von zwei Monaten. Das Format ist dokumentiert. Ihre Daten sind nicht dafür aufgebaut.
Die Lücken sind fast immer dieselben:
Identifikation des Käufers. Eine strukturierte Rechnung braucht den Käufer als aufgelöste Kennung, nicht als Firmennamen, den ein Vertriebsmitarbeiter in ein Freitextfeld getippt hat. Wenn Ihre Kundentabelle einen einzigen Adress-Block und keine OIB-Spalte hat, ist das Schemaarbeit, bevor es XML-Arbeit ist.
Klassifizierung der Positionen. Jede Position braucht ihren KPD-2025-Code: mindestens sechs Stellen, mit Punkten geschrieben, zum Beispiel 47.82.20. Die Klassifikation ist an die CPA 2.2 der EU angeglichen, und die Codes werden über die Anwendung KLASUS beim Staatlichen Amt für Statistik nachgeschlagen. Die Codes gelten für eRačun-Rechnungen, nicht für B2C-Fiskalbelege. Einen bestehenden Katalog zu mappen ist ein Datenprojekt, und es lässt sich nicht parallelisieren, weil jede Entscheidung jemand treffen muss, der die Produkte kennt.
Rundung und Summen. Ihr System rundet vermutlich an einer Stelle, an der der Standard es nicht erwartet. Positionsbeträge, die sich nicht mit den Rechnungssummen abstimmen lassen, scheitern am Access Point an EN-16931-Geschäftsregeln wie BR-CO-10 und BR-CO-13, lange bevor der Käufer das Dokument überhaupt sieht.
Gutschriften und Korrekturen. Teams bauen den Rechnungspfad, gehen live und stellen dann fest, dass der Korrekturpfad einen eigenen Dokumenttyp und einen Verweis auf das Original braucht.
Dokumente, die keine Rechnungen sind. Für Anzahlungen und nachträgliche Genehmigungen gelten eigene Regeln. Entscheiden Sie früh, welche Ihrer Dokumente in den Anwendungsbereich fallen.
Eine eRačun-Rechnung ist eine Nachricht an ein System, das sie ablehnen kann. Genau dort liegt der operative Aufwand.
Planen Sie Ablehnungen vom ersten Commit an ein. Eine Rechnung, die an der Validierung scheitert, hat Ihr System verlassen, existiert für den Käufer aber nicht, während Ihre Buchhaltung sie munter als ausgestellt führt. Der Rechnungsdatensatz braucht einen Status, der abbildet, was das Netz gemeldet hat, und nicht, was Ihre Oberfläche angenommen hat.
Legen Sie Ihren Idempotenzschlüssel von Anfang an fest und dokumentieren Sie die Entscheidung. Die UBL-Rechnungs-ID und die Kennung der Fiskalisierungsnachricht sind nicht derselbe Schlüssel und haben nicht dieselbe Bedeutung. Ein erneutes Senden muss denselben Schlüssel wiederverwenden, statt einen neuen zu erzeugen, sonst wird aus Ihrem Retry eine doppelte Rechnung.
Bewahren Sie das XML auf, nicht eine PDF-Darstellung davon, und zwar für die gesetzliche Aufbewahrungsfrist, zusammen mit der Signatur und der Bestätigung. Das XML ist die Rechnung. Ein PDF beweist nichts darüber, was das Netz empfangen hat.
Und sorgen Sie dafür, dass es jemand merkt. Eine Queue, die stillschweigend stehen bleibt, ist der Fehler, der echtes Geld kostet, weil es niemand bemerkt, bis ein Kunde nach seiner Rechnung fragt. Ein täglicher Abgleich zwischen den in Ihrem System ausgestellten und den vom Netz bestätigten Rechnungen macht aus einem Problem, das ein Quartal lang läuft, eines von einem Tag.
Wie wir das umsetzen
Wir behandeln das als Integration, nicht als Ablösung. Die Rechnung bleibt dort, wo sie entsteht. Zwischen Ihrem System und dem Vermittler liegt eine Workflow-Schicht: Sie ordnet Ihre Felder der Spezifikation zu, validiert vor dem Versand, schreibt die Bestätigung zurück auf den Rechnungsdatensatz, wiederholt Sendungen mit dem vereinbarten Schlüssel und meldet einen Vorgang zur manuellen Prüfung, wenn ein Dokument sich nicht mappen lässt. Diese Schicht betreiben wir self-hosted in der EU oder auf Ihren eigenen Servern, sodass der Vermittler die Rechnung erhält und sonst niemand eine Kopie Ihrer Buchhaltungsdaten hält.
Es ist dasselbe Muster, das wir auch bei anderer einsetzen, und die eRačun-Anbindung ist ein guter erster Anwendungsfall, weil das korrekte Ergebnis von jemand anderem definiert ist und sich deshalb gut testen lässt.
Schicken Sie uns eine kurze Beschreibung des Systems, aus dem Sie heute Ihre Rechnungen stellen, und wir sagen Ihnen, welchen der vier Wege wir wählen würden und warum.
