Von Kristijan Sekereš

Omans E-Rechnung Fawtara 2027: Was individuelle ERP- und Kassensysteme brauchen

Uferpromenade von Muttrah in Maskat mit Bergen hinter der Stadt

Oman ersetzt Rechnungen auf Papier und als PDF durch strukturierte E-Rechnungen im XML-Format, die über einen akkreditierten Dienstleister laufen und an die omanische Steuerbehörde (Oman Tax Authority, OTA) gemeldet werden. Das Programm heißt Fawtara. Steuerpflichtige mit jährlichen Umsätzen über 5 Millionen OMR beginnen am 1. April 2027. Alle anderen für die Mehrwertsteuer registrierten Steuerpflichtigen beginnen am 1. Oktober 2027.

Am härtesten trifft es den Einzelhandel. Verkäufe an Verbraucher sind ab demselben Tag erfasst wie Verkäufe an Unternehmen, und jeder einzelne Verkauf braucht eine eigene E-Rechnung. Wenn Ihre Kassensoftware, Ihr ERP oder Ihre Abrechnungs-Engine selbst entwickelt oder stark angepasst ist, liegt die Arbeit, diese Dokumente zu erzeugen, bei Ihnen.

Die Termine und welcher für Sie gilt

Quelle ist die Fawtara-FAQ der OTA, zuletzt aktualisiert am 31. August 2026. Der Test ist klar beschrieben. Sie führen ab dem 1. April 2027 ein, wenn eine dieser Bedingungen erfüllt ist:

  • Ihre Umsätze vom 1. April 2026 bis 31. März 2027 übersteigen 5.000.000 OMR, oder
  • Ihre erwarteten Umsätze vom 1. April 2027 bis 31. März 2028 übersteigen 5.000.000 OMR.

„Ist keine der beiden Bedingungen erfüllt, müssen Sie die E-Rechnung ab dem 1. Oktober 2027 einführen.“

Was in den Betrag einfließt: steuerpflichtige Umsätze ohne Anlagegüter, ohne Waren und Dienstleistungen im Reverse-Charge-Verfahren und ohne Lieferungen innerhalb des Golf-Kooperationsrats (GCC). Eine Mehrwertsteuergruppe wird auf Gruppenebene beurteilt, nicht Mitglied für Mitglied. Ein Gebietsfremder zählt nur Umsätze, die er in Oman erbringt.

Beachten Sie die zweite Bedingung. Ein Unternehmen, das auf 5 Millionen OMR zuwächst, kann allein aufgrund seiner Prognose in der April-Gruppe landen. Wenn Sie in der Nähe der Grenze liegen, gehen Sie von April aus.

Die OTA betreibt ein Prüfwerkzeug für die Einführungsphasen, das Ihre VATIN sowie Ihre aktuelle und erwartete Umsatzklasse abfragt und einen möglichen Einführungszeitraum anzeigt. Es ist ausdrücklich nur zur Information und Vorbereitung gedacht, behandeln Sie seine Antwort also als Orientierung und die FAQ als Regel.

Der Zeitplan hat sich schon einmal verschoben

Die HTML-FAQ-Seite der OTA beschreibt noch den älteren Plan: hundert große Unternehmen ab August 2026, alle großen Unternehmen ab Februar 2027, alle anderen ab August 2027. Das PDF ersetzt diese Termine durch April und Oktober 2027. Für eine erste Gruppe ausgewählter großer Steuerpflichtiger (Rollout 1) bleibt August 2026 der offizielle Go-live-Termin, mit einer Übergangsfrist bis Ende Oktober 2026 als Teil eines Pilotbetriebs.

Ein Satz im Abschnitt zum Zeitplan des PDF sagt, die verpflichtende Einhaltung über 5 Millionen OMR gelte ab „April 1st 2026“. Alles andere im selben Dokument nennt den 1. April 2027, auch die oben zitierte ausführliche Antwort zum Anwendungsbereich. Das wirkt wie ein Versehen, ist aber ein guter Grund, mit dem Originaldokument zu arbeiten und nicht mit irgendjemandes Zusammenfassung, unsere eingeschlossen.

So funktioniert Fawtara

Fawtara läuft auf Peppol, mit einem Fünf-Ecken-Modell:

  1. Ecke 1: Sie, der Verkäufer, stellen die Rechnung aus.
  2. Ecke 2: Ihr akkreditierter Dienstleister (ASP) prüft sie gegen die omanischen Regeln und leitet sie weiter.
  3. Ecke 3: der Dienstleister des Käufers empfängt sie.
  4. Ecke 4: der Käufer.
  5. Ecke 5: die OTA, die die Steuerdaten von den Dienstleistern erhält.

