Why Croatia’s foreign-currency eInvoice fiscalization rule can create reconciliation differences across invoicing, fiscalization, payment reporting and accounting
Croatia’s Fiscalization 2.0 framework creates a subtle but important distinction between the commercial eInvoice and the fiscalization representation sent to the Tax Administration. When the underlying transaction is denominated in a foreign currency, that distinction can produce multiple legitimate or implementation-driven euro values for the same business document, with consequences for ERP design, matching logic, audit trails and payment reconciliation.
Croatia’s new eInvoice fiscalization regime looks straightforward when a transaction is issued and settled in euros. The complexity appears when the commercial invoice is denominated in another currency, because the eInvoice exchanged between seller and buyer can remain a foreign-currency business document while the fiscalization message sent to the Croatian Tax Administration is constructed as a euro-denominated regulatory representation. The Croatian technical specification explicitly states that the fiscalization field for invoice currency uses EUR, even though that field maps conceptually to the invoice currency in the EN 16931/UBL structure. This creates a transformation step that software teams cannot safely treat as a simple copy of the original eInvoice.
The issue became concrete in a Croatian Tax Administration opinion dated 21 April 2026, class 410-01/26-01/433, which was prompted by two practical questions concerning eInvoices issued in foreign currency. The first concerned whether the data sent in the fiscalization XML must be expressed in euros, and the second concerned whether the amount reported when the invoice is paid must likewise be reported in euros regardless of the currency of the bank settlement. The public technical documentation and the Fiscalization Act provide enough detail to see why this is more than a currency-conversion detail. It is a data-model and reconciliation problem that can propagate through several systems.
The first distinction: the commercial invoice and the fiscalization message are not the same object
An eInvoice is the commercial and tax document exchanged between seller and buyer, while fiscalization is a separate reporting process in which prescribed data from that eInvoice is sent to the Tax Administration. Croatia’s Fiscalization Act defines fiscalization of eInvoices as the delivery of prescribed eInvoice data to the fiscalization system, and it requires the issuer and the recipient to fiscalize each issued and received eInvoice separately. The same law also requires the eInvoice itself to comply with the EU eInvoicing norm. That structure matters because the original eInvoice may be denominated in USD, CHF or another currency, while the fiscalization message is a separate derived dataset.
The technical specification makes the distinction visible. In the fiscalization message, the field valutaERacuna is described as the ISO 4217 currency code for the invoice amounts, but the specification adds that EUR is to be used. In practical terms, this means that a USD 10,000 invoice can remain a USD 10,000 eInvoice in the exchange layer while the data reported through fiscalization must be transformed into euro values. That transformation is where several kinds of divergence can begin.
A simple example
| Commercial eInvoice | USD 10,000 |
| Fiscalization representation | EUR 9,180, assuming the legally applicable conversion produces that result |
| Later bank settlement | USD 10,000 paid at a later date |
| Accounting result | A euro settlement value that may differ from the fiscalization value because of exchange-rate movement |
There is nothing inherently wrong with these values being different because they answer different questions. The commercial invoice states the amount the parties agreed to pay. The fiscalization message expresses the regulatory value sent to the tax authority. The settlement records what was actually paid. Accounting may separately recognise the euro equivalent and any foreign-exchange gain or loss. The implementation problem begins when software assumes that these are four views of one number rather than four values with different semantics.
The second distinction: both seller and buyer fiscalize the same eInvoice
Croatia’s model adds another layer of complexity because fiscalization is not performed only by the issuer. Article 47 of the Fiscalization Act requires both the issuer and the recipient to fiscalize every issued and received eInvoice, while Article 48 sets different timing obligations for the outgoing and incoming sides. The issuer fiscalizes at issuance, while the recipient generally has up to five working days after receipt. The Tax Administration therefore receives two fiscalization representations that refer to the same commercial invoice.
In a perfectly aligned implementation, the monetary values submitted by both parties should reconcile. In practice, however, two independent ERP stacks, two different eInvoice providers, or two different fiscalization middleware implementations may calculate the euro representation independently. A USD 10,000 invoice can therefore become EUR 9,180 in the seller’s fiscalization message and EUR 9,178.50 in the buyer’s message if the systems select different dates, exchange-rate sources, decimal precision or rounding sequences. A discrepancy of this kind does not necessarily mean that the original invoice is wrong, but it creates a matching problem inside the fiscalization ecosystem.
Example. A seller issues invoice HR-2026-418 for USD 10,000. Its ERP converts the relevant amounts into EUR using the rate and calculation method configured for fiscalization and reports EUR 9,180. The buyer receives exactly the same UBL eInvoice, but its ERP performs its own conversion and reports EUR 9,178.50. The document number, supplier, customer, issue date and original USD amount are identical, yet the fiscalization records no longer match numerically. A matching engine that assumes absolute equality can mark the transaction as inconsistent even when the divergence is caused by implementation choices rather than by a false invoice.
The exchange-rate source and the exchange-rate date are separate implementation decisions
Croatian VAT law provides the broader tax framework for foreign-currency conversion. Article 36 of the VAT Act states that, outside import situations, foreign-currency elements used to determine the VAT base are converted using the Croatian National Bank middle rate on the date the VAT liability arises. The same provision allows a taxpayer, as an exception, to use the European Central Bank rate published on that date. This means that software design must distinguish the source of the exchange rate from the date to which the rate belongs.
The date is particularly important because it is easy for an ERP implementation to use the invoice issue date automatically even where the legally relevant VAT date is different. A delivery may take place on 28 April, the invoice may be issued on 2 May, fiscalization may occur on 2 May, and payment may follow on 15 June. If one component converts using 28 April and another uses 2 May, the difference can be material. If a later payment report uses a third date, the same foreign-currency transaction can generate yet another euro value. The safest architecture therefore stores the exchange-rate date and legal reason for choosing it as explicit data rather than hiding them inside a generic currency-conversion service.
The Tax Administration opinion that triggered the recent clarification specifically asked whether fiscalization data for a foreign-currency eInvoice should be expressed in euros using the HNB middle rate. The publicly indexed excerpt of that opinion exposes the questions but not the full official answer, while the current technical specification independently confirms the use of EUR in the fiscalization message. For production implementation, the exact exchange-rate instruction in the complete opinion should therefore be checked against the current version of the technical documentation and the taxpayer’s VAT treatment, especially where the ECB option under the VAT Act could otherwise be relevant.
Rounding can produce differences even when both systems use the same rate
Exchange-rate disagreements are only one source of variance. Rounding can create different fiscalization values even when the parties use the same currency rate and the same legal date. The Croatian technical specification represents many monetary values with two decimal places, including invoice totals and VAT amounts. A system that converts each line from USD to EUR and rounds every converted line before summing can reach a different result from a system that first sums the USD lines and converts the total only once.
Example. Assume an invoice has one hundred low-value lines, several discounts and two VAT rates. The seller converts and rounds every line separately before calculating the euro subtotal, while the buyer calculates the foreign-currency subtotal first and performs a single conversion. Both systems use the same exchange rate, but the accumulated rounding can create a difference of several cents. If VAT is also rounded per rate or per line, the difference can extend to the tax base and VAT amount, which are among the data fields fiscalized under Article 48.
This is a classic example of a problem that is small in accounting terms and large in automated control terms. A human accountant understands a one-cent rounding difference immediately. A deterministic reconciliation rule sees two unequal values unless tolerance logic and a defined rounding model are built into the system. Croatia’s model therefore forces developers to treat rounding policy as a compliance configuration rather than a presentation preference.
Payment reporting can introduce a third euro value
The foreign-currency issue does not end when the invoice is successfully fiscalized. Under Article 53 of the Fiscalization Act, the issuer must report payment information for eInvoices that were paid in the previous month. The eReporting technical specification contains a mandatory naplacenIznos field for the paid amount together with the payment date and method, but the field itself does not carry a separate currency element in the payment record. This makes the conversion rule for a foreign-currency settlement operationally important.
Example. A USD 10,000 invoice is fiscalized on the relevant tax date at EUR 9,180. Two months later, the customer pays the agreed USD 10,000, but the market value at settlement is EUR 9,350. The commercial obligation has been settled exactly, yet the accounting euro value of the payment is EUR 170 higher than the euro value that represented the invoice at fiscalization. A reporting implementation must know whether the eReporting amount is expected to reproduce the invoice’s original fiscal euro value, reflect the euro equivalent of the payment, or follow another prescribed conversion rule. The distinction determines whether the system reports a clean reconciliation or apparently creates a EUR 170 overpayment.
This is also where payment status, foreign-exchange accounting and fiscalization can diverge. The invoice can be fully paid in its contractual currency even though the euro amount recognised by the bank or general ledger is different from the fiscalized euro amount. A system that uses euro equality to determine whether an invoice is paid can therefore reach the wrong conclusion. Payment matching should remain anchored to the contractual currency and amount, while the fiscal and accounting euro representations should be stored separately and linked by explicit conversion metadata.
Partial payments, prepayments and credit notes multiply the reconciliation paths
The complexity increases when an invoice is paid in instalments. A USD 10,000 invoice may be settled through three USD payments made on different dates, each with a different euro value. The sum of the accounting euro equivalents of those three payments will almost certainly differ from the euro value used when the invoice was fiscalized. If the eReporting layer uses a prescribed euro conversion for each payment event, software needs a reconciliation model that can explain why the original fiscalization total and the accumulated payment-reporting total are not necessarily identical.
Credit notes create a related problem because a correction document may be issued when the exchange rate is different from the rate used for the original invoice. The Croatian fiscalization dataset explicitly carries references to previous invoices when an invoice or other document changes an earlier invoice. That relationship should be used to preserve the original currency logic and trace the correction back to the original transaction, rather than allowing the credit note to become an isolated euro record. Otherwise, a credit that economically reverses USD 1,000 can appear to reverse a slightly different euro amount from the original invoice and create residual balances that are purely exchange-rate effects.
One business transaction can legitimately carry several monetary truths
The deeper lesson is that a foreign-currency eInvoice under Fiscalization 2.0 can have several monetary representations at the same time. The original eInvoice records the contractual amount in the agreed currency. The fiscalization message records the euro-denominated regulatory representation. The payment system records what was actually settled. The accounting system records the euro value relevant to the ledger and any foreign-exchange gain or loss. The Tax Administration may additionally hold both issuer-side and recipient-side fiscalization records for the same document.
A realistic data chain can therefore look like this. The eInvoice is USD 10,000. The seller fiscalizes EUR 9,180. The buyer fiscalizes EUR 9,178.50 because of a different implementation detail that must be investigated. The customer later pays USD 10,000 when the bank settlement is worth EUR 9,350. The seller’s accounting system recognises the original receivable and a foreign-exchange difference. None of these values can safely overwrite another because they represent different stages and different legal or economic meanings.
The biggest software risk is a false mismatch
Croatia’s architecture is designed to increase transparency and enable the Tax Administration to match data across participants. Foreign-currency conversion makes that matching more nuanced. The most dangerous implementation mistake is to define reconciliation as simple equality between euro values without taking into account source currency, exchange-rate date, rate source, rounding method, document role and payment event. That approach can produce false mismatch alerts, unnecessary manual investigations and, in the opposite direction, can hide a genuine compliance problem if a tolerance rule is made too generous.
A stronger matching model first identifies the commercial document by stable identifiers and parties, then verifies the original currency and original amounts, and only after that compares the derived euro values using the conversion context that produced them. A discrepancy of EUR 1.50 may be acceptable if it is fully explained by a permitted rate or rounding path, while a difference of EUR 0.01 can be a real defect if the source system used the wrong tax date or omitted an invoice line. The amount of the difference is therefore less important than the provenance of the difference.
ERP and fiscal middleware should preserve conversion provenance
The practical response is to stop treating currency conversion as a hidden calculation. A robust implementation should retain the original invoice currency and amounts, the fiscalization currency and derived euro amounts, the exchange rate used, the source of that rate, the legally relevant date, the calculation precision before rounding, the rounding method, the payment currency and amount, the payment-reporting euro amount, and the accounting euro settlement value. These fields do not all need to be transmitted in every Croatian message, but they should exist in the internal audit trail so that any difference can later be reconstructed.
The same principle applies to middleware providers. A country adapter should not expose one generic field called invoiceAmountEUR and silently reuse it everywhere. It should model distinct values such as the original document amount, the fiscalized amount, the reported paid amount and the ledger settlement amount. This becomes especially important in a multi-country environment because other jurisdictions may permit the foreign currency in the tax message, require only VAT to be stated in local currency, or use a different official exchange-rate source. A generic global interface must therefore preserve the semantic role of each amount before applying the local country transformation.
Testing needs to cover differences, not only successful conversion
Testing should reproduce the cases that create differences rather than validating only a single USD-to-EUR invoice. The important scenarios include a delivery date that differs from the invoice date, a rate change between those dates, many invoice lines that expose rounding effects, partial payments on different days, a credit note issued after the exchange rate has moved, a recipient fiscalization produced by a different software stack, and correction of a previously reported payment. The objective is not merely to prove that a converter returns a number, but to prove that the same business event can be explained consistently across the commercial invoice, fiscalization, eReporting and accounting layers.
Croatia’s technical documentation has also continued to evolve, including updates to validators and fiscalization specifications during 2026. This is another reason to keep the conversion policy versioned. A fiscalization record should be reproducible using the rules that were valid when it was created, even if the technical specification, validator or interpretation changes later. Versioned conversion logic is therefore part of auditability, not simply software maintenance.
A small currency rule exposes a larger Fiscalization 2.0 design lesson
The foreign-currency rule is a good illustration of what changes when tax administrations move from document-based compliance to structured digital reporting. In a paper environment, an accountant can see that one document is in USD and can understand why the euro accounting value changes over time. In a machine-to-machine environment, every meaning has to be represented explicitly enough for software to distinguish an invoice value, a tax value, a settlement value and a derived reporting value. If that semantics is compressed into one generic monetary field, automated fiscalization can create more ambiguity rather than less.
For Croatian taxpayers, ERP vendors, eInvoice providers and fiscalization middleware developers, the practical challenge is therefore not simply to convert foreign currency into euros. The challenge is to preserve the relationship between the original amount and every euro value derived from it, together with the rate, date, method and legal purpose of the conversion. That is what allows two systems to explain a difference instead of merely flagging one.
Conclusion
Croatia’s treatment of foreign-currency eInvoices demonstrates how a narrow reporting rule can create a wide system impact. A single USD invoice can generate a foreign-currency commercial document, one or two euro-denominated fiscalization records, one or more payment-reporting records and a separate accounting settlement value. Differences can arise from the exchange-rate source, legally relevant date, rounding sequence, independent issuer and recipient implementations, partial settlements, corrections and ordinary foreign-exchange movement. Some differences can be legitimate, others can indicate a defect, and the system must be designed to tell the difference.
The safest implementation principle is to treat the euro fiscalization amount as a derived regulatory representation rather than as a replacement for the original invoice amount. Once that separation is maintained, reconciliation can be built around provenance and meaning instead of simplistic numerical equality, which is likely to become increasingly important as Fiscalization 2.0 moves more tax control from human-readable documents into machine-readable data.
Sources
Fiscal Solutions, “Croatia: Fiscalization of e-invoices issued in foreign currency.” https://www.fiscal-requirements.com/news/5806-croatia-fiscalization-of-e-invoices-issued-in-foreign-currency
Croatian Tax Administration, Fiskalizacija 2.0 / eRačun technical documentation page. https://porezna.gov.hr/fiskalizacija/bezgotovinski-racuni/fiskalizacija-bezgotovinskih-racuna
Croatian Tax Administration, Technical Specification for eInvoice Fiscalization and eReporting, current 2026 version; the fiscalization field valutaERacuna specifies EUR. https://porezna.gov.hr/fiskalizacija/api/dokumenti/139
Croatian Fiscalization Act, Narodne novine 89/2025, especially Articles 47, 48 and 53. https://narodne-novine.nn.hr/clanci/sluzbeni/2025_06_89_1233.html
Croatian VAT Act, Article 36, foreign-currency conversion using the HNB middle rate with an ECB-rate option. https://www.zakon.hr/c/zakon/674643/zakon-o-porezu-na-dodanu-vrijednost-2026-2026
Croatian Tax Administration opinion, class 410-01/26-01/433, 21 April 2026, “Fiskalizacija eRačuna u stranoj valuti,” indexed by Mišljenja.hr. https://misljenja.hr/fiskalizacija-eracuna-stranoj-valuti/m7183/
Croatian Tax Administration, notice on the updated eInvoice validator, 12 March 2026. https://porezna.gov.hr/fiskalizacija/bezgotovinski-racuni/bezgotovinski-racuni-novosti/o/doradena-verzija-validatora-eracuna
