Üçlü eşleştirme otomasyonu: AP için tablolar ve iş akışı ile ödeme tutmaları

Üçlü eşleştirmenin gerçekte çözdüğü problem nedir

Üçlü eşleştirme otomasyonu basit: bir faturayı yalnızca sipariş ettiğinizle ve gerçekten aldığınızla eşleştiğinde ödersiniz. Üç belge satın alma emri (PO), teslimat kaydı (receipt) ve tedarikçi faturasıdır.

Bu kontrol olmadan, hesaplar ödemeyi hatalı veya eksik bir tek belgeye dayanarak yapabilir. Bir tedarikçi teslim edilenden daha fazla birim faturalandırabilir, anlaşılan fiyattan farklı bir fiyat kullanabilir veya bir e-posta dizisinde yeni gibi görünen yinelenen bir fatura gönderebilir.

Bu hatalar genellikle ilk gün dramatik görünmez. Küçük kaçaklar olarak ortaya çıkar: bir satır öğesinin iki kez faturalandırılması, gönderinin birkaç birim eksik olması, onaylanmamış bir fiyat artışı veya gereksiz yere eklenen navlun. Zamanla bu küçük hatalar gerçek bir paraya dönüşür.

Amaç “faturaları onaylamak” değil. Amaç, seçtiğiniz ana alanlar (genellikle miktar, birim fiyat ve toplamlar) PO, receipt ve faturada hizalanana kadar ödemeyi engellemektir. Eşleşmezlerse, fatura e-postaya kaybolmamalı. Net bir neden kodu ve farklı olan tam alanlarla birlikte bir istisna kuyruğuna gitmelidir.

Üçlü eşleştirme ayrıca ekipler arasında net bir çizgi çizer. Procurement (satınalma) ne sipariş edildiğinden (şartlar ve fiyat) sorumludur. Receiving (teslim kabulu) ne geldiğini onaylar (miktarlar ve tarihler). Finance/AP hangi ödemelerin yapılacağını kontrol eder (fatura inceleme ve serbest bırakma).

Erken beklentileri ayarlayın: bu bir süreç ve veri problemidir, onay butonuyla ilgili bir sihir değil. PO satırları belirsizse, receipt'ler kaydedilmiyorsa veya faturalar bir PO satırına bağlanamıyorsa, otomasyon sizi kurtarmaz.

Belgeler ve roller: PO, receipt, fatura ve kimin neyi sahiplenmesi gerektiği

Üçlü eşleştirme yalnızca her belgenin net bir sahibi olduğunda işe yarar. "Kimin neyi güncellediği" bulanıksa, sistem ya iyi ödemeleri engeller ya da kötü ödemeleri geçirir.

Pratik bir sahiplik modeli şöyledir:

• Talep eden (Requester) satın alma talebini oluşturur ve ihtiyacı doğrular.
• Procurement PO'yu oluşturur ve yönetir (tedarikçi, fiyat, şartlar).
• Depo/alıcı (veya hizmet sahibi) receipt veya kabulü gönderir.
• AP/Finance faturayı kaydeder ve ödemeyi kontrol eder.

Her belgenin ayrıca eşleşmenin tahmin yürütme olmaması için asgari alan setine ihtiyacı vardır.

PO (purchase order) için tedarikçi kimliği, PO numarası, satır öğeleri (SKU veya hizmet), sipariş edilen miktar, birim fiyat, para birimi, vergi kuralları ve ödeme şartları gerekir.

Receipt için bir PO referansı, receipt tarihi, PO satırına göre alınan miktarlar ve kim tarafından alındığı gerekir. Hizmetler için bunu kabul olarak ele alın ve onaylayanı kaydedin.

