2026 itibarıyla finansal dijitalleşme artık yalnızca e-Fatura kesmek anlamına gelmiyor. Gelir İdaresi Başkanlığı tarafında e-Belge ekosistemi 509 sayılı VUK Genel Tebliği ekseninde gelişmeye devam ediyor; 2025 sonunda yayımlanan 589 sıra no.lu değişiklik tebliği de 509’daki e-Arşiv alanlarını güncelledi. Aynı dönemde GİB’in YN ÖKC ve e-Belge kılavuzları, e-Fatura ve e-Arşiv belgelerinde KDV tevkifat oranı ve tevkif edilen KDV tutarı gibi alanların gösterildiği teknik şablonları net biçimde ortaya koyuyor. Yani sistem artık sadece belge üretmeye değil, doğru veri üretmeye zorlanıyor.

Turizm sektöründe sorun şu: genel muhasebe paketleri belgeyi üretir ama işlemin turizm mantığını bilmez. Örneğin bir havayolu bileti satışında yazılımın şu ayrımı yapabilmesi gerekir: brüt bilet bedeli, vergi kalemleri, net fare, servis bedeli, BSP’ye gidecek tutar, müşteriden tahsil edilen toplam, iadede geri dönecek kısım, komisyonun geri alınması ve kur etkisi. IATA BSP kılavuzunda, acentenin yalnızca kendi düzenleyip raporladığı STDs üzerinde doğrudan refund işlemi yapabileceği; refund işleminde BSP billing raporlarında görülen komisyon tutarının BSP’ye borç olarak yansıyabildiği açıkça yer alıyor. Bu veri ayrışmıyorsa, muhasebe kaydı hukuken tamam görünse bile işletme gerçeği bozulur.

Aynı sorun BSP veri akışında da vardır. IATA’nın Data Interchange Specifications Handbook’ı, BSP dünyasında RET, HOT, CSI, TI ve CSP gibi farklı dosya organizasyonlarının kullanıldığını; örneğin CSI’nin kartla ödenmiş veya karta iade edilmiş işlemleri, TI’nin ise STD stok kontrolünü ve raporlanmayan satış/fraud çözümünü desteklediğini anlatır. Bu, bilet muhasebe programının yalnızca muhasebe fişi değil; veri haritalama, reconciliation ve kontrol altyapısı olması gerektiği anlamına gelir.

Turizmde mali kayıt ile operasyon kaydı ayrıldığında hata sadece muhasebede çıkmaz; yanlış vergi, yanlış kârlılık ve yanlış cari bakiye üçlüsü aynı anda oluşur. Bilet muhasebesi ayrı Excel’de, BSP mutabakatı ayrı mail kutusunda, e-Fatura ayrı panelde yürüyorsa sistem değil, personel fedakârlığı çalışıyordur.

Otomasyon Çözümü: Sektörel bir turizm finans sistemi; PNR, ticket, BSP period, refund, EMD, service fee ve cari hareketi tek transaction çekirdeğinde toplamalıdır. Demo Talebi bırakarak ücretsiz finansal check-up isteyin; dağınık sürecinizin nerede sızıntı verdiğini somut olarak gösterelim.

Bilet iptal ve iade süreçlerinde en büyük sorun, işletmelerin “müşteriye ne döndü?” sorusuyla “BSP’de ne kapandı?” sorusunu aynı şey sanmasıdır. Oysa bu iki veri çoğu zaman birebir örtüşmez. Özellikle servis bedeli alan acentelerde, iade senaryosunda havayolu iadesi ile acente hizmet bedelinin muhasebesi farklı yönetilmelidir. IATA BSP Manual, acentenin kendi düzenlediği ve raporladığı belgelere refund yapabileceğini; raporlanan refund işlemlerinde satış komisyonunun geri alınmasının da BSP billing’de hesaplandığını belirtir. Bu yüzden iade muhasebesi yalnızca “eksi fatura” değildir; aynı anda gelir düzeltmesi, BSP alacak/borç düzeltmesi ve müşteri iade hareketidir.

Türkiye tarafında belge düzeni de ayrı önem taşır. E-belge yapısında belge kurgusu, KDV ve gerektiğinde tevkifat alanlarıyla birlikte teknik formatta taşınır. GİB’in yayımladığı e-belge teknik kılavuzları, e-Fatura/e-Arşiv tarafında KDV oranı, hesaplanan KDV, tevkifat oranı ve tevkif edilen KDV gibi alanların yapı içinde gösterildiğini ortaya koyuyor. Yanlış belge akışı yalnızca muhasebe değil, belge geçerliliği riski de doğurur.

