Omans e-fakturering Fawtara 2027: vad specialbyggda ERP- och kassasystem behöver

Oman ersätter fakturor på papper och i PDF med strukturerade e-fakturor i XML som går via en ackrediterad tjänsteleverantör och rapporteras till skattemyndigheten Oman Tax Authority (OTA). Programmet heter Fawtara. Skattskyldiga med årliga leveranser över OMR 5 miljoner börjar den 1 april 2027. Alla andra momsregistrerade skattskyldiga börjar den 1 oktober 2027.

Det är detaljhandeln som drabbas hårdast. Försäljning till konsumenter omfattas från samma dag som försäljning mellan företag, och varje enskild försäljning behöver en egen e-faktura. Om ditt kassasystem, ERP eller faktureringssystem är egenutvecklat eller kraftigt anpassat är arbetet med att ta fram de dokumenten ditt.

Datumen, och vilket som gäller dig

Källan är OTA:s Fawtara FAQ, senast uppdaterad 31 augusti 2026. Kriteriet är tydligt formulerat. Du ska införa e-fakturering från 1 april 2027 om något av följande stämmer:

• dina leveranser från 1 april 2026 till 31 mars 2027 överstiger OMR 5 000 000, eller
• dina förväntade leveranser från 1 april 2027 till 31 mars 2028 överstiger OMR 5 000 000.

”Om inget av villkoren är uppfyllt ska du införa e-fakturering från 1 oktober 2027.”

Det här räknas in i beloppet: skattepliktiga leveranser, med undantag för anläggningstillgångar, varor och tjänster som omfattas av omvänd skattskyldighet, och leveranser inom GCC. En momsgrupp bedöms på gruppnivå, inte medlem för medlem. En utländsk aktör räknar bara leveranser som görs i Oman.

Lägg märke till det andra villkoret. Ett företag som växer mot OMR 5 miljoner kan hamna i aprilgruppen enbart på grund av sin prognos. Om du ligger nära gränsen, räkna med april.

OTA har ett verktyg för att kontrollera införandet som tar ditt VATIN och ditt nuvarande och förväntade intervall för leveranser och visar en möjlig införandeperiod. Det är märkt som enbart avsett för information och förberedelse, så se svaret som en vägledning och FAQ:n som regeln.

Tidsplanen har redan ändrats en gång

OTA:s egen FAQ-sida i HTML beskriver fortfarande den äldre planen: hundra stora företag från augusti 2026, alla stora företag från februari 2027, alla övriga från augusti 2027. PDF:en ersätter de datumen med april och oktober 2027. För en första grupp utvalda stora skattskyldiga (Rollout 1) är augusti 2026 fortfarande det officiella startdatumet, med en övergångsperiod till slutet av oktober 2026 som en del av ett pilotprojekt.

En mening i PDF:ens avsnitt om tidslinjen säger att det obligatoriska kravet för den som ligger över OMR 5 miljoner gäller från ”April 1st 2026”. Allt annat i samma dokument säger 1 april 2027, inklusive det utförliga svaret om tillämpningsområdet som citeras ovan. Det ser ut som ett förbiseende, men det är ett bra skäl att utgå från primärdokumentet i stället för någons sammanfattning, vår inräknad.

Så fungerar Fawtara

Fawtara bygger på Peppol, med en modell i fem hörn:

1. Hörn 1: du, säljaren, utfärdar fakturan.
2. Hörn 2: din ackrediterade tjänsteleverantör (ASP) validerar den mot de omanska reglerna och skickar den vidare.
3. Hörn 3: köparens tjänsteleverantör tar emot den.
4. Hörn 4: köparen.
5. Hörn 5: OTA, som tar emot skatteuppgifterna från tjänsteleverantörerna.

Formatet är XML, byggt enligt de PINT Oman-specifikationer som OpenPeppol publicerar (Billing Process version 1.0.1 när detta skrivs). FAQ:n är rak: ”En PDF-faktura är inte en e-faktura.” Du kan fortfarande skriva ut på papper, men bara e-fakturan är en giltig faktura i skattehänseende.

Tre detaljer i FAQ:n formar utvecklingsarbetet:

• Leverantören validerar, du har ansvaret. ASP:n kontrollerar varje faktura mot de omanska schematron-reglerna, men ”ansvaret för att fakturan uppfyller kraven ligger kvar hos de skattskyldiga”.
• Du är ansluten till en leverantör åt gången. Du begär kopplingen via Fawtara-portalen och kan byta senare.
• Det finns inget standard-API för skattskyldiga. Med FAQ:ns ord är kopplingen av en skattskyldig ”inte standardiserad och varierar beroende på tjänsteleverantörens system”. Ditt ERP pratar med leverantörens gränssnitt, inte med OTA.

När köparen är en konsument eller ett företag som ännu inte är anslutet till nätverket rapporterar leverantören ändå skatteuppgifterna till OTA, och kunden får fakturan på samma sätt som i dag. Export går från dig till din leverantör och vidare till OTA.

