Croatia’s E‑Invoicing, Fiscalization & E‑Reporting Requirements

Croatia’s E‑Invoicing, Fiscalization & E‑Reporting Requirements (as of Feb 2026)

Mandatory E-Invoicing Data Fields (B2B/B2G)

• Invoice Identification & Dates: A unique invoice number (following Croatia’s format rules, which incorporate the seller’s business premise code and cash register/device code), the invoice issue date (YYYY-MM-DD), and an invoice type code (e.g. “380” for a standard invoice, “381” for a credit note). If the delivery or service occurred on a different date (or it’s an advance invoice), the date of supply or service completion must also be stated. Additionally, the payment due date (due date for payment) must be included if applicable. [vatupdate.com]
• Seller and Buyer Details: The supplier (issuer) name and the company’s tax identification number – Croatia uses the OIB (Personal Identification Number) as the VAT ID – are required on every invoice. (If an individual operator or employee issues the invoice on behalf of the company, that person’s OIB must also be recorded in the e-invoice XML as a separate field.) The customer (recipient) name must appear, and if the buyer has an OIB (which all domestic businesses do), it should be included as well. (For public bodies or private individuals who may not have an OIB, the invoice would note their other identifying info – but for B2B transactions between VAT taxpayers, both sides’ OIBs are typically present.) [vatupdate.com]
• Line-Item Details: Each invoiced line must be detailed with: a description of the goods or services, the quantity and unit of measure (using standard units like pieces, kg, hours, etc.), and the unit price (net of VAT) before any discount. Any line-level discount can be shown either by reducing the unit price or as a separate discount entry. Critically, Croatia now requires a product/service classification code for each line item – specifically the 6-digit “KPD 2025” code (aligned with EU CPA codes) that categorizes the item. Every invoice line must include the appropriate KPD code identifying that item (e.g. a certain type of product or service). Also, for each line you must specify the VAT category and rate applied – for example, standard 25% VAT (“S”), reduced rate 13% (“AA”), exempt (“E”) or reverse-charge, etc., along with any required explanation code if tax is exempted or reversed. [vatupdate.com]
• Taxable Amounts and VAT Summary: The invoice needs to break down the taxable base amount for each VAT rate or exemption category used, and the corresponding VAT amount for each rate. From this, the total VAT amount on the invoice is calculated and must be shown. Additionally, the total invoice amount excluding VAT (net total) and the total including VAT (gross amount payable) are mandatory sum fields on the invoice. If any advance payments were made or a credit is applied, the invoice should note the amount already paid and the remaining amount due so that it’s clear what the buyer still owes. [vatupdate.com]
• Payment Information: The law specifically requires the invoice to include the supplier’s bank account number (IBAN or other payment identifier) to which the payment should be made. (If a payment service provider or a virtual account is used, that identifier must be provided instead.) This ensures the Tax Authority knows the account involved in the transaction. In practice, most invoices will list an IBAN and possibly the bank’s BIC. Also, while not explicitly mandated as a separate field by law, it is common (and supported by the format) to indicate the payment terms (e.g. payment method and terms) – for instance, whether it’s by bank transfer, card, or cash, and within 30 days, etc.. (Notably, the payment method code is optional in the schema; the law doesn’t force you to include how the invoice will be paid, though you may include it. The key required payment info is the due date and the seller’s account details). [vatupdate.com]
• References (if applicable): If the invoice is a correction of a previous invoice (such as a credit note or debit note), it must reference the original invoice’s number and date that it amends. This link back to the original document is mandatory for all adjustments. Likewise, if the invoice is an advance/proforma being settled or some document that isn’t a final invoice, references are needed to connect it to the final invoice. (For standard invoices, this section may not apply, so it’s only required when relevant.) [vatupdate.com]
• Digital Signature and Unique Identifiers: Every e-invoice must be digitally signed by the issuer using a qualified electronic signature certificate issued in Croatia (the certificate is tied to the company’s OIB). The signature and certificate info travel with the invoice data to ensure authenticity and integrity. Unlike the older cash-register system, B2B/B2G e-invoices do not receive a “JIR” code from the tax authority – instead, the combination of the invoice’s unique number and the digital signature serves to uniquely identify and authenticate the invoice in the system. (For B2C receipts, the JIR code still exists – explained later – but for e-invoices the tax system tracks them by the invoice’s own ID and the digital signature rather than assigning a separate code.) [vatupdate.com]

Fiscalization for B2C Transactions (Real-Time Receipt Reporting)

Continuous E-Reporting Responsibilities (Seller vs. Buyer)