Fatura için tedarikçi fatura numarası, fatura tarihi, PO referansı (veya PO'yu güvenle bulma yolu), satır detayları (adet, birim fiyat), vergiler/navlun ve toplam gerekir.

Ayrıca eşleştirmenin ne zaman çalışacağını kararlaştırın. Bu tek seferlik bir olay olmamalı. Gerçeklik her değiştiğinde tetikleyin:

1. Bir fatura yakalandığında (ödeme/hold kararını hemen verebilmek için).
2. Bir receipt gönderildiğinde (beklemede olan fatura ödenebilir hale gelebilsin diye).
3. Bir PO değiştiğinde (açık faturalar yeniden kontrol edilsin diye).

Kısmi teslimatlar ve birden fazla fatura normaldir. Bir PO satırı üç teslimatta gelebilir ve iki faturaya bölünebilir. Mantığınız her seferinde tek belgeye bakmak yerine PO satırı başına kümülatif olarak alınan vs faturalandırılanı karşılaştırmalı.

Bir şey inşa etmeden önce karar vermeniz gereken kurallar

Tablolar veya iş akışı adımlarına dokunmadan önce, tüm sistemi yönetecek kurallar üzerinde anlaşın. Belirsiz kurallar öngörülebilir başarısızlık yaratır: ya sistem çok fazla engeller (insanlar atlatarak geçer), ya da çok az engeller (kötü faturalar yine de ödenir).

Eşleştirme seviyesini seçin. Sadece üst bilgi (header) eşleştirme belgeler düzeyinde toplamları kontrol eder. Kolay gibi görünse de, kısmi teslimatlar, bekleyen siparişler, navlun satırları veya karışık vergi oranları ile hızla kırılır. Satır düzeyinde eşleştirme kurulumu daha uzun sürer ama daha güvenlidir çünkü PO, receipt ve faturadaki aynı şeyi karşılaştırırsınız: belirli satırı, miktarını ve birim fiyatını.

Sert engeller ile uyarıları tanımlayın. Sert engel, sorun çözülene kadar ödemenin devam edemeyeceği anlamına gelir. Uyarı ise faturanın ilerleyebileceği ama birinin riski kabul etmesi gerektiği anlamına gelir.

Tipik başlangıç noktaları:

• Sert engel: faturalandırılan miktar alınan miktarı aşıyor (mal için).
• Sert engel: birim fiyat, PO fiyatını toleransın ötesinde aşıyor.
• Uyarı: küçük yuvarlama farkları.
• Uyarı: beklenen ve ayrı kodlanan vergi veya navlun farkları.

Tolerans kurallarını açık tutun. Yöntemi (yüzde, mutlak tutar veya ikisinin yüksek olanı) ve kimin sahip olduğunu tanımlayın. Örnek: satır başına +/- %1 veya +/- 5$ izin verin; toleransları yalnızca finance değiştirebilsin ve her değişiklik denetim notu ile olsun.

Küçük, paylaşılan bir durum seti kullanın. Her ekip için özel durumlardan kaçının. Temiz bir set genellikle yeterlidir: Matched, Hold, Exception, Approved. “Hold” ödeme engellendiğini, “Exception” insan incelemesi gerektiğini, “Approved” ise adlandırılmış bir kişinin uyumsuzluğu kabul edip nedenini kaydettiğini ifade eder.

Veri modeli: gerekli tablolar (ve nedenleri)

Üçlü eşleştirme otomasyonu yalnızca veri modeliniz bir PO satırını, ne alındığını ve ne faturalandığını eşleştirebiliyorsa çalışır. Her fatura satırı belirli bir PO satırına eşlenebilir olmalı (veya açıkça non-PO olarak işaretlenmeli) ve her receipt satırı o PO satırındaki kalan miktarı azaltmalıdır.

Temel satınalma tablolarıyla başlayın:

• Vendors: her tedarikçi için bir satır (isim, şartlar, vergi bilgileri).
• ItemsServices: isteğe bağlı, ama tutarlılık sağlar (SKU, açıklama, ölçü birimi).
• PurchaseOrders: PO başlığı (vendor_id, currency, requested_by, status).
• PO_Lines: eşleştirmenin merkezi (po_id, item_id/description, ordered_qty, unit_price).

Receiving'in kendi kayıtlarına ihtiyacı var, hatta bir “receipt” sadece bir onay olsa bile. Receipt'leri faturalarla ayrı tutun ki ne geldiğini ve ne zaman geldiğini ispatlayabilesiniz:

• Receipts: receipt başlığı (vendor_id, received_date, location, status).
• Receipt_Lines: her satır PO satırına referans verir (receipt_id, po_line_id, received_qty, notes).

Faturalama receiving'i yansıtır. Tedarikçinin ne faturalandırdığını satır düzeyinde saklayın ve bunu kapsaması gereken PO satırıyla bağlayın:

• Invoices: fatura başlığı (vendor_id, invoice_number, invoice_date, due_date, status).
• Invoice_Lines: (invoice_id, po_line_id when applicable, invoiced_qty, unit_price, tax, line_total).

Son olarak, iş akışınızın engelleyebileceği ödeme odaklı bir kayıt oluşturun. Bazı ekipler buna bill, payment request veya pay run item der:

• PaymentRequests (veya Bills): invoice_id ile bağlanır ve payment_hold (true/false) ile hold_reason içerir.

Denetimler ve temiz istisna ele almak için başlıklara (PO'lar, receipts, faturalar, ödemeler) tutarlı yaşam döngüsü alanları ekleyin: status, created_at/created_by, approved_at/approved_by, posted_at ve (isteğe bağlı) importlar için source_document_id.

Eşleştirmeyi güvenilir kılan ana alanlar ve ilişkiler

Eşleştirme, her belgenin aynı satır öğesine izlenebilmesiyle en iyi çalışır. Bu, stabil kimlikler, temiz bağlantılar ve satırlardan yeniden hesaplanabilen toplamlar anlamına gelir.

Her tablonun hem stabil bir iç ID'si hem de insanların aradığı dış numarayı taşıdığından emin olun:

• PO başlık: po_id, po_number, vendor_id, currency, status, po_date
• PO satırları: po_line_id, po_id, item_id veya description, ordered_qty, unit_price, tax_rate, line_total
• Receipts: receipt_id, receipt_number, vendor_id, received_date; receipt_line_id, receipt_id, po_line_id, received_qty
• Faturalar: invoice_id, vendor_id, vendor_invoice_number, invoice_date, currency, subtotal, tax_total, total; invoice_line_id, invoice_id, po_line_id, qty, unit_price, tax_amount, line_total
• Vendors ve items: vendor_id, payment_terms, default_currency; item_id, uom, tax_code

En önemli bağlantılar satır düzeyindedir:

• invoice_line.po_line_id PO satırına işaret etmelidir.
• receipt_line.po_line_id aynı PO satırına işaret etmelidir.

Bu, miktarı ve fiyatı tahmin yürütmeden karşılaştırmanıza izin verir.

Kısmi işlemleri idare etmek için PO satırı başına çalışan toplamlar hesaplayın: received_qty (receipt satırlarının toplamı) ve invoiced_qty (fatura satırlarının toplamı). Sonra remaining_qty = ordered_qty - received_qty ve open_to_invoice_qty = received_qty - invoiced_qty hesaplayın. Bu değerler bir faturanın erken, gecikmiş veya fazla faturalandırma olup olmadığını açıkça gösterir.

Bir PO değiştiğinde geçmişi üzerine yazmayın. Bir PO revizyon numarası saklayın ve ya eski PO satırlarını (active flag ile) tutun ya da kim neyi ne zaman değiştirdiğini gösteren bir değişiklik günlüğü tutun.

Çakışmaları ve yanlış joinleri önlemek için temel korumalar ekleyin:

• Unique (vendor_id, vendor_invoice_number)
• Unique receipt_number ve po_number
• currency, quantities ve unit_price için NOT NULL
• qty >= 0 ve unit_price >= 0 gibi check constraint'ler
• invoice_line ve receipt_line için po_line'a foreign key'ler

Adım adım iş akışı: fatura kabulünden ödeme tutmaya kadar

Üçlü eşleştirme otomasyonu genellikle üç giriş noktasına sahiptir: bir fatura gelir (e-posta, yükleme, EDI), bir receipt gönderilir veya bir PO değişir (fiyat, miktar, durum). İş akışı bunların herhangi birine tepki vermeli ki eksik parça geldikçe fatura hold'dan çıkabilsin.

1) Önce fatura temellerini doğrulayın. Tedarikçinin aktif olduğunu, PO'nun var olduğunu, para biriminin PO ile eşleştiğini ve toplamların dahili olarak tutarlı olduğunu (satır toplamları toplandığında doğru sonuç veriyor, vergi makul, negatif miktarlar yoksa kredi destekleniyorsa izin verilir) onaylayın. Bunlar başarısız olursa, faturayı doğrudan Hold'a gönderin ve net bir neden belirtin.

2) Satır bazında eşleştirin, sadece üst bilgiye bakmayın. Her fatura satırı için ilgili PO satırını ve bugüne kadar olan receipt toplamlarını bulun. Karşılaştırın:

• Faturalandırılan miktar vs alınan miktar (ya da daha önce faturalandırılmış olanlar düşüldükten sonra alınan)
• Faturadaki birim fiyat vs PO'daki birim fiyat
• Tolerans kuralları
• PO satırının halen faturalamaya açık olup olmadığı

3) Durumu ayarlayın ve engellemeyi uygulayın. Yaygın bir desen:

• Matched: tüm satırlar kontrolleri geçiriyor, açık istisna yok.
• Hold: en az bir satır başarısız veya gerekli veri eksik.

Hold ayarlandığında, ödeme çalışmasının uyması gereken bir payment hold kaydı oluşturun. Hold'ları faturadan ayrı tutun ki hold'lar eklenip, serbest bırakılıp veya değiştirilebilsin; fatura geçmişi yeniden yazılmasın.

4) Finance'in güvenebileceği neden kodlarını kaydedin. Sadece serbest metin hold'larından kaçının. PRICE_OVER_TOLERANCE, QTY_NOT_RECEIVED, PO_CLOSED, VENDOR_MISMATCH veya CURRENCY_MISMATCH gibi kodlar ve kısa bir not kullanın.

Finans için istisna kuyruğu tasarımı (ne saklanmalı, ne gösterilmeli)

İstisna kuyruğu eşleştirmeyi kullanılabilir kılan yerdir, sadece katı kurallar değil. Finance yalnızca karar gerektiren faturaları ve hızlı karar vermek için yeterli bağlamı görmelidir; ayrıca temiz bir denetim izi bırakılmalıdır.

