Koyu zeminli iFinances kapağı — pembe vurgulu mükerrer ödeme motifi: üst üste binmiş iki ödeme satırı ve 'İki kez ödediniz' başlığı
İçgörüler
Strateji

Mükerrer Ödeme: ERP ile Banka Arasındaki Boşlukta Saklanır

iFinances Editörlüğü29 Ağustos 202611 dk

ERP'nin mükerrer kontrolü fatura numarasına bakar; farklı referansla ödenen kopya yalnız banka satırı eşleşince görünür. Altı kaçış deseni ve her birinin testi.

Mükerrer ödemenin en kötü tarafı, olduğu anda hiçbir alarmın çalmamasıdır. Aynı faturayı ikinci kez ödediğinizde defterde hiçbir satır kırmızıya dönmez: tedarikçi kartı sessizce ters bakiye verir, banka bakiyesi kendi içinde tutar, ay kapanır, mizan dengede kalır. Parayı geri isteyecek biri çıkana kadar kimsenin o tabloya bakmak için sebebi yoktur — ve karşı taraf çoğu zaman sizi aramaz.

Ağustos 2020'de Citibank, Revlon kredisinde 7,8 milyon dolarlık faizi göndermek yerine yaklaşık 900 milyon dolarlık anaparayı gönderdi. Bu bir mükerrer ödeme değildi, ama tam olarak aynı boşluğu gösterir: bir ödeme kendi sisteminde doğru görünürken bankada bambaşka bir şeye dönüşebilir ve aradaki farkı yakalayacak bir kontrol yoksa hatayı size ancak parayı alan taraf söyler.

Türkiye'deki finans ekiplerinde bu boşluk çok tanıdık bir cümleyle örtülür: "Bizim ERP mükerrer faturayı zaten engelliyor." Engelliyor — ama engellediği şey mükerrer fatura KAYDI, mükerrer ÖDEME değil. İkisi arasındaki fark, bu yazının konusu.

Mükerrer fatura kontrolü neyi karşılaştırabilir, neyi karşılaştıramaz

Sahada karşılaştığımız yaygın kalıpta mükerrer fatura kontrolü bir anahtar eşitliği üzerine kuruludur: cari kart + fatura numarası, çoğu kurulumda tutar da eklenerek. Kayıt sırasında bu anahtar daha önce görülmüşse uyarı çıkar. Hangi alanların karşılaştırıldığı ve kontrolün tam olarak hangi anda tetiklendiği pakete ve kurulum ayarlarına göre değişir; kendi sisteminizdeki kurguyu kullandığınız yazılımın dokümantasyonundan teyit edin.

Değişmeyen şey, kurgunun altındaki mantıktır — ve o mantığın üç yapısal sınırı vardır:

  • Metin eşitliğine dayanan herhangi bir kontrol, yazım varyantını göremez. FTR2026000001234 ile FTR-2026-000001234, ya da başında boşluk kalmış bir numara, karakter karşılaştırması açısından iki farklı belgedir. Elle girilen tedarikçi faturalarında bu varyasyon istisna değil, kuraldır.
  • Anahtarında cari kart bulunan bir kontrol, iki karta bölünmüş tedarikçiyi karşılaştıramaz. Aynı tedarikçi defterinizde iki karta bölünmüşse — bir kartta "ABC Metal San. Tic. A.Ş.", diğerinde "ABC Metal A.Ş." — anahtarın ilk parçası zaten farklıdır, karşılaştırma hiç yapılmaz.
  • Fatura tarafında tetiklenen bir kontrol, ödeme tarafını göremez. Faturayı bir kez kaydedip iki kez ödediyseniz, kayıt anında çalışan bir denetim devreye hiç girmez. Aynı şekilde, hiç faturaya bağlanmadan yapılan bir avans veya acil havale bu kontrolün görüş alanının tamamen dışındadır.

Yani fatura tarafındaki kontrol, ödeme kaçışlarının yalnızca en kaba biçimini kapatır. Geriye kalanı ancak paranın gerçekten çıktığı yerden — banka ekstresinden — geri okuyarak görebilirsiniz.

Boşluk nerede: üç ayrı gerçeklik, tek bir para

