2027'de Umman'ın Fawtara e-Fatura Sistemi: Özel ERP ve POS Sistemlerinin İhtiyaç Duydukları

Umman, kâğıt ve PDF faturaların yerine akredite bir hizmet sağlayıcıdan geçen ve Umman Vergi İdaresi'ne (Oman Tax Authority, OTA) raporlanan yapılandırılmış XML e-faturaları getiriyor. Programın adı Fawtara. Yıllık teslim tutarı 5 milyon OMR'nin üzerinde olan mükellefler 1 Nisan 2027'de başlıyor. KDV'ye kayıtlı diğer tüm mükellefler ise 1 Ekim 2027'de başlıyor.

En ağır etki perakendede. Tüketici satışları, işletmeler arası satışlarla aynı gün kapsama giriyor ve her bir satış için ayrı bir e-fatura gerekiyor. Kasa yazılımınız, ERP'niz ya da faturalama motorunuz şirket içinde geliştirildiyse veya yoğun biçimde özelleştirildiyse, bu belgeleri üretme işi size düşüyor.

Tarihler ve Sizin İçin Geçerli Olanı

Kaynak, OTA'nın en son 31 Ağustos 2026'da güncellenen Fawtara SSS belgesi. Ölçüt açıkça ortaya konmuş. Aşağıdakilerden biri doğruysa 1 Nisan 2027'den itibaren uygulamaya geçersiniz:

• 1 Nisan 2026 ile 31 Mart 2027 arasındaki teslimleriniz 5.000.000 OMR'yi aşıyorsa veya
• 1 Nisan 2027 ile 31 Mart 2028 arasında beklenen teslimleriniz 5.000.000 OMR'yi aşıyorsa.

“Hiçbiri karşılanmıyorsa e-faturayı 1 Ekim 2027'den itibaren uygulamanız gerekir.”

Tutara dahil olanlar: duran varlıklar, tersine vergilendirme (reverse charge) mekanizmasına tabi mal ve hizmetler ile KİK (GCC) içi teslimler hariç vergiye tabi teslimler. Bir KDV grubu üye bazında değil, grup düzeyinde değerlendirilir. Yerleşik olmayan bir kişi için yalnızca Umman'da yapılan teslimler sayılır.

İkinci koşula dikkat edin. 5 milyon OMR'ye doğru büyüyen bir işletme yalnızca tahminine dayanarak Nisan grubuna düşebilir. Sınıra yakınsanız Nisan'ı varsayın.

OTA'nın sunduğu bir geçiş kontrol aracı, VKN'nizi (VATIN) ve mevcut ve beklenen teslim aralığınızı alıyor ve olası bir uygulama dönemi gösteriyor. Aracın yalnızca farkındalık ve hazırlık amaçlı olduğu belirtiliyor; bu nedenle yanıtını bir yol gösterici, SSS belgesini ise kural olarak görün.

Takvim bir kez değişti

OTA'nın kendi HTML SSS sayfası hâlâ eski planı anlatıyor: Ağustos 2026'dan itibaren yüz büyük şirket, Şubat 2027'den itibaren tüm büyük şirketler, Ağustos 2027'den itibaren diğer herkes. PDF bu tarihlerin yerine Nisan ve Ekim 2027'yi koyuyor. Seçilmiş büyük mükelleflerden oluşan ilk grup (Rollout 1) için Ağustos 2026 resmî canlıya geçiş tarihi olmaya devam ediyor; bir pilot uygulama kapsamında Ekim 2026 sonuna kadar bir geçiş süresi tanınıyor.

PDF'in takvim bölümündeki bir cümle, 5 milyon OMR'nin üzerindeki mükellefler için zorunlu uyumun “1 Nisan 2026”da yürürlüğe girdiğini söylüyor. Aynı belgenin geri kalanı ise yukarıda alıntılanan ayrıntılı kapsam yanıtı dahil her yerde 1 Nisan 2027 diyor. Bir dikkatsizlik gibi duruyor, ancak bizimki dahil herhangi birinin özeti yerine birincil belgeden çalışmak için iyi bir neden.

Fawtara Nasıl Çalışıyor

Fawtara, beş köşeli bir model kullanan Peppol üzerinde çalışıyor:

1. Köşe 1: satıcı olarak siz faturayı düzenlersiniz.
2. Köşe 2: akredite hizmet sağlayıcınız (ASP) faturayı Umman kurallarına göre doğrular ve iletir.
3. Köşe 3: alıcının hizmet sağlayıcısı faturayı alır.
4. Köşe 4: alıcı.
5. Köşe 5: vergi verilerini hizmet sağlayıcılardan alan OTA.

