Replies: 11 comments
-
|
Here is the complete Schematron file ready to use. Tested with ph-schematron 9.1.1 (SchematronResourceSCH), all 6 unit tests passing. SK-CIUS-v1.4.sch<?xml version="1.0" encoding="UTF-8"?>
<!--
SK CIUS v1.4 — Slovak Country-Specific Rules for Peppol BIS Billing 3.0
Based on: Finančná správa SR, Peppol BIS3 v1.4 (February 2026)
Legal basis: Zákon 222/2004 Z.z. o DPH, Zákon 431/2002 Z.z. o účtovníctve
These rules enforce additional mandatory fields required by Slovak legislation
on top of the EN 16931 / Peppol BIS Billing 3.0 standard.
Applies to: UBL 2.1 Invoice and CreditNote
Author: MRP - Company spol. s r.o.
Version: 1.4.0
Date: 2026-03-11
-->
<schema xmlns="http://purl.oclc.org/dsdl/schematron"
queryBinding="xslt2"
schemaVersion="1.4.0">
<title>SK CIUS v1.4 — Validation rules for Slovak e-invoicing</title>
<ns prefix="ubl" uri="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"/>
<ns prefix="cn" uri="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"/>
<ns prefix="cac" uri="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"/>
<ns prefix="cbc" uri="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"/>
<phase id="SK-CIUS-model">
<active pattern="sk-cius-document"/>
<active pattern="sk-cius-seller"/>
<active pattern="sk-cius-buyer"/>
<active pattern="sk-cius-tax"/>
<active pattern="sk-cius-line"/>
<active pattern="sk-cius-tax-representative"/>
<active pattern="sk-cius-credit-note"/>
</phase>
<!-- Document-level mandatory fields -->
<pattern id="sk-cius-document">
<rule context="ubl:Invoice">
<assert id="SK-01" flag="fatal"
test="cbc:TaxPointDate">
[SK-01]-[BT-7] Tax point date (dátum zdaniteľného plnenia) is mandatory in SK CIUS
(§74 ods. 1 písm. d) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-02" flag="fatal"
test="cbc:DueDate">
[SK-02]-[BT-9] Payment due date (dátum splatnosti) is mandatory in SK CIUS.
</assert>
</rule>
<rule context="cn:CreditNote">
<assert id="SK-01" flag="fatal"
test="cbc:TaxPointDate">
[SK-01]-[BT-7] Tax point date (dátum zdaniteľného plnenia) is mandatory in SK CIUS
(§74 ods. 1 písm. d) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-02" flag="fatal"
test="cbc:DueDate or cac:PaymentMeans/cbc:PaymentDueDate">
[SK-02]-[BT-9] Payment due date (dátum splatnosti) is mandatory in SK CIUS.
</assert>
</rule>
</pattern>
<!-- Seller (AccountingSupplierParty) mandatory fields -->
<pattern id="sk-cius-seller">
<rule context="cac:AccountingSupplierParty/cac:Party">
<assert id="SK-03" flag="fatal"
test="cac:PartyLegalEntity/cbc:CompanyID">
[SK-03]-[BT-30] Seller legal registration identifier (IČO) is mandatory in SK CIUS.
</assert>
<assert id="SK-04" flag="fatal"
test="cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/cbc:CompanyID">
[SK-04]-[BT-31] Seller VAT identifier (IČ DPH) is mandatory in SK CIUS
(§74 ods. 1 písm. b) zákona 222/2004 Z.z.).
</assert>
</rule>
<rule context="cac:AccountingSupplierParty/cac:Party/cac:PostalAddress">
<assert id="SK-05" flag="fatal"
test="cbc:StreetName">
[SK-05]-[BT-35] Seller address line 1 (ulica) is mandatory in SK CIUS
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-06" flag="fatal"
test="cbc:CityName">
[SK-06]-[BT-37] Seller city (mesto) is mandatory in SK CIUS
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-07" flag="fatal"
test="cbc:PostalZone">
[SK-07]-[BT-38] Seller post code (PSČ) is mandatory in SK CIUS
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
</rule>
</pattern>
<!-- Buyer (AccountingCustomerParty) mandatory fields -->
<pattern id="sk-cius-buyer">
<rule context="cac:AccountingCustomerParty/cac:Party">
<assert id="SK-08" flag="fatal"
test="cac:PartyTaxScheme/cbc:CompanyID">
[SK-08]-[BT-48] Buyer VAT identifier (IČ DPH kupujúceho) is mandatory in SK CIUS.
</assert>
</rule>
<rule context="cac:AccountingCustomerParty/cac:Party/cac:PostalAddress">
<assert id="SK-09" flag="fatal"
test="cbc:StreetName">
[SK-09]-[BT-50] Buyer address line 1 (ulica kupujúceho) is mandatory in SK CIUS
(§74 ods. 1 písm. b) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-10" flag="fatal"
test="cbc:CityName">
[SK-10]-[BT-52] Buyer city (mesto kupujúceho) is mandatory in SK CIUS
(§74 ods. 1 písm. b) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-11" flag="fatal"
test="cbc:PostalZone">
[SK-11]-[BT-53] Buyer post code (PSČ kupujúceho) is mandatory in SK CIUS
(§74 ods. 1 písm. b) zákona 222/2004 Z.z.).
</assert>
</rule>
</pattern>
<!-- Tax-related mandatory fields -->
<pattern id="sk-cius-tax">
<rule context="(ubl:Invoice | cn:CreditNote)/cac:TaxTotal">
<assert id="SK-12" flag="fatal"
test="cbc:TaxAmount">
[SK-12]-[BT-110] Invoice total VAT amount (celková suma DPH) is mandatory in SK CIUS.
</assert>
</rule>
<rule context="cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory">
<assert id="SK-13" flag="fatal"
test="cbc:Percent">
[SK-13]-[BT-119] VAT category rate (sadzba DPH) is mandatory in SK CIUS
(§74 ods. 1 písm. i) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-14" flag="fatal"
test="not(cbc:ID = 'E' or cbc:ID = 'G' or cbc:ID = 'O' or cbc:ID = 'K' or cbc:ID = 'AE') or cbc:TaxExemptionReasonCode or cbc:TaxExemptionReason">
[SK-14]-[BT-120/BT-121] VAT exemption reason (dôvod oslobodenia od DPH) is mandatory
in SK CIUS when tax category is exempt (§74 ods. 1 písm. j) zákona 222/2004 Z.z.).
</assert>
</rule>
</pattern>
<!-- Invoice line mandatory fields -->
<pattern id="sk-cius-line">
<rule context="cac:InvoiceLine/cac:Price/cac:AllowanceCharge | cac:CreditNoteLine/cac:Price/cac:AllowanceCharge">
<assert id="SK-15" flag="fatal"
test="cbc:BaseAmount">
[SK-15]-[BT-148] Item gross price (cena za položku brutto) is mandatory in SK CIUS
when a price discount is applied.
</assert>
</rule>
</pattern>
<!-- Tax Representative (BG-11) conditional mandatory fields -->
<pattern id="sk-cius-tax-representative">
<rule context="(ubl:Invoice | cn:CreditNote)/cac:TaxRepresentativeParty/cac:PostalAddress">
<assert id="SK-16" flag="fatal"
test="cbc:StreetName">
[SK-16]-[BT-64] Tax representative address line 1 (ulica daňového zástupcu) is mandatory
in SK CIUS when tax representative (BG-11) is present
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-17" flag="fatal"
test="cbc:CityName">
[SK-17]-[BT-66] Tax representative city (mesto daňového zástupcu) is mandatory
in SK CIUS when tax representative (BG-11) is present
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
<assert id="SK-18" flag="fatal"
test="cbc:PostalZone">
[SK-18]-[BT-67] Tax representative post code (PSČ daňového zástupcu) is mandatory
in SK CIUS when tax representative (BG-11) is present
(§74 ods. 1 písm. a) zákona 222/2004 Z.z.).
</assert>
</rule>
</pattern>
<!-- CreditNote-specific rules -->
<pattern id="sk-cius-credit-note">
<rule context="cn:CreditNote[cbc:CreditNoteTypeCode = '381']">
<assert id="SK-19" flag="fatal"
test="cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID">
[SK-19]-[BT-25] Preceding invoice reference (referencia na pôvodnú faktúru) is mandatory
in SK CIUS for credit notes (type 381).
</assert>
</rule>
</pattern>
</schema>Valid SK Invoice test sample (should pass with 0 errors)<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>SK-TEST-001</cbc:ID>
<cbc:IssueDate>2026-03-11</cbc:IssueDate>
<cbc:DueDate>2026-04-11</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:TaxPointDate>2026-03-11</cbc:TaxPointDate>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>OBJ-2026-001</cbc:BuyerReference>
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0245">2020458836</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>Hlavna 1</cbc:StreetName>
<cbc:CityName>Bratislava</cbc:CityName>
<cbc:PostalZone>81101</cbc:PostalZone>
<cac:Country><cbc:IdentificationCode>SK</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>SK2020458836</cbc:CompanyID>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>MRP - Company spol. s r.o.</cbc:RegistrationName>
<cbc:CompanyID schemeID="0158">35697270</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0245">2020084055</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>Priemyselna 5</cbc:StreetName>
<cbc:CityName>Kosice</cbc:CityName>
<cbc:PostalZone>04001</cbc:PostalZone>
<cac:Country><cbc:IdentificationCode>SK</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>SK2020084055</cbc:CompanyID>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Testovacia firma s.r.o.</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">20.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="EUR">100.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="EUR">20.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">100.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">120.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="EUR">120.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Konzultacne sluzby</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount>
</cac:Price>
</cac:InvoiceLine>
</Invoice>Unit test results (ph-schematron 9.1.1, Java 17)
Happy to prepare a full Maven module PR ( |
Beta Was this translation helpful? Give feedback.
-
|
Hello @mariansbr, However, currently I am only adding rules that are provided by authoritative sources, to make sure they are governed properly. To resolve this situation, may I suggest that you reach out to your local Peppol Authority and see how you can make this an official release, that also contains the lower layers of CEN rules and Peppol rules. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick response and the clarification, @phax! That makes perfect sense — we fully understand the need for authoritative governance of validation rules. We will reach out to the Slovak Peppol Authority (Finančná správa SR / Ministry of Finance) to discuss making this an official release. The SK CIUS v1.4 specification is already published by them, but the Schematron implementation is not yet available as an official artifact. In the meantime, we'll keep using our Schematron standalone in our AP. Once we have progress with the authority, we'll update this issue. Thanks again for your excellent work on the Peppol ecosystem! |
Beta Was this translation helpful? Give feedback.
-
|
@mariansbr Thanks for your understanding and looking forward to the official rules. Most likely they will than be integrated into the phive-rules-peppol package |
Beta Was this translation helpful? Give feedback.
-
|
Hello @mariansbr, I am implementing same thing and to my understanding we cannot validate incoming documents against the SK specific rules, because they are BIS3 (meaning they are valid even tho they dont meet all the additional SK requirements as long as they pass all BIS3 validation)... This is the issue for SK FS, because they refuse to have their own document type based on bis3 with its own validation (similar to xrechnung in germany)... So all the validation specific for SK must be done by C1 and/or C4 directly... AP must validate based on document type specified on SBD and it Will be basic BIS3, nothing more.. |
Beta Was this translation helpful? Give feedback.
-
|
Peppol BIS Billing Schematrons have already today country specific rules that apply based on sender and/or receiver country code. So I assume the SK rules will be integrated as well. Search the current Schematron e.g. for "de" to see that all German rules are integrated already |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight @vrbyjimmy We came to the same conclusion during our implementation. Our AP validates incoming documents only against BIS 3.0 (Level 1 XSD + Level 2 Schematron) — this determines the MLS response (AP/RE). SK CIUS validation runs as non-blocking warnings only, intended for our C1/C4 business layer (logged but never causes MLS rejection). For outgoing documents, SK CIUS warnings are returned via our We fully agree that the lack of a SK-specific document type (like XRechnung Hopefully Finančná správa SR will address this in future iterations — either with a dedicated SK CustomizationID or by publishing official validation artifacts. |
Beta Was this translation helpful? Give feedback.
-
|
@mariansbr our responses overlapped :) |
Beta Was this translation helpful? Give feedback.
-
|
@mariansbr I created updated BIS3 schematron file based on original version of BIS3 and extended by SK specific rules based on your schematron. https://github.com/vrbyjimmy/peppol/blob/main/PEPPOL-EN16931-UBL-SK-PROPOSAL.sch lines 504-579, revision is highly appreciated! this can be used as a proposal for SK FS to be used and internally communicated with openpeppol to extend the standard... tho Im not quite sure which channels this should go through.. I will try to communicate this inside our company to be communicated to SK FS officials |
Beta Was this translation helpful? Give feedback.
-
|
Hi @vrbyjimmy I reviewed your SK CIUS proposal — great work, embedding the rules directly into the BIS3 schematron is exactly the right I found two issues:
Currently: Missing /cac:Party/ in the path. Since the context is at document level and PartyTaxScheme is nested under Party in UBL,
According to §74(1)(b) of Act 222/2004 on VAT, the buyer's VAT identifier is mandatory only if one has been assigned. Not A few more things to consider:
Other than that, the rules are identical to what we have on our side. Your approach with and not(element='') is actually |
Beta Was this translation helpful? Give feedback.
-
|
Thx for review @mariansbr, I did few itterations and corrections already, so the sch is actually valid and can be processed, lol latest change is here vrbyjimmy/peppol@d0e2600 and sch here https://github.com/vrbyjimmy/peppol/blob/main/PEPPOL-EN16931-UBL-SK-PROPOSAL.sch I will suggest to people in our company to bring this up on next meeting with FS SK, tho you are welcome to do the same |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
We would like to propose adding a new module
phive-rules-cius-skfor Slovak Country-Specific Implementation Specification (SK CIUS) validation rules, following the same pattern asphive-rules-cius-ptandphive-rules-cius-ro.Background
Slovakia joined Peppol in 2025 and has published its CIUS specification (SK CIUS v1.4, February 2026) through Finančná správa SR (Slovak Financial Administration). The specification defines additional mandatory fields on top of EN 16931 / Peppol BIS Billing 3.0, required by Slovak VAT law (Zákon 222/2004 Z.z. o DPH).
We are operating a Peppol Access Point for Slovakia and have already completed SK Testbed certification. We use the
peppol-sk-tddlibrary (v0.1.2) for Tax Data Document generation.SK CIUS Rules
We have created a Schematron file with 19 rules enforcing Slovak-specific cardinality constraints. The rules are based on the official specification published at:
https://www.financnasprava.sk/_img/pfsedit/Dokumenty_PFS/Podnikatelia/Dan_z_pridanej_hodnoty/efaktura/2026/2026.02.19_Peppol_Bis3_v1_4.xlsx
Unconditional mandatory (0..1 → 1..1):
Conditional mandatory:
What we provide
We have a ready-to-use Schematron file (
SK-CIUS-v1.4.sch) with:We are happy to contribute the
.schfile, test XML samples, and help with the Maven module structure following thephive-rules-cius-ptpattern.About us
MRP - Company spol. s r.o., operating Peppol Access Point for Slovakia (AP ID: PSK001029). We are already using several phax libraries in production: phase4 4.3.1, peppol-commons 12.3.11, peppol-sk-tdd 0.1.2, phive-rules-peppol 4.2.2.
Thank you for your excellent work on the Peppol ecosystem!
Beta Was this translation helpful? Give feedback.
All reactions