[Feature Request] Add phive-rules-cius-sk — Slovak CIUS validation rules

[mariansbr]

Summary

We would like to propose adding a new module phive-rules-cius-sk for Slovak Country-Specific Implementation Specification (SK CIUS) validation rules, following the same pattern as phive-rules-cius-pt and phive-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-tdd library (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):

Rule ID	BT	UBL Element	Legal basis
SK-01	BT-7	TaxPointDate	§74/1/d zák. 222/2004
SK-02	BT-9	DueDate
SK-03	BT-30	Seller PartyLegalEntity/CompanyID
SK-04	BT-31	Seller PartyTaxScheme/CompanyID (VAT)	§74/1/b
SK-05	BT-35	Seller PostalAddress/StreetName	§74/1/a
SK-06	BT-37	Seller PostalAddress/CityName	§74/1/a
SK-07	BT-38	Seller PostalAddress/PostalZone	§74/1/a
SK-08	BT-48	Buyer PartyTaxScheme/CompanyID
SK-09	BT-50	Buyer PostalAddress/StreetName	§74/1/b
SK-10	BT-52	Buyer PostalAddress/CityName	§74/1/b
SK-11	BT-53	Buyer PostalAddress/PostalZone	§74/1/b
SK-12	BT-110	TaxTotal/TaxAmount
SK-13	BT-119	TaxCategory/Percent	§74/1/i

Conditional mandatory:

Rule ID	BT	Condition	Legal basis
SK-14	BT-120/121	When tax category is E/G/O/K/AE	§74/1/j
SK-15	BT-148	When price AllowanceCharge exists
SK-16	BT-64	When TaxRepresentativeParty exists	§74/1/a
SK-17	BT-66	When TaxRepresentativeParty exists	§74/1/a
SK-18	BT-67	When TaxRepresentativeParty exists	§74/1/a
SK-19	BT-25	For CreditNote type 381

What we provide

We have a ready-to-use Schematron file (SK-CIUS-v1.4.sch) with:

• Full ISO Schematron (queryBinding="xslt2")
• UBL 2.1 namespace support (Invoice + CreditNote)
• 7 patterns, 19 assertions
• Bilingual error messages (English with Slovak terms)
• Legal references to Slovak VAT law
• Unit tests (6 test cases, all passing with ph-schematron 9.1.1)

We are happy to contribute the .sch file, test XML samples, and help with the Maven module structure following the phive-rules-cius-pt pattern.

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!

[mariansbr]

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)

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

Test	Validates	Result
validSkInvoice_noErrors	Full SK invoice = 0 errors	PASS
missingTaxPointDate_SK01	Missing BT-7 + BT-9 triggers SK-01/SK-02	PASS
missingSellerAddress_SK05_SK06_SK07	Missing seller street/city/zip triggers SK-05/06/07	PASS
missingBuyerVat_SK08	Missing buyer VAT ID triggers SK-08	PASS
exemptWithoutReason_SK14	Exempt category E without reason triggers SK-14	PASS
testbedInvoice_detectsMissingTaxPointDate	Real SK testbed invoice triggers SK-01	PASS

Happy to prepare a full Maven module PR (phive-rules-cius-sk) if you'd like!

[phax]

Hello @mariansbr,
thanks for reaching out to me and proposing this addition. Also thanks for posting the SCH file - please keep it.

However, currently I am only adding rules that are provided by authoritative sources, to make sure they are governed properly.
To my understanding, as Slovakian invoicing format will be based on Peppol BIS 3 (and later BIS 4), I expect there to be official rules coming up.

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.

[mariansbr]

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!

[phax]

@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

[vrbyjimmy]

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..

[phax]

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

[mariansbr]

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 /api/validate endpoint so that C1 clients can see what's missing before sending — but again, it doesn't block the send.

We fully agree that the lack of a SK-specific document type (like XRechnung urn:cen.eu:en16931:2017#compliant#urn:xoev.de:kosit:xrechnung_3.0 in Germany) is the root issue. Without it, there's no way for the AP to know that SK-specific rules should apply to a given document.

Hopefully Finančná správa SR will address this in future iterations — either with a dedicated SK CustomizationID or by publishing official validation artifacts.

[phax]

@mariansbr our responses overlapped :)

[vrbyjimmy]

@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

[mariansbr]

Hi @vrbyjimmy

I reviewed your SK CIUS proposal — great work, embedding the rules directly into the BIS3 schematron is exactly the right
approach (same as NO, DK, IT national rules).

I found two issues:

1. XPath bug in SK-R-04 (line 518)

Currently:
cac:AccountingSupplierParty/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/cbc:CompanyID

Missing /cac:Party/ in the path. Since the context is at document level and PartyTaxScheme is nested under Party in UBL,
this rule would never match. Should be:
cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/cbc:CompanyID

2. SK-R-08 — Buyer VAT should be warning, not fatal

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
every buyer is a VAT payer (e.g. natural persons, non-taxable entities), so fatal would reject valid invoices.

A few more things to consider:

• Add BT references to assertion messages (e.g. [BT-7], [BT-9]) — the EN16931 validation does this too and it makes
  debugging easier
• Add legal references to Act 222/2004 — this strengthens the proposal towards SK Financial Administration
• CreditNote DueDate — consider allowing cbc:DueDate or cac:PaymentMeans/cbc:PaymentDueDate, since BT-9 can map to both
  locations in UBL

Other than that, the rules are identical to what we have on our side. Your approach with and not(element='') is actually
more thorough (catches empty elements).

[vrbyjimmy]

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