Biçim, OpenPeppol'ün yayımladığı PINT Oman spesifikasyonlarına göre oluşturulan XML (bu yazının yazıldığı sırada Billing Process sürüm 1.0.1). SSS belgesi açık sözlü: “PDF fatura bir e-fatura değildir.” Kâğıda yine çıktı alabilirsiniz, ancak vergi açısından geçerli fatura yalnızca e-faturadır.

SSS belgesindeki üç ayrıntı mühendislik çalışmasını şekillendiriyor:

• Doğrulamayı sağlayıcınız yapar, sorumluluk sizde kalır. ASP her faturayı Umman schematron kurallarına göre kontrol eder, ancak “fatura uyumunun sorumluluğu mükelleflerde kalır.”
• Aynı anda tek bir sağlayıcıya bağlanırsınız. Bağlantıyı Fawtara portalı üzerinden talep edersiniz ve sonradan sağlayıcı değiştirebilirsiniz.
• Standart bir mükellef API'si yok. SSS belgesinin ifadesiyle bir mükellefin bağlanması “standartlaştırılmamıştır ve hizmet sağlayıcının sistemine göre değişir.” ERP'niz OTA ile değil, sağlayıcınızın arayüzüyle konuşur.

Alıcı bir tüketici ya da henüz ağa katılmamış bir işletme olduğunda sağlayıcınız vergi verilerini yine OTA'ya raporlar ve müşteri faturayı bugün aldığı şekilde alır. İhracatta akış sizden sağlayıcınıza, oradan OTA'ya gider.

Kimler zaten kapsanıyor

ERP ya da POS tedarikçiniz kendisi akredite bir sağlayıcıysa veya böyle bir sağlayıcıya bağlantı sunuyorsa, bu yazının büyük kısmı sizi ilgilendirmiyor. SSS belgesi ERP sistemlerinin “mükelleflerin akredite hizmet sağlayıcılarıyla yaptıkları düzenlemeye göre korunabileceğini” söylüyor ve paket bir sistemde bu düzenlemeyi sağlamak tedarikçinin işi. Sizin işiniz ana veriler ve test.

Kendi hizmet sağlayıcınız olmayı da seçebilirsiniz. Akreditasyon ölçütleri arasında bilişim faaliyetlerini içeren bir Umman ticaret sicil kaydı, asgari ödenmiş sermaye, faaliyet geçmişi ve ISO/IEC 27001 sertifikası var; SSS belgesi buna Peppol eDelivery ve PINT OM test paketlerini geçmeyi ekliyor. Bu yazılım şirketlerine uygun. Bir perakendeci için kestirme bir yol değil.

Bu yazı diğer herkes için: faturaları özel bir ERP'den, şirket içinde geliştirilmiş bir kasa sisteminden, eski bir veritabanına sonradan eklenmiş bir faturalama motorundan çıkan ya da hâlâ elle fatura yazan bir şubesi olan şirketler.

Yazılımınızda Neyin Değişmesi Gerekiyor

Fatura verilerinizi PINT Oman'a eşleyin

SSS belgesinin eşleme konusundaki rehberliği tek satır: Umman PINT spesifikasyonlarını kullanın. Anlamsal modelde emeğin çoğu, Umman'a özgü alanlara (BTOM önekli) gidiyor:

• Her belge için bir UUID (BTOM-002). Ada dayalı olan RFC 4122 sürüm 5 olmak zorunda. Bunu tüzel kişilik, şube, kasa ve belge numarası gibi sabit bir şeyden türetin; böylece yeniden denenen bir gönderim ikinci bir fatura yerine aynı UUID'yi üretir.
• Bir fatura işlem türü (BTOM-001). Bu, her konumun bir bayrak olduğu 20 konumlu bir dizedir: tam vergi faturası, basitleştirilmiş vergi faturası, alıcı tarafından düzenlenen fatura (self-billed), üçüncü taraf, ihracat, teslim sayılan işlem, hizmet ithalatında tersine vergilendirme, kâr marjı, e-ticaret, mal ithalatı, özel bölge teslimi, ön ödeme ve diğerleri. Birden fazla bayrak işaretlenebilir. Sisteminizin her faturaya hangilerinin uygulandığını bilmesi gerekir ve çoğu ERP bu bilgiyi hiç saklamadı.
• Satıcı ve alıcı tanımlayıcıları, bir şema koduyla: ticaret sicil kaydı, vergi kimlik numarası, sivil kimlik, pasaport, ithalatçı gümrük kimliği veya özel bölge lisans numarası.
• Para birimi. Fatura para birimi, KDV muhasebe para birimi, ikisi arasındaki döviz kuru ve muhasebe para birimindeki KDV toplamının her birinin kendi alanı var.
• Kod listeleri: KDV istisnası, sıfır oran gerekçeleri, hizmet türleri ve ülkenin idari alt bölümleri için.

