Hogyan állítsunk elő helyes Peppol BIS 3.0 számlákat Csehországból és Szlovákiából

A leggyakoribb ok, amiért egy cseh vagy szlovák könyvelőrendszerből érkező számla a fogadó oldalon nem megfelelően érkezik meg, nem egy hibás XML-fájl - hanem az, hogy a forrásrendszer olyan fogalmakat használ, mint a jóváíró vagy terhelő bizonylat, illetve az előlegszámla, amelyeket az EN 16931 szabvány és a Peppol BIS Billing 3.0 formátum másképp fejez ki. A BIS 3.0 csak két dokumentumtípust ismer, az Invoice-t és a CreditNote-ot, valamint egy rögzített bizonylattípus-kódlistát - minden helyi fogalmat erre kell helyesen leképezni, különben a vevő által fizetendő végösszeg hibás lesz.

Az alábbiakban pontosan bemutatjuk, hogyan kezeljük ezt a saját access pointunkon, hogy az integrátorok és a könyvelőszoftver-fejlesztők össze tudják vetni vele a saját megvalósításukat.

Bizonylattípus-kódok: ne mindent “380”-ként küldjön

A BT-3 mező (cbc:InvoiceTypeCode, jóváíró bizonylat esetén cbc:CreditNoteTypeCode) mondja meg a fogadónak, milyen bizonylatról van szó. A cseh és szlovák háttérrendszerek több bizonylattípust különböztetnek meg, mint amennyi a Peppolon keresztül küldött számlákon jellemzően megjelenik - ha minden alapértelmezetten 380-as kóddal megy ki, ez a megkülönböztetés elvész.

Egy dolog rendszeresen meglepi az integrátorokat: a BIS 3.0-nak nincs saját DebitNote dokumentumtípusa. Az összeget növelő helyesbítő bizonylatot Invoice-ként, 384-es kóddal kell küldeni, az eredeti bizonylatra a cac:BillingReference mezőn keresztül hivatkozva - nem pedig negatív összegű CreditNote-ként, amit több fogadórendszer elutasít vagy hibásan dolgoz fel.

Fizetési azonosítók: VS, KS és SS

A cseh és szlovák bankok, valamint a könyvelőszoftverek három azonosító alapján párosítják a beérkező fizetéseket, amelyekhez az UBL-ben nincs külön mező:

• VS (variabilis szimbólum) - azonosítja, melyik bizonylathoz tartozik a fizetés, jellemzően a számlaszám.
• KS (konstans szimbólum) - egy négyjegyű, banki oldalon meghatározott kód a fizetés jellegére.
• SS (specifikus szimbólum) - egy kiegészítő, tízjegyű azonosító; a bankok egyre kevésbé támogatják (a SEPA-ban nincs rá mező), de egyes fogadók még mindig elvárják.

Az EN 16931 a BT-83 mezőt (cbc:PaymentID) szó szerint úgy határozza meg, mint “a fizetést a számlával összekapcsoló érték” - pontosan ez a szerepe egy önálló VS-nek is. Ha VS az egyetlen azonosító, akkor közvetlenül ide kerül, tiszta értékként, előtag és cac:PaymentMeans/cbc:InstructionID nélkül:

1
2
3
4

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

A VS:...;KS:...;SS:... strukturált kódolást az InstructionID mezőben (és olvasható visszaesésként a PaymentID mezőben VS.../KS.../SS... formában) csak akkor használjuk, ha egynél több azonosítót kell egyszerre kódolni - tehát amint megjelenik a KS vagy az 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>

A VS elhagyása a leggyakoribb oka annak, hogy egy fizetés megérkezik ugyan a fogadó számlájára, de sosem párosul össze a kiváltó számlával. A második leggyakoribb hiba, hogy egy önálló VS-t is becsomagolnak a VS: előtagba és az InstructionID mezőbe, noha nincs jelen sem KS, sem SS - egy általános (nem cseh/szlovák) fogadó számára ez csak felesleges zaj egy olyan mezőben, amelynek tiszta hivatkozást kellene tartalmaznia.

Előlegek és azok levonása

A szokásos folyamat három lépésből áll: az eladó kiállít egy előlegszámlát (fizetési felszólítás, 386-os kód, nem adóügyi bizonylat), a fizetés beérkezésekor kiállítja az előleg átvételéről szóló adóügyi bizonylatot (388-as kód - az áfát a fizetés beérkezésétől számított 15 napon belül kell megállapítani), majd a teljesítéskor kiállítja a végszámlát, amelynek le kell vonnia minden már megadóztatott előleget.

Ez a levonás a BT-113 mező, a cac:LegalMonetaryTotal blokkban szereplő cbc:PrepaidAmount, amelynek a szabványos képlet (BR-CO-16) szerint be kell épülnie a cbc:PayableAmount mezőbe:

PayableAmount = TaxInclusiveAmount − PrepaidAmount + PayableRoundingAmount

Példa: 25 000 CZK értékű áru + 21% áfa (összesen 30 250 CZK). Egy 10 000 CZK + áfa (12 100 CZK) összegű előlegre már kiállították és megfizették az adóügyi bizonylatot. A végszámlának ekkor a következőt kell tartalmaznia:

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>

