Fawtara e-számlázás Ománban 2027-ben: mire van szüksége az egyedi ERP- és pénztárrendszereknek

Omán a papír- és PDF-számlákat strukturált XML e-számlákra cseréli, amelyek egy akkreditált szolgáltatón haladnak át, és amelyeket jelentenek az ománi adóhatóságnak (Oman Tax Authority, OTA). A program neve Fawtara. Az évi 5 millió OMR feletti értékesítéssel rendelkező adózók 2027. április 1-jén kezdenek. Minden más áfaregisztrált adózó 2027. október 1-jén.

A kiskereskedelmet sújtja a legjobban. A fogyasztói értékesítés ugyanattól a naptól tartozik a hatály alá, mint az üzleti, és minden egyes értékesítéshez saját e-számla kell. Ha a pénztárszoftvere, az ERP-je vagy a számlázómotorja házon belül készült, vagy erősen testre szabták, ezeknek a dokumentumoknak az előállítása az Ön feladata.

A dátumok, és hogy melyik vonatkozik Önre

A forrás az OTA Fawtara GYIK-ja, amelyet utoljára 2026. augusztus 31-én frissítettek. A feltételt egyértelműen rögzíti. 2027. április 1-jétől kell bevezetnie, ha az alábbiak bármelyike teljesül:

• a 2026. április 1. és 2027. március 31. közötti értékesítései meghaladják az 5 000 000 OMR-t, vagy
• a 2027. április 1. és 2028. március 31. közötti várható értékesítései meghaladják az 5 000 000 OMR-t.

„Ha egyik sem teljesül, 2027. október 1-jétől kell bevezetnie az e-számlázást.”

Mi számít bele az összegbe: az adóköteles értékesítések, a tárgyi eszközök, a fordított adózás alá tartozó termékek és szolgáltatások, valamint a GCC-n belüli ügyletek nélkül. A csoportos áfaalanyt csoportszinten értékelik, nem tagonként. A nem belföldi illetőségű adózónál csak az Ománban teljesített értékesítések számítanak.

Figyeljen a második feltételre. Egy 5 millió OMR felé növekvő vállalkozás pusztán az előrejelzése alapján is az áprilisi körbe kerülhet. Ha közel van a határhoz, számoljon az áprilissal.

Az OTA egy bevezetési ellenőrző eszközt üzemeltet, amely a VATIN-je, valamint a jelenlegi és várható értékesítési sávja alapján megmutat egy lehetséges bevezetési időszakot. Kifejezetten csak tájékoztatási és felkészülési célra szolgál, ezért a válaszát kezelje iránymutatásként, a szabály pedig a GYIK.

Az ütemterv már egyszer elmozdult

Az OTA saját HTML-es GYIK-oldala még a korábbi tervet írja le: száz nagyvállalat 2026 augusztusától, minden nagyvállalat 2027 februárjától, mindenki más 2027 augusztusától. A PDF ezeket a dátumokat 2027 áprilisára és októberére cseréli. A kiválasztott nagy adózók első csoportjára (Rollout 1) 2026 augusztusa marad a hivatalos éles indulási dátum, egy pilot keretében 2026. október végéig tartó türelmi idővel.

A PDF ütemtervről szóló részének egyik mondata szerint az 5 millió OMR feletti kötelező megfelelés „April 1st 2026”, azaz 2026. április 1. óta hatályos. Ugyanebben a dokumentumban minden más 2027. április 1-jét mond, a fent idézett részletes hatályra vonatkozó választ is beleértve. Elírásnak tűnik, de jó ok arra, hogy az elsődleges dokumentumból dolgozzon, ne bárki összefoglalójából, a miénket is beleértve.

Hogyan működik a Fawtara

A Fawtara a Peppolon fut, ötsarkú modellel:

1. 1. sarok: Ön, az eladó, kiállítja a számlát.
2. 2. sarok: az akkreditált szolgáltatója (ASP) validálja az ománi szabályok szerint, és továbbítja.
3. 3. sarok: a vevő szolgáltatója fogadja.
4. 4. sarok: a vevő.
5. 5. sarok: az OTA, amely a szolgáltatóktól megkapja az adóadatokat.

