This validator must be used to verify compatibility with fiscalization.
To successfully submit an XML document, it must pass UBL 2.1 validation using both validation types:
– Kompatibilnost za slanje fiskalizacije
– HR Porezna uprava validator
If validation returns errors, they will be listed in the response. Using CTRL + F in the official specification, you can locate the rule or XML element that caused the error.
This validator is used exclusively for users sending invoices in the HR Invoice format (OutgoingInvoicesData).
It does not validate UBL 2.1 documents and must not be used for UBL eInvoices.
This is the official Croatian Tax Authority specification for eInvoices and HR extensions. It defines which XML elements are used, where they are located, and whether they are mandatory or optional.
Element cardinality is defined using ranges:
0..n – the element is optional and may appear multiple times
1..n – at least one element must exist
1..1 – exactly one element must exist
If the validator returns an error, search this specification (CTRL + F) for the rule or XML element causing the issue.
The XSD schema defines the complete technical structure of the UBL 2.1 eInvoice.
Most importantly, it defines the exact order of elements in the XML document.
If the validator returns an error such as:
The element 'Invoice' has invalid child element 'DueDate'.
List of possible elements expected: 'ProfileExecutionID, ID'.
this means the element order is incorrect. Open the XSD schema in an XML editor and verify the correct sequence of elements.
This package contains ready-made XML examples for the most common business scenarios, including different VAT rates, VAT-exempt invoices, margin scheme, reverse charge, and combined tax cases.
Use these examples to compare the structure and values of your XML with valid documents.
– Download XML with explanations for each field
This example provides a detailed explanation of the meaning of each XML element and how to correctly populate its values.
It is especially useful during the initial XML generation implementation or when resolving validation errors.
Seller Contact ID must contain the OIB without the country prefix, i.e. exactly 11 digits.
The OIB may belong to a natural person who created the invoice or to a legal entity (company),
depending on the business case.
Seller Contact Name must contain the name of the person or company to which the specified OIB belongs.
Tax category O is used exclusively when the entire invoice is not subject to VAT.
In this case, the value FRE must be entered in PartyTaxScheme / TaxScheme / ID.
In all other cases, when VAT is present on the invoice, the TaxScheme ID must be VAT.
The XML must not contain empty elements or elements without values.
Such elements must be completely removed from the XML.
If an element is not mandatory and has no value, it must not be generated at all,
otherwise the XML will fail validation.
The population method depends on whether OIB or GLN is used.
If OIB is used:
– EndpointID contains only the OIB, with schemeID="9934"
– PartyIdentification ID is entered in the format 9934:OIB
If GLN is used:
– EndpointID contains only the GLN
– PartyIdentification ID is entered with schemeID="0088"
Always verify correct population using our XML examples.
Items such as special hospitality taxes, returnable fees, or customs duties
are shown as document-level charges and no KPD code is entered.
If the invoice contains no other items (InvoiceLine),
such a charge must be shown as an InvoiceLine and the KPD code
closest to the actual nature of the charge must be used.
Documents of type credit note (381) and advance invoice (386) do not require KPD codes.
If you are creating a reversal of an advance payment,
you may use document ID 386 to avoid entering a KPD code.
Under the special VAT margin scheme, VAT is not shown on the invoice itself,
but is reported in a separate form submitted independently
(this obligation still exists and is not affected by the changes).
The invoice itself is not subject to VAT based on Article 5 of the VAT Act.
Accordingly, the eInvoice must contain:
– only one invoice line
– an exemption note
– tax category O
– cbc:Name = HR:O
If PPOM must also be shown, it is entered as a charge,
but it must also be in category O, since only category O
may exist on such an invoice.
The Copy Indicator is used only when correcting an already fiscalized invoice
without changing any amounts.
In this case, a new corrected invoice is sent with the same invoice number.
If the amount of a fiscalized invoice must be changed,
a reversal invoice must be created first, followed by a new invoice with the same number.
No.
Numeric fields (amounts, taxes, quantities) must not contain spaces,
blank characters, or text. Values must be entered strictly as numbers.
In that case, check the namespaces defined at the top of the XML document.
Namespaces must comply with the UBL 2.1 specification.
It is recommended to use the namespaces from our official XML examples,
as incorrect namespaces are a common cause of hidden validation errors.
Arbitrary KPD codes must not be used.
One of the officially defined KPD codes from the Croatian Tax Authority code list
must be used. If unsure, select the code that best matches
the actual service or goods.
The HR document extension is created only when the invoice contains items
that are not subject to VAT (e.g. exemptions, pass-through items, special taxes).
If the invoice contains exclusively VAT-taxable items,
the HR extension is not created.
Always follow our XML examples.