Omānas Fawtara e-rēķini 2027. gadā: kas vajadzīgs pielāgotām ERP un kases sistēmām

Omāna aizstāj papīra un PDF rēķinus ar strukturētiem XML e-rēķiniem, kas iet caur akreditētu pakalpojumu sniedzēju un tiek paziņoti Omānas nodokļu iestādei (Oman Tax Authority, OTA). Programmu sauc Fawtara. Nodokļu maksātāji, kuru gada piegādes pārsniedz 5 miljonus OMR, sāk 2027. gada 1. aprīlī. Visi pārējie PVN reģistrētie nodokļu maksātāji sāk 2027. gada 1. oktobrī.

Visasāk tas skar mazumtirdzniecību. Pārdošana patērētājiem ietilpst darbības jomā no tās pašas dienas kā pārdošana uzņēmumiem, un katram atsevišķam pirkumam vajadzīgs savs e-rēķins. Ja jūsu kases programmatūra, ERP vai norēķinu dzinējs ir izstrādāts uzņēmumā vai būtiski pielāgots, šo dokumentu veidošanas darbs ir jūsu ziņā.

Datumi un kurš no tiem attiecas uz jums

Avots ir OTA Fawtara BUJ, pēdējoreiz atjaunināti 2026. gada 31. augustā. Kritērijs izklāstīts skaidri. Jums jāievieš no 2027. gada 1. aprīļa, ja izpildās kāds no šiem nosacījumiem:

• jūsu piegādes laikā no 2026. gada 1. aprīļa līdz 2027. gada 31. martam pārsniedz 5 000 000 OMR, vai
• jūsu sagaidāmās piegādes laikā no 2027. gada 1. aprīļa līdz 2028. gada 31. martam pārsniedz 5 000 000 OMR.

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

Kas tiek ieskaitīts šajā summā: ar nodokli apliekamas piegādes, izņemot pamatlīdzekļus, preces un pakalpojumus, kam piemēro apgriezto maksāšanu, un piegādes GCC valstu starpā. PVN grupu vērtē grupas līmenī, nevis pa dalībniekiem. Nerezidents ieskaita tikai Omānā veiktās piegādes.

Ievērojiet otro nosacījumu. Uzņēmums, kas aug virzienā uz 5 miljoniem OMR, var nonākt aprīļa grupā tikai savas prognozes dēļ. Ja esat tuvu robežai, pieņemiet, ka jums jāsāk aprīlī.

OTA uztur ieviešanas posma pārbaudes rīku, kurā ievada savu VATIN un pašreizējo un sagaidāmo piegāžu diapazonu, un tas parāda iespējamo ieviešanas periodu. Tas apzīmēts kā paredzēts tikai informēšanai un sagatavotībai, tāpēc uzskatiet tā atbildi par orientieri, bet BUJ par noteikumu.

Grafiks jau vienreiz ir mainīts

OTA pašas HTML BUJ lapā joprojām aprakstīts vecais plāns: simts lieli uzņēmumi no 2026. gada augusta, visi lielie uzņēmumi no 2027. gada februāra, visi pārējie no 2027. gada augusta. PDF šos datumus aizstāj ar 2027. gada aprīli un oktobri. Pirmajai atlasīto lielo nodokļu maksātāju grupai (Rollout 1) oficiālais darba sākuma datums joprojām ir 2026. gada augusts, ar labvēlības periodu līdz 2026. gada oktobra beigām kā daļu no izmēģinājuma.

Vienā teikumā PDF laika grafika sadaļā teikts, ka obligātā atbilstība virs 5 miljoniem OMR ir spēkā no „April 1st 2026“. Viss pārējais tajā pašā dokumentā norāda 2027. gada 1. aprīli, ieskaitot iepriekš citēto detalizēto atbildi par darbības jomu. Tas izskatās pēc pārrakstīšanās kļūdas, taču tas ir labs iemesls strādāt pēc primārā dokumenta, nevis pēc kāda kopsavilkuma, arī ne mūsējā.

Kā darbojas Fawtara

Fawtara darbojas uz Peppol, izmantojot piecu stūru modeli:

1. 1. stūris: jūs kā pārdevējs izrakstāt rēķinu.
2. 2. stūris: jūsu akreditētais pakalpojumu sniedzējs (ASP) to validē pret Omānas noteikumiem un nodod tālāk.
3. 3. stūris: pircēja pakalpojumu sniedzējs to saņem.
4. 4. stūris: pircējs.
5. 5. stūris: OTA, kas saņem nodokļu datus no pakalpojumu sniedzējiem.

