How to generate correct Peppol BIS 3.0 invoices from Czechia and Slovakia

The most common reason an invoice from a Czech or Slovak accounting system doesn’t come out right on the receiving end isn’t a malformed XML file - it’s a mismatch between how the source software models concepts like credit note, debit note or advance invoice, and how EN 16931 and Peppol BIS Billing 3.0 can express them. BIS 3.0 only has two document roots, Invoice and CreditNote, and a fixed invoice-type code list - so every local concept has to be mapped onto that correctly, or the amount the customer ends up owing comes out wrong.

Here’s exactly how we handle this on our access point, so integrators and accounting-software vendors can check their own implementation against it.

Invoice type codes: don’t send everything as “380”

BT-3 (cbc:InvoiceTypeCode, or cbc:CreditNoteTypeCode on a credit note) tells the receiver what kind of document this is. Czech and Slovak back-office systems distinguish more document types than usually make it onto invoices sent over Peppol - defaulting everything to 380 throws that distinction away.

One thing that regularly surprises integrators: BIS 3.0 has no DebitNote document type. A corrective document that increases the amount has to travel as an Invoice with code 384, referencing the original document through cac:BillingReference - not as a CreditNote with a negative amount, which several receiving systems will reject or misclassify outright.

Payment references: VS, KS and SS

Czech and Slovak banks and accounting software reconcile incoming payments using three symbols that have no dedicated field in UBL:

• VS (variable symbol) - identifies which document the payment settles, almost always the invoice number.
• KS (constant symbol) - a bank-assigned 4-digit code for the nature of the payment.
• SS (specific symbol) - a supplementary 10-digit reference; increasingly unsupported now that SEPA has no field for it, but still expected by some recipients.

EN 16931 defines BT-83 (cbc:PaymentID) as, literally, “a value used to establish a link between the payment and the invoice” - exactly what a bare VS is for. When VS is the only symbol, it belongs there directly, as a plain value, with no prefix and no cac:PaymentMeans/cbc:InstructionID:

1
2
3
4

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:PaymentID>176692026</cbc:PaymentID>
</cac:PaymentMeans>

We only reach for the structured VS:...;KS:...;SS:... encoding in InstructionID (with a human-readable VS.../KS.../SS... fallback in PaymentID too) once there’s more than one symbol to encode - in other words, as soon as KS or SS shows up:

1
2
3
4
5

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>42</cbc:PaymentMeansCode>
  <cbc:InstructionID>VS:176692026;KS:0008;SS:1234567890</cbc:InstructionID>
  <cbc:PaymentID>VS176692026/KS0008/SS1234567890</cbc:PaymentID>
</cac:PaymentMeans>

Omitting VS is the single most common reason a payment lands in the recipient’s account without ever being matched to the invoice that triggered it. The second most common is wrapping a lone VS in the VS: prefix and InstructionID anyway, even with no KS or SS around - to a generic (non-Czech/Slovak) recipient, that’s just noise in a field meant to hold a clean reference.

Advance payments and how they get deducted

The standard local workflow has three steps: an advance invoice (payment request, code 386, not a tax document) is issued, then on receiving payment a tax document on receipt of the advance (code 388) is issued - VAT becomes due within 15 days of receipt - and finally, on delivery, a final invoice is issued that must deduct every advance already taxed against it.

That deduction is BT-113, cbc:PrepaidAmount on cac:LegalMonetaryTotal, and it has to feed into cbc:PayableAmount using the standard formula (BR-CO-16):

PayableAmount = TaxInclusiveAmount − PrepaidAmount + PayableRoundingAmount

Example: goods worth 25,000 CZK + 21% VAT (30,250 CZK total). An advance of 10,000 CZK + VAT (12,100 CZK) was already taxed and paid. The final invoice must show:

1
2
3
4
5

<cac:LegalMonetaryTotal>
  <cbc:TaxInclusiveAmount currencyID="CZK">30250.00</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="CZK">12100.00</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="CZK">18150.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Skip PrepaidAmount and the invoice still validates cleanly against EN 16931 - it just tells the customer they owe the full 30,250 CZK again. If your source system tracks deposits (ISDOC does, in TaxedDeposits/NonTaxedDeposits), their total needs to be summed into BT-113 on every export, not just left as a document reference.

Credit note, or debit note?

Both are corrective documents, in opposite directions:

• A credit note (Czech: dobropis) reduces the amount owed - sent as CreditNote, code 381.
• A debit note (Czech: vrubopis) increases the amount owed - sent as Invoice, code 384, because BIS 3.0 has no DebitNote document root.

Both should carry cac:BillingReference pointing at the original document’s ID, so the receiving accounting system applies the correction to the right entry instead of treating it as a standalone document.

VAT Category Code and VATEX: why zero VAT isn’t enough

BT-118 (cbc:ID on cac:TaxCategory) is the legal regime of the supply - not how much VAT is on the invoice. A 0.00 VAT amount doesn’t by itself mean category Z: it could be an exempt supply (E), an intra-community supply (K), an export (G), a reverse charge (AE), or something outside the scope of VAT entirely (O). Category Z only applies where the law sets an actual zero rate.

For any category other than S or Z, you also need a reason - either a VATEX code (BT-121, cbc:TaxExemptionReasonCode) or free text (BT-120, cbc:TaxExemptionReason), or both. Finančná správa SR’s FAQ (August 2026) recommends using BT-121 as the primary field and BT-120 as supplementary explanatory text. The basic mapping for Slovak conditions:

VATEX is a European/Peppol code list, not a Slovak legislative one - not every provision of the VAT act has its own dedicated code. Where you’re not sure of the exact Article 132 reason, the generic VATEX-EU-132 is a safer choice than guessing a specific subcode.

Our ISDOC-to-BIS3 converter (and the reverse direction) now accounts for this: ISDOC has no VAT-category code list of its own, but it does carry two structured signals - LocalReverseCharge (a line under the domestic reverse-charge regime) and VATApplicable (a line outside the scope of VAT) - which now map correctly onto AE/O and their VATEX codes, instead of both silently collapsing into a standard rate or a generic “exempt.”

Slovakia: SK CIUS and the 1 January 2027 deadline

Slovakia’s Finančná správa SR layers a set of mandatory fields on top of EN 16931/BIS 3.0 (SK CIUS): tax point date (BT-7), payment due date (BT-9), seller’s legal registration ID and VAT ID (BT-30, BT-31), buyer’s VAT ID (BT-48), full addresses for both parties (BT-35/37/38, BT-50/52/53), the VAT rate (BT-119), and, for exempt supplies, the exemption reason (BT-120/121).

Peppol e-invoicing has been voluntary in Slovakia since Q2 2026, and becomes mandatory for all VAT payers from 1 January 2027, delivered through certified access points. We covered this in more detail in How Slovakia solved e-invoicing for us and in our FAQ on mandatory e-invoicing in Slovakia.

Summary

For invoices going to Czech or Slovak recipients, passing EN 16931 schema validation isn’t enough on its own - a document with the wrong type code, a missing advance-payment deduction, no VS, or the wrong VAT category will still validate. Checklist: corrective documents carry the right type (credit note as CreditNote/381, debit note as Invoice/384), advances are deducted via PrepaidAmount, payment symbols are encoded in PaymentID/InstructionID, the VAT category matches the actual legal regime (not just how much VAT is on the line) and carries the matching VATEX code, and Slovak-bound invoices carry every SK CIUS field. This is exactly what we check automatically when generating and validating invoices on our access point.

Sources: ISDOC - format specification, Finančná správa SR - e-invoicing, Peppol BIS Billing 3.0