Croatia eRačun Invoice (UBL)
Croatian eRačun invoice (UBL, HR CIUS 2025, Fiskalizacija 2.0)
A Croatian eRačun for Fiskalizacija 2.0, checked against the UBL 2.1 schema, the EN 16931 rules and the Croatian rules (HR-BR-*) published by the Tax Administration.
About
Since 1 January 2026, VAT-registered businesses in Croatia send and receive domestic invoices as eRačun, under Fiskalizacija 2.0. An eRačun follows EN 16931 with the Croatian CIUS and extensions (HR CIUS 2025), in UBL 2.1, and its data is reported to the Tax Administration.
The Croatian rules (HR-BR-*) check what Fiskalizacija 2.0 needs on top of EN 16931: the OIB of seller and buyer with its check digit, invoice numbers without spaces, the business process, the KPD classification of each line, Croatian tax categories and the fiscalisation data in the UBL extensions.
E-invoicing in Croatia: the rules in short and how to check an invoice →
Good to know
- Rules run only when the document matches the schema. Documents over 50 MB are checked against the schema only.
- The EN 16931 rules are the current release, as the Tax Administration's guide asks (the official CEN artefacts), followed by its HR-CIUS-EXT-EN16931-UBL rules, which include the KPD product classification and tax category name checks.
- The EN 16931 rules warn about data outside the EN 16931 model (UBL-CR-*), such as the UBL extensions that carry the Croatian fiscal data; those are warnings, not errors.
- The example is from the Tax Administration's eRačun examples (12.12.2025), with 2026 dates and a seller OIB with a valid check digit: as published, the examples are dated 2025 and use a placeholder OIB, which the current rules reject (HR-BR-40, HR-BR-9, HR-BR-53).
Files
14 files · 2.7 MB-
maindoc/UBL-Invoice-2.1.xsd main
-
common/UBL-CommonAggregateComponents-2.1.xsd
-
common/UBL-CommonBasicComponents-2.1.xsd
-
common/UBL-CommonExtensionComponents-2.1.xsd
-
common/UBL-QualifiedDataTypes-2.1.xsd
-
common/UBL-UnqualifiedDataTypes-2.1.xsd
-
common/UBL-ExtensionContentDataType-2.1.xsd
-
common/CCTS_CCT_SchemaModule-2.1.xsd
-
common/UBL-CommonSignatureComponents-2.1.xsd
-
common/UBL-SignatureAggregateComponents-2.1.xsd
-
common/UBL-SignatureBasicComponents-2.1.xsd
-
common/UBL-xmldsig-core-schema-2.1.xsd
-
common/UBL-XAdESv132-2.1.xsd
-
common/UBL-XAdESv141-2.1.xsd
The validator loads all of these with their folder structure, so includes and imports resolve as published.
Business rules
Schematron · run in this orderThe rules run after the schema check, only when the document matches the schema, and in your browser like the schema check (with SaxonJS by Saxonica). Each finding names its rule, such as BR-CO-15, and the line it points at; each rule has a page with what it checks.
Example document
hr-eracun-invoice.xml · 4.7 KB · passes the schema and the rules
In CI and from code
The same schema by its name, hr-eracun-invoice, through the API.
npx @xmlvalid/cli validate "**/*.xml" --schema hr-eracun-invoice- uses: xmlvalid/validate-action@v1
with:
files: "**/*.xml"
schema: hr-eracun-invoice
api-key: ${{ secrets.XMLVALID_API_KEY }}curl https://xmlvalid.com/api/v1/validations \
-H "Authorization: Bearer $XMLVALID_API_KEY" \
-F document={{ $schema->example ?? 'document.xml' }} -F schema=hr-eracun-invoiceFree accounts get 100 API validations a month. On Pro, a URL monitor can check a published document against this schema every hour and email you when it breaks. More CI setups