A correct invoice amount alone is not enough for a hotel. The document type, recipient registration, service date, scenario, tax lines, delivery result, delivery evidence and cancellation chain must also be managed correctly. While the front desk sees only an 'invoice issued' message, the document may still be pending at the integrator, rejected by the Revenue Administration or sent to the wrong recipient. Because scope rules also changed in 2026, legacy PMS settings based on fixed thresholds create risk. A sound e-Document flow applies current rules to the taxpayer profile, selects the document type from the recipient registry, prevents duplicate creation, turns technical states into clear tasks and maintains an auditable link between the folio and accounting. This guide is not tax advice; confirm the property's taxpayer and document setup with a qualified tax adviser.

What you will learn in this article
  • Document type should follow the sender's and recipient's e-Invoice registration at issue time, not the sales channel or whether the guest appears to be corporate.
  • The PMS should not separate folio close from the Revenue Administration or integrator status; it should prevent duplicates with a unique operation key and retain every status change.
  • Cancellation, objection, reissue and archiving should preserve the original document, while XML, rendering, signature, delivery and status records remain in one audit chain.

Determine the 2026 scope by taxpayer profile

e-Belge kapsamı yalnız otelin cirosuna bakılarak belirlenmez. 509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği'nin güncel hali; sektör, faaliyet, satış hasılatı ve Başkanlık bildirimi gibi farklı geçiş nedenleri içerir. 589 Sıra No.lu Tebliğ ise e-Arşiv Fatura olarak düzenlenmesi gereken diğer faturalar için 2026 dönemine ilişkin geçiş kuralını değiştirmiş, ticari kazancı basit usulde tespit edilenler ile işletme hesabı esasına göre defter tutanlar için farklı bir takvim öngörmüştür. Otel şirketleri, şahıs işletmeleri ve farklı defter usulleri bu nedenle aynı varsayımla yönetilmemelidir.

PMS'te tek bir 'e-Fatura açık' kutusu yerine mükellefiyet başlangıç tarihi, yararlanma yöntemi, vergi kimlik numarası, mali mühür durumu, özel entegratör, şube/birim kodu ve kapsam dayanağı tutulmalıdır. Mevzuattaki parasal sınırlar ve tarihler kod içine kalıcı sayı olarak gömülmemeli; başlangıç-bitiş tarihiyle sürümlenmelidir. Yıl değişiminde yeni rezervasyon açmak ayarı otomatik güncellemek için yeterli değildir: mali müşavir teyidi, test belgesi, kullanıcı kabulü ve canlıya geçiş kaydı gereklidir. Böylece geçmiş belgeler yeni kuralla sessizce yeniden yorumlanmaz.

  • 509 ve 589 Sıra No.lu Tebliğler tesisin mükellefiyet türüyle birlikte değerlendirildi.
  • Kapsam nedeni, başlangıç tarihi ve yararlanma yöntemi tesis kartına kaydedildi.
  • Parasal sınır ve tarihler sürümlü kural tablosuna taşındı.
  • Yıl geçişi mali müşavir onayı ve test senaryosuna bağlandı.

Select e-Invoice or e-Archive Invoice from the recipient registry

e-Fatura uygulamasına kayıtlı bir otel, istisnalar dışında e-Fatura kayıtlı alıcıya e-Fatura; kayıtlı olmayan vergi mükellefine veya nihai tüketiciye e-Arşiv Fatura düzenler. Bu ayrım rezervasyonun OTA'dan gelmesi, ödemenin şirket kartıyla yapılması veya faturada şirket adı yazılması üzerinden tahmin edilmemelidir. Belge düzenleme anında alıcının vergi kimlik numarasıyla güncel kayıtlı kullanıcı listesi sorgulanmalı; uygun etiket veya posta kutusu seçilmelidir. Gerçek kişide T.C. kimlik numarası ve yabancı misafir bilgilerinin kullanımı ise veri minimizasyonu ve güncel belge kurallarıyla birlikte ele alınmalıdır.