Fatura satırlarının sorunsuz eşlenmesini, ana verilerin ise eşlenmemesini bekleyin. VKN'si olmayan müşteri kayıtları, eksik ticaret sicil numaraları, serbest metinle yazılmış istisna gerekçeleri ve bölge kodu olmayan adreslerin tamamı ilk canlı faturadan önce temizlenmeli.

Her satışı bir belge olarak ele alın

POS sistemlerini değiştiren kural bu: “B2C işlemlerinde toplu faturaya izin verilmez. Her fatura için ayrı bir e-fatura düzenlenmelidir.” Gün sonu özeti yok. Günde 3.000 satış yapan bir mağaza günde 3.000 e-fatura gönderir.

SSS belgesi B2C gönderimler için 24 saat, B2B gönderimler için gerçek zamanlı süre öngörüyor. Bir kasa için bunun anlamı şu:

• POS, XML'i satış anında UUID'siyle birlikte oluşturur (ya da satışı bunu yapan bir servise iletir). B2C için ayrı bir fiş UUID alanı var (BTOM-004).
• Ağ ya da sağlayıcı devre dışı olduğunda bir depola ve ilet kuyruğu belgeleri tutar ve 24 saat içinde gönderir.
• Bir belge birkaç saat sonra hâlâ gönderilmemişse yirmi üç saat sonra değil, o zaman birine uyarı gider.

İmzalamadan önce sağlayıcı fiyatlandırmasını hacminize göre kontrol edin. SSS belgesi her sağlayıcının kendi modelini belirlediğini ve bunun “abonelik ücretlerini, işlem bazlı ücretleri veya diğer fiyatlandırma düzenlemelerini içerebileceğini” söylüyor. Perakende hacimlerinde belge başına ücret bütçede ayrı bir kalem olur.

Gerçek zamanlı B2B

İşletme faturalarında gönderim gerçek zamanlıdır. ERP'niz faturayı kaydeder, sağlayıcı doğrular ve sonuç geri gelir. Bu, fatura iş akışını iki şekilde değiştirir. Doğrulama hataları artık kayıt anında ortaya çıkar; bu nedenle finans ekibinden birinin reddi gösteren ve düzeltmeye olanak tanıyan bir ekrana ihtiyacı vardır. Fatura numaralandırma, UUID ve yeniden deneme mantığı ise ilk günden doğru olmalıdır, çünkü mükerrer faturalar bir zaman aşımının ardından körlemesine yapılan yeniden gönderimle ortaya çıkar.

Akış ters yönde de işler. Alıcı konumunda olduğunuzda, Fawtara'ya zaten katılmış şirketlerden gelen tedarikçi e-faturaları sağlayıcınız üzerinden XML olarak ulaşır ve borç hesapları ekibinin bunları sisteme almanın bir yoluna ihtiyacı vardır.

Basılı fişteki QR kodlar

QR kodu sağlayıcı değil, siz (köşe 1) üretirsiniz. Tam veya basitleştirilmiş tüm B2C işlemleri için zorunludur ve XML'de değil, insanların okuyabileceği faturada yer alır. OTA bunu faturaları bir mobil uygulama üzerinden doğrulamak için kullanmayı planlıyor. İçeriği için SSS belgesi Peppol Oman Architecture belgesinin (sürüm 1.0.2) D Ekine yönlendiriyor: biri fiş tasarımını değiştirmeden önce bu eki edinin. Fiş şablonları ve yazıcı sürücüleri bu projenin parçası.

Alacak dekontları, iadeler ve düzeltmeler

Düzenlendikten sonra bir e-fatura, elektronik alacak veya borç dekontu düzenlenerek düzeltilir. Spesifikasyonda orijinal faturanın UUID'si ve bir gerekçe kodu için alanlar var (BTOM-031 ve BTOM-032); bu nedenle kasada yapılan bir iadenin orijinal satışı bulabilmesi gerekir.

İthalat ve alıcı tarafından düzenlenen faturalar

Mal ve hizmet ithalatı, alıcı tarafından düzenlenen (self-billed) faturalar olarak raporlanır. Satın alma akışınız ithalatı herhangi bir belge düzenlemeden kaydediyorsa, orada yeni bir adım ortaya çıkar.