Formāts ir XML, veidots pēc PINT Oman specifikācijām, ko publicē OpenPeppol (raksta tapšanas brīdī Billing Process versija 1.0.1). BUJ ir nepārprotami: „A PDF invoice is not an e-invoice“. Papīru joprojām var drukāt, taču nodokļu vajadzībām derīgs rēķins ir tikai e-rēķins.

Trīs detaļas no BUJ nosaka inženiertehnisko darbu:

• Pakalpojumu sniedzējs validē, atbildība paliek jums. ASP pārbauda katru rēķinu pret Omānas schematron noteikumiem, taču „the responsibility for invoice compliance remains with the taxpayers“.
• Vienlaikus jūs pieslēdzaties vienam pakalpojumu sniedzējam. Savienojumu pieprasa Fawtara portālā, un vēlāk to var mainīt.
• Standarta API nodokļu maksātājiem nav. BUJ vārdiem, nodokļu maksātāja pieslēgšana „is not standardized and will vary depending on the service provider's system“. Jūsu ERP sazinās ar pakalpojumu sniedzēja saskarni, nevis ar OTA.

Ja pircējs ir patērētājs vai uzņēmums, kas vēl nav tīklā, jūsu pakalpojumu sniedzējs tik un tā paziņo nodokļu datus OTA, un klients saņem rēķinu tāpat kā šodien. Eksports iet no jums pie jūsu pakalpojumu sniedzēja un tālāk uz OTA.

Kam tas jau ir nodrošināts

Ja jūsu ERP vai kases sistēmas piegādātājs pats ir akreditēts pakalpojumu sniedzējs vai piedāvā savienotāju ar tādu, lielākā daļa šī raksta uz jums neattiecas. BUJ teikts, ka ERP sistēmas „can be retained based on the arrangement taxpayers have with their accredited service providers“, un gatavas sistēmas gadījumā šī vienošanās jānodrošina piegādātājam. Jūsu darbs ir pamatdati un testēšana.

Jūs varētu arī pats kļūt par pakalpojumu sniedzēju. Akreditācijas kritēriji ietver Omānas komercreģistrāciju ar IT darbībām, minimālo apmaksāto kapitālu, darbības vēsturi un ISO/IEC 27001 sertifikāciju, un BUJ piebilst, ka jāiztur Peppol eDelivery un PINT OM testu komplekti. Tas der programmatūras uzņēmumiem. Mazumtirgotājam tas nav īsceļš.

Šis raksts ir visiem pārējiem: uzņēmumiem, kuru rēķinus veido pielāgota ERP, pašu izstrādāta kases sistēma, norēķinu dzinējs, kas piestiprināts vecai datubāzei, vai filiāle, kas joprojām raksta rēķinus ar roku.

Kas jāmaina jūsu programmatūrā

Piesaistiet rēķinu datus PINT Oman

BUJ norādījumi par lauku piesaisti ir viena rinda: izmantojiet Omānas PINT specifikācijas. Semantiskajā modelī lielākā daļa darba ir ar Omānai specifiskajiem laukiem (ar prefiksu BTOM):

• UUID katram dokumentam (BTOM-002). Tam jābūt RFC 4122 5. versijai, kas balstīta uz nosaukumu. Atvasiniet to no kā stabila, piemēram, juridiskās personas, filiāles, kases un dokumenta numura, un atkārtota iesniegšana radīs to pašu UUID, nevis otru rēķinu.
• Rēķina darījuma veids (BTOM-001). Tā ir 20 pozīciju virkne, kurā katra pozīcija ir pazīme: pilns nodokļa rēķins, vienkāršots nodokļa rēķins, pašizrakstīts, trešās personas, eksports, pieņemtā piegāde, pakalpojumu importa apgrieztā maksāšana, peļņas daļa, e-komercija, preču imports, piegāde speciālajā zonā, priekšapmaksa un citas. Var būt iestatītas vairākas pazīmes. Jūsu sistēmai jāzina, kuras attiecas uz katru rēķinu, un lielākā daļa ERP to nekad nav glabājušas.
• Pārdevēja un pircēja identifikatori ar shēmas kodu: komercreģistrācija, nodokļu maksātāja identifikācijas numurs, civilais ID, pase, importētāja muitas ID vai speciālās zonas licences numurs.
• Valūta. Rēķina valūtai, PVN uzskaites valūtai, valūtas kursam starp tām un PVN kopsummai uzskaites valūtā katrai ir savs lauks.
• Kodu saraksti PVN atbrīvojumam, nulles likmes iemesliem, pakalpojumu veidiem un valsts administratīvajām vienībām.

