Jak generować poprawne faktury Peppol BIS 3.0 z Czech i Słowacji

Najczęstszy powód, dla którego faktura z czeskiego lub słowackiego systemu księgowego nie dociera do odbiorcy poprawnie, to nie błędny plik XML - to niedopasowanie między tym, jak system źródłowy opisuje pojęcia takie jak nota korygująca czy faktura zaliczkowa, a tym, jak potrafi je wyrazić norma EN 16931 i format Peppol BIS Billing 3.0. BIS 3.0 zna tylko dwa typy dokumentów, Invoice i CreditNote, oraz stałą listę kodów typu dokumentu - każde lokalne pojęcie trzeba więc poprawnie do nich dopasować, inaczej kwota, którą ma zapłacić klient, wyjdzie błędnie.

Poniżej dokładnie opisujemy, jak obsługujemy to na naszym punkcie dostępowym (access point), aby integratorzy i dostawcy oprogramowania księgowego mogli zweryfikować własną implementację.

Kody typów dokumentów: nie wysyłaj wszystkiego jako “380”

BT-3 (cbc:InvoiceTypeCode, a w przypadku noty korygującej cbc:CreditNoteTypeCode) informuje odbiorcę, z jakim dokumentem ma do czynienia. Czeskie i słowackie systemy księgowe rozróżniają więcej typów dokumentów, niż zwykle trafia na faktury wysyłane przez Peppol - wysyłanie wszystkiego domyślnie jako 380 gubi to rozróżnienie.

Jedna rzecz regularnie zaskakuje integratorów: BIS 3.0 nie ma osobnego typu dokumentu na notę korygującą zwiększającą kwotę. Taki dokument trzeba wysłać jako Invoice z kodem 384, z odwołaniem do dokumentu oryginalnego przez cac:BillingReference - a nie jako CreditNote z ujemną kwotą, co wiele systemów odbiorczych odrzuca lub błędnie interpretuje.

Referencje płatności: VS, KS i SS

Czeskie i słowackie banki oraz oprogramowanie księgowe kojarzą przychodzące płatności na podstawie trzech symboli, dla których UBL nie ma dedykowanego pola:

• VS (symbol zmienny) - identyfikuje, którego dokumentu dotyczy płatność, najczęściej numer faktury.
• KS (symbol stały) - czterocyfrowy kod nadawany przez bank, określający charakter płatności.
• SS (symbol specyficzny) - dodatkowa dziesięciocyfrowa referencja; coraz rzadziej obsługiwana, bo SEPA nie przewiduje dla niej pola, ale część odbiorców nadal jej oczekuje.

EN 16931 definiuje BT-83 (cbc:PaymentID) dosłownie jako “wartość łączącą płatność z fakturą” - czyli dokładnie to, do czego służy sam VS. Gdy VS jest jedynym symbolem, powinien więc trafić bezpośrednio tam, jako czysta wartość, bez prefiksu i bez cac:PaymentMeans/cbc:InstructionID:

1
2
3
4

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

Strukturalne kodowanie VS:...;KS:...;SS:... w InstructionID (z czytelną wersją zapasową VS.../KS.../SS... również w PaymentID) stosujemy tylko wtedy, gdy trzeba zakodować więcej niż jeden symbol - czyli od momentu, gdy pojawia się KS lub SS:

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>

Pominięcie VS to najczęstsza przyczyna, dla której płatność trafia na konto odbiorcy, ale nigdy nie zostaje dopasowana do faktury, która ją wywołała. Drugą najczęstszą jest opakowywanie samego VS w prefiks VS: i InstructionID, mimo że nie ma żadnego KS ani SS - dla ogólnego (nieczeskiego/niesłowackiego) odbiorcy to tylko szum w polu, które powinno zawierać czystą referencję.

Zaliczki i ich odliczanie

Typowy proces ma trzy kroki: sprzedawca wystawia fakturę zaliczkową (wezwanie do zapłaty, kod 386, nie jest dokumentem podatkowym), po otrzymaniu płatności wystawia dokument podatkowy z tytułu otrzymanej zaliczki (kod 388 - VAT trzeba rozliczyć w ciągu 15 dni od otrzymania płatności), a po dostawie wystawia fakturę końcową, która musi odliczyć każdą już opodatkowaną zaliczkę.

To odliczenie to pole BT-113, cbc:PrepaidAmount w cac:LegalMonetaryTotal, które musi zostać uwzględnione w cbc:PayableAmount zgodnie ze standardowym wzorem (BR-CO-16):

PayableAmount = TaxInclusiveAmount − PrepaidAmount + PayableRoundingAmount

Przykład: towar o wartości 25 000 CZK + 21% VAT (30 250 CZK łącznie). Na zaliczkę 10 000 CZK + VAT (12 100 CZK) wystawiono już i opłacono dokument podatkowy. Faktura końcowa musi wtedy zawierać:

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>

