Önce tahsilatı giderden ayırın, sonra aralarında iz kurulmasını sağlayın

İhracat bedelinin kripto varlıkla tahsil edilmiş olması ile gümrük veya liman giderinin ödenmesi iki ayrı ticari olaydır. İlk olayda işletme müşteriden doğan alacağını kapatır; ikincisinde gümrük müşavirine, terminal işletmesine, taşıyıcıya, acenteye ya da başka bir hizmet sağlayıcısına karşı borcunu yerine getirir. Aynı varlık veya aynı ödeme altyapısı kullanılsa bile tahsilat kaydı, gider belgesi yerine geçmez. Sağlam süreç, iki olayı birbirine karıştırmadan aralarında izlenebilir bir kaynak ve amaç bağı kurar.

Bu nedenle kontrolün başlangıç sorusu “cüzdanda yeterli bakiye var mı?” değil, “hangi şirket borcu, hangi belgeye dayanarak, kime ve hangi yetkiyle ödeniyor?” olmalıdır. Kripto geliriyle ilişkilendirilen müşteri, sipariş, fatura ve tahsilat kaydı ayrı; liman veya gümrük hizmetinin siparişi, masraf dökümü, lehtarı ve ödeme onayı ayrı tutulur. İhracatta proforma, sipariş ve ödeme kaydını eşleştirme yaklaşımı gelir tarafındaki referans zincirini kurmaya yardımcı olur. Gider tarafında ise aynı disiplin, masraf dosyası ve lehtar kaydı etrafında uygulanmalıdır.

Bu makaledeki çerçeve, bir ödemenin hukuken veya vergisel olarak uygun olduğu sonucunu üretmez. Belgenin niteliği, giderin kaydı, ödeme aracının kabulü, kambiyo ve raporlama yükümlülükleri ülkeye, tarafların statüsüne, sözleşmeye ve işlemin yapısına göre değişebilir. İşlem öncesinde ilgili ülkelerde yetkin hukuk, vergi, gümrük ve muhasebe uzmanlarının kontrolü gerekir. Buradaki amaç, uzman incelemesine sunulabilecek tutarlı bir doğrulama ve kontrol kaydı oluşturmaktır.

Ödeme talebinin ticari dayanağını ve gerçek lehtarı doğrulayın

Her ödeme talebi, operasyon ekibinin gönderdiği bir mesajdan daha güçlü bir ticari dayanağa bağlanmalıdır. Dosyada hizmetin ne olduğu, hangi sevkiyat veya gümrük işlemi için verildiği, talebi kimin oluşturduğu ve bedelin hangi belgeyle desteklendiği açıkça görünmelidir. Liman hizmeti için terminal veya acente faturası; müşavirlik için sözleşme, hizmet emri ve fatura; henüz nihai fatura yoksa proforma veya resmi masraf talebi kullanılabilir. “Acil liman ödemesi” gibi genel bir açıklama tek başına yeterli kontrol kanıtı değildir.

Asgari ticari dayanak kaydında şu alanlar bulunmalıdır:

Lehtar kontrolü yalnızca ekrandaki unvana bakılarak yapılmamalıdır. Fatura veya masraf dekontundaki tüzel kişi, sözleşmedeki hizmet sağlayıcısı ve ödeme adresinin sahibi arasında açıklanabilir bir bağ aranır. Gümrük müşaviri ödemeyi kendi adına değil başka bir acente adına istiyorsa temsil ilişkisi ve ödeme talimatı dosyaya eklenir. Liman hizmet sağlayıcısının tahsilatı grup şirketine yönlendirmesi hâlinde grup ilişkisi, yetkili talimat ve belgedeki lehtar uyumu ayrıca onaylanır. E-posta alan adı, bilinen iletişim kanalı ve daha önce doğrulanmış tedarikçi kartı yardımcı kontrollerdir; tek başına sahiplik kanıtı sayılmaz.

Ödeme amacı da serbest metin olarak bırakılmamalıdır. “Hizmet bedeli” yerine liman elleçleme, ardiye, acentelik, müşavirlik veya belge işlem bedeli gibi belgedeki tanımla uyumlu bir amaç seçilir. Ancak şirket içi açıklamanın bir giderin hukuki veya vergisel niteliğini belirlemediği unutulmamalıdır. Sınıflandırmayı yetkili uzman ve muhasebe politikası belirler.

Belge paketini ödeme kaydıyla tek dosyada eşleştirin

