VATupdate
I Love Croatia

Share this post on

FacebookXEmailLinkedInWhatsApp
Croatia

Mandatory E-Invoice Data Fields (Croatia’s Fiscalization 2.0)

4 days ago
65 views
18 min read

Mandatory E-Invoice Data Fields (Croatia’s Fiscalization 2.0): Under the new law, every e-invoice must include all standard invoice information as defined by the EU norm EN 16931, plus certain national additions. The key data elements that must be present on the electronic invoice and reported to the Tax Authority’s system include: [finacro.hr], [finacro.hr]
  • Invoice Identification and Dates:
    • Invoice number – a unique number for the invoice, structured to include the business premise code and the issuing device code (as per Croatian requirements). [sapeinvoice.com], [sapeinvoice.com]
    • Invoice issue date – the date the invoice is issued (format YYYY-MM-DD). [finacro.hr]
    • Invoice type code – indicates the type of document (e.g. 380 for standard invoice, 381 for credit note, etc., following UNTDID 1001 codes). [sapeinvoice.com]
    • Supply date or service completion date – if different from the issue date (especially relevant for advance invoices or if delivery occurred earlier). [finacro.hr]
    • Payment due date – the date by which payment is due (if applicable). [finacro.hr]
  • Seller and Buyer Details:
    • Supplier (Issuer) information – name of the company or person issuing the invoice and the Croatian tax ID (OIB) of the issuer. (The OIB of the operator issuing the invoice on behalf of the company must also be included as a separate field in the XML.) [finacro.hr], [finacro.hr] [sapeinvoice.com]
    • Customer (Recipient) information – name of the buyer and their OIB (if they have one). Public bodies or non-VAT taxpayers may not have an OIB in some cases, but generally for domestic B2B an OIB is used to identify the buyer. [finacro.hr]
  • Line-item Details: For each billed line item on the invoice, the following must be provided in a structured way: [finacro.hr], [finacro.hr]
    • Description of goods or services – a text describing the item (item name).
    • Quantity and unit of measure – how many units were supplied, and the unit (e.g., pieces, kg, hours) coded according to UN/ECE standards. [sapeinvoice.com], [sapeinvoice.com]
    • Unit price (net of VAT) – price per unit before VAT and discounts. Any line-level discount can be reflected either by adjusted unit price or as a separate allowance entry. [finacro.hr]
    • Classification code of product/service – Croatia now mandates a 6-digit classification code for each item, using the national KPD 2025 system (aligned with EU CPA product codes). Every invoice line must include the appropriate KPD code identifying the good or service. Example: “11.07.01” for a certain product category. (This code is reported in the XML as an item classification.) [finacro.hr], [finacro.hr] [kpmg.com], [kpmg.com]
    • VAT category and rate for the item – the tax category (e.g., standard rate, reduced rate, exempt, reverse-charge) and the percentage rate applied to that line. For example, “S” might denote standard 25% VAT, “E” exempt, etc., per UNCL5305 codes. If exempt or reverse-charged, a reason code for VAT exemption must be included as well. [sapeinvoice.com], [sapeinvoice.com]
  • Invoice Total Breakdowns: Summary monetary amounts must be present for transparency and tax reporting: [finacro.hr], [finacro.hr]
    • Taxable amounts by rate: the net amount (excluding VAT) for each VAT rate or exemption category on the invoice. [finacro.hr], [finacro.hr]
    • VAT amount by rate: the VAT amount for each rate category applied. [finacro.hr]
    • Total VAT amount: the total VAT charged on the invoice (sum of all VAT amounts). [finacro.hr]
    • Total amount excluding VAT: the invoice total net of VAT (sum of line item net amounts minus any overall discounts). [finacro.hr], [finacro.hr]
    • Total amount including VAT: the grand total that the buyer must pay (gross amount). [sapeinvoice.com]
    • Any advance payments (prepayments) already made for this invoice, if applicable, and the resulting amount due (outstanding to be paid). The “amount due for payment” is especially important if part of the invoice was paid in advance or if a credit is applied. [sapeinvoice.com], [sapeinvoice.com]
  • Payment Information:
    • Bank account or payment identifier: The invoice must include the supplier’s bank account number (typically IBAN) or a virtual account number to which the payment should be made. This field ensures the tax authority knows the account used for transactions. (If payment will go through a payment service provider, the BIC or national bank code should be provided as well.) [finacro.hr], [finacro.hr] [sapeinvoice.com], [sapeinvoice.com]
    • Payment terms: any payment terms like due date (mentioned above) and, if relevant, payment method. (While the law doesn’t require a specific “payment method” field on the invoice for reporting, in practice the schema allows indicating the method in the payment data; e.g. code for wire transfer, card, cash, etc.)
  • References and Other Mandatory Elements:
    • If the invoice amends a previous invoice (e.g. a credit note or debit note), it must reference the original invoice number and date. The system will expect fields for “original invoice number” and “original issue date” in such cases, to link the documents. [finacro.hr]
    • Each invoice is digitally signed by the issuer. The signature and the digital certificate’s identifier (with the issuer’s OIB) are part of the data transmitted, ensuring authenticity. (This is handled by the system; the main point is that a valid qualified electronic signature is required on the e-invoice file.) [rtcsuite.com]
    • The Unique Invoice Identifier (JIR) from fiscalization 1.0 (for cash transactions) is not used on B2B e-invoices; instead, the tax system uses the invoice’s own number and the digital signature to track it. For B2C receipts, the JIR/Protected Code still apply at point of sale, but for B2B/B2G the new system relies on the e-invoice’s data and an internal reference ID.
