E-facturatie via Fawtara in Oman in 2027: wat maatwerk-ERP en kassasystemen nodig hebben

Oman vervangt papieren facturen en pdf-facturen door gestructureerde XML-e-facturen die via een geaccrediteerde serviceprovider lopen en aan de Oman Tax Authority (OTA) worden gerapporteerd. Het programma heet Fawtara. Belastingplichtigen met jaarlijkse leveringen boven OMR 5 miljoen beginnen op 1 april 2027. Alle andere btw-geregistreerde belastingplichtigen beginnen op 1 oktober 2027.

De detailhandel wordt het hardst geraakt. Verkopen aan consumenten vallen er vanaf dezelfde dag onder als zakelijke verkopen, en elke afzonderlijke verkoop heeft een eigen e-factuur nodig. Is uw kassasoftware, ERP-systeem of factureringsengine zelf gebouwd of zwaar aangepast, dan is het werk om die documenten aan te maken het uwe.

De data, en welke voor u geldt

De bron is de Fawtara-FAQ van de OTA, laatst bijgewerkt op 31 augustus 2026. De toets is helder. U voert e-facturatie in vanaf 1 april 2027 als een van deze twee voorwaarden waar is:

• uw leveringen van 1 april 2026 tot en met 31 maart 2027 zijn hoger dan OMR 5.000.000, of
• uw verwachte leveringen van 1 april 2027 tot en met 31 maart 2028 zijn hoger dan OMR 5.000.000.

“Wordt aan geen van beide voldaan, dan moet u e-facturatie invoeren vanaf 1 oktober 2027.”

Wat meetelt voor het bedrag: belaste leveringen, exclusief bedrijfsmiddelen, goederen en diensten onder de verleggingsregeling, en leveringen binnen de GCC. Een btw-groep wordt op groepsniveau beoordeeld, niet per lid. Een niet-ingezetene telt alleen leveringen in Oman mee.

Let op de tweede voorwaarde. Een bedrijf dat naar OMR 5 miljoen groeit, kan alleen op basis van zijn prognose in de groep van april terechtkomen. Zit u dicht bij de grens, ga dan uit van april.

De OTA biedt een tool om de invoeringsfase te controleren die uw VATIN en uw huidige en verwachte omzetklasse vraagt en een mogelijke invoeringsperiode toont. De tool is uitdrukkelijk alleen bedoeld voor bewustwording en voorbereiding, dus behandel het antwoord als richtsnoer en de FAQ als de regel.

De planning is al een keer verschoven

De eigen HTML-pagina met de FAQ van de OTA beschrijft nog het oudere plan: honderd grote bedrijven vanaf augustus 2026, alle grote bedrijven vanaf februari 2027, alle anderen vanaf augustus 2027. De pdf vervangt die data door april en oktober 2027. Voor een eerste groep geselecteerde grote belastingplichtigen (Rollout 1) blijft augustus 2026 de officiële livedatum, met een respijtperiode tot eind oktober 2026 als onderdeel van een piloot.

Eén zin in het deel over de tijdlijn in de pdf zegt dat de verplichting boven OMR 5 miljoen ingaat op “April 1st 2026”. Al het andere in hetzelfde document zegt 1 april 2027, ook het gedetailleerde antwoord over de reikwijdte dat hierboven staat. Het leest als een vergissing, maar het is een goede reden om met het primaire document te werken in plaats van met iemands samenvatting, ook de onze.

Hoe Fawtara werkt

Fawtara draait op Peppol, met een vijfhoeksmodel:

1. Hoek 1: u, de verkoper, reikt de factuur uit.
2. Hoek 2: uw geaccrediteerde serviceprovider (ASP) valideert haar tegen de Omaanse regels en geeft haar door.
3. Hoek 3: de serviceprovider van de afnemer ontvangt haar.
4. Hoek 4: de afnemer.
5. Hoek 5: de OTA, die de fiscale gegevens van de serviceproviders ontvangt.

Het formaat is XML, opgebouwd volgens de PINT Oman-specificaties die OpenPeppol publiceert (Billing Process versie 1.0.1 op het moment van schrijven). De FAQ zegt het zonder omwegen: “Een pdf-factuur is geen e-factuur.” U kunt nog steeds op papier afdrukken, maar alleen de e-factuur is een geldige factuur voor de belasting.

Drie details uit de FAQ bepalen het technische werk:

• Uw provider valideert, u blijft verantwoordelijk. De ASP controleert elke factuur tegen de Omaanse schematron-regels, maar “de verantwoordelijkheid voor de conformiteit van de factuur blijft bij de belastingplichtigen”.
• U bent met één provider tegelijk verbonden. U vraagt de koppeling aan via het Fawtara-portaal en u kunt later overstappen.
• Er is geen standaard-API voor belastingplichtigen. In de woorden van de FAQ is het koppelen van een belastingplichtige “niet gestandaardiseerd en verschilt het per systeem van de serviceprovider”. Uw ERP-systeem praat met de interface van uw provider, niet met de OTA.

