Omans e-fakturering Fawtara i 2027: hvad specialudviklede ERP- og kassesystemer skal kunne

Havnefronten i Muttrah i Muscat med bjerge bag byen

Oman erstatter papir- og PDF-fakturaer med strukturerede XML-e-fakturaer, der går gennem en akkrediteret tjenesteudbyder og indberettes til Oman Tax Authority (OTA), den omanske skattemyndighed. Programmet hedder Fawtara. Skatteydere med en årlig levering på over 5 millioner OMR starter 1. april 2027. Alle andre momsregistrerede skatteydere starter 1. oktober 2027.

Det er detailhandlen, der rammes hårdest. Salg til forbrugere er omfattet fra samme dag som salg til virksomheder, og hvert eneste salg skal have sin egen e-faktura. Er jeres kassesoftware, ERP-system eller faktureringsmotor egenudviklet eller kraftigt tilpasset, er arbejdet med at danne de dokumenter jeres.

Datoerne, og hvilken der gælder for jer

Kilden er OTA's FAQ om Fawtara, senest opdateret 31. august 2026. Testen er beskrevet tydeligt. I skal implementere fra 1. april 2027, hvis en af disse betingelser er opfyldt:

jeres leverancer fra 1. april 2026 til 31. marts 2027 overstiger 5.000.000 OMR, eller
jeres forventede leverancer fra 1. april 2027 til 31. marts 2028 overstiger 5.000.000 OMR.

»Er ingen af dem opfyldt, skal I implementere e-fakturering fra 1. oktober 2027.«

Hvad der tæller med i tallet: afgiftspligtige leverancer, eksklusive anlægsaktiver, varer og tjenesteydelser under omvendt betalingspligt og leverancer inden for GCC. En momsgruppe vurderes på gruppeniveau, ikke medlem for medlem. En ikke-hjemmehørende virksomhed tæller kun leverancer foretaget i Oman.

Læg mærke til det andet led. En virksomhed, der vokser mod 5 millioner OMR, kan havne i aprilgruppen alene på grund af sin prognose. Ligger I tæt på grænsen, så gå ud fra april.

OTA har et værktøj til at tjekke udrulningen, som tager jeres VATIN og jeres nuværende og forventede leveringsinterval og viser en mulig implementeringsperiode. Det er mærket som kun beregnet til orientering og forberedelse, så brug svaret som vejledning og FAQ'en som reglen.

Tidsplanen er allerede flyttet én gang

OTA's egen FAQ-side i HTML beskriver stadig den ældre plan: hundrede store virksomheder fra august 2026, alle store virksomheder fra februar 2027 og alle andre fra august 2027. PDF'en erstatter de datoer med april og oktober 2027. For en første gruppe af udvalgte store skatteydere (Rollout 1) er august 2026 fortsat den officielle go live-dato, med en henstandsperiode til udgangen af oktober 2026 som del af en pilot.

Én sætning i PDF'ens afsnit om tidsplanen siger, at obligatorisk overholdelse over 5 millioner OMR gælder fra »April 1st 2026« (1. april 2026). Alt andet i samme dokument siger 1. april 2027, inklusive det detaljerede svar om anvendelsesområdet, der er citeret ovenfor. Det ligner en fejl, men det er en god grund til at arbejde ud fra det primære dokument frem for nogens sammenfatning, også vores.

Sådan fungerer Fawtara

Fawtara kører på Peppol med en model med fem hjørner:

Hjørne 1: jer, sælgeren, der udsteder fakturaen.
Hjørne 2: jeres akkrediterede tjenesteudbyder (ASP), der validerer den mod de omanske regler og sender den videre.
Hjørne 3: købers tjenesteudbyder, der modtager den.
Hjørne 4: køber.
Hjørne 5: OTA, der modtager skattedata fra tjenesteudbyderne.

Formatet er XML, bygget efter de PINT Oman-specifikationer, som OpenPeppol offentliggør (Billing Process version 1.0.1, da dette skrives). FAQ'en siger ligeud, at »en PDF-faktura ikke er en e-faktura«. I kan stadig printe på papir, men kun e-fakturaen er en gyldig faktura i skattemæssig forstand.

Tre detaljer fra FAQ'en former det tekniske arbejde:

Udbyderen validerer, I har ansvaret. ASP'en kontrollerer hver faktura mod de omanske schematron-regler, men »ansvaret for fakturaens overholdelse af reglerne ligger fortsat hos skatteyderne«.
I forbinder til én udbyder ad gangen. I anmoder om koblingen via Fawtara-portalen og kan skifte senere.
Der findes intet standard-API for skatteydere. Med FAQ'ens ord er koblingen af en skatteyder »ikke standardiseret og vil variere afhængigt af tjenesteudbyderens system«. Jeres ERP-system taler med udbyderens grænseflade, ikke med OTA.

