Banka Mutabakat Otomasyonu: Cari Eşleştirme Algoritması Nasıl Kurulur?

Banka mutabakat otomasyonunun zor kısmı ekstreyi okumak değil, gelen 1.847,50 TL'nin hangi faturaya ait olduğuna karar vermektir. Bu bir arama değil atama problemidir: N banka hareketini M açık kalemle eşlemeniz gerekir ve her hareket birden fazla kaleme, her kalem birden fazla harekete aday olabilir. İşe yarayan mimari tek bir akıllı algoritma değil, kademeli bir hat: önce tekilleştirme, sonra yapısal referans (camt.053'te EndToEndId, TR Karekod'da RefBlg, ISO 11649'da RF referansı), sonra tahsis edilmiş hesap, sonra tutar-tarih tekliği, en sonda ve yalnızca öneri olarak bulanık unvan benzerliği. Aşağıda bu hattın her kademesi, gerçek alan adlarıyla.

Bu yazı, banka entegrasyonu rehberimizin devamıdır. MT940'ın genel yapısı, ÖHVPS ve sanal POS ayrımı orada anlatıldı; burada yalnızca eşleştirme katmanı var. Alan adları 25 Eylül 2026'da camt.053 uygulama kılavuzundan, MT940 biçim dokümanından ve TCMB TR Karekod rehberinden doğrulanmıştır.

Referansı Taşıyabiliyorsanız Algoritmaya İhtiyacınız Yok

Eşleştirme algoritması, ödeme referansını taşıyamadığınız durumlarda başvurduğunuz telafi mekanizmasıdır. Referansı taşıyabiliyorsanız eşleşme oranı yüzde doksanların üzerine çıkar ve yanlış eşleşme neredeyse sıfırlanır. Türkiye'de referans taşımanın üç yolu var ve üçü de dokümante edilmiş standartlara dayanıyor.

1. ISO 11649 RF Creditor Reference

Biçimi 2!a2!n21c: "RF" + iki kontrol hanesi + en fazla 21 alfanümerik karakter, toplam azami 25 karakter. Kontrol haneleri ISO/IEC 7064 MOD 97-10 ile hesaplanır. Faydası şu: müşteri açıklamaya yanlış bir kod yazarsa siz bunu eşleştirmeye kalkışmadan önce anlarsınız, çünkü kontrol hanesi tutmaz. Kodsuz bir "FTR-2026-4821" dizesinde böyle bir emniyet yoktur.

<?php
// ISO 11649 RF Creditor Reference - uretim ve dogrulama.
// ISO/IEC 7064 MOD 97-10. PHP 8.1+, bcmath gerekmez.

function rfHarfleriSayiyaCevir(string $s): string
{
    $out = '';
    foreach (str_split(strtoupper($s)) as $ch) {
        $out .= ctype_digit($ch) ? $ch : (string) (ord($ch) - 55); // A=10 ... Z=35
    }
    return $out;
}

function mod97(string $rakamlar): int
{
    $kalan = 0;
    foreach (str_split($rakamlar) as $d) {          // uzun sayilar icin parcali mod
        $kalan = ($kalan * 10 + (int) $d) % 97;
    }
    return $kalan;
}

function rfUret(string $referans): string
{
    $kontrol = 98 - mod97(rfHarfleriSayiyaCevir($referans . 'RF00'));
    return sprintf('RF%02d%s', $kontrol, strtoupper($referans));
}

function rfGecerliMi(string $rf): bool
{
    $rf = preg_replace('/\s+/', '', strtoupper($rf));
    if (! preg_match('/^RF\d{2}[0-9A-Z]{1,21}$/', $rf)) {
        return false;
    }
    return mod97(rfHarfleriSayiyaCevir(substr($rf, 4) . substr($rf, 0, 4))) === 1;
}

// rfUret('FTR2026004821')  => 'RF61FTR2026004821'
// rfGecerliMi('RF61FTR2026004821') => true
// rfGecerliMi('RF61FTR2026004812') => false   (rakamlar yer degistirdi, yakalandi)