Buradaki tipik hata şudur: müşteri iadesi yapılır, fakat servis bedeli ile havayolu iade kalemi ayrıştırılmaz; sonrasında gelir hesabı, KDV etkisi ve cari hareketler iç içe geçer. Özellikle yoğun refund alan kurumsal acentelerde bu durum ay sonu kapanışını bozduğu gibi, finans müdürünün brüt-net analizini de anlamsız hale getirir.

Otomasyon Çözümü: Refund akışı; orijinal satış, BSP iade kaydı, servis bedeli politikası ve müşteri ödeme iadesiyle bağlantılı tek workflow olarak tasarlanmalıdır. Hatalı muhasebe kayıtlarından kurtulmak için ücretsiz finansal check-up demosu alın.

Turizm şirketlerinin büyük kısmı USD, EUR ve zaman zaman GBP ile çalışır; buna karşılık satışın tahsilatı çoğu zaman TL veya karma para birimlerinde yapılır. Bu nedenle bilet kesildiği andaki kur, tedarikçi borcu kapandığı andaki kur ve müşteri tahsilatının geldiği andaki kur birbirinden farklı olabilir. Genel muhasebe yazılımı çoğu zaman sadece dönem sonu kur farkını görür; ama turizm finansı işlem bazlı kur farkı görmek zorundadır.

IATA BSP süreçleri de bunu destekler; çünkü BSP ortamında biletleme ve settlement verisi belirli dönemsel raporlama ile ilerler. Aynı zamanda BSP Data Interchange yapısında credit sales invoicing ve settlement business functions ayrı veri akışlarıyla tanımlanır. Bu da bir bilet muhasebe programında dövizli işlem bazlı reconciliation yapılmasının “güzel olur” değil, zorunlu olduğunu gösterir.

Pratikte üç ayrı risk vardır. Birincisi satış kuru ile tahsilat kuru arasındaki fark. İkincisi tedarikçi ya da BSP kapanış kuru ile satış anı arasındaki fark. Üçüncüsü iadede veya exchange işleminde oluşan ters yönlü fark. Bu üçü tek ekranda görünmüyorsa, acente yüksek ciro yaparken gerçekte marj kaybedebilir.

Dövizli mizanı olmayan turizm şirketi, kâr ettiğini varsayar; hangi para biriminde ne kaybettiğini ise çoğu zaman yıl sonuna kadar görmez. Bu geç fark edilen zarar, muhasebe sorunu değil yönetim raporlama sorunudur.

Otomasyon Çözümü: Turizm ön muhasebe yazılımı; işlem tarihi kuru, belge kuru, tahsilat kuru ve kapanış kuru bazında hareketleri izlemeli, dövizli mizan ve ürün bazlı kur farkı raporu üretmelidir. Demo Talebi oluşturun; kur farkı görünürlüğünüzü canlı senaryo ile anlatalım.

Sahadaki en yaygın ve en pahalı hatalardan biri, service fee ile net tedarikçi bedelinin tek kalem gibi işlenmesidir. Uçak biletinde, otel voucher’ında, vize hizmetinde, transferde veya operasyonel ek hizmetlerde acentenin asıl geliri çoğu zaman servis bedeli, markup veya komisyon farkıdır. Siz bu ayrımı sistemde net yapmazsanız, brüt satış büyür ama gerçek gelir analizi bozulur.

Bu konu BSP ve GDS akışlarında daha kritik hale gelir. IATA’nın teknik veri kılavuzları; agent reporting, airline accounting/sales, credit sales invoicing ve settlement fonksiyonlarının ayrı dosya akışlarıyla tanımlandığını söylüyor. Yani teknoloji tarafı zaten size “satışın tümü tek veri değildir” diyor. Muhasebe tarafı da bunu aynı ayrıntıda modellemelidir.

Yanlış senaryo şu şekildedir: müşteri 100 birim öder, bunun 85’i tedarikçi/bilet bedeli, 15’i service fee’dir; ama sistem bunu tek satış kalemi yazar. Sonra iade geldiğinde 85’in bir kısmı döner, 15’in politikası belirsiz kalır. Sonuç: hatalı gelir tablosu, bozuk cari, tartışmalı iade ve gereksiz iç denetim yükü.