Når køber er en forbruger eller en virksomhed, der endnu ikke er på netværket, indberetter udbyderen stadig skattedata til OTA, og kunden får fakturaen, som de gør i dag. Eksport går fra jer til jeres udbyder til OTA.

Hvem der allerede er dækket

Er jeres ERP- eller kasseleverandør selv en akkrediteret udbyder, eller leverer den en connector til en, er det meste af denne artikel ikke jeres problem. FAQ'en siger, at ERP-systemer »kan bevares ud fra den aftale, skatteyderne har med deres akkrediterede tjenesteudbydere«, og for et standardsystem er det leverandøren, der skal levere den aftale. Jeres arbejde er stamdata og test.

I kan også selv blive tjenesteudbyder. Kriterierne for akkreditering omfatter en omansk handelsregistrering med it-aktiviteter, en minimumsindbetalt kapital, driftshistorik og ISO/IEC 27001-certificering, og FAQ'en tilføjer, at testsuiterne for Peppol eDelivery og PINT OM skal bestås. Det passer til softwarevirksomheder. Det er ikke en genvej for en detailhandler.

Denne artikel er til alle andre: virksomheder, hvis fakturaer kommer ud af et specialudviklet ERP-system, et egenudviklet kassesystem, en faktureringsmotor skruet på en gammel database eller en filial, der stadig skriver fakturaer i hånden.

Hvad der skal ændres i jeres software

Map jeres fakturadata til PINT Oman

FAQ'ens vejledning om mapping er én linje: brug de omanske PINT-specifikationer. I den semantiske model er det de Oman-specifikke felter (med præfikset BTOM), der kræver størstedelen af indsatsen:

Et UUID for hvert dokument (BTOM-002). Det skal være RFC 4122 version 5, som er navnebaseret. Afled det af noget stabilt, for eksempel juridisk enhed, filial, kasse og dokumentnummer, så et genforsøg giver det samme UUID i stedet for en faktura nummer to.
En fakturatransaktionstype (BTOM-001). Det er en streng på 20 positioner, hvor hver position er et flag: fuld momsfaktura, forenklet momsfaktura, selvfakturering, tredjepart, eksport, fiktiv levering (deemed supply), omvendt betalingspligt ved import af tjenesteydelser, avancemargin, e-handel, import af varer, levering i særlig zone, forudbetaling og andre. Flere flag kan sættes. Jeres system skal vide, hvilke der gælder for hver faktura, og de fleste ERP-systemer har aldrig gemt det.
Identifikatorer for sælger og køber med en ordningskode: handelsregistrering, skatteidentifikationsnummer, civilt id, pas, importørens told-id eller licensnummer i en særlig zone.
Valuta. Fakturavaluta, momsregnskabsvaluta, vekselkursen mellem dem og momstotalen i regnskabsvalutaen har alle deres egne felter.
Kodelister for momsfritagelse, årsager til nulsats, servicetyper og landets underopdelinger.

Regn med, at fakturalinjerne mappes uden problemer, og at stamdata ikke gør. Kundeposter uden VATIN, manglende CR-numre, fritagelsesårsager i fritekst og adresser uden regionskode skal alle ryddes op, før den første faktura går i drift.

Behandl hvert salg som et dokument

Det er reglen, der ændrer kassesystemer: »Samlefakturaer er ikke tilladt for B2C-transaktioner. Der skal udstedes en separat e-faktura for hver faktura.« Ingen opsamling ved dagens slutning. En butik, der slår 3.000 salg ind om dagen, sender 3.000 e-fakturaer om dagen.

FAQ'en giver B2C-indsendelser 24 timer og B2B-indsendelser realtid. For en kasse betyder det:

Kassen danner XML'en (eller overdrager salget til en tjeneste, der gør det) i salgsøjeblikket, med sit UUID. Der findes et separat felt til kvitterings-UUID for B2C (BTOM-004).
En kø efter store and forward-princippet holder dokumenterne, når netværket eller udbyderen er nede, og tømmes inden for de 24 timer.
Nogen får en alarm, når et dokument stadig ikke er sendt efter et par timer, ikke efter treogtyve.

Tjek udbyderens priser mod jeres volumen, før I skriver under. FAQ'en siger, at hver udbyder fastsætter sin egen model, som »kan omfatte abonnementsgebyrer, transaktionsbaserede gebyrer eller andre prisordninger«. Ved detailvolumener er et gebyr pr. dokument en linje i budgettet.

B2B i realtid

For erhvervsfakturaer sker indsendelsen i realtid. Jeres ERP-system bogfører fakturaen, udbyderen validerer den, og resultatet kommer tilbage. Det ændrer faktureringsforløbet på to måder. Valideringsfejl viser sig nu i bogføringsøjeblikket, så en i økonomiafdelingen har brug for et skærmbillede, der viser afvisningen og lader dem rette den. Og fakturanummerering, UUID og logikken for genforsøg skal være korrekte fra første dag, for en timeout fulgt af en blind genafsendelse er præcis sådan, dubletfakturaer opstår.

