Guide: Specific use for Croatia

Service overview

The following services are offered by Unimaze:

• Sending and receiving on the Croatian network.

• Perform tax reporting and other fiscalization activities on behalf of the client.

  • Look up whether the receiver can receive an invoice electronically. If so, register the outbound invoice as fiscal evidence, otherwise as a taxable delivery.

  • Register an inbound invoice as fiscal evidence.

Processing tax feedback

Integrators must handle all incoming messages, included extended MLRs containing information about fiscal actions.

An overview of the flow is detailed here: ERP Tax Integration Flow

• Each inbound message, including MLRs and eMLRs, is announced with a deliveryNotified webhook event. Use the message's action (data.action in the event) to handle invoices (SubmitInvoice), credit notes (CorrectWithCredit) and responses (SubmitMessageResponse). Tell regular MLRs and extended MLRs (with document parameters and attachments) apart based on the transaction information.
• For outbound invoices, a taxReportingStatusChanged event tells you when the reporting status changes. When the Tax Administration rejects the report, the event's properties carry its errorCode and errorMessage, and actionMessageId identifies the tax report (MLA).
• Implementors should at least mark these as delivered (once detected by the ERP).
• In the daily safety-net check, GET /messages?status=pendingdelivery&transfer=inbound&transactionGroup=SubmitInvoice,CorrectWithCredit,SubmitMessageResponse lists the messages that were never marked as delivered. Calling it on a schedule instead (polling) is the legacy approach, see Polling (legacy).
• Fiscal actions rely on MLAs (message level actions) and eMLRs to hold the evidence of the tax reporting, so be sure to understand Working with MLRs, eMLRs and MLAs.

B2B (Fiscalization 2.0)

For short answers on obligations, deadlines and corrections, see the Croatia FAQ.

Supplier must register a payment

A supplier has the legal obligation to register a payment for an e-invoice once it has received the payment.

Register the payment with POST /api/v1/messages/{messageId}/compliance/hr/register-payment, where messageId is the invoice you sent. The body looks like this:

{
  "paymentDate": "2025-11-18",
  "chargedAmount": 100.12,
  "paymentMethod": "SettlementPayment"
}

paymentMethod is SettlementPayment, TransactionAccount or Other.

You can also register a payment independently of the message, with POST /api/v1/compliance/hr/register-payment. This is not recommended unless you are migrating and the invoices or credit notes don't exist in Unimaze, because the link between the messages is lost. supplierIdentifier is your own OIB:

{
  "documentNumber": "INV1002",
  "issueDate": "2025-11-01",
  "supplierIdentifier": "11223344556",
  "supplierName": "Supplier d.o.o.",
  "customerIdentifier": "99887766554",
  "customerName":"customer d.o.o.",
  "paymentDate": "2025-11-18",
  "chargedAmount": 100.12,
  "paymentMethod": "SettlementPayment"
}

Customer may register a rejection

There is no deadline for rejecting an e-invoice, but a customer has the legal obligation to report each rejection by the 20th of the month after the rejection. The rejection is sent as a business message from the customer to the supplier, and then reported to the Tax Administration.

Register the rejection with POST /api/v1/messages/{messageId}/compliance/hr/register-rejection, where messageId is the invoice you received. This is the recommended approach. The body looks like this:

{
  "rejectionType": "MismatchAffectingTaxes",
  "rejectionReason": "Did not receive goods too"
}

• rejectionType is MismatchNotAffectingTaxes, MismatchAffectingTaxes or Other.
• Only the receiver of the invoice can register a rejection. Anyone else gets 400.
• Unimaze creates the rejection business message and sends it to the supplier when the supplier can receive it, and then reports the rejection to the Tax Administration. Otherwise it reports the rejection to the Tax Administration directly.
• You get an eMLR for the tax reporting, and MLRs for the delivery of the business message if your participant is set up for MLRs.

Instead, you can build the rejection business message yourself, following the Aplikacijski odgovor za odbijanje računa specification (English version available on request), and send it with POST /api/v1/messages/create-business-transaction. Unimaze delivers it to the supplier and then reports the rejection.

You can also register a rejection independently of the message, with POST /api/v1/compliance/hr/register-rejection. This is not recommended unless you are migrating and the invoices or credit notes don't exist in Unimaze, because the link between the messages is lost. customerIdentifier is your own OIB:

{
  "documentNumber": "INV1002",
  "issueDate": "2025-11-01",
  "customerIdentifier": "11223344556",
  "customerName": "customer d.o.o",
  "supplierIdentifier": "99887766554",
  "supplierName": "supplier d.o.o.",
  "rejectionType": "MismatchAffectingTaxes",
  "rejectionReason": "Did not receive goods too"
}