2. TR Karekod: referans zaten mesajın içinde

TCMB'nin FAST-TR Karekod rehberi (Sürüm 1.5, Ocak 2025), işyeri karekodunda "Ek Veri Alanları Şablonu"nu 62 alan kodu altında tanımlıyor ve iki alt alanı doğrudan ödeme mesajına taşıyor:

Dinamik karekodda 54 (Tutar) zorunludur ve 07 alt alanıyla son geçerlilik zamanı verilir. Yani karekodla tahsilat yapıyorsanız tutar ve referans birlikte, bozulmadan gelir: eşleştirme problemi ortadan kalkar. Faturaya basılan karekod, mutabakat otomasyonuna yapılabilecek en ucuz yatırımdır çünkü algoritma yazmak yerine sorunu kaynağında çözer.

3. Müşteriye tahsis edilmiş hesap

Her müşteriye ayrı bir tahsilat hesabı (sanal IBAN / alt hesap) verilebiliyorsa eşleştirme tek satırlık bir sorguya iner. Bankanızın kurumsal ürün ekibine sorulacak soru budur. Maliyeti vardır, ama karşılığında hem algoritma hem de operasyon ekibi ortadan kalkar.

Ekstrede Hangi Alan Neye Yarıyor?

Eşleştirme kurallarınızı yazmadan önce elinizdeki alanların ne olduğunu bilmeniz gerekir. camt.053 tarafında hareket (Ntry) düzeyinde ve işlem detayı (TxDtls) düzeyinde ayrı alan setleri var:

<Ntry>
  <NtryRef>20260904000918</NtryRef>              <!-- banka hareket referansi -->
  <Amt Ccy="TRY">1847.50</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <RvslInd>false</RvslInd>                       <!-- ters kayit mi? -->
  <Sts>BOOK</Sts>                                <!-- muhasebelesti mi? -->
  <BookgDt><Dt>2026-09-04</Dt></BookgDt>
  <ValDt><Dt>2026-09-04</Dt></ValDt>
  <AcctSvcrRef>TRB2026090400091827</AcctSvcrRef> <!-- TEKILLESTIRME ANAHTARI -->
  <BkTxCd>
    <Domn><Cd>PMNT</Cd>
      <Fmly><Cd>RCDT</Cd><SubFmlyCd>DMCT</SubFmlyCd></Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <EndToEndId>RF61FTR2026004821</EndToEndId> <!-- BIRINCIL ESLESTIRME -->
      </Refs>
      <RltdPties><Dbtr><Nm>ORNEK GIDA SAN VE TIC LTD STI</Nm></Dbtr></RltdPties>
      <RmtInf>
        <Strd><CdtrRefInf><Ref>RF61FTR2026004821</Ref></CdtrRefInf></Strd>
        <Ustrd>EYLUL FATURA ODEMESI</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
  <AddtlNtryInf>GELEN EFT</AddtlNtryInf>
</Ntry>

Dört alan hakkında kılavuz metninin kendisi belirleyici:

• CdtrRefInf/Ref için tanım şu: "Unique reference, as assigned by the creditor, to unambiguously refer to the payment transaction." Kılavuz ekliyor: zincir boyunca tek bir tanımlayıcı taşınabiliyorsa alacaklı referansı EndToEndId içine yazılmalıdır. Pratik sonuç: RF referansınızı her iki alana da koyun, çünkü hangi bankanın hangisini taşıyacağını önceden bilemezsiniz.
• Sts hareketin banka defterindeki durumudur. BOOK dışındaki bir hareketi (örneğin beklemede olanı) muhasebeleştirmeyin; ertesi gün kaybolabilir.
• RvslInd için tanım net: "If the CreditDebitIndicator is CRDT and ReversalIndicator is Yes, the original operation was a debit entry." Yani CdtDbtInd=CRDT görmek "para geldi" demek değildir; ters kayıt olabilir.
• BkTxCd üçlü sınıflandırmadır: alan (Domn), aile (Fmly), alt aile (SubFmlyCd). Gelen havale PMNT / RCDT / DMCT ile gelir. Bu kod, komisyon ve masraf hareketlerini tahsilatlardan ayırmanın en sağlam yoludur; açıklama metnine bakarak ayırmaya çalışmayın.

