Guides
Start typing to search…

Guide: Specific use for Croatia

This is a guide to using Transaction Services for specific requirements for document handling in Croatia.

🚧

Work in progress

Page updates are in progress regarding MLRs and eMLRs.

📘

For general guidance on working with JSON metadata, please refer to MAPI Guided Tour -- Transaction Services.

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 if receiver is eligible to receive an invoice electronically and, in that case, register and outbound invoice as a fiscal evidence, otherwise as a taxable delivery.

    • Register an inbound invoice as fiscal evidence.

Supplier must register a payment

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

A supplier party registers the payment using POST /messaging/:mid/compliance/hr/register-payment with a payload looking like this:

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

Another option is to do this independently of the message using POST /compliance/hr/register-payment. This is not recommended unless doing a migration where the invoices/credit notes don't exist on our service, since link between messages will be lost.

In this case the payload looks like this:

{
  "documentNumber": "INV1002",
  "issueDate": "2025-11-01",
  "supplierIdentifier": "11223344556",  // own OIB number
  "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

A customer has the legal obligation to register a rejection of an e-invoice before the 20th of the subsequent month after the invoice was issued.

A customer party can register using POST /messaging/:mid/compliance/hr/register-payment with a payload looking like this:

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

Another option is to do this independently of the message using POST /compliance/hr/register-rejection. This is not recommended unless doing a migration where the invoices/credit notes don't exist on our service, since link between messages will be lost.

In this case the payload looks like this:

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

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

  • A good practice is to filter inbound messages using actions e.g. invoke GET /messages?status=pendingdelivery&transfer=inbound&transactionGroup=SubmitInvoice,CorrectWithCredit,SubmitMessageResponse and differentiate between regular MLRs and extended MLRs (with document parameters and attachments) based on transaction information.\

    NOTE
    At the moment the transaction group filter only supports a single value, so essentially the GET /messages call would EITHER have to be made three times OR do a GET /messages?status=pendingdelivery&transfer=inbound and handle based on the Action type.

  • Implementors should at least mark these as delivered (once detected by the ERP).

  • ❗️

    IN PROCESS

    • Add section to explain what eMLR tells about the fiscal action (reference to another page maybe?)
    • Add link to GET /... that will fetch the eMLR along with its parameters.

Profile types and document types

Two parameters in JSON for POST /transactions/submit-invoice and POST /transactions/correct-with-credit are used for determining which profile to use:

  • profileType describes the actual profile e.g. P1, P2, ..., P12 as described in PDF Opis poslovnih procesa (from source Fiskalizacija 2.0 / eRačun)

  • documentType has enumeration values like CommercialInvoice, PrepaidInvoice, FactoredInvoice. For most networks and process specifications this has no meaning, since no distinction is made and only CommercialInvoice is supported.

Neither of these values is mandatory and will be set to default if omitted (P1 and CommercialInvoice), whereas specifying only one of them will map to the most appropriate default value for the other. When both are set an error will be returned, in case they are in conflict.

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 item on an invoice or credit note (except pre-payment invoices) must contain a classification code according to the Klasus KPD2025 classification system.

They must be presented in this format <root category\>.\<sub category\>.\<item category\>.

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:

Updated 19 days ago