Kurumsal rezervasyonda konaklayan kişi ile faturanın alıcısı farklı olabilir. PMS, misafir profilini, ödeyen hesabı, cari hesabı ve belge alıcısını ayrı alanlarda tutmalıdır. Vergi kimlik numarası eksik ya da doğrulanmamışsa sistem yanlış türde belge üretmek yerine taslak veya kontrol kuyruğu oluşturmalıdır. Kayıtlı kullanıcı sorgusunun zamanı ve sonucu saklanmalı; alıcı daha sonra e-Fatura sistemine girse veya çıksa bile geçmiş belgenin neden o türde düzenlendiği açıklanabilmelidir.

  • Belge türü düzenleme anındaki e-Fatura kayıtlı kullanıcı sorgusuyla seçildi.
  • Misafir, ödeyen, cari hesap ve belge alıcısı ayrı tutuldu.
  • Vergi kimlik numarası ve alıcı etiketi gönderimden önce doğrulandı.
  • Sorgu zamanı, sonucu ve kullanılan kayıt kanıt olarak saklandı.

Align the service date, document date and invoicing deadline

Vergi Usul Kanununun fatura düzenine ilişkin genel kuralında fatura, malın teslimi veya hizmetin yapıldığı tarihten itibaren azami yedi gün içinde düzenlenir; süresinde düzenlenmeyen belge hiç düzenlenmemiş sayılır. Otelde hizmetin ne zaman tamamlandığı, uzun konaklama, grup hesabı, acenta mutabakatı, erken çıkış, no-show, avans ve dönem sonu gibi senaryolarda ayrıca belirlenmelidir. PMS yalnız checkout düğmesine basıldığı anı belge tarihi kabul etmemeli; hizmet tarihi ile düzenleme tarihini ayrı alanlarda doğrulamalıdır.

Faturanın önceden düzenlenmesi KDV ve konaklama vergisi bakımından farklı sonuçlar doğurabilir. Özellikle konaklama vergisi, hizmet sunulmadan önce düzenlenen belgede gösterilmez; bu nedenle avans tahsilatı, geçici folyo ve nihai e-Belge aynı hareket türü gibi işlenmemelidir. Sistem, yedi günlük üst sınırı genel kontrol olarak izlerken Bakanlığın belirli işlemler için daha kısa süre veya anlık düzenleme getirebilme yetkisini de göz ardı etmemelidir. Tesisin somut uygulaması mali müşavirle yazılı prosedüre dönüştürülmelidir.

  • Hizmet tarihi, checkout zamanı ve belge düzenleme tarihi ayrı alanlarda izlendi.
  • Genel yedi günlük süre gecikme uyarısı ve görev akışına bağlandı.
  • Avans, geçici folyo ve nihai fatura farklı işlem türleri olarak tanımlandı.
  • Özel süre gerektiren işlemler için mevzuat ve mali müşavir kontrolü eklendi.

Validate recipient, line and tax data at the folio source

Belgenin ekrandaki PDF görüntüsü ile teknik XML içeriği aynı olmalıdır; esas veri yalnız görsel şablonda aranamaz. Satıcı unvanı, vergi dairesi, vergi kimlik numarası, adres, şube/birim kodu, alıcı bilgileri, belge numarası, UUID, tarih-saat, para birimi ve senaryo gönderimden önce doğrulanmalıdır. Satırlarda 'konaklama' veya 'hizmet' gibi aşırı genel ifadeler yerine oda-gece, pansiyon türü, ek hizmet ve dönem gibi işlemi anlaşılır kılan açıklamalar kullanılmalıdır.

Folyo toplamı doğrudan tek satıra kopyalanmamalıdır. Oda, yiyecek, içecek, transfer, indirim, konaklama vergisi, KDV ve tahsilat farklı mali niteliklere sahiptir. Hesap kodu, vergi oranı, istisna/muafiyet kodu, tevkifat, döviz kuru ve yuvarlama kuralı ürün kartından ve satış bağlamından üretilmelidir. Nakit veya kart tahsilatı gelir satırı değildir; iade de yeni bir satış gibi faturaya eklenmemelidir. Gönderim öncesi kontrol ekranı matrah, vergi ve genel toplamın kaynağını kullanıcıya açıklayabilmelidir.

  • XML ile insan tarafından okunan görüntüdeki kritik alanlar karşılaştırıldı.
  • Belge satırları folyo hesap kodu ve gerçek hizmet açıklamasıyla üretildi.
  • Vergi, indirim, tahsilat ve iade hareketleri birbirinden ayrıldı.
  • Matrah, vergi ve genel toplam gönderim öncesi kaynağıyla gösterildi.