MT940 tarafında karşılıkları :61: alanının alt alanlarındadır. Biçim 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x] ve borç/alacak işareti dört değer alabilir: C, D, RC (alacağın tersi, borç kaydı), RD (borcun tersi, alacak kaydı). Ters kayıt mantığı burada da var ve RC/RD'yi ayırmayan ayrıştırıcı iade edilen bir havaleyi yeni tahsilat sayar.

Aynı alanın 6. alt alanı işlem tipi kodudur: SWIFT üzerinden gelmeyen ödeme ve transferlerde N3!c biçimindedir (NTRF transfer, NMSC muhtelif, NCHG masraf, NDDT otomatik ödeme, NRTI iade edilen kalem, NINT faiz). Banka tarafından ilk kez ekstreyle bildirilen kalemlerde önek F olur (FCHG, FINT). Tahsilat eşleştirmesine yalnızca NTRF ve benzeri transfer kodlarını sokun; NCHG ve FINT satırları muhasebeye gider, cari eşleştirmeye değil.

Yapılandırılmış :86: kullanan bankalarda etiketler de standarttır: /RREF/ (alacaklı referansı), /EREF/ (uçtan uca referans), /ORDP/ (gönderen taraf), /REMI/ (serbest açıklama), /RCMT/ (alınan tutar), /CHRG/ (masraf). Bir bankanın :86:'sında bu etiketleri görüyorsanız, ayrıştırıcınızı serbest metin yerine etiket bazlı yazın.

Dört Kademeli Eşleştirme Hattı

Kademeler sırayla çalışır ve bir kademe eşleştirdiğinde sonrakiler o hareket için çalışmaz. Her eşleşme, hangi kademenin ürettiğini kaydeder; bu alan sonradan kalite ölçmenin tek yoludur.

<?php
// Eslestirme hatti: kademeler sirayla denenir, ilk kesin sonucta durulur.

final class EslestirmeHatti
{
    /** @param list<Kademe> $kademeler K0 haric, sirali */
    public function __construct(private array $kademeler) {}

    public function calistir(BankaHareketi $h): Eslesme
    {
        foreach ($this->kademeler as $kademe) {
            $sonuc = $kademe->dene($h);

            if ($sonuc->kesin()) {
                return $sonuc->kilitle($kademe->ad());     // otomatik muhasebeles
            }
            if ($sonuc->adaylar() !== []) {
                return Eslesme::operatoreDusur($sonuc->adaylar(), $kademe->ad());
            }
        }
        return Eslesme::eslesmedi();
    }
}

Hattın en önemli özelliği, "birden fazla aday" durumunu başarısızlık değil, farklı bir sonuç olarak ele almasıdır. Tutarı tutan iki fatura varsa doğru davranış rastgele birini seçmek değil, ikisini de operatöre sıralı göstermektir.

Tolerans Sabit Bir Sayı Değildir

"5 TL tolerans" gibi tek bir eşik kurmak iki yönden de yanlıştır. Tolerans, farkın sebebine göre tanımlanır:

Son satır en sık karıştırılanıdır. Eksik ödemeyi toleransla yutan bir sistem, cari bakiyeyi kapatır ve müşterinin borcunu sessizce siler. Bu, eşleşmemiş bir tahsilattan kat kat pahalıdır.

Kısmi ve Toplu Ödeme: Alt Küme Toplamı Tuzağı

Bir müşteri tek havaleyle üç faturasını birden öder. Elinizde 1.847,50 TL var ve o müşterinin 18 açık faturası. Hangi faturaların toplamı bu tutarı veriyor? Bu, bilinen bir zor problemdir (alt küme toplamı) ve aday sayısı arttıkça kombinasyon sayısı katlanarak büyür. 18 kalemde 262.143 alt küme vardır; hesaplamak mümkündür ama asıl sorun performans değil, birden fazla alt kümenin aynı toplamı vermesidir.