Gaidiet, ka rēķina rindas piesaistīsies bez problēmām, bet pamatdati ne. Klientu ieraksti bez VATIN, trūkstoši CR numuri, brīva teksta atbrīvojuma iemesli un adreses bez reģiona koda: tas viss jāsakārto pirms pirmā reālā rēķina.

Uzskatiet katru pirkumu par dokumentu

Šis ir noteikums, kas maina kases sistēmas: „Consolidated invoices are not allowed for B2C transactions. An E-invoice must be issued separately for every invoice.“ Nekāda dienas kopsavilkuma. Veikals, kas dienā reģistrē 3 000 pirkumu, dienā nosūta 3 000 e-rēķinu.

BUJ B2C iesniegšanai paredz 24 stundas, bet B2B iesniegšanai reāllaiku. Kases sistēmai tas nozīmē:

• Kases sistēma pirkuma brīdī izveido XML (vai nodod pirkumu servisam, kas to izdara) ar tā UUID. B2C gadījumā ir atsevišķs čeka UUID lauks (BTOM-004).
• Saglabāšanas un pārsūtīšanas rinda glabā dokumentus, kad tīkls vai pakalpojumu sniedzējs nav pieejams, un nosūta tos 24 stundu laikā.
• Kāds saņem brīdinājumu, ja dokuments joprojām nav nosūtīts pēc dažām stundām, nevis pēc divdesmit trim.

Pirms parakstāt līgumu, salīdziniet pakalpojumu sniedzēja cenas ar savu apjomu. BUJ teikts, ka katrs pakalpojumu sniedzējs nosaka savu modeli, kas „may include subscription fees, transaction-based fees, or other pricing arrangements“. Mazumtirdzniecības apjomos maksa par katru dokumentu ir atsevišķa budžeta pozīcija.

B2B reāllaikā

Uzņēmumu rēķiniem iesniegšana notiek reāllaikā. Jūsu ERP iegrāmato rēķinu, pakalpojumu sniedzējs to validē, un rezultāts atnāk atpakaļ. Tas maina rēķinu darbplūsmu divējādi. Validācijas kļūdas tagad parādās iegrāmatošanas brīdī, tāpēc kādam finanšu nodaļā vajadzīgs ekrāns, kas parāda noraidījumu un ļauj to izlabot. Turklāt rēķinu numerācijai, UUID un atkārtošanas loģikai jābūt pareizai no pirmās dienas, jo taimauts, kam seko akla atkārtota nosūtīšana, ir tieši tas, kā rodas dublēti rēķini.

Plūsma darbojas arī pretējā virzienā. Kad esat pircējs, piegādātāju e-rēķini no uzņēmumiem, kas jau ir Fawtara, pienāk caur jūsu pakalpojumu sniedzēju kā XML, un kreditoru uzskaitei vajadzīgs veids, kā tos ielādēt.

QR kodi uz izdrukātā čeka

QR kodu ģenerējat jūs (1. stūris), nevis pakalpojumu sniedzējs. Tas ir obligāts visiem B2C darījumiem, gan pilniem, gan vienkāršotiem, un tas parādās cilvēkam lasāmajā rēķinā, nevis XML. OTA plāno to izmantot rēķinu pārbaudei ar mobilo lietotni. Par tā saturu BUJ norāda uz Peppol Oman Architecture dokumenta (versija 1.0.2) D pielikumu: iegūstiet šo pielikumu, pirms kāds pārveido čeka dizainu. Čeku veidnes un printeru draiveri ir daļa no šī projekta.

Kredītrēķini, atgriešana un labojumi

Pēc izrakstīšanas e-rēķinu koriģē, izrakstot elektronisku kredītrēķinu vai debetrēķinu. Specifikācijā ir lauki sākotnējā rēķina UUID un iemesla kodam (BTOM-031 un BTOM-032), tāpēc atmaksai pie kases jāspēj atrast sākotnējais pirkums.

Imports un pašizrakstīšana

Preču un pakalpojumu imports tiek paziņots kā pašizrakstīti rēķini. Ja jūsu iepirkumu plūsma importu iegrāmato, neizveidojot nekādu dokumentu, tur parādās jauns solis.

Arhivēšana