Otomasyon Çözümü: Her işlemde “supplier cost / agency revenue / tax components / collections” ayrımı zorunlu alan olarak modellenmelidir. Hatalı service fee muhasebesinden çıkmak istiyorsanız ücretsiz finansal check-up demosu alın.

Sektörel doğru çözüm, bilet muhasebesini manuel veri girişi olmaktan çıkarmaktır. PNR, ticket number, EMD, itinerary, fare, tax breakdown, payment info ve refund/exchange hareketleri mümkün olduğunca kaynak sistemden alınmalıdır. Teknik tarafta Amadeus, Sabre ve Travelport/Universal API ekosistemleri; uçuş arama, booking ve booking management gibi kabiliyetleri resmi geliştirici platformlarında sunuyor. Bu, modern bir turizm muhasebe programının GDS/veri kaynağından veri çekebilmesi gerektiğini gösterir.

Muhasebe modülünün burada yapması gereken şey, ham veriyi göstermesi değil; o veriyi finansal nesnelere çevirmesidir. Yani:

ticket bazlı satış fişi,

service fee ayrıştırması,

BSP alacak/borç hareketi,

müşteri cari kaydı,

kredi kartı / sanal pos / havale tahsilat eşleşmesi,

refund ve ADM/ACM etkisi,

dövizli mizan hareketi

aynı kayıt zincirinde oluşmalıdır.

BSPlink tarafında günlük ADM/ACM indirmeleri, disputed ADM/ACM transaction’ları ve status değişiklikleri dosya bazlı alınabilir. IATA kaynaklarında bu dosyaların günlük indirilebilir olduğu açıkça yazıyor. Bu veri manuel takip edildiğinde muhasebe her zaman geriden gelir; entegrasyonla işlendiğinde ise risk anlık görünür hale gelir.

Bir bilet muhasebe yazılımı ticket kesim ekranı değildir. Asıl değeri, satıştan settlement’a kadar tüm hareketi finansal olarak izleyebilmesidir. BSP ile defter arasında “excel köprüsü” kuruyorsanız, o köprü bir gün çöker.

Otomasyon Çözümü: GDS/BSP verisini otomatik çekip servis bedeli, net bilet, tahsilat ve iade senaryosuna dönüştüren yapı kurun. Demo Talebi bırakın; bilet muhasebesinde manuel veri girişini nasıl sıfıra yaklaştırdığımızı gösterelim.

Turizm finansı yalnızca biletten ibaret değildir. Incoming, outgoing, tur, transfer ve operasyon tarafında çok daha karmaşık maliyet akışları vardır. Rehbere verilen avans, araç tedarikçisinin hakedişi, otel allotment maliyeti, operasyon personeli masrafı, sahada yapılan nakit harcama ve sonradan belgeye bağlanan giderler klasik muhasebe paketinde çoğu zaman “masraf” olarak kalır. Oysa bunlar operasyon bazlı maliyet merkezi olmalıdır.

Burada sistemin yapması gereken; operasyonu muhasebeye sonradan anlatmak değil, operasyon oluşturulurken finansal nesneleri birlikte üretmektir. Tur açıldığı anda cost center, rehber avansı, tedarikçi borcu, tahmini kârlılık ve tahsilat planı birlikte doğmalıdır. Böylece rehber avansı kasa hareketi olarak kalmaz; ilgili tur dosyasının maliyetine bağlanır.

KDV tarafında da ayrışma gerekir. Özellikle dışarıdan alınan bazı hizmetlerde kısmi tevkifat, hizmet türüne ve alıcı statüsüne göre gündeme gelebilir. GİB’in KDV Genel Uygulama Tebliği’nde servis taşımacılığı için 5/10, ticari reklam hizmetleri için 3/10 tevkifat oranları açıkça yer alıyor. Turizm şirketlerinde servis taşımacılığı, reklam, organizasyon, temizlik, yemek gibi dış kaynaklı hizmetler yaygın olduğu için yazılımın işlem türü bazında tevkifat kontrolü yapabilmesi gerekir.

Turizm şirketlerinde e-dönüşüm konusu standart e-Fatura üretiminin ötesine geçer. Çünkü faturanın satır yapısı, KDV oranı, tevkifat alanı, varsa konaklama vergisi ve dövizli işlem mantığı doğru kurgulanmalıdır. GİB tarafındaki teknik kılavuzlar, e-Fatura ve e-Arşiv faturalarda KDV tevkifat oranı ve tevkif edilen KDV tutarı gibi alanların belge şablonunda yer aldığını gösteriyor. Bu yüzden turizme özel muhasebe yazılımı, belgeyi sonradan kesen değil; belgeyi doğuran finansal veriyi doğru hazırlayan sistem olmalıdır.

