Dış Ticarette Çoklu Para Birimi ve Kur Farkı Takibi Nasıl Kurulur?

Dış ticaretle uğraşan bir işletmede yıl sonu toplantısının en tehlikeli cümlesi şudur: "Ciromuz geçen yıla göre %70 arttı." Rakam doğrudur. Ama aynı dönemde kur %55 arttıysa gerçek büyüme %10 bandındadır ve o toplantıda alınan yatırım kararı yanlış bir zeminde alınmıştır. Çoklu para birimi muhasebe kurgusu olmayan bir sistemde bu ayrımı yapmanın yolu yoktur; çünkü kayıtların hiçbiri, işlemin yapıldığı günün kurunu taşımaz.

Sahada iki yanlış çözüm görüyoruz. Birincisi her şeyi yalnız TL tutmak: bu durumda geçmiş dönemler karşılaştırılamaz hâle gelir. İkincisi her şeyi yalnız dolar tutmak: bu kez kasadaki nakit, bankadaki bakiye ve müşteriden tahsil edilen çek TL olduğu için günlük iş yürümez. Doğru cevap ikisinin arasında değil, ikisinin birlikte saklanmasındadır.

Bu yazıda bir finans kaydının hangi alanlarla tutulması gerektiğini, kur güncellendiğinde geçmiş kayıtlara neden dokunulmaması gerektiğini ve bu kurgunun çek/vade takibi, fason imalat maliyeti ve ortaklık hesabı gibi günlük işlere nasıl yansıdığını anlatıyoruz.

Tek para birimiyle tutulan kayıt neden yanıltır?

Bir finans kaydı yalnız TL tutulduğunda o kaydın anlamı zamanla erir. 2024'te girilmiş 300.000 ₺'lik bir tedarikçi ödemesi ile bugün girilen 300.000 ₺'lik bir ödeme aynı rakamdır ama aynı değer değildir. Yıl sonunda bu iki satır alt alta toplandığında ortaya çıkan sayı, işletmenin gerçekten ne harcadığını göstermez.

Yalnız dolar tutmak da çözmüyor. Kasadaki para TL, bayiden alınan çek TL, elektrik faturası TL. Doları tek referans yapan bir sistem, her ekranda kullanıcıyı kafadan çevirme yapmaya zorlar; üstelik "hangi kurdan çevirdik?" sorusu ortada kalır. Kayıt bir kez yanlış kurla çevrildiğinde hatayı geriye dönük bulmak neredeyse imkânsızdır.

Üçüncü ve en sinsi yanlış, TL tutarı saklayıp dolar karşılığını rapor anında güncel kurla hesaplamaktır. Bu yaklaşımda geçmiş dönem raporu her açılışta farklı çıkar. Ocak ayının kârını mart ayında yeniden hesaplarsınız ve rakam değişir. Böyle bir sistemde kimse rapora güvenmez.

Doğru yaklaşım: tutar ₺, tutar $ ve o günün kuru birlikte

Kural tek cümledir: her finans kaydı, işlem günündeki kurla birlikte hem ₺ hem $ olarak saklanır. Yani veritabanında tek bir tutar alanı değil, üç alan bulunur: tutar (₺), tutar ($) ve kur. Bu üçü kaydın parçasıdır; sonradan hesaplanmaz, kaydedildiği anda dondurulur.

Kazanç şu: geçmişe dönük her rapor, kur bugün ne olursa olsun aynı sonucu verir. "Geçen yıl dolar bazında ne kadar harcadık?" sorusunun tek bir doğru cevabı olur. Ve en önemlisi, ₺ eğrisiyle $ eğrisini üst üste çizdiğinizde büyümenin ne kadarının gerçek, ne kadarının kur kaynaklı olduğu tek bakışta görünür.

Bir finans hareketinde hangi alanlar saklanmalı?

Kur alanını eklemek tek başına yetmiyor. Bir hareketin sonradan doğrulanabilir olması için etrafındaki bağlamın da kayıtta durması gerekiyor. Aşağıdaki liste, dış ticaret yapan işletmeler için kurduğumuz finans modüllerinde asgari alan setidir.

Bu alanların hepsi tek satırda durmalı. Kuru ayrı bir tabloda tutup rapor anında birleştirmek, ilk bakışta zarif görünen ama ilk kur güncellemesinde çöken bir tasarımdır.

Kur güncellendiğinde geçmiş kayıtlar değişmemeli

Bu, kur farkı takibi kurgusunun en kritik tasarım kararıdır ve çoğu proje burada hata yapar. Kur güncelleme ekranına yeni değer girildiğinde sistem geçmiş kayıtları yeniden hesaplamamalı; yalnız bundan sonraki kayıtlar güncel kurdan işlem görmelidir.