Sahada tutan kural seti:

• Alt küme aramasını yalnızca tek bir cari belirlenmişse (K1 veya K2 kademesinden geçmişse) çalıştırın. Cari belli değilken tüm açık kalemler üzerinde arama yapmak, tesadüfi eşleşme üretir.
• Aday kalem sayısını sınırlayın: en eski 12 açık kalem yeter. Sınırı aşarsa operatöre düşürün.
• Çözüm tek değilse otomatik eşleştirmeyin. İki farklı fatura kombinasyonu aynı toplamı veriyorsa doğru cevabı bilemezsiniz.
• Tek çözüm bulunsa bile, alt küme dışında kalan kalemlerden biri aynı tutara sahipse yine operatöre düşürün.
• Çoğu kurumda daha basit bir kural işi bitirir: FIFO tahsis. Tutarı en eski açık kalemden başlayarak kapatın, artan kısmı avans olarak bekletin. Bunu müşteriyle yazılı olarak mutabık kalın; muhasebe politikası kararıdır.

Bulanık Eşleştirme: Metrikten Önce Normalizasyon

Gönderen unvanı benzerliği, ancak normalizasyon doğruysa işe yarar. Türkçe kurumsal unvanlarda gürültü kaynakları bellidir: banka ekstresi genellikle büyük harfe çevirir ve Türkçe karakterleri düşürür, unvan ekleri farklı yazılır (LTD ŞTİ, LTD.ŞTİ., LIMITED SIRKETI), ve alan uzunluğu sınırlı olduğu için unvan kırpılır.

<?php
// Unvan normalizasyonu. Benzerlik hesabindan ONCE calisir.
// Bu adim atlanirsa hangi metrigi kullandiginizin onemi kalmaz.

function unvanNormalize(string $ham): string
{
    $s = mb_strtoupper($ham, 'UTF-8');
    $s = strtr($s, ['Ç'=>'C','Ğ'=>'G','İ'=>'I','Ö'=>'O','Ş'=>'S','Ü'=>'U','I'=>'I']);
    $s = preg_replace('/[^A-Z0-9 ]+/', ' ', $s);

    $gurultu = ['LTD','STI','SIRKETI','LIMITED','ANONIM','AS','A S','SAN','TIC',
                'SANAYI','TICARET','VE','INSAAT','HOLDING'];
    $parcalar = array_diff(preg_split('/\s+/', trim($s)), $gurultu);

    sort($parcalar);                      // kelime sirasi onemli degil
    return implode(' ', $parcalar);
}

// "ORNEK GIDA SAN. VE TİC. LTD. ŞTİ."  => "GIDA ORNEK"
// "ÖRNEK GIDA SANAYİ TİCARET LİMİTED"  => "GIDA ORNEK"   (ayni)

Normalizasyondan sonra jeton kümesi karşılaştırması (ortak kelime oranı) çoğu durumda karakter mesafesi metriklerinden daha iyi sonuç verir, çünkü asıl sorun harf hatası değil kelime eksikliğidir. Hangi metriği seçerseniz seçin kural aynı: bulanık benzerlik tek başına eşleştirme yapmaz. Tutar ve tarih zaten tutuyorsa unvan benzerliği bir adayı öne çıkarır; tutar tutmuyorsa unvanın yüzde doksan benzemesi bir anlam taşımaz.

Bu Şurada Kırılıyor

Ters kayıtlar. İade edilen bir havale ekstrede RvslInd=true ya da MT940'ta RD işaretiyle döner. Bunu ayırmayan sistem, iade edilen tahsilatı ikinci kez cariye yazar ve müşteri iki kat ödemiş görünür. Bu hata genellikle ay sonunda, mizan tutmadığında fark edilir.