Bir tedarikçi ödemesinin izi üç yerde ayrı ayrı durur. Defterde bir muhasebe kaydı, bankada bir hesap hareketi, GİB tarafında bir elektronik belge vardır. Bu üçü aynı olayı anlatır ama aynı dili konuşmaz: defter fatura numarasıyla, banka açıklama alanındaki serbest metinle, e-fatura ise kendi belge numarasıyla düşünür.

Hacim de küçük değil. GİB 2024 Faaliyet Raporu'na göre 2024'te yaklaşık 1 milyar e-fatura ve 11 milyar e-arşiv belgesi düzenlendi; e-fatura mükellefi sayısı 1.565.603. Bu ölçekte, üç kaydın birbirine bağlanmadığı her yer bir saklanma alanıdır.

Mükerrer ödeme tam olarak bu üç gerçekliğin arasındaki dikişte yaşar. Defterde bakarsanız iki ayrı ödeme kaydı görürsünüz ama ikisi de "geçerli" görünür. Bankada bakarsanız iki çıkış görürsünüz ama hangisinin hangi faturayı kapattığını bilmezsiniz. Ancak ikisini yan yana koyup her banka satırını bir belgeye bağladığınızda, bir faturaya iki ödemenin düştüğü ortaya çıkar.

Ne kadar sızıyor? Kendi rakamınızı hesaplayın

APQC'nin süreç kıyaslama verisine göre mükerrer ya da hatalı ödemeler, kuruluşların yıllık ödemelerinin üst çeyrekte %0,8'i, alt çeyrekte %2'si düzeyinde. Bu oran "kaybedilen para" değil, "yanlış çıkan para" oranıdır; önemli bir kısmı tespit edilirse geri alınır. Ama tespit edilmeyeni de aynı havuzun içindedir.

Kendi büyüklüğünüzü görmek için tek bir çarpma yeterli: yıllık tedarikçi ödemeleriniz × 0,008. Yılda 400 milyon TL ödeme yapan bir şirkette bu, iyi yönetilen bir süreçte bile 3,2 milyon TL'lik bir "yanlış çıkmış olabilir" hacmi demektir; alt çeyrek performansında rakam 8 milyon TL'ye çıkar. Bu bir kayıp tahmini değil, tarama önceliği belirleme aracıdır: bu büyüklükteki bir hacmi hiç taramadan geçirmek bilinçli bir karar olmalıdır, varsayılan davranış değil.

Hataların insan kaynaklı kısmı da ölçülmüş durumda. Gartner'ın Temmuz 2023'te 497 muhasebeciyle yaptığı ankette katılımcıların %18'i her gün, %33'ü haftada birkaç kez, %59'u ayda birkaç kez hata yaptığını söyledi. Elektronik tablolarda durum daha da net: Raymond Panko'nun derlediği saha denetimlerinde incelenen operasyonel tabloların yaklaşık %94'ünde en az bir hata bulundu. (Sıkça dolaşan "tabloların %88'i hatalı" alıntısı yanlıştır; 88, denetlenen tablo sayısıdır.) Ödeme talimatının bir yerinde Excel varsa — ki çoğunda vardır — hata oranı sıfır kabul edilemez.

Mükerrer ödemenin altı kaçış deseni

Aşağıdaki altı desen, ERP'nin fatura-numarası kontrolünü aşan tipik yollardır. Her birinin yanına, o deseni yakalayan somut testi yazdık.

Birinci: aynı tedarikçi, iki cari kart. Unvan iki farklı yazımla açılmış, VKN aynı. Fatura ikinci karta ikinci kez kaydedilir, ikisi de ödenir. *Testi:* cari kartlarınızı VKN üzerinden tekilleştirin; VKN'si aynı olan iki kartın ödeme listelerini aynı tabloda yan yana koyun. Unvan benzerliği tek başına yetmez, Türkçe karakter ve kısaltma farkları unvanı bambaşka gösterir.

İkinci: fatura numarasının yazım varyantı. Tire, boşluk, sıfır dolgusu, İngilizce/Türkçe karakter farkı. Aynı belge, sistem için iki belge. *Testi:* karşılaştırmayı numaranın yalnızca rakam ve harflerini bırakacak şekilde normalleştirdikten sonra yapın; tedarikçi + tutar + tarih penceresi üzerinden ikinci bir tarama daha koşun.