Vem som redan är täckt

Om din ERP- eller kassaleverantör själv är en ackrediterad leverantör, eller levererar en koppling till en sådan, är det mesta i den här artikeln inte ditt problem. FAQ:n säger att ERP-system ”kan behållas utifrån den överenskommelse de skattskyldiga har med sina ackrediterade tjänsteleverantörer”, och för ett standardsystem är det leverantörens sak att leverera den överenskommelsen. Ditt arbete gäller grunddata och testning.

Du kan också bli din egen tjänsteleverantör. Kriterierna för ackreditering omfattar en omansk handelsregistrering med IT-verksamhet, ett lägsta inbetalt kapital, en verksamhetshistorik och certifiering enligt ISO/IEC 27001, och FAQ:n lägger till att man ska klara testsviterna för Peppol eDelivery och PINT OM. Det passar mjukvaruföretag. För en detaljhandlare är det ingen genväg.

Den här artikeln är för alla andra: företag vars fakturor kommer ur ett specialbyggt ERP, ett egenutvecklat kassasystem, en faktureringsmotor som har skruvats fast på en gammal databas, eller en filial som fortfarande skriver fakturor för hand.

Vad som måste ändras i din programvara

Mappa dina fakturadata till PINT Oman

FAQ:ns vägledning om mappning är en enda rad: använd de omanska PINT-specifikationerna. I den semantiska modellen är det de Oman-specifika fälten (med prefixet BTOM) som kräver mest arbete:

• Ett UUID för varje dokument (BTOM-002). Det måste vara RFC 4122 version 5, som är namnbaserad. Härled det från något stabilt, till exempel juridisk person, filial, kassa och dokumentnummer, så ger en ny inskickning samma UUID i stället för en andra faktura.
• En fakturatransaktionstyp (BTOM-001). Det är en sträng med 20 positioner där varje position är en flagga: fullständig skattefaktura, förenklad skattefaktura, självfakturering, tredjepart, export, fiktiv leverans, omvänd skattskyldighet vid import av tjänster, vinstmarginal, e-handel, import av varor, leverans i specialzon, förskottsbetalning med flera. Mer än en flagga kan vara satt. Ditt system måste veta vilka som gäller för varje faktura, och de flesta ERP-system har aldrig lagrat det.
• Identifierare för säljare och köpare med en schemakod: handelsregistrering, skatteregistreringsnummer, civilt ID, pass, importörens tull-ID eller licensnummer för specialzon.
• Valuta. Fakturavaluta, valuta för momsredovisning, växelkursen mellan dem och momstotalen i redovisningsvalutan har alla egna fält.
• Kodlistor för momsbefrielse, skäl till nollskattesats, tjänstetyper och administrativa indelningar av länder.

Räkna med att fakturaraderna går att mappa utan problem och att grunddata inte gör det. Kundposter utan VATIN, saknade CR-nummer, undantagsskäl i fritext och adresser utan regionkod måste alla rensas upp före den första skarpa fakturan.

Behandla varje försäljning som ett dokument

Det här är regeln som förändrar kassasystem: ”Samlingsfakturor är inte tillåtna för B2C-transaktioner. En e-faktura ska utfärdas separat för varje faktura.” Ingen sammanställning vid dagens slut. En butik som slår in 3 000 köp om dagen skickar 3 000 e-fakturor om dagen.

FAQ:n ger B2C-inskickningar 24 timmar och B2B-inskickningar realtid. För en kassa innebär det:

• Kassan bygger XML:en (eller lämnar över försäljningen till en tjänst som gör det) i samma ögonblick som köpet sker, med sitt UUID. Det finns ett separat fält för kvittots UUID för B2C (BTOM-004).
• En store-and-forward-kö håller kvar dokumenten när nätverket eller leverantören ligger nere och tömmer kön inom 24 timmar.
• Någon larmas när ett dokument fortfarande inte är skickat efter några timmar, inte efter tjugotre.

Jämför leverantörens prissättning med din volym innan du skriver på. FAQ:n säger att varje leverantör bestämmer sin egen modell, som ”kan omfatta prenumerationsavgifter, transaktionsbaserade avgifter eller andra prisupplägg”. Vid detaljhandelsvolymer blir en avgift per dokument en egen rad i budgeten.

B2B i realtid

För fakturor mellan företag sker inskickningen i realtid. Ditt ERP bokför fakturan, leverantören validerar den och resultatet kommer tillbaka. Det ändrar fakturaflödet på två sätt. Valideringsfel syns nu i samma stund som fakturan bokförs, så någon på ekonomiavdelningen behöver en vy som visar avvisningen och låter dem rätta den. Och fakturanumreringen, UUID:t och logiken för nya försök måste vara rätt från första dagen, eftersom en timeout följd av en blind omsändning är precis hur dubbla fakturor uppstår.