Aynı tutarın tekrarı. Abonelik iş modellerinde onlarca müşteri aynı gün aynı tutarı gönderir. K3 kademesi burada hiç çalışmaz ve çalışmamalıdır; "tek aday" koşulunu gevşetme isteğine direnin. Bu modelde çözüm algoritma değil, K1 veya K2'yi devreye almaktır.

Toplu ödeme tek satır olarak gelir. Maaş ya da tedarikçi toplu ödemelerinde banka tek bir borç kaydı gösterir; kalem dökümü ekstrede yoktur. Dökümü gönderdiğiniz ödeme dosyasından alın ve banka hareketiyle o dosya arasında bağ kurun. Ekstreden çözmeye çalışmayın.

Açıklama kırpılır. MT940'ta hesap sahibi referansı 16 karakterle sınırlıdır ve fazlası bir sonraki alt alana taşar; :86: ise en fazla 6 satır, satır başına 65 karakterdir. 24 karakterlik bir referans kodu tasarlayıp "açıklamaya yazsınlar" demek çalışmaz. RF referansınızı kısa tutun.

Ekstre iki kez işlenir. Aynı gün iki kez indirilebilir, bir dosya yeniden gönderilebilir. AcctSvcrRef varsa tekilleştirme anahtarı odur; yoksa deterministik parmak izi üretin ve updateOrCreate ile yazın.

Ham satır saklanmaz. Ayrıştırıcınızda altı ay sonra bir hata bulacaksınız. Ham :61:/:86: satırını veya ham <Ntry> düğümünü saklamadıysanız geçmişi yeniden işleyemezsiniz. Bu, mutabakat projelerinde geri dönülemez tek hatadır.

Neyi Ölçmelisiniz?

Yaygın metrik "otomatik eşleşme oranı"dır ve yanıltıcıdır, çünkü eşiği gevşeterek yükseltilebilir. Panonuzda şu dördü olmalı:

• Yanlış eşleşme sayısı (operatörün geri aldığı otomatik eşleşmeler). Hedef sıfırdır ve bu tek rakam sistemin gerçek kalitesidir.
• Kademe dağılımı. Eşleşmelerin kaçı K1, kaçı K3 kaynaklı? K3 payı yükseliyorsa referans taşıma sisteminiz bozuluyor demektir.
• Bekleyen hareketin yaşı. Kaç gündür eşleşmemiş hareket var? Ortalama değil, en eskisi.
• Operatöre düşen günlük iş sayısı. Otomasyonun iş yükünü gerçekten azaltıp azaltmadığını yalnızca bu gösterir.

Hedef sayıları kendi tabanınızdan çıkarın. Sistemi açtığınız ilk ayın rakamları referans noktanızdır; sektör ortalaması diye dolaşan oranlar farklı iş modellerinden gelir ve sizin için anlamı yoktur.

Efor Bandı

ininia'da yazılım geliştirme 300-400 USD/adam-gün bandında, adam-gün dökümüyle fiyatlanır. Mutabakat otomasyonu teklifinde şu kalemlerin ayrı görünmesini isteyin:

• Ekstre alımı ve banka başına ayrıştırıcı (bu kalem banka sayısıyla çarpılır)
• Tekilleştirme, ham veri saklama ve yeniden işleme aracı
• Eşleştirme kural motoru ve kademe yapısı
• Manuel eşleştirme arayüzü ve geri alma akışı (en çok hafife alınan kalem)
• Kısmi/toplu ödeme tahsis mantığı ve muhasebe politikası uygulaması
• Referans taşıma tarafı: RF kodu üretimi, fatura üzerine karekod basımı
• ERP/muhasebe tarafına yazma ve günlük mutabakat raporu

Kendi kapsamınız için aralık görmek isterseniz proje fiyat hesaplama aracımızı kullanabilirsiniz.

Sıkça Sorulan Sorular

Eşleştirmeye yapay zekâ koysak olmaz mı?

Bulanık kademede sıralama modeli olarak işe yarar, otomatik karar verici olarak yaramaz. Sebep teknik değil operasyonel: yanlış eşleşme geri alınması pahalı bir işlemdir ve modelin neden o kararı verdiğini muhasebeye açıklayamazsınız. Modeli K4'te öneri sıralayıcı yapın, K1'in yerine koymayın.