Üçüncü: önce avans, sonra fatura. Proforma karşılığı avans ödenir, ardından asıl fatura geldiğinde tam tutar yeniden ödenir; avans kapatılmamıştır. *Testi:* tedarikçi kartında borç bakiyesi (ters bakiye) arayın. Satıcı kartının borç vermesi normal değildir; genellikle ya kapatılmamış avans ya da mükerrer ödeme anlamına gelir.

Dördüncü: banka portalından yapılan acil ödeme. Gün içinde acil çıkan bir havale banka ekranından yapılır, ERP'ye sonra işlenir — ya hiç işlenmez ya da normal ödeme koşusuyla ikinci kez çıkar. *Testi:* banka ekstresindeki her çıkışı bir defter kaydına bağlayın; eşleşmeyen banka satırı listesi kısa değilse süreç değil, tesadüf yönetiyor demektir.

Beşinci: iade ya da alacak dekontu netleştirilmedi. İade faturası düzenlenmiş ama ödeme kalemi listeden çıkarılmamıştır; hem iade mahsup edilir hem tam tutar ödenir. *Testi:* dönem içinde iade/alacak belgesi olan tedarikçilerin ödeme toplamını fatura toplamıyla ayrı ayrı karşılaştırın.

Altıncı: toplu talimat içindeki kalemin tekrar ödenmesi. Bankaya gönderilen toplu ödeme listesindeki bir satır, listeden düştüğü sanılarak ayrıca ödenir. Banka ekstresinde toplu talimat çoğu zaman tek satır olarak göründüğü için karşılaştırma zorlaşır. *Testi:* toplu ödeme dosyasını kalem kalem saklayın ve banka toplamını kalemlere dağıtarak eşleştirin; toplu ödeme dağıtımı yapılmadan bu desen görünmez.

Bu desenlerin ortak noktası dikkat eksikliği değil, görünürlük eksikliğidir. Altısı da tek bir sistemin içinden bakıldığında normal görünür; yalnızca defter, banka ve e-fatura verisi aynı tabloya konduğunda anormalleşir. Eksik fatura, mükerrer kayıt ve örüntü dışı tutarların nasıl işaretlendiğini anlatan yazımız bu tarama mantığını ayrıntılı ele alıyor.

Örnek: izi banka satırından geriye sürmek

Kurgusal ama tanıdık bir senaryo. Tedarikçiye ait 240.000 TL'lik bir fatura var. Nisan ayında ödeme koşusunda ödeniyor; açıklamaya fatura numarası yazılıyor. Mayıs ayında aynı tedarikçi hesap ekstresi gönderiyor, ekstrede fatura hâlâ açık görünüyor — çünkü karşı taraf tahsilatı başka bir faturaya kapatmış. İyi niyetle "ödenmemiş" diye ikinci kez ödeniyor; bu kez açıklama "cari ödeme" oluyor.

Defterinizde artık aynı tedarikçiye 480.000 TL ödeme, 240.000 TL fatura var; kart 240.000 TL borç bakiyesi veriyor. Aylık kapanışta bu bakiye tek başına "avans" diye yorumlanırsa kaçış tamamlanır. Yakalayan şey şudur: banka ekstresindeki iki çıkışın da aynı VKN'ye gittiğini, toplamın tek faturayı iki kez karşıladığını ve ikinci ödemenin hiçbir belgeye bağlanamadığını gösteren bir eşleştirme. Bu, ödenmiş bir faturanın açık görünmesinin aynası — hayalet borç sizin tarafınızda değil, karşı tarafın ekstresinde ortaya çıkmıştır ve ikinci ödemeyi tetikleyen de odur.

Buradaki ders şu: tedarikçi ekstresine dayanarak ödeme yapmadan önce, o ekstredeki açık kalemin sizin banka çıkışlarınızla eşleşip eşleşmediğine bakılmalıdır. Ekstre karşı tarafın kapama kararını yansıtır; sizin ödeme gerçeğinizi değil.

Buldunuz: iade, mahsup ve düzeltme

Mükerrer ödemeyi tespit ettikten sonra üç şey gerekir.

Delil paketi. İki banka dekontu, ilgili fatura ve iki ödemenin de aynı belgeyi karşıladığını gösteren eşleştirme dökümü. Talebi bu paketle açtığınızda tartışma "ödedik mi" sorusundan "nasıl iade edelim" sorusuna kayar.