A formátum XML, az OpenPeppol által közzétett PINT Oman specifikációk szerint felépítve (e cikk írásakor a Billing Process 1.0.1-es verziója). A GYIK egyértelműen kimondja: „A PDF-számla nem e-számla.” Papírt továbbra is nyomtathat, de adózási szempontból csak az e-számla érvényes számla.

A GYIK három részlete alakítja a fejlesztést:

• A szolgáltató validál, a felelősség Önnél marad. Az ASP minden számlát ellenőriz az ománi Schematron-szabályok szerint, de „a számla megfelelőségéért a felelősség az adózóknál marad”.
• Egyszerre egy szolgáltatóhoz kapcsolódik. A kapcsolatot a Fawtara portálon keresztül kéri, és később válthat.
• Nincs szabványos adózói API. A GYIK szavaival egy adózó bekötése „nem szabványosított, és a szolgáltató rendszerétől függően eltérő lesz”. Az ERP-je a szolgáltatója interfészével kommunikál, nem az OTA-val.

Ha a vevő fogyasztó vagy olyan vállalkozás, amely még nincs a hálózaton, a szolgáltatója ugyanúgy jelenti az adóadatokat az OTA-nak, az ügyfél pedig ugyanúgy kapja meg a számlát, mint ma. Az export Öntől a szolgáltatójához, onnan az OTA-hoz megy.

Kire vonatkozik már a megoldás

Ha az ERP- vagy pénztárrendszere szállítója maga is akkreditált szolgáltató, vagy csatlakozót szállít egyhez, a cikk nagy része nem az Ön problémája. A GYIK szerint az ERP-rendszerek „megtarthatók az adózók és akkreditált szolgáltatóik közötti megállapodás alapján”, és dobozos rendszernél ezt a megállapodást a szállítónak kell teljesítenie. Az Ön munkája a törzsadatok és a tesztelés.

Saját maga is szolgáltatóvá válhat. Az akkreditációs feltételek között szerepel az informatikai tevékenységet tartalmazó ománi cégjegyzékbejegyzés, egy minimális befizetett tőke, működési előzmények és az ISO/IEC 27001 tanúsítás, a GYIK pedig hozzáteszi a Peppol eDelivery és a PINT OM tesztcsomagok sikeres teljesítését. Ez szoftvercégeknek való. Kiskereskedőnek nem rövidítés.

Ez a cikk mindenki másnak szól: azoknak a cégeknek, amelyek számlái egyedi ERP-ből, házon belüli pénztárrendszerből, egy régi adatbázisra csavarozott számlázómotorból vagy olyan fióktelepről jönnek, ahol még kézzel írják a számlákat.

Mit kell megváltoztatni a szoftverében

Képezze le a számlaadatait a PINT Omanra

A GYIK leképezésre vonatkozó útmutatása egyetlen sor: használja az ománi PINT specifikációkat. A szemantikai modellben az Omán-specifikus mezőkre (BTOM előtaggal) megy a munka nagy része:

• UUID minden dokumentumhoz (BTOM-002). Az RFC 4122 5-ös verziójának kell lennie, amely névalapú. Származtassa valami stabilból, például a jogi személyből, a fióktelepből, a pénztárból és a dokumentumszámból, és egy újraküldött beadvány ugyanazt az UUID-t állítja elő, nem egy második számlát.
• Számla-ügylettípus (BTOM-001). Ez egy 20 pozíciós karakterlánc, ahol minden pozíció egy jelző: teljes adószámla, egyszerűsített adószámla, önszámlázás, harmadik fél, export, értékesítésnek tekintett ügylet, szolgáltatásimport fordított adózással, különbözeti adózás, e-kereskedelem, termékimport, különleges övezetbeli értékesítés, előleg és mások. Egyszerre több jelző is beállítható. A rendszerének tudnia kell, melyik vonatkozik az egyes számlákra, és a legtöbb ERP ezt soha nem tárolta.
• Az eladó és a vevő azonosítói sémakóddal: cégjegyzékszám, adóazonosító szám, személyi azonosító, útlevél, importőri vámazonosító vagy különleges övezeti engedélyszám.
• Pénznem. A számla pénzneme, az áfaelszámolás pénzneme, a kettő közötti árfolyam és az áfa végösszege az elszámolási pénznemben mind saját mezővel rendelkezik.
• Kódlisták az áfamentességhez, a nulla kulcs indokaihoz, a szolgáltatástípusokhoz és az országon belüli közigazgatási egységekhez.