• Issuer’s Real-Time Fiscalization of the Invoice: When a supplier issues an e-invoice to a domestic business customer, they must simultaneously (or immediately) send the invoice data to the Tax Administration’s fiscalization system. This is essentially the B2B equivalent of the fiscalization described for B2C, except that the full invoice XML is sent (with all the detailed fields discussed earlier, not just summary totals). The Tax Administration receives the invoice info in real time for every invoice issued. This is the seller’s primary reporting duty: every invoice must be “fiscalized” at the time of issuance by submitting its data digitally. In technical terms, the issuer’s system or their intermediary sends an XML message to the tax authority (often via a web service called “Fiskalizacija”) containing all the invoice’s fields. If the issuer is self-billing (issuing an invoice to themselves on behalf of a supplier) there’s a slight timing allowance – they must still report it within 5 working days – but generally for normal cases it’s immediate. [finacro.hr]
• Recipient’s Confirmation of Receipt (Buyer’s Fiscalization): The buyer of a domestic e-invoice is obliged to also report that invoice to the Tax Administration when they receive it. They have up to 5 working days from receipt of the invoice to do so, but in practice this can be an automated process upon invoice ingestion. The buyer’s report basically mirrors the invoice data: it confirms “Invoice X from Seller Y, amount Z, was received by us (Buyer Z) on this date.” Importantly, the buyer’s submission includes all the same key fields of the invoice – the tax authority expects to get a matching record from the buyer to pair with the seller’s record. The only differences are that the buyer’s report is labeled as an incoming invoice (whereas the seller’s is outgoing) and it does not generate any new invoice content; it’s just an acknowledgment message. There’s no additional data field the buyer must add (other than perhaps indicating the date they received it, which can be derived) – they do not need to re-enter all details manually, since in practice they’d use the structured invoice file. So fields like invoice number, dates, OIBs, line amounts, product codes, VAT amounts, etc., are present in both the seller’s and buyer’s reports. This dual reporting allows the tax system to cross-check that both parties recorded the same transaction. Once the buyer’s report is received, the Tax Administration knows the invoice was successfully delivered and accepted by the buyer. [finacro.hr] [vatupdate.com], [vatupdate.com] [vatupdate.com]
  • If the buyer fails to report an invoice they received, it’s a red flag. The system will see an invoice that the seller reported but the buyer never acknowledged. This could imply non-compliance or an issue (perhaps the invoice wasn’t actually delivered to the buyer, or the buyer is neglecting their obligation). Thus, the buyer’s confirmation is effectively mandatory – it’s not optional if you’re the invoice recipient. It serves as an acknowledgment of the invoice in the government’s eyes. There isn’t a separate “acceptance” message; by reporting the invoice data, the buyer is acknowledging it. (If they have a problem with the invoice, that’s where rejection comes in – see next point.)
• Recipient’s Rejection (if needed): If the buyer finds an error or dispute with the invoice, they have the option to reject the invoice. In the electronic system, a rejection is done by the buyer sending a “Record of Rejection” message through e-Reporting. This message will identify the invoice (by invoice number, date, and the seller’s OIB) and include a reason code for the rejection. The Croatian system defines a few standard rejection reasons: for example, “U” for a tax-relevant discrepancy (like the VAT or amount is wrong), “N” for a non-tax discrepancy (minor issues not affecting VAT, perhaps a wrong address), or “O” for Other reasons. The buyer must send this rejection report by the 20th of the month following the invoice’s month at the latest if they intend to officially reject it (they can also do it sooner). Once a rejection is reported, the Tax Administration marks that invoice as rejected in its system, and presumably the buyer won’t claim input VAT on it. The seller is informed through the system that the invoice was rejected (they would see this status in the portal or via their intermediary). The seller would then likely issue a corrected invoice if appropriate. If the buyer does not file a rejection report by the deadline, the invoice is considered accepted by default. So from the seller’s perspective: no news is good news – you’ll get confirmation the buyer reported it (which they must do within 5 days), and if you don’t get a rejection notice later, the invoice stands. (Sellers can view these statuses in the government’s FiskAplikacija portal, which lets them see which invoices have been reported by the recipient and whether any were rejected.) [vatupdate.com] [marosavat.com]
• Issuer’s Payment Status Reporting: Another obligation is for the issuer to report when an invoice is paid (collected). Croatia is introducing this as part of e-Reporting to keep track of payments for VAT purposes. The seller must send a “payment report” by the 20th of the month after any payment was received on an invoice (or multiple partial payments) – essentially a monthly reporting cycle for payments received. The payment report references the original invoice (by number and OIBs) and states the date and amount that was paid, and optionally the method (they use codes like “T” for bank transfer, “O” for offset, etc.). For example, if invoice #100 was paid on Feb 10, 2026, the seller would include that info in their February e-report (due by Mar 20, 2026). If an invoice hasn’t been paid yet, there’s nothing to report for it (though the tax authorities will then know it’s still outstanding). This requirement means the seller has to track and periodically inform the tax authority of invoice settlement status. It’s an additional data point beyond the invoice itself. The buyer does not report payments – only the issuer does, since the seller is the one receiving the money in their account and can confirm it. [vatupdate.com] [ecosio.com]
• Reporting Invoices that Could Not Be Issued Electronically: The law anticipates situations where a supplier couldn’t issue a standard e-invoice to the buyer (for example, the buyer wasn’t registered in the national e-invoice directory, so the seller had no electronic address to send to). In such cases, the seller is allowed to issue a paper invoice temporarily, but they must still report the transaction via the e-Reporting system. The mechanism for this is a special report often nicknamed the “delivery report” or “IR report” (for Izvješće o isporuci). Essentially, the seller sends an electronic notice to the Tax Administration with all the details of the transaction that would have been on an invoice, flagged as “Invoice was not issued electronically”. This includes the buyer and seller details, date of sale, items, amounts, taxes – effectively a complete invoice data set – just without an actual e-invoice document. The system uses a specific invoice type code “IR” (for this scenario) to distinguish it. This report must be submitted within 5 working days of the transaction (since no e-invoice was sent). It ensures the tax authorities still get the data on time. Later, if the seller eventually obtains the buyer’s e-invoicing details or resolves the issue, they might issue the e-invoice and link it, but the immediate requirement is fulfilled by this report. Only the issuer performs this step (since by definition the buyer didn’t get an e-invoice to report). This is a mandatory reporting event for sellers whenever an invoice can’t be electronically issued. It prevents gaps in the system’s data. [finacro.hr] [vatupdate.com]

