Your main goal is to enable full or partial integration with MER for the end users following operations via your ERP system and implementing all legal requirement for Fiscalization 2.0 :
In order to build XML’s properly, make sure to donload the Specification for usecase of the eInvoice (english or croatian version). All specification can be found in the Download section of the site. As you go through the specification. you will find definitions of each existing tag, nodes and business rules that have to be followed accoiringly.
On top of this, to make the generation of XML as smooth as possible, XSD scheme was provided as a machine readable format of the expected structure.
For filling XML, use values that are described for every field
——————-
Example
BT-1. InvoiceNumber
Description: Unique identification account
Cardinality: 1..1 (meaning field has to be created and used only once)
In XML structure, it looks like:
<Invoice>
….
…
</Invoice>
——————-
When building XML structure of the, you will need to follow specification strictly and the order of the fields and nodes (Parent and child hierarchy).
Some XML fields and nodes have business rules that need to be met to be valid.
In the specification, there is a list of business rule list marked BR-XYZ or HR-BR-XYZ with the concrete description of business rule with exact description of the error.
——————-
Example
BR-2. The Invoice must have an Invoice number (BT-1).
HR-BR-1 The account number must not contain whitespace characters
Correct value should be:
<cbc:ID>23/1/1</cbc:ID>
——————-
From the January 1st 2026 all XMLs of eInvoice and eCreditNotes sent to MER will be validated synchronously when you send request on API methods Send or eReporting and the response will be list of errors in case document is not valid.
For integrating APIs, first you need to understand the process of the communication between ERP system, MER and other participants in the exchange of the electronic documents.
To be able to send document to MER for Fiscalization, first of all, you will need to implement API method SEND which is a standard method for sending electronic document to MER which will be sent to Fiscalization.
Send method process documents asynchronously.
In the same moment you send document to MER, there are two things MER will check before giving you response:
Response from this API can be one of three options: (UPDATE 2025-09-24)
In case a document is successfuly sent, you will get a response with an ElectronicID value which you need to store in your system as a unique identifier of the sent electronic document in MER system. With that value, you will be able to pull the status of the fiscalization of the document sent to MER.
Otherwise, if you get an error while trying to send document to MER via Send method, MER will give a description of the error and it won’t process the document any further. Based on the error message, you should present the information in your end user with the information that the attempt of sending the document to MER failed.
The most common error categories are:
NOTE: if the XML is correct but customer is not registered in AMS of the Tax Authority system from 1.1.2026., you will need to implement an option to send document to the eReporting system via API eReporting. Until 1.1.2026. eReporting system shouldn’t be used on production, but only on our test environment.
The Fiscalization law has proposed that user whose document couldn’t be fiscalized, need to send it to eReporting system to inform Tax Authority that the invoice was issued but couldn’t be fiscalized. That is a backup option in case fiscalization fails.
Sending to eReporting API will be syncrously sent to eReporting system of the Tax Authority system so you will get the status of the sent document to eReporting system.
Types of responses:
To track if electronic documentshave reached customers access point, whether they have beed successfully fiscalized, or in case the document has been sent to an eReporting channel, to track what the status of eReporting is, you need to implement APIs that allow you to track statuses of documents.
There will be 3 types of statuses in use: (UPDATE 2025-09-24)
Basic MER statuses will be always linked to the sending of the electronic document via MER but document business statuses and fiscalization statuses can miss out in certain scenarios so integration of multiple APIs can give you whole picture of the exchange of the electronic documents.
APIs for checking statuses of the sent document:
Possible combination of the statuses for a sent electronic document: (UPDATE 2025-09-24)
NOTE: character (->) in cases bellow indicates status change.
Case 1. MER sender, MER customer, fiscalization is successful, document is not rejected
Case 2. MER sender, MER customer, fiscalization is not successful
Case 3. MER sender, MER customer, fiscalization is successful, document is rejected
Case 4. MER sender, MER customer, fiscalization is successful, document is accepted
Case 5. MER sender, another Access point customer, fiscalization is sucessful, document is not rejected
Case 6. MER sender, another Access point customer, fiscalization is not successful
Case 7. MER sender, fiscalization is not possible, eReporting successful
Case 8. MER sender, fiscalization is not possible, eReporting unsuccessful
Case 9. MER Sender, fiscalization is not possible, eReporting successful but customer is registered in MER database and MER has their e-mail address for receiving electronic documents. This case can be uses only if MER has customer registered and have their e-mail address for receiving electronic documents. This case will be introduced soon!
Receiving information of the incoming electronic documents should be implemented for automation of the downloading, processing and booking directly into ERP system.
There are two options for downloading electronic documents:
Downloading sent electronic document is done using combination of API method QueryOutbox and API method Receive. After sending documents using API method Send and eReporting you get the ElectronicIDs from MER server response so you already have the list of ElectronicIDs. Now you can download digitaly signed XMLs for the internal e-archive.
There can also be an option that electronic documents has been send via another ERP system and you need to get the list of the sent documents inside your ERP, then you can send API method QueryOutbox to get the list of the sent electronic documents and download them into another ERP via API Receive.
Using ElectronicID, you need to create request for Receive API where you will download one-by-one XML of the electronic document. Inside the XML, you will have base64 encoded PDF as visual representation of the data (Invoice, CreditNote) and also can be found other attachments that were added inside XML. All attachments can be found inside cbc:EmbeddedDocumentBinaryObject. Attribute mimeCode defines the type of document that is encoded inside base64.
This scenario can be used in case of accounting office (knjigovodstveni servis) that is outsourced or when end user have different ERP systems then the one used in their accounting office.
NOTE: Downloading digitaly signed XML of users sent documents with the API Receive doesn’t effect basic MER status.
Receiving of the incoming electronic document is done using combination of API method QueryInbox and API method Receive. First you need to send request to QueryInbox for receiving the list of incoming invoices and write all ElectronicIDs which you got from the list. We can suggest to filter documents by electronic ID in case you already have downloaded them.
Using ElectronicID, you need to create request for Receive API where you will download one-by-one XML of the electronic document. Inside the XML, you will have base64 encoded PDF as visual representation of the data (Invoice, CreditNote) and also can be found other attachments that were added inside XML. All attachments can be found inside cbc:EmbeddedDocumentBinaryObject. Attribute mimeCode defines the type of document that is encoded inside base64.
One document can be downloaded multiple times even if they are in basic MER statuses 30 or 40.
NOTE: Receiving incoming electronic document via API Receive will change basic MER status from 30 to 40. It is not possible to update basic MER status from 40 back to 30 from ERP.
For fiscalization 2.0 , users have the obligation to inform Tax Authority about rejecting of the incoming electronic document and to inform them regarding payment of the sent document. Both information are backed by our APIs:
MarkPaid API is API used for sending payment information for the electronic document that has been sent via MER SEND API method and you have electronicID document of that document.
In case you need to send information for received payment for the electronic document that wasn’t sent via MER and you don’t have ElectronicID, then you need to use API method MarkPaidWithoutElectronicID
The same goes for the rejecting of the incoming electronic documents – use Reject method in case you have the ElectronicID because ERP has downloaded electronic document directly via MER system or RejectWithoutElectronicID when ERP system didn’t download electronic document directly via MER system so you don’t have ElectronicID of the document you want to reject.
There is option to use API UpdateDocumentProcessStatus to set electronic documents business status to APPROVED for the accounting office (knjigovodstveni servis). Usecase for this method means that end user who has another ERP system in which user sends and receives electronic documents, can update document business status so his account office (knjigovodstveni servis) can via their ERP system connect to the users MER account and download sent and received electronic documents. In case end user accepts document and wants it to be paid, they can update business process status to APPROVED so accounting office can pull that status of the end users incoming electronic document and do the payment process if they are allowed to do it in the name of the end user.
It is important to go through usecases of APIs and thre responses you can be able to handle errors that are the responses to certain requests. Managing to configure most usecases and responses produces quality user experience and helps informing user how to hendle using the integration module for e-invoicing via MER. More can be found on our site https://manual.moj-eracun.hr/documentation/api-specification/error-codes/.
If you have any questions, feel free to contact us by sending e-mail to integracije@moj-eracun.hr or by asking question to our MERI L2 AI assistant.