All these data elements are embedded in the structured XML invoice that follows the EU UBL 2.1 format with Croatia’s extensions. The Croatian CIUS (Core Invoice Usage Specification) defines the above fields as mandatory in the invoice file. Notably, Croatia’s CIUS is called “HR-FISK 2.0” and adds requirements like the seller’s and buyer’s OIB, the 6-digit CPA product code, and the bank account details which go beyond the base EN16931 standard invoice. Both issuers and recipients must send these invoice data to the Tax Administration in real time (issuer at issuance, recipient upon receipt) so that the tax authority receives a complete set of information about each invoice. [rtcsuite.com]
Additional E-Reporting Data Requirements (Beyond the Invoice itself): Croatia’s e-Reporting is a continuous transaction control system that not only ingests the e-invoice contents above, but also requires additional reporting for certain events. In practice, most of the needed data for e-reporting events are references to the original invoice plus some event-specific fields. Below are the key data points for each type of e-reporting message:
  • Invoice Receipt Confirmation (Fiscalization of Receipt by Buyer): When an invoice is received by the buyer, the buyer must “fiscalize” it by reporting it to the tax system within 5 working days. The data the buyer submits is essentially the same invoice data listed above. In other words, the buyer’s system sends the Tax Administration a copy of the invoice record, marked as an incoming invoice (with an indicator that this is a received invoice). No additional fields unique to the buyer are needed (other than the buyer’s own OIB which is already part of the invoice). This dual reporting (issuer and recipient) allows the system to match invoices. Important: The buyer’s report will include a field specifying it’s an “incoming” invoice (versus the issuer’s “outgoing” designation). Once the recipient’s report is received, the tax authority knows the invoice was successfully delivered. (If the buyer never reports it, that may indicate an issue or non-compliance, which is why this confirmation is mandated.)
  • Invoice Payment (Collection) Reporting: When an invoice is paid, the issuer is required to send a report of the payment status. This ensures the tax authority can track when and how the invoice was settled. The following data must be provided in a “Record Payment” (Evidencija naplate) message for an invoice: [finacro.hr], [finacro.hr]
    • Invoice reference: identification of which invoice is being marked as paid – typically the invoice number and issue date, and the seller/buyer OIBs to ensure unique identification in the system. (The payment report message will include fields for the original invoice’s number, date, and the issuer’s OIB.) [rtcsuite.com]
    • Payment date: the date on which the payment was received. [sapeinvoice.com]
    • Amount paid: the amount that has been paid (which could be full amount or a partial installment). If multiple partial payments occur, multiple reports can be sent; the system accumulates them. [sapeinvoice.com]
    • Payment method: a code indicating how the payment was made. Croatia’s system uses codes such as “T” for bank transfer (transaction account), “O” for offset/compensation (settlement between parties), or “Z” for other methods. This code is included in the payment report (e.g., “T” if the invoice was paid via a wire transfer). [sapeinvoice.com], [sapeinvoice.com]
    • Payment reference: optionally, an identifier like the bank transaction reference or payment slip number can be included (though not strictly mandated, the schema allows details of the payment for traceability).
    These payment reports effectively update the status of the invoice in the tax authority’s database. The Fiscalization 2.0 technical specification confirms that a payment report message (RecordCollectionRequest) must be linked to a prior fiscalized invoice, and it will be rejected if the invoice isn’t already in the system. In summary, to report a payment, the tax system expects the invoice’s ID and the payment details (date, amount, method). (The law doesn’t require reporting of the payer’s bank account in this message – the assumption is that the payer is the invoice recipient already known – so the focus is on when and how much was paid.) [sapeinvoice.com], [finacro.hr]
  • Invoice Rejection Reporting: In cases where the recipient rejects an invoice (for example, due to a pricing error or it’s not their purchase), the recipient must notify the Tax Administration through an e-reporting message so that the invoice is not considered accepted. The “Record Rejection” (Evidencija odbijanja računa) message requires the following data: [finacro.hr], [sapeinvoice.com]
    • Invoice reference: identification of the invoice being rejected (invoice number, issue date, supplier OIB, etc., similar to payment reference above). This tells the system exactly which previously reported invoice is being rejected by the buyer. [sapeinvoice.com]
    • Rejection date: the date the invoice was rejected by the customer (usually the date this message is sent, but it can be back-dated a little if the decision was made earlier). [sapeinvoice.com], [sapeinvoice.com]
    • Reason for rejection: a code and/or description of why the invoice is rejected. The Croatian system defines three standardized reason codes: “N” (Non-tax relevant discrepancy) – e.g. minor errors like an incorrect address or purchase order number; “U” (Tax relevant discrepancy) – e.g. a mistake in tax calculation, price, or quantity that affects VAT; “O” (Other reason) – any other reason not covered by N or U (e.g. duplicate invoice, goods not delivered, etc.). The rejection message must include one of these codes (N, U, or O) in the field for “type of rejection reason”. Optionally, the recipient can provide a short textual explanation for the rejection as well (for example: “Invoice rejected due to price mismatch with contract”). [sapeinvoice.com]
    • The rejection message is digitally signed by the rejecting party and sent via the web service like other messages. Once processed, the Tax Administration marks that invoice as rejected in its records. (If the supplier corrects the invoice and issues a new one, that will be a separate e-invoice with a new number reported normally.)
    Example: A buyer receives an invoice charging 25% VAT but the goods should have been zero-rated; the buyer can reject the invoice for a tax discrepancy. They would send a rejection report for invoice #123, dated e.g. 2025-11-10, reason code “U” (tax error) with a note “Incorrect VAT charged – invoice refused”. This must be reported by the 20th of the month following the invoice if they intend to formally reject it.
  • Delivery of Goods without Invoice (E-Transport report): If for some reason an invoice cannot be issued at the time of delivery of goods, the supplier is obliged to report the delivery details to the tax authorities through a “delivery report” (this is informally referred to as the e-Transport obligation). The e-reporting message for this is called “Record Delivery for which Invoice Was Not Issued” (Evidentirati isporuku za koju nije izdan e-Racun). Essentially, the supplier provides a provisional transaction record so the tax authority knows a taxable delivery occurred. Required data for this report include: [sapeinvoice.com], [sapeinvoice.com]
    • Transaction identifier: Since no invoice number exists yet, the supplier must create a reference for the delivery. In practice, the same fields for an invoice are used – you still provide a “Document number” and date, but classify it with a special type code. The invoice type code “IR” is used in the XML to indicate “Outgoing invoice for which an e-invoice was not issued”. This tells the system this is a report of a delivery without a formal invoice. The supplier will include a document number (which could be a delivery note number or any internal reference) and the date of delivery. [sapeinvoice.com]
    • Supplier and customer details: same as if it were an invoice – the parties involved in the delivery (supplier’s OIB, name; customer’s OIB, name) need to be reported. [sapeinvoice.com]
    • Description of goods and values: essentially a mini-invoice – the supplier provides what was delivered: item description, quantity, value, and applicable tax category/rate. All the item-level data that an invoice would contain (net amounts, VAT amounts) are included in this delivery report. This is because the Tax Administration wants to capture the taxable basis and expected VAT, even if the invoice comes later or not at all. [sapeinvoice.com], [sapeinvoice.com]
    • Total value of delivery: the total taxable amount and VAT for the delivered goods, similar to an invoice total, so that the tax liability is known. [sapeinvoice.com]
    • The delivery report is basically structured like an invoice message, with the key difference that it’s flagged as “IR” (instead of a normal invoice type) and it does not necessarily mean an actual fiscal invoice was issued to the buyer. It’s a data placeholder. Later, if an invoice is eventually issued for this delivery, that invoice would be reported normally and can be matched to the prior delivery report (the system can link them via references, though the law’s specifics on linkage are still being developed).
    Use case: This scenario happens, for example, if a customer’s e-invoicing address or VAT ID isn’t known at delivery time (so an e-invoice can’t be routed), or in consignment scenarios. The law mandates the supplier to report the delivery within 5 working days in such cases. The same data fields as a full invoice are required in the report (essentially it’s an invoice without an invoice document). The official spec notes that the data set and checks are identical to an invoice, except the “invoice type” is marked as IR for these records. This ensures no required field is omitted. [sapeinvoice.com], [sapeinvoice.com]
  • Cross-Border Invoice Reporting: (Not explicitly asked in the question, but for completeness: if a Croatian taxpayer receives an invoice from a foreign supplier or issues an invoice that is out of scope of domestic fiscalization, those invoices still need to be reported through the e-Reporting system. The data required would be similar to a regular invoice record so that the tax authority captures the transaction. For example, an EU supplier invoice received by a Croatian company must be reported by the Croatian company, including the foreign supplier’s details, invoice number/date, and amounts, so the tax authority knows about the acquisition. This is done via the same “Register Invoice” method, marking it as incoming and possibly indicating it’s a foreign invoice.)