Doğrulama dosyasının merkezinde belge paketi bulunur. Paket yalnızca faturanın PDF kopyasından ibaret değildir; talebin oluşumundan ödemenin kapatılmasına kadar aynı referansın korunmasını sağlar. Bir kripto fatura kaydı gelir tarafındaki tahsilatı ticari referansa bağlayabilir. Gider tarafında ise ERP, hazine modülü veya kontrollü bir kayıt tablosu benzer ilişkiyi kurmalıdır. Sistemler farklıysa ortak dosya numarası bütün kayıtlara yazılır.

Dosyada, işlem durumuna göre, fatura veya proforma; masraf dekontu; sözleşme ya da hizmet emri; gümrük müşavirinin veya liman hizmet sağlayıcısının tam ticari unvanı; vergi ve iletişim bilgileri; ödeme talimatı; ilgili sevkiyat ve taşıma referansı; iç onaylar; ağ işlem kaydı ve muhasebe fişi birlikte indekslenir. Belge revize edilmişse eski sürüm silinmez. Hangi sürümün neden değiştiği, yeni tutarı kimin doğruladığı ve ödeme hesabının hangi sürüme göre yapıldığı kaydedilir.

Pratik eşleştirme tablosu şu sütunları taşıyabilir:

Kontrol alanı Belgedeki kaynak Ödeme kaydındaki karşılığı Onay durumu
Ticari borç Fatura, proforma veya masraf dekontu Gider dosya numarası ve açıklama Belge kontrolü
Hizmet ve sevkiyat Hizmet emri, beyanname veya taşıma referansı Sipariş/sevkiyat referansı Operasyon kontrolü
Lehtar Belgeyi düzenleyen ve sözleşme tarafı Doğrulanmış alıcı unvanı ve adres kaydı Tedarikçi kontrolü
Tutar ve para birimi Belgenin toplamı ve kalemleri Kur kaydı ile hesaplanan varlık tutarı Hazine kontrolü
Ödeme kanıtı Karşı tarafın kabul talimatı Ağ, varlık, adres ve işlem kimliği Finans kontrolü
Kapanış Makbuz, hesap ekstresi veya hizmet sağlayıcı teyidi Muhasebe fişi ve kapatma tarihi Muhasebe kontrolü

Belgenin var olması, içeriğin doğru olduğunu otomatik olarak göstermez. Mükerrer fatura numarası, önceki sevkiyata ait masraf, farklı tüzel kişilik, değiştirilmiş ödeme adresi veya açıklanamayan ek kalemler istisna kuyruğuna alınmalıdır. İç kontrol ve olay kaydı rehberi, normal akıştan sapmaların mesajlaşmada kaybolmaması için olay, kanıt, karar sahibi ve sonuç alanlarını ayrı tutma yaklaşımını açıklar.

Ağ, varlık, adres, kur ve tutar alanlarını ödeme öncesinde sabitleyin

Ticari belge doğrulandıktan sonra ödeme talimatının teknik alanları hazırlanır. “USDT gönderilecek” ifadesi yeterli değildir; aynı varlık farklı ağlarda bulunabilir ve adres biçiminin tanıdık görünmesi doğru ağı garanti etmez. Desteklenen varlıkların genel kapsamı desteklenen coinler sayfasında görülebilir, fakat belirli bir gider ödemesinde kullanılacak varlık, ağ ve adres karşı tarafın güncel ve yetkili talimatıyla ayrıca doğrulanmalıdır. USDT ağ seçimi rehberi de varlık adı ile ağ bilgisinin neden iki ayrı alan olduğunu açıklar.

Ödeme kaydı, işlem gönderilmeden önce en az şu teknik ve finansal alanları kilitlemelidir:

Kur kaydı sonradan yeniden üretilebilecek kadar ayrıntılı olmalıdır. Yalnızca “güncel kur kullanıldı” yazmak yeterli değildir. Kaynak, fiyatın alındığı zaman, fiyatın hangi iki değer arasında kurulduğu, yuvarlama yöntemi ve onaylanan nihai varlık tutarı kaydedilir. Kur kaynağının seçimi ile muhasebede kullanılacak değerleme yöntemi aynı konu değildir; muhasebe ve vergi uygulaması ayrıca uzman tarafından belirlenmelidir.