Prevent duplicate documents technically in the PMS integration

Resepsiyonun Kaydet düğmesine iki kez basması, ağın kesilmesi veya özel entegratörün geç yanıt vermesi aynı folyo için iki belge oluşturmamalıdır. PMS her mali işlem için değişmeyen bir idempotency anahtarı üretmeli; bu anahtar tesis, folyo, belge türü ve sürümle ilişkilendirilmelidir. Aynı istek tekrarlandığında yeni numara vermek yerine önceki sonucun sorgulanması gerekir. Belge numarası ile UUID'nin benzersizliği, yıllık sıra ve birim kodu kuralları yalnız arayüzde değil sunucu ve veritabanı katmanında korunmalıdır.

Entegrasyon isteği; taslak oluşturuldu, imzaya gönderildi, özel entegratöre iletildi, GİB'e ulaştı, alıcıya teslim edildi veya hata aldı gibi aşamalara ayrılmalıdır. Kullanıcı tarayıcıyı kapatsa bile arka plan işi devam etmeli ve sonuç tekrar PMS'e yazılmalıdır. Zaman aşımı 'başarısız' ile eş anlamlı değildir; önce belge UUID'si ve entegratör referansıyla sorgu yapılmalıdır. Yeniden deneme yalnız güvenli durumlarda otomatik olmalı, belirsiz sonuçlar mali belge sorumlusunun kontrol kuyruğuna düşmelidir.

  • Her fatura isteği için değişmeyen ve benzersiz işlem anahtarı üretildi.
  • Belge numarası, UUID ve yıllık sıra veritabanı kısıtlarıyla korundu.
  • Zaman aşımında yeniden üretmek yerine mevcut belge durumu sorgulandı.
  • Belirsiz sonuçlar otomatik tekrar yerine yetkili kontrolüne yönlendirildi.

Turn delivery statuses into front-desk tasks

'Gönderildi' tek başına yeterli bir son durum değildir. Belge özel entegratöre kabul edilmiş fakat GİB zarfında hata almış, alıcı etiketi kapanmış veya ticari fatura yanıtı bekliyor olabilir. Entegratörün teknik kodu ham biçimde kullanıcıya bırakılmamalı; bekleniyor, tamamlandı, kullanıcı düzeltmesi gerekli ve teknik ekip gerekli gibi operasyonel sınıflara çevrilmelidir. Her sınıf için sorumlu rol, son işlem zamanı, önerilen çözüm ve tekrar sorgulama zamanı görünmelidir.

e-Fatura senaryosu ile e-Arşiv teslimi aynı durum akışı değildir. Ticari faturada uygulama yanıtı, temel faturada hukuki itiraz yolları, e-Arşivde elektronik veya kâğıt teslim bilgisi ayrı izlenmelidir. Misafire e-posta gönderilmiş olması GİB raporlamasının tamamlandığını kanıtlamaz; GİB kabulü de e-postanın teslim edildiğini göstermez. PMS, entegratör paneli ve muhasebe raporundaki sayılar günlük olarak uzlaştırılmalı; bekleyen ve hatalı kayıtlar vardiya kapanmadan görünür olmalıdır.

  • Teknik durum kodları anlaşılır operasyon durumlarına eşlendi.
  • Her hata için sorumlu ekip, çözüm ve son kontrol zamanı gösterildi.
  • GİB kabulü, alıcı teslimi ve ticari yanıt ayrı durumlar olarak izlendi.
  • Bekleyen ve hatalı belgeler günlük kapanış raporuna eklendi.

Manage cancellation, objection and reissue without deletion

Yanlış düzenlenen e-Belge veritabanından silinip yok sayılmamalıdır. e-Arşiv Fatura iptal talebinde GİB kılavuzu, sekiz günlük sürenin belgenin alıcıya iletilmesinden itibaren başladığını ve talebin bu süre içinde yapılmasını açıklar. İtiraz ise Türk Ticaret Kanunundaki yöntemlerle oluşan belge numarası ve yöntemi gibi ek kanıtlar gerektirir. e-Fatura tarafında senaryo, alıcı yanıtı ve uygulanabilir hukuki yol ayrıca değerlendirilmelidir; her belgeye aynı 'iptal et' düğmesi bağlanmamalıdır.