Flödet går också åt andra hållet. När du är köpare kommer leverantörsfakturor från företag som redan är anslutna till Fawtara som XML via din leverantör, och leverantörsreskontran behöver ett sätt att ta in dem.

QR-koder på det utskrivna kvittot

QR-koden genereras av dig (hörn 1), inte av leverantören. Den är obligatorisk för alla B2C-transaktioner, fullständiga eller förenklade, och den finns på den läsbara fakturan, inte i XML:en. OTA planerar att använda den för att verifiera fakturor via en mobilapp. För innehållet hänvisar FAQ:n till Appendix D i dokumentet Peppol Oman Architecture (version 1.0.2): skaffa den bilagan innan någon gör om ett kvitto. Kvittomallar och skrivardrivrutiner är en del av projektet.

Kreditnotor, returer och rättelser

En utfärdad e-faktura justeras genom att man utfärdar en elektronisk kredit- eller debetnota. Specifikationen har fält för den ursprungliga fakturans UUID och en orsakskod (BTOM-031 och BTOM-032), så en återbetalning i kassan måste kunna hitta den ursprungliga försäljningen.

Import och självfakturering

Import av varor och tjänster rapporteras som självfakturor. Om ditt inköpsflöde bokför import utan att skapa något dokument tillkommer ett nytt steg där.

Arkivering

Lagringen ligger kvar hos dig. FAQ:n säger att OTA inte kommer att lämna tillbaka fakturauppgifter till de skattskyldiga, och Peppol lagrar inte dokument. Spara den validerade XML:en, leverantörens svar och den utskrivna versionen tillsammans, enligt momslagstiftningens regler om lagringstid.

En plan räknad baklänges från deadline

FAQ:n säger att OTA kontaktar de som ingår i ett införande minst sex månader före deras anslutning. För aprilgruppen är det nu.

Om du börjar 1 april 2027:

1. Oktober 2026: bekräfta din grupp med kontrollverktyget och FAQ:ns kriterium. Lista varje system som utfärdar en faktura: ERP, varje kassa, kassan i e-handeln, fakturering av uthyrning eller prenumerationer, och eventuella manuella fakturablock.
2. November 2026: välj en leverantör. Be om API-dokumentation och en sandlåda innan du skriver på, och fråga om B2C-volymer, pris per dokument, hantering när du är offline och hur valideringssvaren ser ut. Begär kopplingen via Fawtara-portalen.
3. December 2026 till januari 2027: bygg. Fältmappning, generering av UUID, logik för transaktionstyp, kön i kassan, QR-koder, flödet för kreditnotor, inkommande fakturor. Kör de omanska schematron-reglerna från nedladdningarna för PINT Oman i din egen testpipeline, så att felen syns i utvecklingen och inte hos leverantören.
4. Februari 2027: tester från början till slut mot leverantörens sandlåda med verkliga exempel på varje transaktionstyp du faktiskt utfärdar, inklusive de besvärliga (export, returer utan kvitto, utländsk valuta).
5. Mars 2027: en generalrepetition i produktion med en filial eller ett affärsområde, en plan för överväxlingen och ett supportschema för de första veckorna.

Om du börjar 1 oktober 2027 är ordningen densamma men förskjuten sex månader: leverantör vald i slutet av första kvartalet, bygget under andra kvartalet, testningen klar i augusti. Gör inte av med marginalen. Datastädningen tar alltid längre tid än någon räknar med.

Vad som fortfarande är osäkert

Datumen har ändrats en gång och kan ändras igen. Planera efter PDF:en daterad 31 augusti 2026 och kontrollera OTA:s dokument varje månad i stället för att förlita dig på nyhetsrapportering. Den rättsliga grunden är beslut 189/2026, som ändrar Executive Regulation till VAT Law. FAQ:n säger att sanktioner kommer att gälla enligt momslagstiftningen när kravet börjar gälla, men anger inga belopp, så det gör inte vi heller.

Specifikationerna är också versionshanterade. Peppols webbplats anger processerna för fakturering, självfakturering och skatteuppgifter i PINT OM i version 1.0.1, utan utgivningsdatum. Datumet som faktiskt visas, 29 juli 2026, är utgivningsdatumet för PDK 1.4.4 på samma sida, inte för de omanska specifikationerna. Lås den version du bygger mot och håll koll på sidan efter nya.

Var du får hjälp

Vi bygger kopplingen mellan det system du faktiskt kör och det format som kravet föreskriver: fältmappning, logik för UUID och numrering, köer i kassan, validering i din pipeline och integrationen med den leverantör du väljer. Vår tjänst för integration av e-fakturering täcker det arbetet, och när ERP-systemet självt är hindret är det ERP-modernisering som är startpunkten.

Om du tillhör aprilgruppen och ännu inte har valt leverantör, skriv till office@c9group.dev.