Számítson arra, hogy a számlasorok tisztán leképezhetők lesznek, a törzsadatok viszont nem. A VATIN nélküli ügyfélrekordokat, a hiányzó cégjegyzékszámokat, a szabad szöveges mentességi indokokat és a régiókód nélküli címeket mind rendbe kell tenni az első éles számla előtt.

Minden értékesítés egy dokumentum

Ez az a szabály, amely megváltoztatja a pénztárrendszereket: „B2C ügyleteknél összesítő számla nem megengedett. Minden számlához külön e-számlát kell kiállítani.” Nincs napzárási összesítő. Egy bolt, amely naponta 3000 értékesítést üt be, naponta 3000 e-számlát küld.

A GYIK a B2C beadványokra 24 órát, a B2B beadványokra valós idejű küldést ír elő. Egy pénztárnál ez a következőt jelenti:

• A pénztár az értékesítés pillanatában előállítja az XML-t (vagy átadja az értékesítést egy szolgáltatásnak, amely ezt megteszi), az UUID-jével együtt. B2C esetén külön nyugta-UUID mező van (BTOM-004).
• Egy tárolás-és-továbbítás (store-and-forward) sor megtartja a dokumentumokat, amikor a hálózat vagy a szolgáltató nem elérhető, és a 24 órán belül kiüríti őket.
• Valaki riasztást kap, ha egy dokumentum néhány óra után még mindig nincs elküldve, nem huszonhárom óra után.

Aláírás előtt vesse össze a szolgáltató árazását a volumenével. A GYIK szerint minden szolgáltató maga határozza meg a modelljét, amely „tartalmazhat előfizetési díjakat, tranzakcióalapú díjakat vagy más árazási megoldásokat”. Kiskereskedelmi volumeneknél a dokumentumonkénti díj külön sor a költségvetésben.

B2B valós időben

Üzleti számláknál a beküldés valós idejű. Az ERP feladja a számlát, a szolgáltató validálja, és visszajön az eredmény. Ez kétféleképpen változtatja meg a számlázási folyamatot. A validációs hibák mostantól a feladás pillanatában jönnek elő, így a pénzügyön valakinek szüksége van egy képernyőre, amely megmutatja az elutasítást, és lehetővé teszi a javítást. A számlaszámozásnak, az UUID-nek és az újrapróbálkozási logikának pedig az első naptól helyesnek kell lennie, mert egy időtúllépés utáni vakon újraküldés így hoz létre duplikált számlákat.

A folyamat a másik irányba is fut. Amikor Ön a vevő, a már Fawtarán lévő cégek beszállítói e-számlái XML-ként érkeznek a szolgáltatóján keresztül, és a szállítói könyvelésnek kell egy módszer a befogadásukra.

QR-kód a nyomtatott nyugtán

A QR-kódot Ön (az 1. sarok) állítja elő, nem a szolgáltató. Minden B2C ügyletnél kötelező, legyen az teljes vagy egyszerűsített, és az ember által olvasható számlán jelenik meg, nem az XML-ben. Az OTA azt tervezi, hogy egy mobilalkalmazással ennek alapján ellenőrzi a számlákat. A tartalmához a GYIK a Peppol Oman Architecture dokumentum (1.0.2-es verzió) D függelékére utal: szerezze be ezt a függeléket, mielőtt bárki újratervez egy nyugtát. A nyugtasablonok és a nyomtatóillesztők is ennek a projektnek a részei.

Jóváíró számlák, visszárúk és helyesbítések

A kiállított e-számlát elektronikus jóváíró vagy terhelő számla kiállításával lehet módosítani. A specifikációban mezők vannak az eredeti számla UUID-jéhez és egy okkódhoz (BTOM-031 és BTOM-032), így a pénztárnál történő visszatérítésnek meg kell tudnia találni az eredeti értékesítést.

