Country deep dive
Croatia's Fiskalizacija 2.0 reform layers a full B2B mandate and an expanded B2C fiscalisation regime on top of a B2G system that's been running for years.
Public-sector invoicing has run on structured e-invoicing for years — Fiskalizacija 2.0 extends the same underlying EN 16931 alignment to the much larger domestic B2B and B2C economy.
Croatia's "Fiscalization 2.0" reform made structured e-invoicing (issuance and receipt) and real-time e-reporting mandatory for all VAT-registered, Croatian-established taxpayers, on top of the B2G e-invoicing mandate already in force since 2019.
The obligation to issue (not just receive) structured e-invoices and e-reporting data extends to non-VAT-registered entities — small companies, freelancers, and certain public/budgetary bodies.
Croatia builds on the standard European invoice model but adds a distinctly national layer of extra mandatory fields.
HR-FISK 2.0 goes beyond the EN 16931 base — Croatia's extensions aren't cosmetic, they add fields the European standard doesn't require.
These three additions — OIB, CPA code, and bank details — are exactly the fields that trip up ERPs configured for a generic EN 16931 build rather than Croatia specifically.
Don't assume the invoice XML needs its own signature the way Italy's FatturaPA does — Croatia's requirement sits at the transport (SOAP) layer instead.
This is a narrow escape hatch, not a general opt-out — it exists specifically for the case where the system genuinely can't find a routable address for the recipient.
This is the part that catches people out: Croatia isn't one flow, it's three running in parallel — exchange, fiscalisation, and monthly e-reporting.
The Supplier's Access Point queries the AMS, which returns the Buyer's Metadata Service (MPS) URL; the AP then queries that MPS to discover the Buyer AP's technical endpoint. No static bilateral connections needed.
Both sides of a transaction independently confirm it to the Tax Administration — this is what makes fiscalisation a genuine two-sided control rather than a one-way filing.
This third layer catches what the real-time flows miss — specifically, what happened to an invoice after issuance (rejected? paid?) rather than just confirming it existed.
Large companies have the option to integrate their ERP directly with the Tax Administration rather than going through a third-party Access Point — worth evaluating if your invoice volumes justify the build.
Unlike a single clearance flow, Croatia requires all three to run independently:
This "dual reporting" structure creates a closed audit loop — the tax authority receives independent confirmations from both the seller and the buyer side, not just one feed.
Because Croatia runs three parallel obligations, "getting compliant" means configuring all three — not just picking an Access Point.
Work out which identifiers your business uses to route invoices — your OIB at minimum, plus any secondary identifiers like GLN — since each can map to a different receiving Access Point in the AMS.
Confirm your chosen provider appears on the Croatian Tax Administration's official list of certified brokers, with passed conformance and security assessments — or evaluate direct ERP integration if you're a large-volume filer.
Do this per identifier — don't assume registering your OIB automatically covers any secondary identifiers you also use.
Confirm UBL 2.1 generation includes the Croatia-specific fields — OIB, 6-digit CPA product codes, and bank account details — not just the base EN 16931 set.
Set up real-time reporting to the Tax Administration for invoices you issue, and a separate real-time confirmation process for invoices you receive — these are genuinely two different technical flows, not one.
Build a process to report rejected/undelivered invoices (as recipient) and payments received (as issuer) ahead of the 20th-of-the-month deadline, every month, without fail.
Croatia gives itself no "penalty holiday" — the fine schedule applies from each element's go-live date, with company-size-scaled ranges.