Aksi hâlde iki şey birden bozulur. Birincisi, onaylanmış dönem raporları her kur hareketinde yeniden yazılır — geçen ayın kârı bu ay farklı çıkar. İkincisi ve daha ağırı, ortaklı veya çok hissedarlı bir yapıda dağıtılmış kâr payları geriye dönük kayar. Kapanmış bir dönemin rakamı, kapanmış olmalıdır.

Uygulamada bunun üç kuralı var:

1. Kayıt anında dondur. Kur, tutarla aynı satıra yazılır; sonradan güncel kurdan türetilmez.
2. Kur güncellemesini günlüğe yaz. Kim, ne zaman, hangi değeri girdi — denetim kaydı olarak saklanır.
3. Dönemi kilitle. Onaylanan dönem kapanır; düzeltme gerekirse yeni bir kayıtla yapılır, eski satır silinmez.

Kur bilgisi yalnız raporda değil, günlük işte de çalışır

Çift para birimli kayıt, ay sonu raporunu düzeltmekle kalmaz; günlük operasyonun dört ayrı noktasında doğrudan işe yarar.

Çek ve vade takibi

Dış ticaret yapan KOBİ'lerde cironun önemli bölümü çekle döner. Alınan ve verilen çekler aynı vade takviminde toplandığında, hangi haftada net nakit çıkışı olacağı önceden görünür. Bir hafta içinde girecek tahsilat çıkacak ödemenin altında kalıyorsa, o hafta gelmeden tahsilat öne çekilir veya ödeme yeniden planlanır. Her çekin $ karşılığının da saklanması, döviz cinsinden alım yapan bir işletmede ödeme gücünü doğru okumayı sağlar.

Fason imalat maliyeti

Üretimi dışarıda yaptıran bir işletmede ürün maliyeti tedarikçi zamlarıyla sürekli değişir. Fason birim fiyatı hem ₺ hem $ olarak saklandığında, ürün kartındaki maliyet grafiği iki eğri gösterir: ₺ maliyet hızla artarken $ maliyet daha yavaş artıyorsa, zammın büyük kısmı kur kaynaklıdır. Bu ayrım, tedarikçiyle yapılacak fiyat görüşmesinin en güçlü argümanıdır.

Sevkiyat ve termin takvimi

Fason atölyeden gelecek mal girişleri ile müşteriye yapılacak sevkler tek takvimde birleştiğinde, "elimde yokken söz verdiğim" durumu ortadan kalkar. Mal girişi kaydedildiği anda hem stok hem tedarikçi cari borcu güncellenir; borcun ₺ ve $ karşılığı da o gün sabitlenir.

Ortak sermayesi ve kâr dağıtımı

Ortaklı işletmelerde en çok tartışma yaratan konu budur. Ortaklar sermayeyi farklı tarihlerde ve farklı kurlardan koyduysa yalnız ₺ toplamına bakmak adil bir karşılaştırma vermez. Her sermaye girişi kendi günü ve kuruyla kaydedildiğinde, "kim ne kadar değer koydu" sorusu tartışmaya değil hesaba dönüşür. Dönem kârı da ortak paylarına ₺ ve $ olarak ayrılır, onaylanan dönem kilitlenir.

Sahadan örnek: çift para birimli bir dış ticaret yazılımı

Bu kurgunun uçtan uca uygulandığı işlerden biri Lunasan İşletme Yönetim ve Finans Takip Yazılımı. İki ortaklı, ürünlerini fason atölyelere yaptıran ve satışının önemli kısmını bayi kanalıyla vadeli yürüten bir işletme için geliştirildi. Kurulumdan önce kasa, cari, fason sipariş ve yatırım takibi ayrı Excel dosyalarına dağılmıştı; "kasada ne var, kime ne borçluyuz, bu ay gerçekten kâr ettik mi" sorularının tek bir doğru cevabı yoktu.

Sistemin çekirdeğine tek bir kural konuldu: her kayıt hem ₺ hem de işlem günündeki kurla $ karşılığıyla saklanır. Bunun üzerine kasa, ortak sermayesi, makine yatırımları, fason imalat, sevkiyat takvimi, cari hesap, sipariş, çek ve gider modülleri kuruldu. Sipariş, gider, yatırım ve sermaye kayıtları kasa hareketlerine otomatik düşüyor; çift kayıt yok.