PMS; asıl belge, iptal/itiraz talebi, karşı taraf yanıtı, iade veya düzeltme belgesi ve yeniden kesilen belgeyi tek zincirde göstermelidir. Kullanıcıdan gerekçe alınmalı, yetki ve gerekiyorsa ikinci onay uygulanmalı, eski folyo değerleri korunmalıdır. Talep reddedildiğinde ya da süre geçtiğinde belgeyi zorla iptal edilmiş göstermek muhasebe ile GİB kaydını ayırır. Son durum entegratör veya GİB'den doğrulanmadan oda hesabı kapatılmamalı; açık uyuşmazlık ayrı görev olarak izlenmelidir.

  • Asıl belge silinmeden iptal, itiraz ve yeniden düzenleme zinciri kuruldu.
  • e-Arşiv iptalinde iletim tarihinden başlayan sekiz günlük süre izlendi.
  • Gerekçe, yetki, karşı taraf yanıtı ve kanıt belgeleri saklandı.
  • GİB/entegratör doğrulaması olmadan belge durumu kesinleştirilmedi.

Design archiving, security and daily reconciliation together

e-Belge yalnız PDF dosyası değildir. UBL-TR XML, görüntüleme dosyası, mali mühür veya elektronik imza bilgisi, zarf ve sistem yanıtları, alıcıya iletim kanıtı ile iptal/itiraz kayıtları gerektiğinde birlikte ibraz edilebilmelidir. Dosyalar değişmezlik ve bütünlük kontrolleriyle saklanmalı; yedekleme, geri yükleme ve sağlayıcı değişikliği test edilmelidir. Özel entegratör hizmeti kullanmak otelin muhafaza ve ibraz sorumluluğunu otomatik olarak ortadan kaldırmaz; sözleşmede veri dışa aktarma, saklama süresi ve hizmet sonlandırma planı bulunmalıdır.

Fatura içeriğinde kimlik, iletişim, konaklama ve ödeme bilgileri bulunabileceği için erişim en az yetkiyle sınırlandırılmalıdır. XML indirme, e-posta yeniden gönderme, iptal talebi, alıcı değişikliği ve manuel durum düzeltmesi loglanmalıdır. Günlük mutabakat; kapanan folyoları, üretilen belgeleri, GİB kabul durumlarını, hataları, iptalleri ve muhasebe fişlerini aynı kontrol toplamında karşılaştırmalıdır. Farklar kullanıcı, tarih ve gerekçeyle kapatılmalı; ay sonuna taşınan açık belge bırakılmamalıdır.

  • XML, görüntü, imza, sistem yanıtı ve teslim kanıtı birlikte arşivlendi.
  • Yedek geri yükleme ve entegratörden veri dışa aktarma düzenli test edildi.
  • Hassas belge işlemleri rol, yetki ve değiştirilemez loglarla korundu.
  • Folyo, e-Belge, GİB durumu ve muhasebe günlük olarak uzlaştırıldı.
Short answers

FAQ

Should a hotel guest receive an e-Invoice or e-Archive Invoice?

Document type follows the guest's or corporate recipient's e-Invoice registration when the document is issued. Issue an e-Invoice to a registered recipient and an e-Archive Invoice to an unregistered taxpayer or final consumer. Confirm the specific taxpayer status and exceptions with a qualified tax adviser.

Should the invoice be resent if the integrator does not respond during checkout?

Creating a new document immediately may cause a duplicate invoice. First query the existing request with the same operation key, UUID or integrator reference; retry in a controlled manner only after a confirmed failure. Route uncertain records to an authorized user for review.

Can an incorrect e-Archive Invoice be corrected by deleting it from the PMS?

No. Preserve the original document, follow the applicable cancellation or objection process and deadline, verify the counterparty and Revenue Administration/integrator status, and create a linked corrected document when required. Log the reason and user identity.

Sources and updates

This content is not tax or legal advice; a qualified tax adviser should review the property's taxpayer, contract and transaction structure. e-Invoice and e-Archive Invoice information was checked against the Revenue Administration sources below on October 11, 2026.