E-faktura i De forente arabiske emirater fra 1. juli 2027: slik gjør du et egenutviklet ERP-system klart for Peppol

Fra 1. januar 2027 må virksomheter i De forente arabiske emirater (UAE) med en årlig omsetning på AED 50 000 000 eller mer utstede og motta B2B- og B2G-fakturaene sine som strukturert XML, sendt gjennom en akkreditert tjenesteleverandør (Accredited Service Provider) over Peppol-nettverket. Alle under den terskelen følger etter 1. juli 2027, og må ha utpekt en leverandør innen 31. mars 2027. Offentlige virksomheter går over 1. oktober 2027.

Fra din oppstartsdato er det XML-filen som er skattefakturaen. PDF-en systemet ditt sender på e-post i dag, trengs bare ved siden av, for kunder som ennå ikke er på nettverket.

Kommer fakturaene dine fra Zoho, Tally, Wafeq eller et lignende standardprodukt, er det meste av dette leverandørens jobb. Alle tre står selv på finansdepartementets liste over akkrediterte leverandører. Din jobb er å velge leverandør, gjennomføre registreringen i EmaraTax og rydde i kundedataene.

Denne artikkelen er for selskaper der fakturaene kommer fra et system de eier selv: et egenutviklet ERP-system, en installasjon som er tilpasset så langt at den ikke lenger kan oppgraderes, en intern faktureringsmotor. Ingen leverer ferdige koblinger for slike systemer. Det sier også UAE Electronic Invoicing Guidelines: virksomhetene må «fullføre eventuelle tilpasninger av interne systemer og begynne å teste overføringen av fakturadata».

Datoene

Fasene er fastsatt i Ministerial Decision No. 244 of 2025, med senere endringer:

I den første raden sto det opprinnelig 31. juli 2026. Ministerial Decision No. 66 of 2026 flyttet fristen til 30. oktober 2026 og lot oppstartsdatoen stå. Tabellen i retningslinjene viser fortsatt den gamle datoen, så de to må leses sammen.

Frivillig innføring har vært åpen for alle siden 1. juli 2026, og det har betydning for planen nedenfor.

Hva som omfattes

E-faktura gjelder alle som driver virksomhet i UAE, uavhengig av mva-registrering. En virksomhet som ikke er mva-registrert, utsteder elektroniske handelsfakturaer i stedet for skattefakturaer, gjennom det samme nettverket.

B2B-, B2G-, G2B- og G2G-transaksjoner er omfattet. Salg til forbrukere er unntatt inntil ministeren bestemmer noe annet, og en virksomhet som bare selger til forbrukere, er foreløpig ikke underlagt ordningen i det hele tatt. Det finnes smale unntak for statlig myndighetsutøvelse, passasjerbilletter for fly og mva-fritatte finansielle tjenester.

Er dere en mva-gruppe, er det én lempelse som betyr noe: transaksjoner mellom medlemmer av samme gruppe får en overgangsperiode på 24 måneder fra 1. januar 2027. Hvert medlem registreres likevel for seg under sitt eget TIN, og fakturaer til eksterne parter er omfattet fra den vanlige datoen.

Femhjørnemodellen sett fra ERP-systemet ditt

UAE bruker en femhjørnemodell:

1. Hjørne 1: deg, leverandøren.
2. Hjørne 2: din akkrediterte tjenesteleverandør (ASP).
3. Hjørne 3: kjøperens ASP.
4. Hjørne 4: kjøperen.
5. Hjørne 5: skattemyndigheten, Federal Tax Authority (FTA).

Systemet ditt snakker med én part: din ASP. Du sender fakturadata i et format dere har avtalt. Din ASP validerer dem, konverterer til UAE-XML ved behov, leverer til kjøperens ASP og rapporterer samtidig skattedataene til FTA. Kjøperens ASP validerer det den mottok, og rapporterer det også. Bekreftelsene går tilbake langs kjeden til deg.

Rapporteringen bruker et eget Peppol-dokument, UAE Tax Data Document, som Peppol-spesifikasjonen beskriver som «brukt av både fakturautsteder og fakturamottaker til å rapportere en faktura». Det dokumentet bygger din ASP. Det du bygger, er håndteringen av det som kommer tilbake: bekreftelse på at kjøpersiden har akseptert fakturaen, bekreftelse på at FTA har mottatt skattedataene, og feilmeldinger for begge.

Din ASP håndterer transport, kryptering, oppslag av deltakere og UUID-en som identifiserer hver faktura entydig. Du er fortsatt ansvarlig for å beregne hver eneste verdi på fakturaen og for å samle inn kjøperens Peppol-identifikator. Leverandøren validerer fakturaen. Den retter den ikke.

Du utpeker nøyaktig én ASP, både for sending og mottak.

Hva systemet ditt må produsere

Formatet

UAE bruker Peppol PINT-AE: UBL-XML, med én spesifikasjon for fakturering og en egen for selvfakturering (begge i versjon 1.0.4 da dette ble skrevet). Det er ingen QR-kode. Du kan ikke legge til egne felt; alt som er bransjespesifikt, avtales med din ASP.