Import és önszámlázás

A termék- és szolgáltatásimportot önszámlázással kiállított számlaként jelentik. Ha a beszerzési folyamata dokumentum kiállítása nélkül könyveli az importot, ott egy új lépés jelenik meg.

Archiválás

A tárolás Önnél marad. A GYIK szerint az OTA nem adja vissza a számlaadatokat az adózóknak, a Peppol pedig nem tárol dokumentumokat. A validált XML-t, a szolgáltató válaszát és a nyomtatott változatot tartsa együtt, az áfajogszabályok megőrzési szabályai szerint.

Terv a határidőtől visszafelé

A GYIK szerint az OTA legalább hat hónappal a bevezetésük előtt megkeresi a bevezetésben részt vevőket. Az áprilisi kör számára ez most van.

Ha 2027. április 1-jén kezd:

1. 2026. október: a bevezetési ellenőrzővel és a GYIK feltételével erősítse meg, melyik körbe tartozik. Vegye számba az összes rendszert, amely számlát állít ki: ERP, minden pénztár, webáruházi fizetés, bérleti vagy előfizetéses számlázás, és minden kézi számlatömb.
2. 2026. november: válasszon szolgáltatót. Aláírás előtt kérjen API-dokumentációt és tesztkörnyezetet, és kérdezzen rá a B2C volumenre, a dokumentumonkénti árazásra, az offline kezelésre és arra, hogyan néznek ki a validációs válaszok. Kérje a kapcsolatot a Fawtara portálon keresztül.
3. 2026. december és 2027. január között: fejlesztés. Mezőleképezés, UUID-előállítás, ügylettípus-logika, a pénztári sor, QR-kódok, jóváírási folyamat, bejövő számlák. Futtassa a PINT Oman letöltések ománi Schematron-szabályait a saját tesztfolyamatában, hogy a hibák a fejlesztés során jöjjenek elő, ne a szolgáltatónál.
4. 2027. február: teljes körű tesztek a szolgáltató tesztkörnyezetével, valódi mintákkal minden ténylegesen kiállított ügylettípusból, a kényelmetlenebbeket is beleértve (export, nyugta nélküli visszárú, deviza).
5. 2027. március: éles főpróba egy fióktelepen vagy üzletágban, átállási terv és ügyeleti beosztás az első hetekre.

Ha 2027. október 1-jén kezd, a sorrend ugyanaz, hat hónappal eltolva: szolgáltató kiválasztva az első negyedév végéig, fejlesztés a másodikban, tesztelés augusztusra befejezve. Ne élje fel a tartalékot. Az adattisztítás mindig tovább tart, mint bárki becsüli.

Mi bizonytalan még

A dátumok egyszer már elmozdultak, és újra elmozdulhatnak. A 2026. augusztus 31-i PDF-hez igazítsa a tervét, és havonta nézze meg az OTA dokumentumait, ahelyett hogy a sajtóhírekre hagyatkozna. A jogalap a 189/2026. számú határozat, amely az áfatörvény végrehajtási rendeletét módosítja. A GYIK szerint a kötelezettség indulásától az áfajogszabályok szerinti bírságok alkalmazandók, összegeket azonban nem sorol fel, így mi sem.

A specifikációk is verziózottak. A Peppol oldalán elérhető aktuális PINT Oman csomag kiadási dátuma 2026. július 29. Rögzítse a verziót, amelyre fejleszt, és kövesse a kiadási megjegyzéseket.

Hol kaphat segítséget

Megépítjük a csatlakozót a ténylegesen futtatott rendszere és a kötelezettség által megkövetelt formátum között: a mezőleképezést, az UUID- és számozási logikát, a pénztári sorokat, a validálást a fejlesztési folyamatában és az integrációt a választott szolgáltatóval. Az e-számlázási integrációs szolgáltatásunk fedi le ezt a munkát, és ha maga az ERP az akadály, az ERP-modernizáció a kiindulópont.

Ha az áprilisi körbe tartozik, és még nem választott szolgáltatót, írjon az office@c9group.dev címre.