Format and Technical Structure: All the above information is transmitted in a structured electronic form: the system uses XML messages based on the UBL 2.1 schema. Each e-invoice must conform to the European standard EN 16931-1:2017 format (syntax can be UBL or UN/CEFACT CII; Croatia chose UBL) with the national extension (CIUS) called “Fiscalization 2.0” for the additional fields. For instance, the CIUS ensures an <OIB> element is included for seller and buyer, and defines the KPD code placement in the XML. The Tax Administration has published the official XSD schemas and WSDL (web service definitions) on its website for software providers to integrate. Data exchange with the Tax Authority is via SOAP web services over HTTPS, in real time or near-real-time. Each message (invoice, payment, rejection, etc.) is an XML file sent to the appropriate endpoint. [rtcsuite.com] [sapeinvoice.com]
Digital Signature and Security: Every invoice or report is electronically signed. Businesses must use a qualified digital certificate issued in Croatia that includes their OIB in the certificate subject. The XML messages use an XML Signature (XAdES-BES) to sign the content, ensuring integrity and authenticity. The Tax Administration’s system verifies the signature and the certificate (it must be from a trusted provider and not expired) as a first step in processing. If the signature or certificate is invalid, the message is rejected with an error. Communication is encrypted via TLS, and clients (businesses or their providers) must register their certificates with the system to gain access. This technical setup is detailed in the official documentation and ensures that the reported data cannot be tampered with in transit. [rtcsuite.com] [sapeinvoice.com], [sapeinvoice.com]
References to Regulations and Guidance: Croatia’s requirements are laid out in the Fiscalization Act (Zakon o fiskalizaciji) as amended in 2025, and further in the implementing regulation and technical specification:
  • The Official Gazette published the Fiscalization Act on 13 June 2025 (No. 89/2025) which provides the legal basis for mandatory e-invoicing and e-reporting. Article 7 of that Act lists the mandatory content of invoices (largely reflected in the list above, including all tax data and identifiers). Article 52 covers the e-reporting obligations for rejections, payments, and deliveries without invoice.
  • The Ministry of Finance – Tax Administration released a comprehensive technical specification titled “Tehnička specifikacija za fiskalizaciju eRačuna i eIzvještavanje” in 2025, which describes the XML schemas (XSD) for each message type and the usage rules. This document (available in Croatian on the Tax Administration website) is the authoritative source for all data fields and their XML tags. For example, it defines the element names like PaymentAccountIdentifier for IBAN, DueDate for payment due date, and the code lists for rejection reasons, payment methods, etc.. [sapeinvoice.com], [sapeinvoice.com]
  • The Tax Administration’s portal provides resources (in Croatian) for taxpayers and software providers, including the WSDL for the web service endpoints and example XML files. See the official page: Porezna Uprava – Fiskalizacija e-Računi (bezgotovinski računi), which links to schemas and instructions. [sapeinvoice.com]
  • Regulations: Alongside the law, a bylaw or rulebook was likely published (often the Ministry publishes a rulebook detailing invoice content requirements). The reference in the Finacro consultation to Narodne novine 151/2024 appears to relate to the adoption of the CPA classification requirement (6-digit code) – an earlier regulation made in late 2024 making the CPA (KPD) classification mandatory on invoices. This is an example of the granular detail found in official sources. [finacro.hr]
  • News and analysis: The requirements have been summarized in numerous external newsletters and articles by tax advisory firms. For instance, KPMG’s TaxNewsFlash and Sovos’ regulatory analysis highlight that in addition to standard invoice fields, Croatia mandates reporting of the supplier’s bank account number, invoice payment status, and product codes, and that both issuers and recipients must transmit invoice data. These sources confirm the list of fields above. The European Commission’s eInvoicing Country Sheet for Croatia (updated August 2025) also confirms that the format is EN16931 with a national CIUS and that the exchange is via a decentralized model with real-time reporting to the authorities. [rtcsuite.com] [rtcsuite.com]
In summary, Croatia’s e-invoicing mandate requires a full, detailed set of invoice information to be sent to the tax authority for each transaction, ensuring that authorities have all the data needed for VAT control. On top of that, the e-reporting system captures invoice life-cycle events like acceptance (or non-acceptance), payment, and goods delivered without invoices by requiring taxpayers to send additional messages containing the relevant data (invoice IDs, dates, reason codes, etc.). All of this is defined in official documentation and must be adhered to by taxpayers’ IT systems. Non-compliance (omitting required data or failing to report within deadlines) can lead to significant penalties, so businesses should review these data requirements carefully. The Tax Administration’s guidelines and the technical spec are the best resources for ensuring all required fields are present in the XML reports. [rtcsuite.com]

Latest Posts in "Croatia"

Sponsors:

Advertisements:

  • Pincvision