Fiskalizacija 2.0 and eRačun

Croatia’s move to structured electronic invoicing. It decides whether a home-grown invoicing tool is a legitimate issuing channel or a toy, so it is worth knowing the dates before writing any invoicing code.

Checked 2026-10-01 while scoping invoicing|the sikod invoicing app.

The dates

2026-01-01

VAT-registered taxpayers must issue and receive eRačun for domestic B2B.
Non-VAT taxpayers (paušalni obrt and similar) must be able to receive eRačun. They may still issue ordinary invoices.
B2C transakcijski računi — invoices to private persons paid by transfer — become subject to fiscalization.

2027-01-01

Non-VAT taxpayers must issue eRačun too. Everyone is in, regardless of VAT status, for all domestic transactions.

What this means for a small non-PDV obrt during 2026

Invoicing domestic companies by bank transfer: ordinary PDF invoices are legal and are not fiscalized, through 2026-12-31.
Invoicing private persons: in scope for fiscalization from 2026-01-01, so it needs a certificate and a provider. Out of reach for a weekend build.
Invoicing foreign clients: no eRačun and no fiscalization obligation. Ordinary invoices, indefinitely.

So a home-grown invoicing app for a non-PDV obrt billing Croatian companies is legitimate, with a hard expiry of 2026-12-31.

Format and channel

eRačun means a structured document to EN 16931 (UBL 2.1 or CII), exchanged through an informacijski posrednik (access point) rather than emailed as a PDF. The PDF becomes a human-readable courtesy, not the legal document.

Free state options exist: FiskAplikacija for viewing fiscalized data and managing authorisations, and MIKROeRAČUN for small non-VAT taxpayers via ePorezna — receiving and fiscalizing in 2026, issuing from 2027.

The design consequence

If you are building an invoicing tool that will outlive 2026, make the schema carry every field EN 16931 marks mandatory from the start: party OIB, country code, line unit codes, delivery date distinct from issue date, payment means. Then the 2027 obligation is a serializer over existing columns rather than a migration plus a backfill of data you never captured.

Invoice numbering, which is easy to get wrong

The number is three-part: broj računa / oznaka poslovnog prostora / oznaka naplatnog uređaja, e.g. 1/P1/1. It must be sequential and gapless per issuer.

Two consequences for software: a test invoice must be deleted so the counter returns, and if one app ever issues for two different legal entities, each needs its own independent sequence.

VAT note for a non-PDV issuer

An invoice that charges no VAT must state the legal basis. The common wording cites čl. 90 Zakona o PDV-u, but sources disagree on whether it should read st. 1. Treat it as configuration and have the knjigovođa confirm it — it is a legal statement, not a string literal.