E-faktura med Fawtara i Oman i 2027: hva egenutviklede ERP- og kassesystemer trenger

Oman erstatter papir- og PDF-fakturaer med strukturerte e-fakturaer i XML som går gjennom en akkreditert tjenesteleverandør og rapporteres til skattemyndigheten Oman Tax Authority (OTA). Programmet heter Fawtara. Skattytere med årlige leveranser over 5 millioner OMR starter 1. april 2027. Alle andre mva-registrerte skattytere starter 1. oktober 2027.

Det er i varehandelen det biter hardest. Salg til forbrukere er omfattet fra samme dag som salg til virksomheter, og hvert eneste salg trenger sin egen e-faktura. Er kasseprogramvaren, ERP-systemet eller faktureringsmotoren deres utviklet internt eller sterkt tilpasset, er jobben med å produsere de dokumentene deres.

Datoene, og hvilken som gjelder deg

Kilden er OTAs spørsmål og svar om Fawtara, sist oppdatert 31. august 2026. Testen er beskrevet enkelt. Du innfører fra 1. april 2027 hvis ett av disse er tilfellet:

• leveransene dine fra 1. april 2026 til 31. mars 2027 overstiger OMR 5 000 000, eller
• leveransene du forventer fra 1. april 2027 til 31. mars 2028, overstiger OMR 5 000 000.

«Er ingen av dem oppfylt, må du innføre e-faktura fra 1. oktober 2027.»

Hva som teller med i tallet: avgiftspliktige leveranser unntatt anleggsmidler, varer og tjenester under ordningen med omvendt avgiftsplikt, og leveranser innad i GCC. En mva-gruppe vurderes på gruppenivå, ikke medlem for medlem. En ikke-resident teller bare leveranser gjort i Oman.

Legg merke til det andre leddet. En virksomhet som vokser mot 5 millioner OMR, kan havne i aprilgruppen bare på grunn av prognosen sin. Ligger du nær grensen, gå ut fra april.

OTA har et verktøy for å sjekke innføringstidspunkt som tar VATIN og nåværende og forventet leveransenivå og viser en mulig innføringsperiode. Det er merket som kun ment for informasjon og forberedelse, så behandle svaret som en pekepinn og spørsmålene og svarene som regelen.

Tidsplanen er allerede flyttet én gang

OTAs egen HTML-side med spørsmål og svar beskriver fortsatt den eldre planen: hundre store selskaper fra august 2026, alle store selskaper fra februar 2027 og alle andre fra august 2027. PDF-en erstatter de datoene med april og oktober 2027. For en første gruppe utvalgte store skattytere (Rollout 1) er august 2026 fortsatt den offisielle oppstartsdatoen, med en overgangsperiode til utgangen av oktober 2026 som del av en pilot.

Én setning i tidslinjedelen av PDF-en sier at obligatorisk etterlevelse over 5 millioner OMR gjelder fra «April 1st 2026». Alt annet i det samme dokumentet sier 1. april 2027, inkludert det detaljerte svaret om virkeområdet sitert over. Det ser ut som en skrivefeil, men det er en god grunn til å jobbe ut fra primærdokumentet heller enn noens oppsummering, vår inkludert.

Slik fungerer Fawtara

Fawtara kjører på Peppol, med en femhjørnemodell:

1. Hjørne 1: du, selgeren, utsteder fakturaen.
2. Hjørne 2: din akkrediterte tjenesteleverandør (ASP) validerer den mot reglene for Oman og sender den videre.
3. Hjørne 3: kjøperens tjenesteleverandør mottar den.
4. Hjørne 4: kjøperen.
5. Hjørne 5: OTA, som mottar skattedataene fra tjenesteleverandørene.

Formatet er XML, bygget etter PINT Oman-spesifikasjonene som OpenPeppol publiserer (Billing Process versjon 1.0.1 da dette ble skrevet). Spørsmålene og svarene sier rett ut at «en PDF-faktura er ikke en e-faktura». Du kan fortsatt skrive ut på papir, men bare e-fakturaen er en gyldig faktura i avgiftssammenheng.

Tre detaljer fra spørsmålene og svarene former utviklingsarbeidet:

• Leverandøren validerer, du er fortsatt ansvarlig. Din ASP kontrollerer hver faktura mot schematron-reglene for Oman, men «ansvaret for at fakturaen oppfyller kravene, ligger fortsatt hos skattyterne».
• Du kobler deg til én leverandør om gangen. Du ber om koblingen gjennom Fawtara-portalen, og du kan bytte senere.
• Det finnes ikke noe standard API for skattytere. Med spørsmålene og svarenes ord er koblingen av en skattyter «ikke standardisert og vil variere avhengig av tjenesteleverandørens system». ERP-systemet ditt snakker med leverandørens grensesnitt, ikke med OTA.

Når kjøperen er en forbruker eller en virksomhet som ennå ikke er på nettverket, rapporterer leverandøren din likevel skattedataene til OTA, og kunden får fakturaen slik som i dag. Eksport går fra deg til leverandøren din og videre til OTA.