Sonuçta ortaya çıkan en somut kazanç, dönem karşılaştırmasının anlam kazanması oldu. Ciro, birim maliyet, kasa bakiyesi ve net kâr; iki dönem arasında hem ₺ hem $ değişimiyle yan yana konabiliyor. TL bazındaki artışın dolar karşılığı yanında durduğu için "gerçekten büyüdük mü" sorusu bir yorum meselesi olmaktan çıktı.

Kurulumda sık yapılan 5 hata

Kuru rapor anında hesaplamak

Geçmiş dönem her açılışta değişir; kimse rapora güvenmez. Kur, kayıtla birlikte dondurulmalı.

Tek bir "döviz" alanıyla yetinmek

Hangi para birimi, hangi kur, hangi tarih belli değilse alan bilgi taşımaz.

Düzeltmeyi silerek yapmak

Yanlış kayıt silinince iz kalmaz. Doğrusu: eski değer, yeni değer ve gerekçe günlükte kalır.

Vadeyi finans kaydından ayırmak

Vade ayrı bir tabloya düşerse nakit takvimi eksik çalışır; çek ve taksitler görünmez olur.

Dönem kilidini atlamak

Kapanmış dönem değiştirilebiliyorsa kâr payları geriye dönük kayar ve ortaklık güveni zedelenir.

Sıkça sorulan sorular

Çoklu para birimi muhasebe her işletme için gerekli mi?

Hayır. Alımı da satışı da TL olan bir işletmede bu yapı gereksiz karmaşıklıktır. Gereklilik şu üç durumdan en az biriyle başlar: ithal girdi kullanıyorsanız, döviz cinsinden fiyat veriyorsanız veya yatırım/sermaye kararlarınızı dolar bazında değerlendiriyorsanız.

Kuru otomatik mi çekmeli, elle mi girmeli?

İkisi de olur, ama karar verilmesi gereken şey kaynağın hangisi olduğudur: Merkez Bankası kuru mu, bankanızın gişe kuru mu, yoksa fiilen işlem yaptığınız kur mu? İşletmenin gerçek nakit akışını yansıtan, fiilen kullanılan kurdur. Otomatik çekim kolaylık sağlar; ancak elle düzeltme hakkı ve düzeltmenin günlüğe yazılması mutlaka bulunmalı.

Euro da eklenebilir mi?

Evet. Yapı "TL + bir referans para birimi" olarak kurulduğunda ikinci veya üçüncü bir para birimi eklemek tasarım değil, veri işidir. Önemli olan referans para biriminin işletme içinde tek olması; kimi raporu dolarla, kimini euroyla okumak yeniden aynı karmaşaya götürür.

Mevcut muhasebe programımızla birlikte çalışabilir mi?

Çoğu durumda evet. Yasal muhasebe kaydı mali müşavirde kalır; işletme yönetim paneli karar destek katmanı olarak yanında çalışır. Muhasebe yazılımının dışa açık bir arayüzü veya düzenli veri aktarım biçimi varsa iki taraf beslenebilir. Bu değerlendirmeyi entegrasyon başlığı altında ön analizde yapıyoruz.

Hazır bir program bu işi görür mü?

Kısmen. Piyasadaki pek çok program döviz alanı sunar, ancak çoğu kuru rapor anında uygular. Satın almadan önce tek soru sorun: "Kuru bugün güncellersem geçen ayın raporu değişir mi?" Cevap "evet" ise o yapı geçmişe dönük tutarlılık vermez. Süreçleriniz standarttan uzaklaşıyorsa özel yazılım daha doğru yatırımdır.

Nereden başlamalı?

Yazılım aramadan önce bir hafta boyunca şunu yapın: son 12 ayın en büyük 20 finans hareketini bir tabloya alın ve her satır için "bu işlem hangi gün, hangi kurdan yapıldı?" sorusunu cevaplamayı deneyin. Kaç satırda cevap veremediğinizi sayın. Bu tek sayı, çoklu para birimi kurgusuna ne kadar ihtiyacınız olduğunu her satıcının sunumundan daha net anlatır.

Ardından ikinci adım süreçleri haritalamaktır: hangi kayıt hangi kayıttan doğuyor, hangi veri iki kez giriliyor. Bu haritayı çıkarmak iş süreci otomasyonu çalışmalarının da ilk adımıdır.

Bu ölçümü birlikte yapmak isterseniz ücretsiz ön analiz talebi oluşturabilirsiniz: süreçlerinizi inceleyip kapsam, süre ve bütçe içeren bir öneriyle 1 iş günü içinde dönüyoruz. Benzer işleri müşteri projeleri sayfasında inceleyebilirsiniz.