PrepaidAmount nélkül a számla még mindig hibátlanul megfelel az EN 16931 validációnak - csak épp a teljes 30 250 CZK-t kéri ismét a vevőtől. Ha a forrásrendszer nyilvántartja az előlegeket (az ISDOC ezt a TaxedDeposits/NonTaxedDeposits elemekben teszi), akkor ezek összegét minden exportnál be kell számítani a BT-113 mezőbe, nem elég csupán bizonylathivatkozásként feltüntetni.

Jóváíró vagy terhelő bizonylat?

Mindkettő helyesbítő bizonylat, csak ellentétes irányban:

• A jóváíró bizonylat (csehül: dobropis) csökkenti a fizetendő összeget - CreditNote-ként, 381-es kóddal kell küldeni.
• A terhelő bizonylat (csehül: vrubopis) növeli a fizetendő összeget - Invoice-ként, 384-es kóddal kell küldeni, mivel a BIS 3.0-nak nincs DebitNote dokumentumtípusa.

Mindkettőnek tartalmaznia kell a cac:BillingReference mezőt, amely az eredeti bizonylat azonosítójára mutat, hogy a fogadó könyvelőrendszere a helyes tételhez tudja rendelni a helyesbítést, ne pedig önálló bizonylatként kezelje.

VAT Category Code és VATEX: miért nem elég a 0%-os áfa

A BT-118 (cbc:ID a cac:TaxCategory mezőben) a teljesítés jogi rezsimjét határozza meg - nem azt, mennyi áfa szerepel a számlán. A 0,00-ás áfaösszeg önmagában nem jelenti a Z kategóriát: lehet adómentes értékesítés (E), Közösségen belüli értékesítés (K), export (G), fordított adózás (AE), vagy egyáltalán áfa hatályán kívüli ügylet (O). A Z kategória csak ott alkalmazható, ahol a jogszabály ténylegesen nulla kulcsot ír elő.

Az S és Z kategórián kívül minden esetben meg kell adni az indokot is - VATEX kóddal (BT-121, cbc:TaxExemptionReasonCode), szöveggel (BT-120, cbc:TaxExemptionReason), vagy mindkettővel. A szlovák Finančná správa SR GYIK-je (2026 augusztus) elsődlegesen a BT-121 használatát javasolja, a BT-120-at pedig kiegészítő magyarázó szövegként. Az alapvető megfeleltetés szlovák viszonylatban:

A VATEX egy európai/Peppol kódlista, nem szlovák jogszabályi kódlista - ezért nem minden áfatörvényi rendelkezéshez tartozik saját, dedikált kód. Ahol a 132. cikken belüli pontos indok nem egyértelmű, biztonságosabb az általános VATEX-EU-132 kódot használni, mint egy konkrét alkódot találgatni.

Az ISDOC↔BIS3 konverterünk ezt már figyelembe veszi: az ISDOC-nak nincs saját áfakategória-kódlistája, de van két strukturált jelzése - a LocalReverseCharge (belföldi fordított adózás alá eső tétel) és a VATApplicable (áfa hatályán kívüli tétel) -, amelyek most helyesen képződnek le AE/O kategóriára és a megfelelő VATEX kódra, ahelyett hogy mindkettő csendben normál kulcsként vagy általános “adómentesként” végezné.

Szlovákia: SK CIUS és a 2027. január 1-jei határidő

A szlovák Finančná správa SR az EN 16931/BIS 3.0 fölé saját kötelező mezőket ír elő (SK CIUS): az adófizetési kötelezettség keletkezésének dátuma (BT-7), a fizetési határidő (BT-9), az eladó cégjegyzékszáma és közösségi adószáma (BT-30, BT-31), a vevő közösségi adószáma (BT-48), mindkét fél teljes címe (BT-35/37/38, BT-50/52/53), az áfakulcs (BT-119), valamint adómentes ügyleteknél a mentesség indoka (BT-120/121).

A Peppol-alapú elektronikus számlázás Szlovákiában 2026 második negyedéve óta önkéntes, és 2027. január 1-jétől kötelező lesz minden áfaalany számára, tanúsított access pointokon keresztül. Bővebben írtunk erről a Hogyan oldotta meg Szlovákia helyettünk az e-számlázást és a kötelező szlovák e-számlázással kapcsolatos gyakori kérdések című cikkeinkben.

Összefoglalás

A cseh vagy szlovák fogadóknak szóló számláknál önmagában az EN 16931 séma szerinti érvényesség nem elég - egy hibás típuskódú, hiányzó előleglevonású, VS nélküli vagy hibás áfakategóriájú bizonylat is érvényesnek minősül. Ellenőrzőlista: a helyesbítő bizonylatok a megfelelő típussal rendelkeznek (jóváíró bizonylat CreditNote/381, terhelő bizonylat Invoice/384), az előlegeket a PrepaidAmount mezővel vonják le, a fizetési azonosítók szerepelnek a PaymentID/InstructionID mezőkben, az áfakategória a tényleges jogi rezsimnek felel meg (nem csupán az áfa mértékének) és a megfelelő VATEX kódot viseli, a szlovák számlák pedig tartalmazzák az összes SK CIUS mezőt. Pontosan ezt ellenőrizzük automatikusan a számlák előállításakor és validálásakor a saját access pointunkon.

Források: ISDOC - formátumspecifikáció, Finančná správa SR - e-számlázás, Peppol BIS Billing 3.0