Glabāšana paliek jūsu ziņā. BUJ teikts, ka OTA nesniegs rēķinu informāciju atpakaļ nodokļu maksātājiem, un Peppol dokumentus neglabā. Glabājiet validēto XML, pakalpojumu sniedzēja atbildi un izdrukāto versiju kopā, saskaņā ar PVN tiesību aktu glabāšanas noteikumiem.

Plāns atpakaļ no termiņa

BUJ teikts, ka OTA sazinās ar ieviešanas dalībniekiem vismaz sešus mēnešus pirms to pieslēgšanas. Aprīļa grupai tas ir tagad.

Ja sākat 2027. gada 1. aprīlī:

1. 2026. gada oktobris: pārliecinieties par savu grupu ar ieviešanas pārbaudes rīku un BUJ kritēriju. Uzskaitiet katru sistēmu, kas izraksta rēķinus: ERP, katru kases sistēmu, e-komercijas norēķinu lapu, nomas vai abonementu norēķinus un jebkuru manuālo rēķinu grāmatu.
2. 2026. gada novembris: izvēlieties pakalpojumu sniedzēju. Pirms līguma parakstīšanas palūdziet API dokumentāciju un smilškastes vidi un pajautājiet par B2C apjomu, cenu par dokumentu, bezsaistes režīmu un to, kā izskatās validācijas atbildes. Pieprasiet savienojumu Fawtara portālā.
3. No 2026. gada decembra līdz 2027. gada janvārim: izstrāde. Lauku piesaiste, UUID ģenerēšana, darījuma veida loģika, kases rinda, QR kodi, kredītrēķinu plūsma, ienākošie rēķini. Palaidiet Omānas schematron noteikumus no PINT Oman lejupielādēm savā testēšanas konveijerā, lai kļūmes parādītos izstrādē, nevis pie pakalpojumu sniedzēja.
4. 2027. gada februāris: pilna cikla testi pakalpojumu sniedzēja smilškastē ar reāliem paraugiem no katra darījuma veida, ko jūs faktiski izrakstāt, ieskaitot neērtos (eksports, atgriešana bez čeka, ārvalstu valūta).
5. 2027. gada marts: ražošanas mēģinājums vienā filiālē vai biznesa virzienā, pārejas plāns un atbalsta grafiks pirmajām nedēļām.

Ja sākat 2027. gada 1. oktobrī, secība ir tā pati, nobīdīta par sešiem mēnešiem: pakalpojumu sniedzējs izvēlēts līdz pirmā ceturkšņa beigām, izstrāde otrajā ceturksnī, testēšana pabeigta līdz augustam. Neiztērējiet rezervi. Datu sakārtošana vienmēr aizņem vairāk laika, nekā kāds paredz.

Kas joprojām nav skaidrs

Datumi jau vienreiz mainīti un var mainīties atkal. Plānojiet pēc 2026. gada 31. augusta PDF un katru mēnesi pārbaudiet OTA dokumentus, nevis paļaujieties uz ziņām. Juridiskais pamats ir Lēmums 189/2026, kas groza PVN likuma izpildnoteikumus. BUJ teikts, ka pēc prasības stāšanās spēkā tiks piemēroti sodi saskaņā ar PVN tiesību aktiem, taču summas nav norādītas, tāpēc mēs tās arī nenorādām.

Arī specifikācijām ir versijas. Peppol vietnē PINT OM rēķinu, pašizrakstīšanas un nodokļu datu procesi norādīti ar versiju 1.0.1, bez izlaišanas datuma. Datums, kas tur ir redzams, 2026. gada 29. jūlijs, ir PDK 1.4.4 izlaišanas datums tajā pašā lapā, nevis Omānas specifikāciju datums. Fiksējiet versiju, pēc kuras būvējat, un pārbaudiet lapu, vai nav jaunu.

Kur saņemt palīdzību

Mēs izveidojam savienotāju starp sistēmu, ko jūs faktiski izmantojat, un formātu, ko prasa regulējums: lauku piesaisti, UUID un numerācijas loģiku, kases rindas, validāciju jūsu konveijerā un integrāciju ar jūsu izvēlēto pakalpojumu sniedzēju. Šo darbu aptver mūsu e-rēķinu integrācijas pakalpojums, un, ja šķērslis ir pati ERP, darbs sākas ar ERP modernizāciju.

Ja esat aprīļa grupā un vēl neesat izvēlējušies pakalpojumu sniedzēju, rakstiet uz office@c9group.dev.