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.
(UPDATE 2025-12-02)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-11-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: UPDATE (2025-11-24) if the XML is correct but customer is not registered in AMS of the Tax Authority system from 1.1.2026., MER will automatically generate request to send documents to eReporting so you don’t have to do it manually. All MER organization will have automatic eReporting turned on by default from 1.1.2026.
The Fiscalization law has proposed that company whose document couldn’t be fiscalized because lack of AMS registration of his customer, 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.
Types of responses:
To track if electronic documents have reached customers access point, whether they have been 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-11-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.
(UPDATE 2025-11-24) APIs for checking statuses of the sent document:
Possible combination of the statuses for a sent electronic document: (UPDATE 2025-11-24)
NOTE: character (->) in cases bellow indicates status change.
Case 1. MER sender, MER customer, fiscalization is successful, document delivered and not rejected
Case 2. (UPDATE 2025-11-24) MER sender, MER customer, document delivered to customer, fiscalization is not successful
Case 3. MER sender, MER customer, fiscalization is successful, document delivered but rejected
Case 4. MER sender, MER customer, fiscalization is successful, document is accepted
Case 5. (UPDATE 2025-11-24) MER sender, another Access point customer, fiscalization is sucessful, document delivered and not rejected
Case 6. (UPDATE 2025-11-24) MER sender, another Access point customer, document delivered to another Access point but fiscalization is not successful
Case 7. (UPDATE 2025-11-24) MER sender, fiscalization is not possible because customer didn’t register into AMS, eReporting successful and MER system has customers email address for sending direct email notification so customer can download XML and PDF of the invoice
Case 8. (UPDATE 2025-11-24) MER sender, fiscalization is not possible because customer didn’t register into AMS, eReporting successful but MER system doesn’t have customers email address for sending direct email notification so customer can download XML and PDF of the invoice
Case 8. MER sender, fiscalization is not possible, eReporting unsuccessful
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.
(MAJOR UPDATE 2025-12-03): To be sure to download and process incoming invoices, first you will have to retreive status of the fiscalization of the received document! Since Tax Authority specified that Access points will first have to exchange documents and then fiscalize them, this means that you will be able to receive document that MER can’t fiscalize. In that case, you will have to check in your incoming invoice is fiscalized and then you are able to download it and process it.
So the suggestion is to implement and call APIs in this order:
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.