Bez PrepaidAmount faktura nadal przejdzie walidację EN 16931 bezbłędnie - tyle że każe klientowi zapłacić ponownie całe 30 250 CZK. Jeśli system źródłowy śledzi zaliczki (ISDOC robi to w elementach TaxedDeposits/NonTaxedDeposits), ich sumę trzeba uwzględnić w BT-113 przy każdym eksporcie, a nie tylko podać jako odwołanie do dokumentu.

Nota korygująca in minus czy in plus?

Oba to dokumenty korygujące, tylko w przeciwnych kierunkach:

• Nota in minus (po czesku: dobropis) zmniejsza kwotę należną - wysyłana jako CreditNote, kod 381.
• Nota in plus (po czesku: vrubopis) zwiększa kwotę należną - wysyłana jako Invoice, kod 384, ponieważ BIS 3.0 nie ma osobnego typu dokumentu DebitNote.

Obie powinny nieść cac:BillingReference wskazujący ID dokumentu oryginalnego, aby system księgowy odbiorcy przypisał korektę do właściwej pozycji, zamiast traktować ją jako samodzielny dokument.

VAT Category Code i VATEX: dlaczego samo 0% VAT nie wystarczy

BT-118 (cbc:ID w cac:TaxCategory) określa reżim prawny dostawy - nie to, ile VAT jest na fakturze. Kwota VAT równa 0,00 sama w sobie nie oznacza kategorii Z: może to być dostawa zwolniona (E), wewnątrzwspólnotowa dostawa towarów (K), eksport (G), odwrotne obciążenie (AE) albo transakcja w ogóle poza zakresem VAT (O). Kategorię Z stosuje się tylko tam, gdzie przepis rzeczywiście przewiduje stawkę zerową.

Dla każdej kategorii innej niż S i Z trzeba dodatkowo podać powód - kodem VATEX (BT-121, cbc:TaxExemptionReasonCode), tekstem (BT-120, cbc:TaxExemptionReason) albo oboma. FAQ Finančnej správy SR (sierpień 2026) zaleca używanie BT-121 jako pola podstawowego, a BT-120 jako tekstu uzupełniającego. Podstawowe mapowanie dla warunków słowackich:

VATEX to europejski/peppolowy słownik kodów, a nie słowacki słownik legislacyjny - nie każdy przepis ustawy o VAT ma więc własny dedykowany kod. Tam, gdzie dokładny powód w ramach art. 132 nie jest pewny, bezpieczniejszym wyborem jest ogólny kod VATEX-EU-132 niż zgadywanie konkretnego podkodu.

Nasz konwerter ISDOC↔BIS3 już to uwzględnia: ISDOC nie ma własnego słownika kategorii VAT, ale niesie dwa ustrukturyzowane sygnały - LocalReverseCharge (pozycja objęta krajowym odwrotnym obciążeniem) i VATApplicable (pozycja poza zakresem VAT) - które teraz poprawnie mapują się na AE/O i odpowiadający kod VATEX, zamiast po cichu trafiać do stawki podstawowej albo ogólnego “zwolnione”.

Słowacja: SK CIUS i termin 1 stycznia 2027

Słowacka Finančná správa SR definiuje ponad EN 16931/BIS 3.0 własny zestaw pól obowiązkowych (SK CIUS): datę powstania obowiązku podatkowego (BT-7), termin płatności (BT-9), numer rejestrowy i NIP UE sprzedawcy (BT-30, BT-31), NIP UE nabywcy (BT-48), pełne adresy obu stron (BT-35/37/38, BT-50/52/53), stawkę VAT (BT-119) oraz przy dostawach zwolnionych - powód zwolnienia (BT-120/121).

Fakturowanie elektroniczne przez Peppol jest na Słowacji dobrowolne od drugiego kwartału 2026, a od 1 stycznia 2027 staje się obowiązkowe dla wszystkich podatników VAT, dostarczane przez certyfikowane punkty dostępowe. Więcej pisaliśmy w artykułach Jak Słowacja rozwiązała za nas fakturowanie elektroniczne oraz najczęstsze pytania o obowiązkowe e-fakturowanie na Słowacji.

Podsumowanie

Dla faktur trafiających do czeskich i słowackich odbiorców sama walidacja schematu EN 16931 nie wystarcza - dokument z błędnym kodem typu, brakującym odliczeniem zaliczki, bez VS albo z błędną kategorią VAT nadal ją przejdzie. Lista kontrolna: dokumenty korygujące mają właściwy typ (nota in minus jako CreditNote/381, nota in plus jako Invoice/384), zaliczki są odliczane przez PrepaidAmount, symbole płatności są zakodowane w PaymentID/InstructionID, kategoria VAT odpowiada faktycznemu reżimowi prawnemu (a nie tylko wysokości VAT) i niesie odpowiedni kod VATEX, a faktury dla Słowacji zawierają wszystkie pola SK CIUS. Dokładnie to sprawdzamy automatycznie przy generowaniu i walidacji faktur na naszym punkcie dostępowym.

Źródła: ISDOC - specyfikacja formatu, Finančná správa SR - e-faktura, Peppol BIS Billing 3.0