Hvem som allerede er dekket

Er leverandøren av ERP- eller kassesystemet ditt selv en akkreditert tjenesteleverandør, eller leverer den en kobling til en, er det meste av denne artikkelen ikke ditt problem. Spørsmålene og svarene sier at ERP-systemer «kan beholdes basert på avtalen skattyterne har med sine akkrediterte tjenesteleverandører», og for et standardsystem er det leverandøren som skal levere den avtalen. Din jobb er stamdata og testing.

Du kan også bli din egen tjenesteleverandør. Kriteriene for akkreditering omfatter en omansk handelsregistrering med IT-virksomhet, en minste innbetalt kapital, driftshistorikk og ISO/IEC 27001-sertifisering, og spørsmålene og svarene legger til at man må bestå testsuitene for Peppol eDelivery og PINT OM. Det passer programvareselskaper. Det er ingen snarvei for en butikkjede.

Denne artikkelen er for alle andre: selskaper der fakturaene kommer fra et egenutviklet ERP-system, et internt kassesystem, en faktureringsmotor skrudd på en gammel database, eller en filial som fortsatt skriver fakturaer for hånd.

Hva som må endres i programvaren

Map fakturadataene dine til PINT Oman

Spørsmålene og svarenes veiledning om mapping er én linje: bruk PINT-spesifikasjonene for Oman. I den semantiske modellen er det de omanske feltene (med prefikset BTOM) som tar mest innsats:

• En UUID for hvert dokument (BTOM-002). Den må være RFC 4122 versjon 5, som er navnebasert. Avled den fra noe stabilt, som juridisk enhet, filial, kasse og dokumentnummer, så gir en ny innsending den samme UUID-en i stedet for en faktura til.
• En transaksjonstype for fakturaen (BTOM-001). Dette er en streng med 20 posisjoner der hver posisjon er et flagg: full skattefaktura, forenklet skattefaktura, selvfakturering, tredjepart, eksport, fiktiv levering, omvendt avgiftsplikt ved import av tjenester, marginordning, netthandel, import av varer, leveranse i spesialsone, forskuddsbetaling og andre. Flere flagg kan settes. Systemet ditt må vite hvilke som gjelder for hver faktura, og de fleste ERP-systemer har aldri lagret det.
• Identifikatorer for selger og kjøper med en skjemakode: handelsregistrering, skatteidentifikasjonsnummer, sivil ID, pass, importørens toll-ID eller lisensnummer for spesialsone.
• Valuta. Fakturavaluta, valuta for mva-regnskapet, vekslingskursen mellom dem og mva-totalen i regnskapsvalutaen har alle egne felt.
• Kodelister for mva-fritak, grunner for nullsats, tjenestetyper og landsdeler.

Regn med at fakturalinjene mapper greit og at stamdataene ikke gjør det. Kundeposter uten VATIN, manglende CR-numre, fritaksgrunner i fritekst og adresser uten regionkode må alle ryddes før den første fakturaen i drift.

Behandle hvert salg som et dokument

Dette er regelen som endrer kassesystemer: «Samlefakturaer er ikke tillatt for B2C-transaksjoner. En e-faktura må utstedes separat for hver faktura.» Ingen oppsummering ved dagens slutt. En butikk som slår inn 3 000 salg om dagen, sender 3 000 e-fakturaer om dagen.

Spørsmålene og svarene gir B2C-innsendinger 24 timer og B2B-innsendinger sanntid. For en kasse betyr det:

• Kassen bygger XML-en (eller overlater salget til en tjeneste som gjør det) i salgsøyeblikket, med UUID-en. Det finnes et eget felt for kvitterings-UUID for B2C (BTOM-004).
• En kø for mellomlagring og videresending holder på dokumentene når nettverket eller leverandøren er nede, og tømmer den innenfor de 24 timene.
• Noen varsles når et dokument fortsatt ikke er sendt etter noen timer, ikke etter tjuetre.

Sjekk leverandørens priser mot volumet ditt før du signerer. Spørsmålene og svarene sier at hver leverandør bestemmer sin egen modell, som «kan omfatte abonnementsavgifter, transaksjonsbaserte avgifter eller andre prisordninger». Med volumene i varehandelen er en avgift per dokument en egen linje i budsjettet.

B2B i sanntid

For fakturaer til virksomheter skjer innsendingen i sanntid. ERP-systemet ditt bokfører fakturaen, leverandøren validerer den, og resultatet kommer tilbake. Det endrer fakturaflyten på to måter. Valideringsfeil dukker nå opp i bokføringsøyeblikket, så noen i økonomiavdelingen trenger et skjermbilde som viser avvisningen og lar dem rette den. Og fakturanummerering, UUID-en og logikken for nye forsøk må være riktig fra første dag, for et tidsavbrudd etterfulgt av en blind ny sending er slik dupliserte fakturaer oppstår.