Tahsil yöntemi. Sürmekte olan bir ticari ilişkide karşı taraf genellikle nakit iade yerine sonraki faturalardan mahsubu önerir. Mahsup pratiktir ama takip edilmezse ikinci bir sorun üretir: mahsup edildiği varsayılıp fiilen edilmeyen tutarlar. Mahsup kararını yazılı alın ve hangi faturadan düşüleceğini kayda geçirin.

Kayıt hijyeni. Fazla ödenen tutar ilgili tedarikçi hesabında borç olarak durur; iade veya mahsup gerçekleşene kadar bunu "kapatılmış" saymayın. Ters bakiyeyi tek taraflı bir virman kaydıyla eritmek en kötü seçenektir: hem izlenebilirliği yok eder hem de dönem sonunda açıklanamayan bir fark bırakır.

Mutabakat mektubu bu noktada işinize yarar, ama tek başına yeterli sayılmaz. TTK m.94, cari hesapta bakiyeyi gösteren cetveli alan tarafın bir ay içinde itiraz etmemesi hâlinde bakiyeyi kabul etmiş sayılacağını düzenler. Kritik nüans şudur: bu sonuç yazılı cari hesap sözleşmesi bağlamında işler — TTK m.89 uyarınca yazılı şekil geçerlilik şartıdır — ve yazılı sözleşme yoksa mutabakat mektubuna sessiz kalmak tek başına kabul doğurmayabilir. Yani "cetveli gönderdik, itiraz etmediler" cümlesi, iade talebinizin yerine geçmez.

Tekrarı önleyen üç kontrol

Cari kartı VKN ile tekilleştirin. Unvan benzerliği öneri üretir, VKN karar verir. Yeni tedarikçi açılışında VKN kontrolü zorunlu alan olmalıdır.

Her banka çıkışını bir belgeye bağlayın. Aylık kapanışta hedef, "banka bakiyesi tutuyor" değil, "eşleşmemiş banka satırı sayısı sıfıra yakın" olmalıdır. Bu iki cümle aynı şey değildir; birincisi toplamı, ikincisi kalemi doğrular. Banka mutabakatının adım adım nasıl kurulduğunu anlatan sayfamızda bu kalem bazlı yaklaşım ayrıntılı duruyor.

Ödeme koşusundan önce bulanık tarama koşun. Aynı VKN, benzer tutar ve dar tarih penceresi kombinasyonunu ödeme öncesi tarayın. Bu tarama bir onay makinesi değil, bir soru üreticisidir: "bu ikisi aynı fatura olabilir mi?" sorusunu insana sorar.

iFinances bu işin neresinde

iFinances, defter/ERP kayıtlarınızı, banka ekstrenizi ve e-fatura verinizi aynı tabloya koyar ve her banka satırını belgeye bağlamaya çalışır. Eşleştirme motoru FIFO ve faturaya özel kapama, kısmi ödeme bölme, toplu ödeme dağıtma ve kuruş toleransı ile çalışır; farklı para birimlerinde TCMB resmî kurunu kullanır. Banka açıklamasındaki unvanı cari kartla eşleştirirken Türkçe karakter katlamalı benzerlik kullanır — ama bu bir ÖNERİdir, kararı insan verir.

Her eşleşmenin yanında yazılı gerekçe durur: tutar örtüşüyor, tarih uyuyor, referans şu faturayı gösteriyor. Eşleşmeyen banka satırları ve örüntü dışı tutarlar anomali olarak işaretlenir; yukarıdaki altı desenin çoğu bu listede yüzeye çıkar. Karşı tarafa güvenli bir bağlantıyla kendi ekstresini yükletebilirsiniz; onun bir yazılıma ihtiyacı olmaz. Excel/CSV alımı ERP'den bağımsızdır: Logo, SAP, Mikro, Netsis, Luca, Zirve ya da düz Excel.

Açık olalım: iFinances defter tutmaz, kayıt üretmez ve hiçbir satırı kendi başına kapatmaz. Yaptığı şey, mükerrer ödemenin saklandığı boşluğu görünür kılmak ve kararı verecek kişinin önüne gerekçesiyle koymaktır. İade talebini de, düzeltme kaydını da siz yaparsınız.

Mükerrer ödemenin ortaya çıktığı yer banka satırıdır; sürecin tamamı için banka mutabakatının adım adım rehberine bakabilirsiniz.

Sık Sorulan Sorular

Mükerrer ödeme nasıl tespit edilir?