Feltene eldre systemer som regel mangler

Departementet publiserer en liste over obligatoriske felt: 51 for en elektronisk skattefaktura. Disse er det som oftest må jobbes med:

• Elektroniske adresser for begge parter. Ditt endepunkt er 0235 pluss ditt tisifrede TIN, som er de første ti sifrene i ditt TRN. Kjøperens følger samme mønster, og det betyr et nytt felt på hver kundepost og noen som samler inn verdiene. Det finnes forhåndsdefinerte endepunkter for spesialtilfeller: 0235:9900000098 når kjøperen ennå ikke er på systemet, 0235:9900000099 for en eksportkjøper uten Peppol-ID, 0235:9900000097 for fiktive leveranser (deemed supplies).
• Selgerens juridiske registrering. Registreringsnummeret pluss typen, fra et fast sett: TL (handelslisens), EID (Emirates ID), PAS (pass) eller CD (Cabinet Decision). På en handelsfaktura er kjøperens registrering også obligatorisk.
• Strukturerte adresser, inkludert landsdelen (emiratet), for selger og kjøper.
• Betalingsbetingelser som data. En forfallsdato og en kode for betalingsmåte på hver faktura.
• Kodede enheter og fullstendige prisdata på hver linje. En enhetskode, bruttopris, nettopris og prisgrunnlagsmengde. Enheter lagret som fritekst («stk», «eske à 12») krever en mappingtabell.
• Avgiftskategori per linje, pluss en oppstilling per kategori: standardsats, fritatt, utenfor virkeområdet, omvendt avgiftsplikt, nullsats eller marginordning. Fakturaer med innenlands omvendt avgiftsplikt har i tillegg en forklarende tekst og varetypen.
• Beløp i AED, alltid. Mva-beløpet og beløpet som skal betales for hver linje, i AED, uansett fakturavaluta. En faktura i utenlandsk valuta trenger i tillegg valutaen for avgiftsregnskapet og totalbeløpet inkludert mva i AED, til sentralbankens kurs.
• Flagg for transaksjonstype. Åtte posisjoner, hver 1 eller 0: frisone, fiktiv levering, marginordning, samlefaktura, løpende levering, fakturering som åpen agent (disclosed agent billing), netthandel, eksport. Flere kan settes på én faktura, og hvert flagg som settes, utløser egne krav. En kunde i en frisone trenger for eksempel også opplysninger om den begunstigede.

Én regel fortjener sitt eget testtilfelle: avrunding skjer på fakturatotalen, til to desimaler, ikke per linje eller per avgiftskategori. Avrunder faktureringskoden din hver linje eller hver mva-sats, bør du teste den mot ekte fakturaer før leverandøren gjør det.

HSN-varekoder er valgfrie foreløpig, og datoen for når de blir obligatoriske, er ikke kunngjort. Selger du varer, bør du legge dem inn mens du uansett har vareregisteret åpent.

Kreditnotaer, forskudd og tilbakeholdte beløp

• En faktura med negativ total er ikke tillatt. En kreditering må utstedes som en elektronisk kreditnota, og det gjelder også en samlefaktura som ender i kreditt.
• Én kreditnota kan vise til flere tidligere fakturaer, og kan dekke bare en del av én. Volumrabatter går gjennom kreditnotaer med tilhørende årsakskode.
• Det finnes ingen kategori for foreløpige fakturaer. Hver foreløpig faktura er en fullverdig elektronisk faktura, som senere justeres med en kreditnota eller en tilleggsfaktura.
• Forskuddsbetalinger får en skattefaktura når de mottas. Sluttfakturaen dekker bare restbeløpet og viser til forskuddsfakturaen.
• Tilbakeholdte beløp kan håndteres ved å fakturere fratrukket det tilbakeholdte, og så utstede en egen faktura når beløpet forfaller.

Inngående fakturaer, som alle glemmer

Den samme ASP-en mottar fakturaene fra dine leverandører. Fra oppstart kommer de som XML og må havne i leverandørreskontroen. Det er ofte den største delen av jobben, fordi den berører matching mot innkjøp og godkjenninger, ikke bare én dokumentmal.

De store leverandørene dine går i drift 1. januar 2027 og vil be om identifikatoren din. Inntil du selv er i drift, sender de til det forhåndsdefinerte endepunktet og gir deg i tillegg en vanlig skattefaktura, så ingenting stopper opp hos deg.

Samarbeidet med en akkreditert tjenesteleverandør

Departementets liste viste 60 akkrediterte leverandører 2. oktober 2026. Det er du som starter registreringen, ikke leverandøren: kontoadministratoren deres i EmaraTax åpner delen for e-faktura, velger leverandøren og sendes videre til leverandørens portal. Signer kontrakten først, og kontroller at selskapsopplysningene i EmaraTax er oppdatert.

For et egenutviklet system er det tekniske spørsmål som avgjør prosjektet:

1. Hva tar leverandøren imot? Sitt eget API-format, filutveksling, eller PINT-AE-XML som du genererer selv. Leverandørens eget format er mindre arbeid i dag; din egen PINT-AE lar deg bytte leverandør uten å bygge mappingen på nytt.
2. Hvordan kommer bekreftelsene tilbake? Webhook, polling, fil? Begge typene hører hjemme på fakturaposten, sammen med UUID-en din ASP tildeler.
3. Hva skjer ved nytt forsøk? Tidsavbrudd skjer. Å sende en faktura på nytt må ikke lage en faktura til, så avtal hvordan duplikater oppdages, og før din egen overføringslogg som dokumentasjon på hva som ble sendt.
4. Finnes det et testmiljø der du kan teste avvisninger, ikke bare tilfellene der alt går bra?
5. Hvordan når inngående fakturaer frem til deg? Og hva skjer mens din side er nede?
6. Arkiverer leverandøren for deg? Det kan avtales, men oppbevaringsplikten forblir din. Regnskapsmaterialet kan ligge utenfor UAE, så lenge det kan legges frem for FTA i fullstendig og lesbar form.

Retningslinjene lister opp hva testingen bør dekke: sending av fakturadata til din ASP, levering til kjøperen, bekreftelsen på utvekslingen, mottak av en leverandørfaktura, rapporteringen fra din ASP til FTA og bekreftelsen på rapporteringen. Test feilsituasjonen for hvert trinn, ikke bare suksessen.

Sanksjonene

Cabinet Decision No. 106 of 2025 fastsetter dem:

• Manglende innføring av ordningen, inkludert å ikke utpeke leverandør i tide: AED 5 000 per påbegynte måned.
• Manglende utstedelse og overføring av en elektronisk faktura eller en elektronisk kreditnota: AED 100 per stykk, begrenset oppad til AED 5 000 per kalendermåned.
• Manglende varsel til FTA om systemsvikt, eller manglende melding til din ASP om endringer i registrerte opplysninger: AED 1 000 per dag.

Ingen av disse gjelder fakturaer utstedt frivillig før din obligatoriske dato.

En nimånedersplan frem til 1. juli 2027

Per begynnelsen av oktober 2026 har et selskap under terskelen ni måneder. Det holder for et egenutviklet system, hvis arbeidet starter nå.

1. Oktober til november 2026: gapanalyse. Eksporter ett års fakturaer og kreditnotaer, klassifiser dem etter kategori, scenario, avgiftskategori og valuta, og skriv ned hvor hvert obligatoriske felt skal hentes fra.
2. November til desember 2026: velg leverandør. Lag en kortliste ut fra de tekniske spørsmålene over, signer og få tilgang til testmiljøet. 31. mars 2027 er siste frist, ikke målet.
3. Desember 2026 til februar 2027: bygg. Endringer i stamdata og innsamling av kundeidentifikatorer, mappingen, validering før sending, håndtering av bekreftelser, en feilkø som noen eier, og behandling av inngående fakturaer.
4. Februar til mars 2027: registrering gjennom EmaraTax, som avsluttes med deltakeridentifikatoren din. Bli ferdig god tid før 31. mars.
5. April til mai 2027: ende-til-ende-testing med leverandøren: alle seks trinnene, inkludert feilsituasjoner og kreditnotaer.
6. Mai til juni 2027: gå i drift frivillig. Sanksjonene gjelder ikke frivillige fakturaer, så dette er det billigste stedet å finne de siste problemene. Avtal rekkefølgen med leverandøren.
7. 1. juli 2027: obligatorisk. Sørg for at noen følger opp feilkøen frem til og med den første mva-meldingen.

Hører du til den store gruppen og ikke har startet, har du frist til 30. oktober 2026 med å utpeke leverandør, og under tre måneder til oppstart. De samme trinnene gjelder, presset sammen til uker, og leverandørens eget inndataformat er trolig den raskeste veien.

Hva som fortsatt kan endre seg

Datoene er allerede flyttet én gang, retningslinjene er i versjon 1.1, og PINT-AE-versjonene endres, med leverandører som er forpliktet til å bruke den nyeste. Hold mappingen i én modul, bak ditt eget grensesnitt, slik at en oppdatering av spesifikasjonen ikke berører faktureringskoden. HSN-koder blir obligatoriske på et tidspunkt, og B2C holdes utenfor bare frem til et nytt vedtak.

Ingenting av dette er en grunn til å vente. Vedtakene er i kraft, og sanksjonstabellen er publisert.

Hvor du får hjelp

Vi bygger koblingen mellom systemet som lager fakturaene dine og leverandøren som sender dem: datamappingen, endringer i stamdata, validering, håndtering av bekreftelser og nye forsøk, og behandling av inngående fakturaer inn i leverandørreskontroen. Vår tjeneste for e-fakturaintegrasjon beskriver hvordan det arbeidet foregår, og kommer kravet midt i et systembytte, se ERP-modernisering.

Kommer fakturaene dine fra et system ingen selger en ferdig kobling til, skriv til office@c9group.dev.