Yaygın bir yaklaşım, ExceptionCases gibi özel bir tablo kullanmaktır. Her satır bir bloke edilmiş faturayı (veya fatura satırını) temsil eder ve fatura, PO ve receipt kayıtlarına referans verir. Eşleştirme motorunu burada salt-okunur tutun. Kuyruk kararlar ve belgelemek içindir.

ExceptionCases içinde ne saklanmalı

Neyin yanlış olduğunu, ne kadar büyük olduğunu, kimin sahip olduğunu ve sonraki adımın ne olacağını saklayın:

• Tür (missing receipt, price variance, quantity variance, PO not found, duplicate invoice)
• Şiddet (info, warning, block) ve kullanıcı dostu bir neden
• Sahip (kişi veya ekip) ve durum (open, waiting on vendor, waiting on warehouse, resolved, overridden)
• Sıralanabilir sayılar olarak varyans anlık görüntüsü (fatura tutarı, eşleşen tutar, fiyat farkı, miktar farkı)
• SLA alanları (due date, escalation flag, reassigned_at, reassignment_reason)

Ayrıca işbirliği ve denetim verilerini saklayın: yorumlar (yazar, zaman damgası) ve ek dosya meta verileri (dosya adı, tür, uploaded_by, uploaded_at). Dosyalar başka yerde olsa bile meta verileri vakanın içinde tutulmalı ki geçmiş korunmuş olsun.

Finance'in ne görmesi ve yapması gerek

Kuyruk görünümü sıkı bir iş listesi olmalı: vendor, fatura numarası, istisna türü, şiddet, tutar, vade tarihi, sahip ve net bir "neden bloklandı" mesajı.

Bir vaka açıldığında yan yana bir özet gösterin: PO satırları, alınan miktarlar, fatura satırları ve başarısız olan tam alanlar.