Flyten går også den andre veien. Når du er kjøperen, kommer e-fakturaer fra leverandører som allerede er på Fawtara, som XML gjennom leverandøren din, og leverandørreskontroen trenger en måte å ta dem inn på.

QR-koder på den utskrevne kvitteringen

QR-koden genereres av deg (hjørne 1), ikke av leverandøren. Den er obligatorisk for alle B2C-transaksjoner, fullstendige eller forenklede, og den står på den lesbare fakturaen, ikke i XML-en. OTA planlegger å bruke den til å verifisere fakturaer gjennom en mobilapp. For innholdet viser spørsmålene og svarene til vedlegg D i dokumentet Peppol Oman Architecture (versjon 1.0.2): skaff det vedlegget før noen designer om en kvittering. Kvitteringsmaler og skriverdrivere er en del av dette prosjektet.

Kreditnotaer, returer og korrigeringer

Når en e-faktura er utstedt, justeres den ved å utstede en elektronisk kredit- eller debetnota. Spesifikasjonen har felt for den opprinnelige fakturaens UUID og en årsakskode (BTOM-031 og BTOM-032), så en refusjon i kassen må kunne finne det opprinnelige salget.

Import og selvfakturering

Import av varer og tjenester rapporteres som selvfakturaer. Bokfører innkjøpsflyten din import uten å lage noe dokument, dukker det opp et nytt trinn der.

Arkivering

Oppbevaringen er fortsatt ditt ansvar. Spørsmålene og svarene sier at OTA ikke vil gi fakturaopplysninger tilbake til skattyterne, og Peppol lagrer ikke dokumenter. Oppbevar den validerte XML-en, leverandørens svar og den utskrevne versjonen sammen, etter oppbevaringsreglene i merverdiavgiftsregelverket.

En plan regnet bakover fra fristen

Spørsmålene og svarene sier at OTA tar kontakt med deltakerne i innføringen minst seks måneder før de skal kobles på. For aprilgruppen er det nå.

Starter du 1. april 2027:

1. Oktober 2026: bekreft gruppen din med sjekkverktøyet og testen i spørsmålene og svarene. List opp hvert system som utsteder en faktura: ERP, hver kasse, kassen i nettbutikken, fakturering av utleie eller abonnementer, og eventuelle manuelle fakturabøker.
2. November 2026: velg leverandør. Be om API-dokumentasjon og et testmiljø før du signerer, og spør om B2C-volum, pris per dokument, håndtering når man er frakoblet, og hvordan valideringssvarene ser ut. Be om koblingen gjennom Fawtara-portalen.
3. Desember 2026 til januar 2027: utvikling. Feltmapping, generering av UUID, logikk for transaksjonstype, kassekøen, QR-koder, flyten for kreditnotaer, inngående fakturaer. Kjør schematron-reglene for Oman fra nedlastingene for PINT Oman i din egen testløype, slik at feil dukker opp i utviklingen og ikke hos leverandøren.
4. Februar 2027: ende-til-ende-tester mot leverandørens testmiljø med ekte eksempler på hver transaksjonstype dere faktisk utsteder, inkludert de vanskelige (eksport, returer uten kvittering, utenlandsk valuta).
5. Mars 2027: en generalprøve i produksjon med én filial eller ett forretningsområde, en plan for overgangen og en vaktordning for de første ukene.

Starter du 1. oktober 2027, er rekkefølgen den samme, forskjøvet seks måneder: leverandør valgt innen utgangen av første kvartal, utvikling i andre kvartal, testing ferdig innen august. Ikke bruk opp slakken. Opprydding i data tar alltid lengre tid enn noen anslår.

Hva som fortsatt er usikkert

Datoene er flyttet én gang og kan flyttes igjen. Planlegg etter PDF-en datert 31. august 2026, og sjekk OTAs dokumenter hver måned i stedet for å stole på nyhetsdekningen. Det rettslige grunnlaget er vedtak 189/2026, som endrer gjennomføringsforskriften til merverdiavgiftsloven. Spørsmålene og svarene sier at sanksjoner vil gjelde etter merverdiavgiftsregelverket når kravet trer i kraft, men oppgir ingen beløp, så det gjør ikke vi heller.

Spesifikasjonene er også versjonert. Den gjeldende PINT Oman-pakken på Peppol-nettstedet har utgivelsesdato 29. juli 2026. Lås versjonen du bygger mot, og følg med på utgivelsesnotatene.

Hvor du får hjelp

Vi bygger koblingen mellom systemet du faktisk kjører og formatet kravet stiller: feltmapping, logikk for UUID og nummerering, kassekøer, validering i testløypa di og integrasjonen med leverandøren du velger. Vår tjeneste for e-fakturaintegrasjon dekker det arbeidet, og når selve ERP-systemet er hindringen, er det ERP-modernisering som er utgangspunktet.

Er du i aprilgruppen og ikke har valgt leverandør ennå, skriv til office@c9group.dev.