Flowet går også den anden vej. Når I er køber, kommer leverandørfakturaer fra virksomheder, der allerede er på Fawtara, gennem jeres udbyder som XML, og kreditorbogholderiet har brug for en måde at få dem ind på.

QR-koder på den printede kvittering

QR-koden dannes af jer (hjørne 1), ikke af udbyderen. Den er obligatorisk for alle B2C-transaktioner, fulde eller forenklede, og den står på den læsbare faktura, ikke i XML'en. OTA planlægger at bruge den til at verificere fakturaer via en mobilapp. Med hensyn til indholdet henviser FAQ'en til bilag D i Peppol Oman Architecture-dokumentet (version 1.0.2): skaf det bilag, før nogen designer en kvittering om. Kvitteringsskabeloner og printerdrivere er en del af projektet.

Kreditnotaer, returneringer og rettelser

Når en e-faktura først er udstedt, justeres den ved at udstede en elektronisk kredit- eller debetnota. Specifikationen har felter til den oprindelige fakturas UUID og en årsagskode (BTOM-031 og BTOM-032), så en refundering ved kassen skal kunne finde det oprindelige salg.

Import og selvfakturering

Import af varer og tjenesteydelser indberettes som selvfakturaer. Bogfører jeres indkøbsforløb import uden at danne noget dokument, opstår der et nyt trin dér.

Arkivering

Opbevaringen forbliver jeres. FAQ'en siger, at OTA ikke vil levere fakturaoplysninger tilbage til skatteyderne, og Peppol gemmer ikke dokumenter. Opbevar den validerede XML, udbyderens svar og den printede version samlet efter momslovgivningens regler om opbevaring.

En plan baglæns fra fristen

FAQ'en siger, at OTA kontakter deltagerne i udrulningen mindst seks måneder før deres onboarding. For aprilgruppen er det nu.

Starter I 1. april 2027:

Oktober 2026: bekræft jeres gruppe med udrulningsværktøjet og FAQ'ens test. List hvert system, der udsteder en faktura: ERP, hver kasse, webshoppens checkout, leje- eller abonnementsfakturering og eventuelle manuelle fakturabøger.
November 2026: vælg en udbyder. Bed om API-dokumentation og et sandkassemiljø, før I skriver under, og spørg til B2C-volumen, pris pr. dokument, håndtering offline og hvordan valideringssvar ser ud. Anmod om koblingen via Fawtara-portalen.
December 2026 til januar 2027: udvikling. Feltmapping, dannelse af UUID, logik for transaktionstyper, kassekøen, QR-koder, forløbet for kreditnotaer og indgående fakturaer. Kør de omanske schematron-regler fra PINT Oman-downloads i jeres egen testpipeline, så fejl viser sig under udviklingen og ikke hos udbyderen.
Februar 2027: end-to-end-test mod udbyderens sandkassemiljø med rigtige eksempler på hver transaktionstype, I faktisk udsteder, inklusive de besværlige (eksport, returneringer uden kvittering, udenlandsk valuta).
Marts 2027: en generalprøve i produktion med én filial eller ét forretningsområde, en plan for omstillingen og en supportvagtplan for de første uger.

Starter I 1. oktober 2027, er rækkefølgen den samme, bare forskudt seks måneder: udbyder valgt inden udgangen af første kvartal, udvikling i andet og test afsluttet i august. Brug ikke luften. Oprydningen i data tager altid længere tid, end nogen regner med.

Hvad der stadig er usikkert

Datoerne er flyttet én gang og kan flytte sig igen. Planlæg efter PDF'en dateret 31. august 2026, og tjek OTA's dokumenter hver måned i stedet for at stole på nyhedsdækningen. Retsgrundlaget er beslutning 189/2026, som ændrer momslovens gennemførelsesbestemmelser. FAQ'en siger, at sanktioner vil gælde efter momslovgivningen, når kravet træder i kraft, men oplyser ikke beløb, så det gør vi heller ikke.

Specifikationerne er også versionerede. Den aktuelle PINT Oman-pakke på Peppols website har udgivelsesdatoen 29. juli 2026. Lås den version, I bygger mod, og hold øje med udgivelsesnoterne.

Hvor I kan få hjælp

Vi bygger connectoren mellem det system, I faktisk kører, og det format, kravet stiller: feltmapping, logik for UUID og nummerering, kassekøer, validering i jeres pipeline og integrationen med den udbyder, I vælger. Vores service til integration af e-fakturering dækker det arbejde, og når selve ERP-systemet står i vejen, starter det med ERP-modernisering.

Er I i aprilgruppen og har endnu ikke valgt en udbyder, så skriv til office@c9group.dev.