Two-channel architecture for Croatian e-invoicing: AS4 exchange and fiscalisation
If you run an ERP, a web shop or a custom system and it has to produce Croatian e-invoices, the first thing to get right is that you are building two integrations, not one.
The first is exchange. Your invoice leaves as UBL 2.1 XML over an AS4 connection to the buyer's access point. The second is fiscalisation and reporting to the Tax Administration, which runs over a different interface with its own schemas and its own message signing. The Tax Administration is explicit that the issuer fiscalises an issued e-invoice separately from the exchange procedure, at the moment of issue, and for self-billing no later than five working days after issue.
Two channels, two sets of failure modes. An invoice can reach the buyer and fail to be fiscalised, or the reverse. Most of what is published about Fiskalizacija 2.0 is written for the owner asking what they owe. This is written for whoever has to wire it up.
Where the dates actually stand
The Fiscalisation Act (NN 89/2025) took effect on 1 September 2025 and applies from 1 January 2026.
Since 1 January 2026, taxpayers registered for VAT issue and fiscalise e-invoices for domestic B2B. Everyone else must be able to receive e-invoices and fiscalise the receipt. From 1 January 2027, taxpayers outside the VAT system have to issue and fiscalise as well.
If you are VAT registered, which most companies running an ERP or a shop at any volume are, both obligations have been live since January 2026. The date still ahead applies to issuers outside the VAT system. Either way, issuing is the side that touches your software.
This is the part engineers underestimate. The , adopted under Article 64 of the Act and in force since 31 January 2026, defines the technical specification as the documentation published on the Tax Administration's Fiskalizacija 2.0 portal, and makes it binding.
Related Services
Send Us Your Site, Repo or Idea. Our Engineers Reply in Writing.
We reply as soon as we can, and tell you what we would change first.
What we shipped, what broke and what we would do differently. No news roundups.
A revision to that documentation is therefore a change to your legal obligation, not an item someone can leave in the backlog. Treat the specification version as a pinned dependency. Record which version you built against, and review it when a new one is published.
At the time of writing the published technical specification is version 1.8, dated 12 March 2026, with UBL 2.1 as the syntax. Check the specification page for the current version before you start.
The national rules sit on top of the European standard EN 16931 rather than replacing it: a national core invoice usage specification plus Croatian extensions. A conformant invoice carries a CustomizationID of this shape, as one unbroken string:
Do not hard-code it from a blog post. Diff it against the specification version you are building against.
On the exchange side, the access point profile is eRačun-AS4, which follows the CEF eDelivery AS4 Profile v1.15 and narrows attributes the CEF profile leaves open. Alongside it sit the directory service that resolves who receives for a given taxpayer, and the metadata service.
Four ways to meet the issuing obligation
MIKROeRAČUN via ePorezna
Fits when: Very low volume, invoices written by hand anyway. Check eligibility and limits first. What it costs you: Nothing to build. Where it hurts: Manual re-keying. Your own system never learns the invoice went out.
Invoicing SaaS as the system of record
Fits when: Your current system is not really where invoices originate. What it costs you: A subscription and a migration. Where it hurts: Two product catalogues to keep in step, and the SaaS owns your invoice data.
Connect your system to an information intermediary
Fits when: Invoices are generated by software you already depend on. What it costs you: An integration project, plus whatever the intermediary charges. Where it hurts: You carry the field mapping and the error handling.
Operate your own access point
Fits when: You are a platform issuing on behalf of many businesses. What it costs you: Implementing the AS4 profile and tracking every revision. Where it hurts: Specification compliance becomes part of your product.
For most companies with a working ERP or shop, the third row is the honest answer. Replacing a system that works in order to satisfy an XML format is an expensive way to solve a mapping problem. Note that the Act does not require an intermediary's service to be paid, only that the relationship be governed by a contract, so compare terms rather than assuming a single market price.
What your data model is missing
This is what turns a two-week integration into a two-month one. The format is documented. Your data is not shaped for it.
The gaps are the same almost every time:
Buyer identification. A structured invoice needs the buyer resolved to an identifier, not a company name typed into a free-text field by a salesperson. If your customer table has one address blob and no OIB column, that is schema work before it is XML work.
Line-item classification. Each line needs its KPD 2025 code: at least six digits, written with dots, for example 47.82.20. The classification is aligned with the EU's CPA 2.2, and codes are looked up through the KLASUS application at the Bureau of Statistics. Codes apply to e-invoices, not to B2C fiscal receipts. Mapping an existing catalogue is a data project, and it does not parallelise, because somebody who knows the products has to make each call.
Rounding and totals. Your system probably rounds somewhere the standard does not expect. Line amounts that do not reconcile to the invoice totals fail EN 16931 business rules such as BR-CO-10 and BR-CO-13 at the access point, before the buyer ever sees the document.
Credit notes and corrections. Teams build the invoice path, go live, then discover the correction path needs its own document type and a reference back to the original.
Documents that are not invoices. Advance payments and subsequent approvals follow their own rules. Decide early which of your documents are in scope.
An e-invoice is a message to a system that can refuse it. That is where the operational work lives.
Build for rejection from the first commit. An invoice that fails validation has left your system but does not exist for the buyer, while your accounting cheerfully shows it as issued. The invoice record needs a status that reflects what the network said, not what your UI assumed.
Decide your idempotency key up front, and write the decision down. The UBL invoice ID and the fiscalisation message identifier are not the same key and do not have the same semantics. A resend must reuse the key rather than mint a new one, or your retry becomes a duplicate invoice.
Keep the XML, not a PDF rendering of it, for the statutory retention period, together with the signature and the acknowledgement. The XML is the invoice. A PDF proves nothing about what the network received.
And make sure someone notices. A queue that silently stops is the failure that costs real money, because nobody finds out until a customer asks where their invoice is. A daily reconciliation between invoices issued in your system and invoices acknowledged by the network turns a quarter-long problem into a one-day one.
How we build it
We treat this as an integration, not a replacement. The invoice stays where it is created. A workflow layer sits between your system and the intermediary: it maps your fields to the specification, validates before sending, writes the acknowledgement back onto the invoice record, retries on the agreed key, and raises an exception for a person when a document cannot be mapped. We run that layer self-hosted in the EU or on your own servers, so the intermediary receives the invoice and nothing else holds a copy of your ledger.
It is the same pattern we use for other work, and e-invoicing is a good first case, because the correct output is defined by someone else and is therefore easy to test against.
Send us a short description of the system you issue invoices from today, and we will tell you which of the four routes we would take and why.