Eylemleri sınırlı ve güvenli tutun:

• Receipt isteği (receiving'e yönlendirir, durumu waiting yapar)
• Credit memo isteği (tedarikçiye yönlendirir, beklenen düzeltmeyi kaydeder)
• Onayla (override) (neden gerektirir, onaylayan ve zaman damgasını alır)
• Yeniden atama (sahibi günceller, yeniden atama geçmişini tutar)
• Çözüldü olarak kapatma (eşleşme başarılı olduktan sonra)

Örnek: bir fatura 8 adet alındığı hâlde 10 adet faturalandığı için bloke edilsin. Finance düzeltecek en hızlı kişiye bildirim göndermeli: genellikle alım yapan veya alıcı. Finance, eksik 2 birim için düzeltilmiş bir fatura talep edebilir veya 8 alınan birim için onaylayıp kalan 2'yi beklemeye alabilir.

Gerçekçi örnek: kısmi teslimat ve uyumsuz fatura

Bir alıcı 100 adet A maddesi için bir PO oluşturur; birim fiyat $10.00. PO toplamı $1,000.

İki gün sonra depo 80 adet için bir receipt gönderir.

Sonra 100 adet için $10.00 olan bir fatura gelir. Eşleştirme faturayı siparişle değil, alınanla karşılaştırmalıdır.

O satır için:

• Sipariş edilen: 100 adet
• Alınan: 80 adet
• Faturalandırılan: 100 adet
• Eşleşen miktar: min(Alınan, Faturalandırılan) = 80 adet
• Eşleşmeyen miktar: Faturalandırılan - Eşleşen = 20 adet

Fatura 20 birimi için receipt olmadığı için "On hold" olur. Finance, net bir neden (Quantity variance: +20) ve yan yana ana sayılarla bir vaka görür.

Bildirimler genellikle sorunu en hızlı çözecek kişilere gider: genellikle receiver (receipt eksikse) ve buyer (gönderi eksikse takip etmesi için).

Kalan 20 birim geldiğinde depo ikinci bir receipt gönderir. Sistem yeniden eşleştirmeyi çalıştırır: received 100 olur, eşleşmeyen 0 olur, fatura Matched olur ve hold serbest bırakılır.

Fiyatta bir uyumsuzluk ekleyin. Tedarikçi 100 birimi $10.50 olarak faturalandırırsa miktar eşleşir ama fiyat uymaz. Beklenen sonuç: fatura hold'da kalır ve "Price variance: +$0.50/unit (+$50 total)" gibi bir nedenla yönlendirilir.

Üçlü eşleştirme iş akışını bozan yaygın hatalar

Çoğu eşleştirme hatası matematikten değil. Zayıf veri bağlantıları ve gönderilmiş belgeler üzerinde gevşek kontroller yüzünden olur.

Sadece fatura toplamında eşleştirme yapmak. Bir üst bilgi doğru görünebilir ama bir satır pahalı veya eksik olabilir. Satır düzeyinde eşleştirme yapın ve hangi öğelerin farklı olabileceğini (genellikle navlun) ve hangi öğelerin olamayacağını (alınan miktar ve birim fiyat) açıkça belirtin.

Bir receipt ve bir fatura varsaymak. Gerçek satınalma, bölünmüş gönderiler ve kısmi faturalama içerir. Aynı PO satırına karşı çok sayıda receipt ve fatura destekleyin ve satır başına kalan açık miktarı takip edin.

Gönderilmiş receipt veya faturaların iz bırakmadan düzenlenmesine izin vermek. Birisi miktarları sessizce değiştirebiliyorsa, eşleştirme kanıt olmaktan çıkar. Gönderilmiş kayıtları kilitleyin ve düzeltmeleri geçmişi koruyacak ayarlama belgeleriyle yapın.

Yinelenenleri önlemeyi atlamak. Aynı tedarikçi fatura numarası iki kez girilebilir veya bir PDF başka biri tarafından tekrar yüklenebilir. Erken aşamada benzersizliği ekleyin (vendor + invoice number ve isteğe bağlı olarak tarih/tutar) ve yinelenen tespit edildiğinde net bir mesaj gösterin.

Belirsiz istisna nedenleri. Finance tahminde bulunmamalı. Fiyat uyumsuzluğu, miktar uyumsuzluğu, eksik receipt, şüpheli yinelenen, PO bulunamadı, tedarikçi uyuşmazlığı gibi kodlar kullanın.

Ödeme engellemeyi açmadan önce hızlı kontrol listesi

Ödeme engelleme eşleştirmenin bir rapor olmaktan kontrol haline gelmesidir. Temeller sağlam değilse, finance için gürültü ve tedarikçiler için gecikmiş ödemeler yaratırsınız.

Farklı görünen küçük bir fatura setiyle test edin: temiz eşleşme, kısmi receipt, fiyat değişikliği ve vergi farkı. Herhangi biri temiz eşleşemiyorsa önce veriyi ve kuralları düzeltin.

Kontrol listesi:

• Referans tamlığı: her faturanın bir vendor ve PO referansı var ve her fatura satırı belirli bir PO satırına eşlenebiliyor (sadece "PO toplamı" değil). Bir tedarikçi yalnızca bir PO başlığı gönderdiğinde ne olacağına karar verin.
• Tutarlı matematik: miktarlar, birim fiyatlar ve toplamlar her seferinde aynı şekilde yeniden hesaplanabiliyor. Vergi, navlun, indirim ve yuvarlama konusunda açık olun (örneğin satır bazında yuvarlama vs sadece fatura toplamında).
• Durumlar yeterince erken engellemeli: ödeme talebi veya ödeme kaydı oluşturulmadan önce "on hold" ayarlayın.
• Yapısal istisnalar: her hold bir neden kodu ve bir sahibi saklar (AP, buyer, receiver). Hold'ların süresinin dolmaması için vade tarihler ekleyin.
• Gerçek denetim izi: override'lar kim onayladı, ne zaman ve neyi onayladığını kaydeder. Eğer düzenlemelere izin veriyorsanız, önceki ve sonraki değerleri kaydedin.

Sonraki adımlar: süreci pilotlayın ve görsel olarak inşa edin

Üçlü eşleştirme otomasyonunu herhangi bir kontrol gibi ele alın: küçük bir harcama diliminde çalıştığını kanıtlayın, sonra genişletin.

Takip etmesi kolay bir pilotla başlayın. Bir iş birimi, temiz fatura gönderen küçük bir tedarikçi grubu veya tek bir ürün kategorisi seçin. Başlangıçta kuralları katı tutun (tam miktar ve fiyat eşleşmesi) ki veri kalitesi sorunları hızla ortaya çıksın.

Başarıyı basit bir finance görünümü ile ölçün: haftalık hold sayısı, en sık neden kodları, hold'tan serbest bırakmaya geçen süre, gerçek uyumsuzluk olan hold sayısı ve hangi tedarikçilerin tekrar eden istisna yarattığı.

Hızlı prototip isterseniz, kodsuz (no-code) bir platform işinizi görebilir çünkü tabloları, eşleştirme kurallarını ve yönlendirmeyi kod yazmadan modelleyebilirsiniz. Örneğin AppMaster (appmaster.io) içinde PO, receipt, invoice ve exception tablolarını kurup, hold mantığını görsel iş süreci ile bağlayabilirsiniz; böylece aynı kurallar her tetiklemede çalışır.

Pilot grubundan gerçek faturalarla test edin; kısmi receipt'ler ve yaygın tedarikçi hatalarını dahil edin. Kalıpları gördükten sonra eşleştirme anahtarlarını ince ayar yapmaya ve küçük toleranslar eklemeye hazırlıklı olun. Hold'lar makul görünüp çözüm süreleri iyileştiğinde, kapsamı genişletin ve daha zengin kurallar ekleyin (vergi ve navlun işleme, birim dönüşümleri, bölünmüş sevkiyatlar) ama temel kontrolü kaybetmeyin: eşleşme temizlenmeden ödeme serbest bırakılmasın.