Is de afnemer een consument of een bedrijf dat nog niet op het netwerk zit, dan rapporteert uw provider de fiscale gegevens toch aan de OTA, en krijgt de klant de factuur zoals nu. Export gaat van u naar uw provider naar de OTA.

Wie al gedekt is

Is uw ERP- of kassaleverancier zelf een geaccrediteerde provider, of levert die een koppeling met een provider, dan is het meeste van dit artikel niet uw probleem. De FAQ zegt dat ERP-systemen “kunnen blijven, afhankelijk van de afspraak die belastingplichtigen met hun geaccrediteerde serviceproviders hebben”, en bij een standaardsysteem is het aan de leverancier om die afspraak waar te maken. Uw werk bestaat uit stamgegevens en testen.

U kunt ook zelf serviceprovider worden. De accreditatiecriteria omvatten een Omaanse inschrijving in het handelsregister met IT-activiteiten, een minimaal gestort kapitaal, een bedrijfshistorie en ISO/IEC 27001-certificering, en de FAQ voegt daar het doorstaan van de testsuites voor Peppol eDelivery en PINT OM aan toe. Dat past bij softwarebedrijven. Voor een retailer is het geen kortere weg.

Dit artikel is voor alle anderen: bedrijven waarvan de facturen uit een maatwerk-ERP komen, uit een eigen kassasysteem, uit een factureringsengine die aan een oude database is vastgeschroefd, of uit een vestiging die facturen nog met de hand schrijft.

Wat er in uw software moet veranderen

Map uw factuurgegevens op PINT Oman

De aanwijzing van de FAQ over mapping is één regel: gebruik de Omaanse PINT-specificaties. In het semantische model gaat het meeste werk zitten in de Omaanse velden (met het voorvoegsel BTOM):

• Een UUID voor elk document (BTOM-002). Die moet RFC 4122 versie 5 zijn, en die is gebaseerd op een naam. Leid hem af van iets stabiels, zoals rechtspersoon, vestiging, kassa en documentnummer, zodat een nieuwe indieningspoging dezelfde UUID oplevert in plaats van een tweede factuur.
• Een transactietype voor de factuur (BTOM-001). Dit is een string van 20 posities waarin elke positie een vlag is: volledige belastingfactuur, vereenvoudigde belastingfactuur, selfbilling, derde partij, export, fictieve levering, verlegging bij invoer van diensten, winstmarge, e-commerce, invoer van goederen, levering in een speciale zone, vooruitbetaling en andere. Er kunnen meerdere vlaggen aanstaan. Uw systeem moet weten welke voor elke factuur gelden, en de meeste ERP-systemen hebben dat nooit opgeslagen.
• Identificaties van verkoper en afnemer met een schemacode: inschrijving in het handelsregister, fiscaal identificatienummer, civiel ID, paspoort, douane-ID van de importeur of vergunningsnummer voor een speciale zone.
• Valuta. Factuurvaluta, valuta van de btw-administratie, de wisselkoers daartussen en het btw-totaal in de administratievaluta hebben elk een eigen veld.
• Codelijsten voor btw-vrijstelling, redenen voor het nultarief, soorten diensten en regio's.

Reken erop dat de factuurregels netjes te mappen zijn en de stamgegevens niet. Klantrecords zonder VATIN, ontbrekende CR-nummers, redenen voor vrijstelling in vrije tekst en adressen zonder regiocode moeten allemaal worden opgeschoond vóór de eerste live factuur.

Behandel elke verkoop als document

Dit is de regel die kassasystemen verandert: “Verzamelfacturen zijn niet toegestaan voor B2C-transacties. Voor elke factuur moet een afzonderlijke e-factuur worden uitgereikt.” Geen dagtotaal. Een winkel die 3.000 verkopen per dag aanslaat, verstuurt 3.000 e-facturen per dag.

De FAQ geeft B2C-indieningen 24 uur en B2B-indieningen realtime. Voor een kassa betekent dat:

• De kassa bouwt de XML (of geeft de verkoop door aan een dienst die dat doet) op het moment van verkoop, met de UUID. Er is een apart veld voor de UUID van de bon bij B2C (BTOM-004).
• Een store-and-forward-wachtrij houdt documenten vast als het netwerk of de provider plat ligt, en verwerkt ze binnen de 24 uur.
• Iemand krijgt een waarschuwing als een document na een paar uur nog niet is verstuurd, niet na drieëntwintig.

Leg de prijzen van providers naast uw volume voordat u tekent. Volgens de FAQ bepaalt elke provider zijn eigen model, dat “abonnementskosten, kosten per transactie of andere prijsafspraken kan omvatten”. Bij retailvolumes is een prijs per document een post op de begroting.

B2B in realtime

Voor zakelijke facturen is de indiening realtime. Uw ERP-systeem boekt de factuur, de provider valideert haar en het resultaat komt terug. Dat verandert de factuurworkflow op twee manieren. Validatiefouten komen nu op het moment van boeken boven, dus iemand op de financiële afdeling heeft een scherm nodig dat de afwijzing toont en waarin hij haar kan herstellen. En factuurnummering, de UUID en de logica voor nieuwe pogingen moeten vanaf de eerste dag kloppen, want een time-out gevolgd door blind opnieuw versturen is precies hoe dubbele facturen ontstaan.