On the supplier side

A rejection arrives as an inbound billing response (SubmitBillingResponse), announced with deliveryNotified like any inbound message. Fetch it with GET /api/v1/transactions/submit-billing-response?messageId={messageId}:

• rejectionReasonCode is N (mismatch not affecting taxes), U (mismatch affecting taxes) or O (other).
• reasons holds the rejection reason as text.

The rejected invoice's lifecycleStatus becomes rejected, and a lifecycleStatusChanged event is sent. Its properties carry the rejectionType and reason when known. It has no actionMessageId, because the customer reports the rejection, not you. Mark the billing response as delivered like any inbound message.

Profile types and document types

Two properties in the JSON for POST /api/v1/transactions/submit-invoice and POST /api/v1/transactions/correct-with-credit decide which profile is used:

• profileType is the business process, P1 to P12, as described in Opis poslovnih procesa (PDF, from Fiskalizacija 2.0 / eRačun). See also Use of profile identifiers.
• invoiceType (invoices) or creditNoteType (credit notes) is the document type.

If you set only one, the other is set to match it. If you set both, they must match:

Otherwise an error is returned. If you set neither, invoices are sent as P1 and CommercialInvoice, and credit notes as P9 and CorrectWithCredit.

Prepayment invoices: set profileType to P4 (advance payment) or P6 (payment before delivery of a specific order); invoiceType is then set to PrepaymentInvoice for you. dueDate is required.

Required fields

Croatian invoices and credit notes sent as JSON are rejected unless they contain:

• supplier.contact.identifier: the OIB of the operator who issues the invoice. Also set supplier.contact.name to the operator's name.
• On every line in invoiceLines (or the credit note lines):
  • taxCategoryName: the HR VAT category, for example HR:PDV25. See Use of VAT codes.
  • taxTypeScheme, for example VAT.
  • commodityClassification with type CommodityGrouping and the KPD code in code, except on prepayment invoices and credit notes. See Product classification.

{
  "supplier": {
    "contact": { "identifier": "11223344556", "name": "Ana Horvat" }
  },
  "invoiceLines": [
    {
      "taxCategoryName": "HR:PDV25",
      "taxTypeScheme": "VAT",
      "commodityClassification": { "type": "CommodityGrouping", "code": "62.01.11" }
    }
  ]
}

This example shows only the Croatian fields; the rest of the invoice is as usual.

Extended tax information

Extra information, provided in the so called HRUBLExtensions are created automatically in Transaction Services (JSON) but must be included in documents sent via the Messaging Service (XML).

Product classification

Every product or service line on an invoice must contain a classification code from the Klasus KPD2025 classification system, in the format <root category>.<sub category>.<item category>.

Lines on a prepayment invoice (386) or a credit note (381 or 261) may leave out the classification, as the Croatian rule HR-BR-25 allows. They still need the tax category name and tax type scheme.

Companies must map their product and service items to classification codes.

For many smaller businesses in service industry, they may be using 3-10 classification codes, but for others depending on the nature of the business (such as in retail, manufacture or wholesale) far more codes could be used.

Further information can be found here:

• General information from the tax administration office and details on how to use these codes: Klasifikacija proizvoda (KPD 2025).

  The source of information, full code list from the Bureau of Statistics: KLASUS - Osnovne informacije

• Information on how to navigate and find the code list: KLASUS_slikovni_prikaz.pdf

B2C (Fiscalization 1.0)

Overview

Unimaze supports B2C fiscalization in Croatia. Depending on the endpoint, sector is specified either as a query parameter or as a property inside the messageHandling body object. When omitted, the platform defaults to B2B processing.

sector is currently only meaningful for Croatian fiscalization. For all other markets the value is ignored.

B2C fiscalization works only after Unimaze has set up your client's fiscal certificate and fiscal parameters.

Endpoints

When using POST /messages/create-business-transaction, pass sector as a query parameter:

POST /messages/create-business-transaction?sector=B2C

or when using POST /transactions/submit-invoice

Pass sector inside the messageHandling JSON body property:

{
  "messageHandling": {
    "receiverIdentifier": "9934:12345678901",
    "fallbackEmailAddress": "[email protected]",
    "sector": "B2C"
  }
}

The rest of the request body is the invoice, as usual.

The accepted values for sector:

Validation Rules

Response

A successful B2C fiscalization response will include the following parameters in the eMLR: