Omano Fawtara e. sąskaitos faktūros 2027 m.: ko reikia individualioms ERP ir POS sistemoms

Omanas popierines ir PDF sąskaitas faktūras keičia struktūrizuotomis XML e. sąskaitomis faktūromis, kurios keliauja per akredituotą paslaugų teikėją ir pateikiamos Omano mokesčių institucijai (Oman Tax Authority, OTA). Programa vadinasi Fawtara. Mokesčių mokėtojai, kurių metinis tiekimas viršija 5 mln. OMR, pradeda 2027 m. balandžio 1 d. Visi kiti PVM mokėtojai pradeda 2027 m. spalio 1 d.

Labiausiai tai paliečia mažmeninę prekybą. Pardavimai vartotojams įtraukiami nuo tos pačios dienos kaip ir pardavimai įmonėms, o kiekvienam atskiram pardavimui reikia atskiros e. sąskaitos faktūros. Jei jūsų kasos programa, ERP ar sąskaitų išrašymo sistema sukurta savo jėgomis arba stipriai pritaikyta, šių dokumentų rengimo darbas tenka jums.

Datos ir kuri iš jų taikoma jums

Šaltinis yra OTA Fawtara DUK, paskutinį kartą atnaujinti 2026 m. rugpjūčio 31 d. Kriterijus nurodytas aiškiai. Diegti nuo 2027 m. balandžio 1 d. privalote, jei tenkinama bent viena sąlyga:

• jūsų tiekimas nuo 2026 m. balandžio 1 d. iki 2027 m. kovo 31 d. viršija 5 000 000 OMR, arba
• jūsų tikėtinas tiekimas nuo 2027 m. balandžio 1 d. iki 2028 m. kovo 31 d. viršija 5 000 000 OMR.

„If neither is met, you are required to implement e-invoicing from 1 October 2027.“

Kas įskaičiuojama į sumą: apmokestinamas tiekimas, išskyrus ilgalaikį turtą, prekes ir paslaugas, kurioms taikomas atvirkštinio apmokestinimo mechanizmas, ir tiekimą Persijos įlankos bendradarbiavimo tarybos (GCC) šalyse. PVM grupė vertinama grupės lygiu, o ne pagal kiekvieną narį atskirai. Nerezidentas skaičiuoja tik Omane atliktą tiekimą.

Atkreipkite dėmesį į antrąją sąlygą. Įmonė, artėjanti prie 5 mln. OMR, gali patekti į balandžio grupę vien dėl savo prognozės. Jei esate arti ribos, laikykite, kad jums taikomas balandis.

OTA turi diegimo etapo tikrinimo įrankį, kuris pagal jūsų PVM mokėtojo kodą (VATIN) ir dabartinio bei tikėtino tiekimo intervalą parodo galimą diegimo laikotarpį. Jis pažymėtas kaip skirtas tik informavimui ir pasirengimui, todėl jo atsakymą laikykite gaire, o DUK taisykle.

Tvarkaraštis jau kartą keitėsi

Paties OTA HTML DUK puslapyje vis dar aprašytas senesnis planas: šimtas didelių įmonių nuo 2026 m. rugpjūčio, visos didelės įmonės nuo 2027 m. vasario, visi kiti nuo 2027 m. rugpjūčio. PDF šias datas pakeičia 2027 m. balandžiu ir spaliu. Pirmajai atrinktų didelių mokesčių mokėtojų grupei (Rollout 1) oficiali paleidimo data lieka 2026 m. rugpjūtis, su lengvatiniu laikotarpiu iki 2026 m. spalio pabaigos kaip bandomojo projekto dalis.

Viename PDF tvarkaraščio skyriaus sakinyje rašoma, kad privalomas atitikimas virš 5 mln. OMR įsigalioja „April 1st 2026“. Visur kitur tame pačiame dokumente nurodyta 2027 m. balandžio 1 d., įskaitant aukščiau cituotą išsamų atsakymą apie taikymo sritį. Panašu į klaidą, tačiau tai gera priežastis remtis pirminiu dokumentu, o ne kieno nors santrauka, įskaitant mūsų.

Kaip veikia Fawtara

Fawtara veikia Peppol tinkle pagal penkių kampų modelį:

1. 1 kampas: jūs, pardavėjas, išrašote sąskaitą faktūrą.
2. 2 kampas: jūsų akredituotas paslaugų teikėjas (ASP) patikrina ją pagal Omano taisykles ir perduoda toliau.
3. 3 kampas: pirkėjo paslaugų teikėjas ją gauna.
4. 4 kampas: pirkėjas.
5. 5 kampas: OTA, gaunanti mokestinius duomenis iš paslaugų teikėjų.

Formatas yra XML, sudarytas pagal OpenPeppol skelbiamas PINT Oman specifikacijas (rašymo metu Billing Process versija 1.0.1). DUK rašoma tiesiai: „A PDF invoice is not an e-invoice“. Popierinę versiją spausdinti vis dar galite, tačiau mokesčių tikslais galiojanti sąskaita faktūra yra tik e. sąskaita faktūra.

Trys DUK detalės lemia inžinerinius sprendimus:

• Teikėjas tikrina, atsakote jūs. ASP kiekvieną sąskaitą faktūrą tikrina pagal Omano schematron taisykles, tačiau „the responsibility for invoice compliance remains with the taxpayers“.
• Vienu metu jungiatės prie vieno teikėjo. Susiejimo prašote per Fawtara portalą, o vėliau galite teikėją pakeisti.
• Standartinės mokesčių mokėtojo API nėra. DUK žodžiais, mokesčių mokėtojo susiejimas „is not standardized and will vary depending on the service provider's system“. Jūsų ERP bendrauja su teikėjo sąsaja, o ne su OTA.

Kai pirkėjas yra vartotojas arba dar prie tinklo neprisijungusi įmonė, jūsų teikėjas vis tiek pateikia mokestinius duomenis OTA, o klientas sąskaitą faktūrą gauna taip, kaip ir šiandien. Eksportas keliauja nuo jūsų pas teikėją ir į OTA.

Kas jau apsaugotas

Jei jūsų ERP ar POS tiekėjas pats yra akredituotas teikėjas arba tiekia jungtį prie tokio, didžioji šio straipsnio dalis jūsų nebeliečia. DUK teigia, kad ERP sistemos „can be retained based on the arrangement taxpayers have with their accredited service providers“, o standartinės sistemos atveju tokį susitarimą įgyvendinti turi tiekėjas. Jūsų darbas yra pagrindiniai duomenys ir testavimas.

Taip pat galite tapti savo paties paslaugų teikėju. Akreditacijos kriterijai apima Omano komercinę registraciją su IT veikla, minimalų apmokėtą kapitalą, veiklos istoriją ir ISO/IEC 27001 sertifikatą, o DUK prideda Peppol eDelivery ir PINT OM testų rinkinių išlaikymą. Tai tinka programinės įrangos įmonėms. Mažmenininkui tai ne trumpesnis kelias.

Šis straipsnis skirtas visiems kitiems: įmonėms, kurių sąskaitos faktūros išrašomos individualia ERP, savo jėgomis sukurta kasų sistema, prie senos duomenų bazės prijungta sąskaitų sistema, arba filialui, kuris sąskaitas faktūras vis dar rašo ranka.

Ką reikia pakeisti jūsų programinėje įrangoje

Susiekite sąskaitų faktūrų duomenis su PINT Oman

DUK nurodymai dėl duomenų susiejimo telpa į vieną eilutę: naudokite Omano PINT specifikacijas. Semantiniame modelyje daugiausia pastangų pareikalauja Omanui būdingi laukai (su priešdėliu BTOM):

• UUID kiekvienam dokumentui (BTOM-002). Jis turi būti RFC 4122 5 versijos, t. y. pagrįstas pavadinimu. Išveskite jį iš kažko stabilaus, pavyzdžiui, juridinio asmens, filialo, kasos ir dokumento numerio, ir pakartotinis pateikimas sukurs tą patį UUID, o ne antrą sąskaitą faktūrą.
• Sąskaitos faktūros operacijos tipas (BTOM-001). Tai 20 pozicijų eilutė, kurioje kiekviena pozicija yra požymis: visa mokestinė sąskaita faktūra, supaprastinta mokestinė sąskaita faktūra, savarankiškas sąskaitų išrašymas, trečiosios šalies, eksportas, laikomasis tiekimas, atvirkštinis apmokestinimas importuojant paslaugas, pelno marža, e. prekyba, prekių importas, tiekimas specialiojoje zonoje, išankstinis apmokėjimas ir kiti. Galima nustatyti kelis požymius. Jūsų sistema turi žinoti, kurie taikomi kiekvienai sąskaitai faktūrai, o dauguma ERP to niekada nesaugojo.
• Pardavėjo ir pirkėjo identifikatoriai su schemos kodu: komercinė registracija, mokesčių mokėtojo identifikacinis numeris, civilinis asmens kodas, pasas, importuotojo muitinės kodas arba specialiosios zonos licencijos numeris.
• Valiuta. Sąskaitos faktūros valiuta, PVM apskaitos valiuta, valiutų kursas tarp jų ir PVM suma apskaitos valiuta turi atskirus laukus.
• Kodų sąrašai PVM neapmokestinimui, nulinio tarifo priežastims, paslaugų tipams ir šalies administraciniams vienetams.

Tikėtina, kad sąskaitų faktūrų eilutės susies sklandžiai, o pagrindiniai duomenys ne. Klientų įrašus be PVM mokėtojo kodo, trūkstamus komercinės registracijos numerius, laisvu tekstu įrašytas neapmokestinimo priežastis ir adresus be regiono kodo reikia sutvarkyti prieš pirmąją tikrą sąskaitą faktūrą.

Kiekvienas pardavimas yra dokumentas

Ši taisyklė keičia POS sistemas: „Consolidated invoices are not allowed for B2C transactions. An E-invoice must be issued separately for every invoice.“ Jokios dienos suvestinės. Parduotuvė, kuri per dieną praveda 3 000 pardavimų, per dieną išsiunčia 3 000 e. sąskaitų faktūrų.

DUK B2C pateikimui skiria 24 valandas, o B2B pateikimui nustato realųjį laiką. Kasai tai reiškia:

• POS sukuria XML (arba perduoda pardavimą tai darančiai paslaugai) pardavimo metu, kartu su UUID. B2C kvitui yra atskiras UUID laukas (BTOM-004).
• Kaupimo ir persiuntimo eilė laiko dokumentus, kai tinklas ar teikėjas neveikia, ir išsiunčia juos per 24 valandas.
• Kas nors gauna įspėjimą, kai dokumentas lieka neišsiųstas po kelių valandų, o ne po dvidešimt trijų.

Prieš pasirašydami palyginkite teikėjo kainodarą su savo apimtimis. DUK teigia, kad kiekvienas teikėjas nustato savo modelį, kuris „may include subscription fees, transaction-based fees, or other pricing arrangements“. Mažmeninės prekybos apimtims mokestis už dokumentą tampa biudžeto eilute.

B2B realiuoju laiku

Verslo sąskaitos faktūros pateikiamos realiuoju laiku. Jūsų ERP užregistruoja sąskaitą faktūrą, teikėjas ją patikrina, ir grįžta rezultatas. Tai keičia sąskaitų faktūrų darbo eigą dviem būdais. Pirma, patikros klaidos dabar išryškėja registravimo metu, todėl kam nors finansų skyriuje reikia ekrano, kuriame matyti atmetimas ir kur jį galima ištaisyti. Antra, sąskaitų faktūrų numeracija, UUID ir pakartojimo logika turi būti teisingos nuo pirmos dienos, nes laiko limitas ir po jo aklas pakartotinis siuntimas yra tai, iš ko atsiranda dvigubos sąskaitos faktūros.

Srautas veikia ir priešinga kryptimi. Kai esate pirkėjas, tiekėjų e. sąskaitos faktūros iš įmonių, jau prisijungusių prie Fawtara, ateina per jūsų teikėją XML formatu, o mokėtinų sumų apskaitai reikia būdo jas priimti.

QR kodai ant spausdinto kvito

QR kodą generuojate jūs (1 kampas), o ne teikėjas. Jis privalomas visoms B2C operacijoms, tiek visoms, tiek supaprastintoms, ir pateikiamas žmogui skaitomoje sąskaitoje faktūroje, o ne XML. OTA planuoja jį naudoti sąskaitoms faktūroms tikrinti mobiliąja programėle. Dėl jo turinio DUK nurodo Peppol Oman Architecture dokumento (versija 1.0.2) D priedą: gaukite šį priedą, prieš kam nors pertvarkant kvitą. Kvitų šablonai ir spausdintuvų tvarkyklės yra šio projekto dalis.

Kreditiniai dokumentai, grąžinimai ir taisymai

Išrašyta e. sąskaita faktūra koreguojama išrašant elektroninę kreditinę arba debetinę sąskaitą faktūrą. Specifikacijoje yra laukai pradinės sąskaitos faktūros UUID ir priežasties kodui (BTOM-031 ir BTOM-032), todėl grąžinant pinigus kasoje turi būti įmanoma rasti pradinį pardavimą.

Importas ir savarankiškas sąskaitų išrašymas

Prekių ir paslaugų importas pateikiamas kaip savarankiškai išrašytos sąskaitos faktūros. Jei jūsų pirkimų procese importas užregistruojamas neišrašant jokio dokumento, ten atsiranda naujas žingsnis.

Archyvavimas

Saugojimas lieka jums. DUK teigia, kad OTA mokesčių mokėtojams sąskaitų faktūrų informacijos negrąžins, o Peppol dokumentų nesaugo. Patikrintą XML, teikėjo atsakymą ir spausdintą versiją laikykite kartu, laikydamiesi PVM teisės aktų saugojimo taisyklių.

Planas atgal nuo termino

DUK teigia, kad OTA susisiekia su diegimo dalyviais likus ne mažiau kaip šešiems mėnesiams iki jų prijungimo. Balandžio grupei tai yra dabar.

Jei pradedate 2027 m. balandžio 1 d.:

1. 2026 m. spalis: patvirtinkite savo grupę diegimo etapo tikrinimo įrankiu ir DUK kriterijumi. Sudarykite visų sąskaitas faktūras išrašančių sistemų sąrašą: ERP, kiekviena POS, e. parduotuvės atsiskaitymas, nuomos ar prenumeratų sąskaitų sistema ir bet kuri rankinė sąskaitų faktūrų knyga.
2. 2026 m. lapkritis: pasirinkite teikėją. Prieš pasirašydami paprašykite API dokumentacijos ir bandomosios aplinkos, paklauskite apie B2C apimtis, kainą už dokumentą, veikimą be ryšio ir kaip atrodo patikros atsakymai. Susiejimo paprašykite per Fawtara portalą.
3. Nuo 2026 m. gruodžio iki 2027 m. sausio: kūrimas. Laukų susiejimas, UUID generavimas, operacijos tipo logika, POS eilė, QR kodai, kreditinių dokumentų srautas, gaunamos sąskaitos faktūros. Paleiskite Omano schematron taisykles iš PINT Oman atsisiuntimų savo testavimo sraute, kad klaidos išryškėtų kūrimo metu, o ne pas teikėją.
4. 2027 m. vasaris: išsamūs testai su teikėjo bandomąja aplinka, naudojant tikrus kiekvieno jūsų iš tikrųjų išrašomo operacijos tipo pavyzdžius, įskaitant nepatogius (eksportą, grąžinimus be kvito, užsienio valiutą).
5. 2027 m. kovas: gamybinė repeticija su vienu filialu ar verslo linija, perėjimo planas ir pagalbos budėjimų grafikas pirmosioms savaitėms.

Jei pradedate 2027 m. spalio 1 d., seka ta pati, tik paslinkta šešiais mėnesiais: teikėjas pasirinktas iki pirmojo ketvirčio pabaigos, kūrimas antrąjį ketvirtį, testavimas baigtas iki rugpjūčio. Neiššvaistykite atsargos. Duomenų tvarkymas visada užtrunka ilgiau, nei kas nors įvertina.

Kas dar neaišku

Datos jau kartą keitėsi ir gali pasikeisti vėl. Planuokite pagal 2026 m. rugpjūčio 31 d. PDF ir kas mėnesį tikrinkite OTA dokumentus, o ne pasikliaukite naujienomis. Teisinis pagrindas yra Sprendimas 189/2026, kuriuo keičiamas PVM įstatymo įgyvendinimo reglamentas. DUK teigia, kad prasidėjus prievolei bus taikomos baudos pagal PVM teisės aktus, tačiau sumų nenurodo, todėl jų nenurodome ir mes.

Specifikacijos taip pat turi versijas. Peppol svetainėje PINT OM sąskaitų išrašymo, savarankiško sąskaitų išrašymo ir mokestinių duomenų procesai nurodyti kaip 1.0.1 versija, be išleidimo datos. Ten rodoma data, 2026 m. liepos 29 d., yra tame pačiame puslapyje esančio PDK 1.4.4 išleidimo data, o ne Omano specifikacijų. Užfiksuokite versiją, pagal kurią kuriate, ir tikrinkite puslapį dėl naujų.

Kur gauti pagalbos

Mes kuriame jungtį tarp sistemos, kurią iš tikrųjų naudojate, ir formato, kurio reikalauja prievolė: laukų susiejimą, UUID ir numeracijos logiką, POS eiles, patikrą jūsų kūrimo sraute ir integraciją su jūsų pasirinktu teikėju. Šį darbą apima mūsų e. sąskaitų faktūrų integravimo paslauga, o kai kliūtis yra pati ERP, viskas prasideda nuo ERP modernizavimo.

Jei esate balandžio grupėje ir dar nepasirinkote teikėjo, rašykite office@c9group.dev.