Das Format ist XML nach den PINT-Oman-Spezifikationen, die OpenPeppol veröffentlicht (zum Zeitpunkt dieses Artikels Billing Process in Version 1.0.1). Die FAQ sagt unmissverständlich: „Eine PDF-Rechnung ist keine E-Rechnung.“ Papier dürfen Sie weiterhin drucken, steuerlich gültig ist aber nur die E-Rechnung.

Drei Details aus der FAQ prägen die technische Umsetzung:

  • Ihr Dienstleister prüft, Sie bleiben verantwortlich. Der ASP prüft jede Rechnung gegen die omanischen Schematron-Regeln, aber „die Verantwortung für die Ordnungsmäßigkeit der Rechnung bleibt bei den Steuerpflichtigen“.
  • Sie sind jeweils mit einem Dienstleister verbunden. Die Verknüpfung beantragen Sie über das Fawtara-Portal, und Sie können später wechseln.
  • Es gibt keine standardisierte API für Steuerpflichtige. In den Worten der FAQ ist die Anbindung eines Steuerpflichtigen „nicht standardisiert und hängt vom System des Dienstleisters ab“. Ihr ERP spricht mit der Schnittstelle Ihres Dienstleisters, nicht mit der OTA.

Wenn der Käufer ein Verbraucher oder ein Unternehmen ist, das noch nicht im Netz ist, meldet Ihr Dienstleister die Steuerdaten trotzdem an die OTA, und der Kunde erhält die Rechnung so wie heute. Exporte gehen von Ihnen über Ihren Dienstleister an die OTA.

Wer bereits abgedeckt ist

Wenn der Anbieter Ihres ERP oder Ihrer Kasse selbst ein akkreditierter Dienstleister ist oder einen Konnektor zu einem liefert, ist das meiste in diesem Artikel nicht Ihr Problem. Laut FAQ können ERP-Systeme „auf Grundlage der Vereinbarung der Steuerpflichtigen mit ihren akkreditierten Dienstleistern beibehalten werden“, und bei einem Standardsystem ist es Sache des Anbieters, diese Vereinbarung umzusetzen. Ihre Arbeit sind Stammdaten und Tests.

Sie könnten auch Ihr eigener Dienstleister werden. Zu den Akkreditierungskriterien gehören eine omanische Handelsregistrierung mit IT-Tätigkeit, ein Mindestkapital, eine Betriebshistorie und eine Zertifizierung nach ISO/IEC 27001, und die FAQ ergänzt das Bestehen der Testsuiten für Peppol eDelivery und PINT OM. Das passt zu Softwareunternehmen. Für einen Einzelhändler ist es keine Abkürzung.

Dieser Artikel richtet sich an alle anderen: Unternehmen, deren Rechnungen aus einem individuellen ERP kommen, aus einem selbst entwickelten Kassensystem, einer Abrechnungs-Engine auf einer alten Datenbank oder aus einer Filiale, die Rechnungen noch von Hand schreibt.

Was sich in Ihrer Software ändern muss

Rechnungsdaten auf PINT Oman abbilden

Die Anleitung der FAQ zur Zuordnung besteht aus einer Zeile: Verwenden Sie die omanischen PINT-Spezifikationen. Im semantischen Modell machen die omanspezifischen Felder (mit dem Präfix BTOM) den größten Teil des Aufwands aus:

  • Eine UUID für jedes Dokument (BTOM-002). Sie muss RFC 4122 Version 5 entsprechen, also namensbasiert sein. Leiten Sie sie aus etwas Stabilem ab, etwa juristischer Person, Filiale, Kasse und Belegnummer, dann erzeugt eine wiederholte Übermittlung dieselbe UUID statt einer zweiten Rechnung.
  • Ein Rechnungstransaktionstyp (BTOM-001). Das ist eine Zeichenkette mit 20 Stellen, in der jede Stelle ein Kennzeichen ist: vollständige Steuerrechnung, vereinfachte Steuerrechnung, Gutschriftsverfahren, Rechnung durch Dritte, Export, fiktive Lieferung, Reverse-Charge bei importierten Dienstleistungen, Differenzbesteuerung, E-Commerce, Wareneinfuhr, Lieferung in einer Sonderzone, Anzahlung und weitere. Es können mehrere Kennzeichen gesetzt sein. Ihr System muss wissen, welche für jede Rechnung gelten, und die meisten ERP-Systeme haben das nie gespeichert.
  • Kennungen von Verkäufer und Käufer mit einem Schema-Code: Handelsregistrierung, Steueridentifikationsnummer, Personalausweis, Reisepass, Zollkennung des Importeurs oder Lizenznummer der Sonderzone.
  • Währung. Rechnungswährung, Buchungswährung für die Mehrwertsteuer, der Wechselkurs zwischen beiden und die Mehrwertsteuersumme in der Buchungswährung haben jeweils eigene Felder.
  • Codelisten für Steuerbefreiungen, Gründe für den Nullsatz, Dienstleistungsarten und Landesuntergliederungen.