camt.053'e geçmeli miyim, MT940 yeter mi?

Bankanız camt.053 veriyorsa geçin, çünkü yapılandırılmış referans alanları (EndToEndId, CdtrRefInf/Ref) eşleştirme hattınızın K1 kademesini doğrudan besler. MT940'ta aynı bilgi serbest metnin içindedir ve banka başına ayrıştırıcı gerektirir. Geçiş yapamıyorsanız iç veri modelinizi yine de camt.053 kavramlarına göre kurun.

Referans kodunu müşteri yanlış yazarsa ne olur?

RF biçimi kullanıyorsanız kontrol hanesi tutmaz ve kod geçersiz sayılır; hareket K1'de eşleşmez, sonraki kademelere düşer. Kontrol hanesi olmayan bir kod kullanıyorsanız yanlış kod başka bir faturayla eşleşebilir. Aradaki fark budur ve bu yüzden RF kullanın.

Valör mü, muhasebe tarihi mi?

Eşleştirme penceresini valör (ValDt) üzerinden kurun, çünkü paranın kullanılabilir olduğu tarih odur. Muhasebeleştirmede ise BookgDt esas alınır. İkisini karıştıran sistemler ay sonu kapanışında bir günlük kaymalar üretir.

Her banka için ayrı kural seti mi yazmalıyım?

Ayrıştırıcı evet, eşleştirme hattı hayır. Ayrıştırıcı bankaya özgüdür ve ham ekstreyi ortak bir hareket modeline çevirir; eşleştirme hattı bu ortak modelin üzerinde tek bir yerde çalışır. Hattı banka bazında çoğaltmaya başladıysanız ortak modeliniz eksik demektir.

Kaç günlük tarih penceresi kullanmalıyım?

Sabit bir sayı vermek yanlış olur; pencere sizin tahsilat vadenize ve müşteri davranışınıza bağlıdır. Doğru yöntem: geçmiş altı ayın eşleşmiş kayıtlarında fatura tarihi ile ödeme tarihi arasındaki farkın dağılımını çıkarın ve pencereyi bu dağılımın üst dilimine göre belirleyin. Pencereyi geniş tutmak eşleşme oranını değil, aday sayısını artırır.

Bir Sonraki Adım

Bugün yapılacak iş algoritma yazmak değil: son üç ayın banka hareketlerini alın ve kaçında EndToEndId ya da yapılandırılmış bir referans dolu olduğunu sayın. Bu oran düşükse yazacağınız en iyi algoritma bile K3 ve K4'te boğulur; önce referans taşıma tarafını (fatura üzerine RF kodu, karekod, tahsis edilmiş hesap) çözmek gerekir. Oran yüksekse zaten işin kolay tarafındasınız ve bir haftalık bir K1 kademesi tahsilatlarınızın büyük kısmını kapatır.

Banka tarafındaki bağlantı katmanı için banka entegrasyonu rehberimize, muhasebe tarafındaki bağlantı için ERP entegrasyonları sayfamıza bakabilirsiniz. Finans tarafındaki kapsamımızı finans & fintech sayfasında görebilir, kendi projeniz için iletişim sayfasından yazabilirsiniz.

Kaynaklar: camt.053.001.02 Bank to Customer Statement Implementation Guidelines v2.1 (08.08.2023) alan tanımları; Danske Bank "Customer Statement MT940 with Structured Information To Account Owner" biçim dokümanı (:61: alt alanları ve işlem tipi kodları); TCMB "FAST – TR Karekod Teknik İlke ve Kuralları Rehberi" Sürüm 1.5, Ocak 2025 (alan kodları ve FAST A01 eşlemeleri); ISO 11649 RF Creditor Reference, ISO/IEC 7064 MOD 97-10; ISO 20022 Bank Transaction Code harici kod listesi. Tamamı 25 Eylül 2026'da okunmuştur.