En güvenilir yol banka ekstresinden geriye okumaktır: dönemdeki her banka çıkışını bir faturaya veya belgeye bağlayın, bağlanamayan satırları liste hâlinde inceleyin. Buna ek olarak tedarikçi kartlarında ters bakiye (satıcı hesabının borç bakiyesi vermesi) taraması yapın, cari kartları VKN üzerinden tekilleştirin ve fatura numaralarını yalnızca harf-rakam kalacak biçimde normalleştirip aynı tedarikçi-tutar-tarih penceresinde ikinci bir tarama koşun. Yalnız ERP'nin fatura numarası kontrolüne güvenmek yetmez; o kontrol mükerrer fatura kaydını engeller, mükerrer ödemeyi değil.

Mükerrer ödeme geri alınabilir mi?

Evet, ama süreci siz başlatmak zorundasınız; karşı taraf çoğu zaman fazla tahsilatı kendiliğinden bildirmez. İki banka dekontu, ilgili fatura ve iki ödemenin aynı belgeyi karşıladığını gösteren eşleştirme dökümünden oluşan bir delil paketiyle talep açın. Sürmekte olan ticari ilişkilerde karşı taraf genellikle nakit iade yerine sonraki faturalardan mahsubu önerir; mahsup kabul edilecekse hangi faturadan düşüleceği yazılı olarak kayda geçirilmelidir, aksi hâlde "mahsup edildi sanılan" ikinci bir açık kalem doğar.

Mükerrer ödemenin muhasebe kaydı nasıl düzeltilir?

Fazla ödenen tutar, iade veya mahsup fiilen gerçekleşene kadar ilgili tedarikçi hesabında borç bakiyesi olarak açık bırakılır ve bu bakiyenin gerekçesi belgelenir. Ters bakiyeyi tek taraflı bir virmanla ya da kasa hareketiyle eritmek en riskli yoldur: izlenebilirliği yok eder ve dönem sonunda açıklanamayan bir fark bırakır. Kaydın nasıl kapatılacağı iade mi mahsup mu olduğuna göre değişir; her iki durumda da kapatma, karşı tarafla yazılı teyide dayanmalıdır. Somut kayıt tekniği için mali müşavirinizle çalışın.

ERP'miz mükerrer fatura kontrolü yapıyor, yine de mükerrer ödeme olur mu?

Olur. Yaygın kalıpta bu kontrol cari kart + fatura numarası anahtarında metin eşitliği arar ve fatura tarafında tetiklenir; karşılaştırılan alanların tam listesi ve tetiklenme anı pakete ve kurulum ayarlarına göre değişir, kendi sisteminizinkini yazılımınızın dokümantasyonundan teyit edin. Mantık aynı kaldığı sürece sonuç da aynıdır: aynı tedarikçi iki cari kartta açılmışsa, fatura numarası farklı yazılmışsa, ödeme banka portalından elle yapılmışsa ya da avans kapatılmadan asıl fatura ödenmişse anahtar hiç eşleşmez ve kontrol devreye girmez. Bu yüzden fatura tarafındaki kontrolün yanına ödeme tarafında, banka ekstresi üzerinden çalışan ikinci bir kontrol gerekir.

Mükerrer ödeme taramasını ne sıklıkla yapmalıyız?

Aylık kapanış çevrimine bağlamak pratik bir standarttır: her ay banka ekstresindeki çıkışları belgelere bağlayıp eşleşmeyenleri inceleyin. Ventana Research'ün 2023 verisine göre kuruluşların %58'i ayı altı iş günü içinde kapatıyor ancak mutabakatlarının çoğunu ya da tamamını otomatikleştiren kuruluş oranı yalnızca %31; yani çoğu ekipte kapanış hızlı, eşleştirme hâlâ elle yapılıyor. Ödeme hacminiz büyükse aylık taramanın yanına ödeme koşusu öncesi hızlı bir aynı-tedarikçi-benzer-tutar kontrolü ekleyin.

✦ iFinances — Görmediğini gör.

iFinances Editörlüğü
Mevzuat, mutabakat, mühendislik. Türkiye finans ekiplerinin masasından.
Aylık bülten

Sonraki ay 2-3 yazı daha. Bültene kayıt olun.

Yeni içgörüleri e-posta kutunuza alın. Spam yok.

info@iwise.co

WhatsApp ile yazın