Rechnen Sie damit, dass sich die Rechnungspositionen sauber abbilden lassen und die Stammdaten nicht. Kundenstammsätze ohne VATIN, fehlende Handelsregisternummern, Befreiungsgründe im Freitext und Adressen ohne Regionscode müssen vor der ersten echten Rechnung bereinigt sein.

Jeder Verkauf ist ein Dokument

Diese Regel verändert Kassensysteme: „Sammelrechnungen sind für B2C-Umsätze nicht zulässig. Für jede Rechnung muss eine eigene E-Rechnung ausgestellt werden.“ Keine Tageszusammenfassung. Ein Geschäft mit 3.000 Verkäufen am Tag sendet 3.000 E-Rechnungen am Tag.

Die FAQ gibt B2C-Übermittlungen 24 Stunden und B2B-Übermittlungen Echtzeit. Für eine Kasse bedeutet das:

  • Die Kasse erstellt das XML (oder übergibt den Verkauf an einen Dienst, der es tut) im Moment des Verkaufs, mit seiner UUID. Für B2C gibt es ein eigenes Feld für die UUID des Kassenbons (BTOM-004).
  • Eine Store-and-Forward-Warteschlange hält die Dokumente, wenn das Netz oder der Dienstleister ausfällt, und arbeitet sie innerhalb der 24 Stunden ab.
  • Jemand wird alarmiert, wenn ein Dokument nach einigen Stunden noch nicht gesendet ist, nicht erst nach dreiundzwanzig.

Prüfen Sie die Preise des Dienstleisters anhand Ihres Volumens, bevor Sie unterschreiben. Laut FAQ legt jeder Dienstleister sein eigenes Modell fest, das „Abonnementgebühren, transaktionsbasierte Gebühren oder andere Preismodelle umfassen kann“. Bei Einzelhandelsvolumen ist eine Gebühr pro Dokument ein Posten im Budget.

B2B in Echtzeit

Bei Rechnungen an Unternehmen erfolgt die Übermittlung in Echtzeit. Ihr ERP bucht die Rechnung, der Dienstleister prüft sie, und das Ergebnis kommt zurück. Das verändert den Rechnungsablauf auf zwei Arten. Prüffehler zeigen sich jetzt im Moment der Buchung, jemand in der Finanzabteilung braucht also eine Ansicht, die die Ablehnung zeigt und die Korrektur erlaubt. Und Rechnungsnummerierung, UUID und Wiederholungslogik müssen ab dem ersten Tag stimmen, denn eine Zeitüberschreitung mit anschließendem blindem Neuversand ist genau der Weg, auf dem doppelte Rechnungen entstehen.

Der Fluss läuft auch in die andere Richtung. Wenn Sie der Käufer sind, kommen E-Rechnungen von Lieferanten, die bereits bei Fawtara sind, als XML über Ihren Dienstleister an, und die Kreditorenbuchhaltung braucht einen Weg, sie zu übernehmen.

QR-Codes auf dem gedruckten Beleg

Den QR-Code erzeugen Sie (Ecke 1), nicht der Dienstleister. Er ist für alle B2C-Umsätze Pflicht, ob vollständige oder vereinfachte Rechnung, und erscheint auf der lesbaren Rechnung, nicht im XML. Die OTA plant, Rechnungen damit über eine mobile App zu prüfen. Für seinen Inhalt verweist die FAQ auf Anhang D des Dokuments zur Peppol-Oman-Architektur (Version 1.0.2): Besorgen Sie diesen Anhang, bevor jemand einen Kassenbon neu gestaltet. Belegvorlagen und Druckertreiber gehören zu diesem Projekt.

Gutschriften, Rücknahmen und Korrekturen

Eine einmal ausgestellte E-Rechnung wird durch eine elektronische Gutschrift oder Lastschrift korrigiert. Die Spezifikation hat Felder für die UUID der ursprünglichen Rechnung und einen Grundcode (BTOM-031 und BTOM-032), eine Erstattung an der Kasse muss den ursprünglichen Verkauf also finden können.

Importe und Gutschriftsverfahren