Adres değişikliği yüksek riskli bir olay olarak ele alınmalıdır. Daha önce ödeme yapılmış bir hizmet sağlayıcısı yeni adres gönderdiğinde, eski e-posta zincirine yanıt gelmesi tek başına yeterli görülmez. Önceden kayıtlı iletişim kişisiyle bağımsız kanaldan doğrulama, değişiklik nedeni ve ikinci onay kayda alınır. Entegrasyon kullanılıyorsa API ürün sayfasında tanıtılan bağlantı yaklaşımı ödeme olaylarını iç sistem referanslarına taşımaya yardımcı olabilir; yine de lehtar sahipliği ve ticari amaç kontrolü şirketin sorumluluk matrisinde kalır.

Onay matrisini ödeme, operasyon ve uyum kararlarını ayıracak şekilde kurun

Tek kişinin belgeyi alması, adresi girmesi, kuru seçmesi ve transferi onaylaması hata veya kötüye kullanımın fark edilmesini zorlaştırır. Kurumsal kripto tahsilatlarında yetki ve onay akışı tahsilat odaklı olsa da görevlerin ayrılığı ilkesi gider ödemelerine de uygulanabilir. Matris, unvanlardan çok karar türlerini tanımlamalıdır.

Örnek sorumluluk ayrımı şöyledir:

  1. İhracat veya lojistik ekibi: Hizmetin gerçekten alındığını, sevkiyat referansını ve operasyonel son tarihi doğrular.
  2. Gümrük ekibi veya yetkili koordinatör: Müşavir, beyanname ve masraf kalemleri arasındaki ilişkiyi kontrol eder; mevzuat sonucu hakkında yetkisi dışında karar vermez.
  3. Satın alma veya tedarikçi yönetimi: Lehtar unvanını, sözleşmeyi, yetkili iletişim kanalını ve adres değişikliğini inceler.
  4. Hazine: Varlık, ağ, adres, kur, tutar, bakiye kaynağı ve ödeme zamanını kontrol eder.
  5. Uyum veya risk sorumlusu: Şirket politikasının gerektirdiği taraf, amaç ve işlem kontrollerini uygular. Cryptoway AML politikası bir sağlayıcı politikasıdır; işletmenin kendi yükümlülükleri ve işlem özelindeki incelemesi yerine geçmez.
  6. Muhasebe: Belge, ödeme kanıtı, kur kaydı ve hesap kapatma ilişkisinin kayda alınabilirliğini kontrol eder.
  7. Nihai onay sahibi: Matrise göre transferi serbest bırakır; hazırlayan kişiyle aynı olmaması tercih edilir.

Matris ayrıca hangi olayların normal akışı durduracağını belirtmelidir: yeni tedarikçi, yeni adres, üçüncü taraf lehtar, belge ile talimat arasında unvan farkı, son anda değişen ağ, bölünmüş ödeme, olağan dışı yuvarlama farkı veya talebin yalnızca kişisel mesajlaşma kanalından gelmesi. Tutar eşikleri şirketin risk iştahına göre belirlenebilir; doğrulanmamış evrensel bir eşik kullanılmamalıdır.

Acil ödeme gerekçesi kontrolü kaldırmamalıdır. Limanda bekleme maliyeti doğması, talebin hızla ele alınmasını gerektirebilir; fakat belge ve adres doğrulamasını atlamak için tek başına gerekçe değildir. Hızlandırılmış akış varsa hangi kontrollerin aynı kaldığı, hangi yöneticinin istisna verdiği ve eksik belgenin ne zaman tamamlanacağı önceden yazılı olmalıdır.

Eksik, fazla, geç ve üçüncü taraf ödemelerini istisna kaydıyla yönetin

Gönderim tamamlandığında süreç bitmez. Beklenen tutar ile transfer edilen tutar, ağda görülen tutar ve lehtarın kabul ettiği tutar karşılaştırılır. Ağ ücreti veya kur hareketi nedeniyle fark oluştuğu varsayılmamalı; farkın nedeni kayıttan gösterilmelidir. Eksik ödeme için kalan borç, yeni kur zamanı ve ek transfer onayı ayrı oluşturulur. Fazla ödeme için mahsup, iade veya alacak kaydı kararı yetkili ekiplerce verilir; ilk işlemin açıklaması geriye dönük değiştirilmez.

Geç ödeme, özellikle proforma veya adres talimatının geçerlilik süresi dolduysa otomatik olarak kabul edilmemelidir. Hizmet sağlayıcısından tutarın ve adresin hâlâ geçerli olduğu teyit edilir; gerekiyorsa yeni belge veya talimat alınır. Liman masrafının gecikme nedeniyle değişmesi hâlinde eski ve yeni kalemler ayrıştırılır. Böylece ilk talep ile son ödeme arasındaki fark yalnızca sözlü açıklamaya dayanmaz.