Handling Exceptions: If E-Invoicing or E-Reporting Cannot Be Used

• Transactions Already Fiscalized via Cash Register: As noted, if a sale is processed through the legacy fiscalization (cash register) system with a JIR code, it is exempt from the e-invoicing requirement. This typically covers B2C sales and any scenario where an invoice was issued to a customer in paper form and fiscalized because they paid on the spot (cash or card). In such cases, the paper receipt with a JIR serves as the legal invoice for that transaction, and no further e-invoice needs to be generated. The rationale is to avoid double-reporting: the Tax Authority already got the data in real time when the JIR was issued. However, the law does add one twist: if that fiscalized receipt was actually for a B2B transaction (say a company purchasing goods and paying cash), the seller should include the buyer’s OIB on the fiscalized receipt if the buyer provided it. (Previously a cash receipt might not list the buyer’s ID at all. Now they want the OIB so the transaction can be tied to the buyer in the system.) In summary, the presence of a JIR on an invoice indicates that invoice was handled via the cash fiscalization route; those invoices are not sent as e-invoices and are considered compliant. [finacro.hr]
• Buyer Not Ready for E-Invoicing: If a seller cannot deliver an e-invoice because the buyer isn’t capable of receiving it electronically, the law provides relief. Specifically, if the buyer’s e-invoicing identifier is not found in the national AMS directory (Adresar Metadata System – basically the registry of companies’ electronic addresses), the seller is not held liable for not issuing an e-invoice. In that case, the seller can issue the invoice in paper form to the customer. Crucially, the seller must still report the invoice data to the Tax Authority via e-Reporting. This is exactly the scenario for the “delivery for which e-invoice was not issued” report (the “IR” report described above). By sending that report within 5 days, the seller fulfills the reporting requirement even though the actual invoice was paper. So the transaction is on record with the tax authorities. Essentially, the lack of the buyer’s e-address lets the seller fall back to paper, but they cannot skip reporting – they just report through a different channel. This exception is expected to be temporary or rare, because most VAT-registered businesses are supposed to register for e-invoicing. Over time, as everyone gets an electronic address or uses an intermediary, this issue should fade. But if it happens, the law explicitly shields the seller from penalties as long as they do the e-reporting. [finacro.hr]
• System Downtime or Technical Problems: The regulations foresee that either the taxpayer’s system or the Tax Authority’s system could have outages. The law and technical rules typically instruct taxpayers that if they cannot transmit data in the moment due to technical issues, they should transmit it as soon as the issue is resolved. (Under the old fiscalization rules, if your cash register couldn’t connect to the server, you could still issue receipts and then send the batch of data later once reconnected – within 48 hours. For the new system, similar provisions likely apply, although specific timeframes aren’t in the summary sources.) In practice, this means if e-invoicing or e-reporting is temporarily unavailable, businesses should queue the data and send it when possible. There isn’t an indefinite pass – delays have to be justified by genuine technical failure. The Tax Administration did upgrade systems and provided a test environment in late 2025 to iron out issues, so by 2026 they expect the channels to be robust. There is no permanent exemption for technical barriers – only a “send later when it works” approach. [edicomgroup.com]
• Cross-Border Transactions: As mentioned, these are not under mandatory e-invoicing. If a Croatian company issues an invoice to a foreign customer, they can still do it via PDF or paper (at least until EU-wide digital reporting comes into play in the future). Such invoices still have to be accounted for in VAT returns, but they don’t go through Croatia’s real-time system. The new law’s continuous reporting is mainly for domestic transactions. One caveat: the Tax Authority does want to know about purchases from foreign suppliers too (for VAT control on reverse charge). Likely there will be an expectation for companies to report received foreign invoices (e.g. a Croatian buyer receiving an invoice from an EU supplier might have to input some data into the system for a pre-filled VAT return to work). This detail goes beyond the core question, but it’s worth noting that the system ultimately aims to capture all transactions affecting Croatian VAT, domestic or cross-border, one way or another.

Penalties, Enforcement, and Grace Period Considerations