Fiskalizacija 2.0: How to Connect an Existing ERP or Web Shop to Croatian e-Invoicing

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:

urn:cen.eu:en16931:2017#compliant#urn:mfin.gov.hr:cius-2025:1.0#conformant#urn:mfin.gov.hr:ext-2025:1.0

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.

Source for classification: Porezna uprava, Klasifikacija roba i usluga u eRačunu.

What breaks after go-live

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.