De stroom loopt ook de andere kant op. Bent u de afnemer, dan komen e-facturen van leveranciers die al op Fawtara zitten als XML binnen via uw provider, en de crediteurenadministratie heeft een manier nodig om ze in te lezen.

QR-codes op de afgedrukte bon

De QR-code wordt door u (hoek 1) gegenereerd, niet door de provider. Ze is verplicht voor alle B2C-transacties, volledig of vereenvoudigd, en staat op de leesbare factuur, niet in de XML. De OTA wil haar gebruiken om facturen via een mobiele app te verifiëren. Voor de inhoud verwijst de FAQ naar bijlage D van het Peppol Oman Architecture-document (versie 1.0.2): haal die bijlage op voordat iemand een bon herontwerpt. Bonsjablonen en printerdrivers horen bij dit project.

Creditnota's, retouren en correcties

Eenmaal uitgereikt, wordt een e-factuur gecorrigeerd met een elektronische credit- of debetnota. De specificatie heeft velden voor de UUID van de oorspronkelijke factuur en een redencode (BTOM-031 en BTOM-032), dus een terugbetaling aan de kassa moet de oorspronkelijke verkoop kunnen terugvinden.

Invoer en selfbilling

Invoer van goederen en diensten wordt gerapporteerd als factuur via selfbilling. Boekt uw inkoopproces invoer zonder een document aan te maken, dan komt daar een nieuwe stap bij.

Archivering

De opslag blijft bij u. Volgens de FAQ geeft de OTA geen factuurinformatie terug aan belastingplichtigen, en Peppol bewaart geen documenten. Bewaar de gevalideerde XML, het antwoord van de provider en de afgedrukte versie bij elkaar, volgens de bewaarregels van de btw-wetgeving.

Een plan terug vanaf de deadline

Volgens de FAQ neemt de OTA minstens zes maanden vóór de onboarding contact op met deelnemers aan een invoeringsfase. Voor de groep van april is dat nu.

Begint u op 1 april 2027:

1. Oktober 2026: bevestig uw groep met de controletool en de toets uit de FAQ. Maak een lijst van elk systeem dat een factuur uitreikt: ERP, elke kassa, de afrekenpagina van de webwinkel, verhuur- of abonnementsfacturatie, en elk handmatig factuurboek.
2. November 2026: kies een provider. Vraag om API-documentatie en een sandbox voordat u tekent, en vraag naar B2C-volume, de prijs per document, offlineafhandeling en hoe validatieantwoorden eruitzien. Vraag de koppeling aan via het Fawtara-portaal.
3. December 2026 tot januari 2027: bouwen. Veldmapping, UUID-generatie, logica voor transactietypen, de wachtrij in de kassa, QR-codes, de stroom voor creditnota's, inkomende facturen. Draai de Omaanse schematron-regels uit de PINT Oman-downloads in uw eigen testpijplijn, zodat fouten in de ontwikkeling opduiken en niet bij de provider.
4. Februari 2027: end-to-endtests tegen de sandbox van de provider met echte voorbeelden van elk transactietype dat u werkelijk uitreikt, ook de lastige (export, retouren zonder bon, vreemde valuta).
5. Maart 2027: een generale repetitie in productie met één vestiging of bedrijfsonderdeel, een overschakelplan en een supportrooster voor de eerste weken.

Begint u op 1 oktober 2027, dan is de volgorde dezelfde, zes maanden later: provider gekozen aan het eind van het eerste kwartaal, bouwen in het tweede, testen afgerond in augustus. Verspil de speling niet. Het opschonen van de data duurt altijd langer dan iemand schat.

Wat nog onzeker is

De data zijn al een keer verschoven en kunnen opnieuw verschuiven. Plan op basis van de pdf van 31 augustus 2026, en controleer elke maand de documenten van de OTA in plaats van op nieuwsberichten te vertrouwen. De wettelijke basis is Besluit 189/2026, dat het uitvoeringsreglement van de btw-wet wijzigt. Volgens de FAQ gelden er boetes onder de btw-wetgeving zodra de verplichting ingaat, maar bedragen noemt ze niet, en wij dus ook niet.

Ook de specificaties hebben versies. Het huidige PINT Oman-pakket op de Peppol-site draagt als releasedatum 29 juli 2026. Leg de versie vast waartegen u bouwt, en volg de releasenotes.

Waar u hulp krijgt

Wij bouwen de koppeling tussen het systeem dat u werkelijk draait en het formaat dat de verplichting eist: veldmapping, logica voor UUID's en nummering, wachtrijen in de kassa, validatie in uw pijplijn, en de integratie met de provider die u kiest. Onze dienst voor e-facturatie-integratie dekt dat werk, en is het ERP-systeem zelf het obstakel, dan begint het bij ERP-modernisering.

Zit u in de groep van april en hebt u nog geen provider gekozen, schrijf dan naar office@c9group.dev.