📘

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

• For working with raw XML, please refer to MAPI Guided Tour – Message Services .
• Even when working with XML documents, these routes descibed below are applicable.

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.

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.
• Alternatively, either make the the GET /messages call (with arguments) would three times OR do a GET /messages?status=pendingdelivery&transfer=inbound and handle document types based on the Action type.
• Implementors should at least mark these as delivered (once detected by the ERP).
• Fiscal actions rely on the use of MLA (message level actions) and eMLRs to contain the evidence for of the tax reporting, so be sure to understand Working with MLRs, eMLRs and MLAs

B2B (Fiscalization 2.0)

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"
}

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:

• 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.

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": "KT:2222228899",
    "fallbackEmailAddress": "[email protected]",
    "sector": "B2C"
  },
  "invoice": { ... }
}

The accepted values for sector:

Validation Rules

Response

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