Arşivleme

Saklama sizin sorumluluğunuzda kalır. SSS belgesi OTA'nın fatura bilgilerini mükelleflere geri vermeyeceğini söylüyor; Peppol da belge saklamaz. Doğrulanmış XML'i, sağlayıcının yanıtını ve basılı sürümü KDV mevzuatının saklama kurallarına göre bir arada tutun.

Son Tarihten Geriye Doğru Bir Plan

SSS belgesi OTA'nın geçiş katılımcılarıyla sisteme dahil edilmelerinden en az altı ay önce iletişime geçtiğini söylüyor. Nisan grubu için bu, şimdi demek.

1 Nisan 2027'de başlıyorsanız:

1. Ekim 2026: geçiş kontrol aracı ve SSS belgesindeki ölçütle grubunuzu doğrulayın. Fatura düzenleyen her sistemi listeleyin: ERP, her POS, e-ticaret ödeme sayfası, kiralama veya abonelik faturalaması ve elle tutulan her fatura defteri.
2. Kasım 2026: bir sağlayıcı seçin. İmzalamadan önce API belgelerini ve bir test ortamı (sandbox) isteyin; B2C hacmini, belge başına fiyatı, çevrim dışı durumların nasıl ele alındığını ve doğrulama yanıtlarının neye benzediğini sorun. Bağlantıyı Fawtara portalı üzerinden talep edin.
3. Aralık 2026 ile Ocak 2027 arası: geliştirme. Alan eşleme, UUID üretimi, işlem türü mantığı, POS kuyruğu, QR kodlar, alacak dekontu akışı, gelen faturalar. PINT Oman indirmelerindeki Umman schematron kurallarını kendi test hattınızda çalıştırın; böylece hatalar sağlayıcıda değil, geliştirme aşamasında ortaya çıkar.
4. Şubat 2027: gerçekte düzenlediğiniz her işlem türünün gerçek örnekleriyle, zor olanlar dahil (ihracat, fişsiz iadeler, yabancı para birimi), sağlayıcının test ortamına karşı uçtan uca testler.
5. Mart 2027: tek bir şube veya iş koluyla bir canlı ortam provası, bir geçiş planı ve ilk haftalar için bir destek nöbet çizelgesi.

1 Ekim 2027'de başlıyorsanız sıra aynı, yalnızca altı ay kaydırılmış: sağlayıcı ilk çeyreğin sonuna kadar seçilir, geliştirme ikinci çeyrekte yapılır, testler Ağustos'a kadar tamamlanır. Aradaki boşluğu harcamayın. Veri temizliği her zaman herkesin tahmin ettiğinden uzun sürer.

Hâlâ Belirsiz Olanlar

Tarihler bir kez değişti ve yeniden değişebilir. Planınızı 31 Ağustos 2026 tarihli PDF'e göre yapın ve haberlere güvenmek yerine OTA'nın belgelerini her ay kontrol edin. Yasal dayanak, KDV Kanunu Uygulama Yönetmeliği'ni değiştiren 189/2026 sayılı Karar. SSS belgesi zorunluluk başladığında KDV mevzuatı kapsamında cezaların uygulanacağını söylüyor, ancak tutarları sıralamıyor; biz de sıralamıyoruz.

Spesifikasyonlar da sürümleniyor. Peppol sitesi PINT OM faturalama, alıcı tarafından düzenlenen fatura ve vergi verisi süreçlerini sürüm 1.0.1 olarak, bir yayım tarihi belirtmeden listeliyor. Sayfada görünen 29 Temmuz 2026 tarihi Umman spesifikasyonlarının değil, aynı sayfadaki PDK 1.4.4'ün yayım tarihi. Geliştirmenizi dayandırdığınız sürümü sabitleyin ve yeni sürümler için sayfayı kontrol edin.

Nereden Yardım Alabilirsiniz

Gerçekte çalıştırdığınız sistem ile zorunluluğun gerektirdiği biçim arasındaki bağlantıyı biz geliştiriyoruz: alan eşleme, UUID ve numaralandırma mantığı, POS kuyrukları, test hattınızda doğrulama ve seçtiğiniz sağlayıcıyla entegrasyon. e-Fatura entegrasyon hizmetimiz bu işi kapsıyor; engel ERP'nin kendisi olduğunda ise başlangıç noktası ERP modernizasyonu.

Nisan grubundaysanız ve henüz bir sağlayıcı seçmediyseniz office@c9group.dev adresine yazın.