Importe von Waren und Dienstleistungen werden als Rechnungen im Gutschriftsverfahren gemeldet. Wenn Ihr Beschaffungsprozess Importe bucht, ohne ein Dokument zu erzeugen, kommt dort ein neuer Schritt hinzu.

Archivierung

Die Aufbewahrung bleibt bei Ihnen. Laut FAQ stellt die OTA den Steuerpflichtigen keine Rechnungsinformationen zurück zur Verfügung, und Peppol speichert keine Dokumente. Bewahren Sie das geprüfte XML, die Antwort des Dienstleisters und die gedruckte Fassung zusammen auf, nach den Aufbewahrungsregeln des Mehrwertsteuerrechts.

Ein Plan rückwärts vom Stichtag

Laut FAQ meldet sich die OTA bei den Teilnehmern einer Einführungsphase mindestens sechs Monate vor ihrem Onboarding. Für die April-Gruppe ist das jetzt.

Wenn Sie am 1. April 2027 beginnen:

  1. Oktober 2026: Bestätigen Sie Ihre Gruppe mit dem Prüfwerkzeug und dem Test aus der FAQ. Listen Sie jedes System auf, das eine Rechnung ausstellt: ERP, jede Kasse, den Checkout im E-Commerce, Miet- oder Abonnementabrechnung und jedes manuelle Rechnungsbuch.
  2. November 2026: Wählen Sie einen Dienstleister. Verlangen Sie vor der Unterschrift API-Dokumentation und eine Sandbox, und fragen Sie nach B2C-Volumen, Preis pro Dokument, Offline-Verarbeitung und dem Aussehen der Prüfantworten. Beantragen Sie die Verknüpfung über das Fawtara-Portal.
  3. Dezember 2026 bis Januar 2027: Umsetzung. Feldzuordnung, UUID-Erzeugung, Logik für die Transaktionstypen, die Warteschlange der Kasse, QR-Codes, Ablauf für Gutschriften, eingehende Rechnungen. Lassen Sie die omanischen Schematron-Regeln aus den Downloads zu PINT Oman in Ihrer eigenen Testpipeline laufen, damit Fehler in der Entwicklung auftauchen und nicht beim Dienstleister.
  4. Februar 2027: Ende-zu-Ende-Tests gegen die Sandbox des Dienstleisters mit echten Beispielen jedes Transaktionstyps, den Sie tatsächlich ausstellen, einschließlich der unangenehmen (Exporte, Rücknahmen ohne Beleg, Fremdwährung).
  5. März 2027: eine Generalprobe in der Produktion mit einer Filiale oder einem Geschäftsbereich, ein Plan für die Umstellung und ein Supportdienstplan für die ersten Wochen.

Wenn Sie am 1. Oktober 2027 beginnen, ist die Reihenfolge dieselbe, um sechs Monate verschoben: Dienstleister bis Ende des ersten Quartals gewählt, Umsetzung im zweiten, Tests bis August abgeschlossen. Verbrauchen Sie den Puffer nicht. Die Datenbereinigung dauert immer länger, als irgendjemand schätzt.

Was noch unsicher ist

Die Termine haben sich einmal verschoben und könnten sich wieder verschieben. Planen Sie nach dem PDF vom 31. August 2026 und prüfen Sie die Dokumente der OTA jeden Monat, statt sich auf Presseberichte zu verlassen. Die Rechtsgrundlage ist der Beschluss 189/2026, der die Durchführungsverordnung zum Mehrwertsteuergesetz ändert. Laut FAQ gelten mit Beginn der Pflicht Sanktionen nach dem Mehrwertsteuerrecht, Beträge nennt sie aber nicht, also nennen wir auch keine.

Auch die Spezifikationen sind versioniert. Das aktuelle PINT-Oman-Paket auf der Peppol-Website trägt das Veröffentlichungsdatum 29. Juli 2026. Legen Sie die Version fest, gegen die Sie bauen, und verfolgen Sie die Release Notes.

Wo Sie Hilfe bekommen

Wir bauen den Konnektor zwischen dem System, das Sie tatsächlich betreiben, und dem Format, das die Pflicht verlangt: Feldzuordnung, Logik für UUID und Nummerierung, Warteschlangen für Kassen, Prüfung in Ihrer Pipeline und die Integration mit dem Dienstleister Ihrer Wahl. Unsere Leistung zur E-Rechnungs-Integration deckt diese Arbeit ab, und wenn das ERP selbst das Hindernis ist, beginnt es bei der ERP-Modernisierung.

Wenn Sie zur April-Gruppe gehören und noch keinen Dienstleister gewählt haben, schreiben Sie an office@c9group.dev.