Üçüncü taraf ödeme iki yönde ortaya çıkabilir: işletme borcunu grup şirketi veya başka bir kişi üzerinden ödemek isteyebilir; hizmet sağlayıcısı da bedelin sözleşmede görünmeyen başka bir lehtara gönderilmesini talep edebilir. Her iki durumda tarafların rolü, yetkilendirme zinciri, ödemenin borcu nasıl kapattığı ve gerekli uyum kontrolleri belgelenmeden transfer serbest bırakılmamalıdır. Bu kayıt, işlemin hukuki veya vergisel olarak kabul edilebilir olduğu anlamına gelmez; ülke ve sözleşme koşullarına göre uzman görüşü gerekir.

Geri ödeme gerektiğinde, ilk gönderen adrese otomatik dönüş de yeni bir adrese koşulsuz transfer de güvenli varsayılmamalıdır. İade nedeni, hak sahibi, iade edilecek varlık ve ağ, tutar hesaplaması, ücret yaklaşımı, onaylar ve karşı taraf teyidi ayrı dosyalanır. Kripto ödemelerinde geri ödeme kuralları müşteri iadelerine odaklanır; aynı kanıt disiplini tedarikçi kaynaklı fazla ödeme veya iptal durumuna uyarlanabilir. İadenin muhasebe ve vergi etkisi işlem özelinde uzman tarafından değerlendirilmelidir.

Her istisna için “olay–kanıt–karar–uygulama–kapanış” sırası kullanılabilir. Örneğin eksik ödeme olayı; belge tutarı, kur kaydı ve ağ işleminden oluşan kanıtla açılır. Hazine veya muhasebe kalan tutara karar verir. İkinci transfer ayrı işlem kimliğiyle uygulanır. Hizmet sağlayıcısının borcun kapandığını teyit etmesiyle dosya kapanır.

Muhasebe ve denetim izi için kapanış kaydını tamamlayın

Ödeme sonrasında oluşturulan kapanış kaydı, denetçinin veya yöneticinin işlemi baştan sona yeniden kurabilmesini sağlamalıdır. Kripto ödeme mutabakatı rehberi ödeme olayı ile ticari kaydın düzenli biçimde eşleştirilmesine odaklanır. Gümrük ve liman giderlerinde buna hizmetin alındığına dair operasyon teyidi, masrafın ilgili sevkiyatla ilişkisi ve lehtarın borcu kapattığına dair kanıt da eklenir.

Kapanış dosyasında şunlar birlikte bulunmalıdır:

İşletmeler için kripto ödeme mutabakatı çerçevesindeki gibi, ağ işlemi ile muhasebe fişi arasında tekil bir referans kullanılmalıdır. Aynı işlem birden fazla gideri kapatıyorsa dağıtım anahtarı açıkça yazılır; bir gider birden fazla transferle ödenmişse bütün işlem kimlikleri aynı dosyada ilişkilendirilir. Böylece bakiye hareketi ile masraf belgesi arasında açıklanamayan toplu fark bırakılmaz.

Denetim izi yalnızca dosyaları saklamak değildir. Kimin hangi veriyi değiştirdiği, değişikliğin ne zaman yapıldığı, önceki değerin ne olduğu ve hangi kanıtla onaylandığı görülebilmelidir. Erişim yetkileri görevle sınırlanmalı; ödeme adresi veya kur kaydı sonradan değiştirildiğinde iz korunmalıdır. İşletmelerde finans ekibini aşırı yüklemeden kripto ödeme yönetimi süreç sahipliğini dağıtmanın önemini açıklar; burada hedef kontrolü azaltmak değil, kanıtı doğru ekipte üretip tek dosyada toplamaktır.

Son kontrol üç eşleştirmeyle yapılır: ticari borç ile belge, belge ile onaylanan ödeme talimatı, ödeme talimatı ile gerçekleşen ağ işlemi. Bunlara muhasebe fişi ve lehtar kapanış teyidi bağlandığında kayıt operasyon, hazine ve denetim için yeniden izlenebilir hâle gelir. Bununla birlikte kayıt bütünlüğü hukuki veya vergisel uygunluk kararı değildir. Özellikle sınır ötesi ödeme, üçüncü taraf lehtar, grup şirketi kullanımı, gümrük giderinin niteliği ve kripto varlık değerlemesi ilgili ülke, sözleşme ve şirket koşullarına göre yetkin uzmanlarca incelenmelidir.