Konaklama vergisinde mevzuat nettir: GİB rehberine göre oran %2’dir, vergilendirme dönemi aylıktır ve her döneme ait vergi izleyen ayın 26’ncı günü akşamına kadar beyan edilir. 6802 sayılı Gider Vergileri Kanunu’nda da oran %2 olarak yer alır. Konaklama tarafında çalışan acenteler veya otel-kontratlı yapılar için bu verginin ayrı satır mantığıyla izlenmesi gerekir; aksi halde konaklama geliri, KDV ve konaklama vergisi birbirine girer.

E-Arşiv/e-Fatura tarafında 509 tebliğ çizgisi ve son değişiklikler nedeniyle, belge formatını sadece muhasebenin değil ürün modülünün de bilmesi gerekir. Çünkü siz satış ekranında konaklama vergisini yanlış konumlarsanız, belge doğru çıksa bile raporlama yanlış olur.

Belgenin kesilmesi, muhasebenin doğru olduğu anlamına gelmez. Doğru muhasebe; belge, vergi ve operasyon verisinin aynı kaynaktan tutarlı üretilmesidir.

Otomasyon Çözümü: E-belge üretimini ürün bazlı finansal kurallara bağlayın. Konaklama vergisi, tevkifat ve dövizli satışlar belge şablonuna otomatik işlensin. Demo Talebi gönderin; e-dönüşümü turizm gerçekliğine nasıl uyarladığımızı anlatalım.

Aşağıdaki tabloyu kısa geçmeyin. Yanlış yazılım seçimi genelde modül eksikliğinden değil, çekirdek tasarım hatasından kaynaklanır.

Aşağıdaki checklist, yazılım değiştirip değiştirmemeniz gerektiğini anlamanın en net yoludur:

BSP raporunuzla muhasebe kayıtlarınız aynı dönemde birebir mutabık mı?

ADM/ACM’leri günlük ya da en azından dönemsel otomatik görüyor musunuz?

Service fee geliriniz net fareden ayrı raporlanıyor mu?

Refund işlemlerinde müşteri iadesi ile BSP düzeltmesi ayrı izleniyor mu?

Dövizli mizanı işlem bazında alabiliyor musunuz?

Tedarikçi borçlarınız rezervasyon veya operasyon bazında görünüyor mu?

Konaklama vergisi ve KDV aynı satırda değil, ayrı katmanlarda mı izleniyor?

Tevkifatlı dış hizmet alımlarında oran ve matrah kontrolü yapabiliyor musunuz?

E-Fatura/e-Arşiv belgeleri manuel müdahale olmadan muhasebe verisinden mi üretiliyor?

Finans müdürü, operasyon sormadan gerçek kârlılığı görebiliyor mu?

Bu 10 maddeden 4’ünde bile “hayır” diyorsanız, işletmede görünmeyen finansal sızıntı vardır.

Turizm şirketlerinin en büyük yanılgısı, satış sistemini ayrı, muhasebeyi ayrı, e-belgeyi ayrı, BSP mutabakatını ayrı yönetebileceğini düşünmesidir. Bu yapı küçük hacimde idare eder; hacim büyüdüğünde ise hata üretir. IATA tarafındaki BSP/BSPlink kurgusu, GİB tarafındaki e-belge ve vergi düzeni, GDS tarafındaki booking ve ticket data akışı artık tek şeyi söylüyor: sektörel entegre finans sistemi kurmak zorundasınız.

Seyahat Acentası Yazılımı yaklaşımında hedef, fiş kesmek değil; ticket, operasyon, cari, vergi ve belgeyi aynı transaction mantığında toplamak. Bunu yapmadığınız sürece muhasebe kapanır ama işletme doğru yönetilmez.

Son CTA: Hatalı muhasebe kayıtlarından, kayıp service fee gelirlerinden, geciken BSP farklarından ve görünmeyen kur zararlarından kurtulmak için ücretsiz finansal check-up demosu alın. Bu işi genel muhasebe mantığıyla değil, turizm finansı mantığıyla kuralım.

Hatalı muhasebe kayıtlarından, kayıp service fee gelirlerinden, geciken BSP farklarından ve görünmeyen kur zararlarından kurtulmak için ücretsiz finansal check-up demosu alın. Bu işi genel muhasebe mantığıyla değil, turizm finansı mantığıyla kuralım.