Sipariş kaydı: Her tahsilat hangi ticari yükümlülüğe bağlanacak?
ERP’de başlangıç noktası ödeme adresi değil, onaylanmış ihracat siparişidir. Satış birimi sipariş numarasını, alıcı tüzel kişiyi, mal kalemlerini, teslim şeklini, fiyat para birimini ve ödeme koşulunu kaydeder. Siparişin sürümü de önemlidir: müşteri miktarı değiştirdiğinde ilk proformayı silip üzerine yazmak yerine değişikliğin hangi tarihte kabul edildiği korunmalıdır. Böylece daha sonra gelen ödeme eski teklife mi güncel siparişe mi ait, anlaşılabilir. Proforma fatura ile sipariş kaydını eşleştirme konusu özellikle revizyonlu satışlarda ayrı bir kontrol gerektirir.
Siparişe bağlı ticari faturada fatura numarası, düzenleme tarihi, tahsil edilecek bakiye ve kabul edilen fiyat para birimi ayrı alanlarda tutulur. Ödeme kripto varlıkla yapılacaksa fatura tutarını doğrudan varlık adedi olarak yeniden yazmayın. Fatura para birimi ile tahsilat varlığı farklı kavramlardır; aradaki çevrim yöntemi, teklifin geçerlilik süresi ve komisyon yükü sözleşmede kararlaştırılmalı, ERP’de ilgili siparişe iliştirilmelidir. Fatura oluşturma aracı ödeme talebini iletebilir; ancak ERP’deki ticari faturanın ve alacak kaydının yerine geçtiği varsayılmamalıdır.
İlk tasarım kararı ortak bir işlem anahtarı seçmektir. Sipariş kimliği, fatura kimliği ve ödeme talebi kimliği birbirinden farklı olabilir; bunları bir eşleştirme tablosunda ilişkilendirin. İşlem bağlantısını yalnızca müşterinin e-posta adresine veya gönderici adresine dayandırmayın: aynı alıcı farklı faturaları ödeyebilir, üçüncü taraf ödeme yapabilir, adresler değişebilir. Düzeltme gerekirse eski ilişkiyi görünmez biçimde değiştirmek yerine kimin hangi gerekçeyle değiştirdiğini kaydedin. Bu küçük karar, denetimde ödeme dekontundan sevkiyat dosyasına geri yürümeyi mümkün kılar.
Örneğin aynı alıcının iki parti mal için iki faturası varsa ve tek transfer gelmişse, “alıcı ödedi” kaydı iki alacağı otomatik kapatmaz. Finans ekibi tahsisin hangi tutarlarla hangi faturalara yapılacağını onaylar; onay ve kalan bakiye ERP’de saklanır. Belirsizlik giderilene kadar işlem eşleştirme bekleyen tahsilat olarak görünür. Böyle bir ara durum, yanlış faturanın kapatılıp sonraki sevkiyatın hatalı serbest bırakılmasını önler.
Ödeme talebinde varlık, ağ ve kur bilgisi neden ayrı alanlar olmalı?
“USDT ile ödenecek” tek başına yeterli bir talimat değildir. Aynı varlık farklı ağlarda bulunabilir; yanlış ağ seçimi tahsilatın beklenen kayda düşmemesine neden olabilir. Talep oluşturulurken varlık kodu, ağ adı, beklenen varlık tutarı, fatura referansı, talebin son geçerlilik zamanı ve ödeme sağlayıcısının talep kimliği ayrı alanlarda saklanmalıdır. Alıcıya gönderilen talimatın sürümünü de koruyun. Finans ekibi daha sonra hangi adresin ve hangi ağın müşteriye gerçekten bildirildiğini bu kayıttan doğrular.
ERP için en az iki tutar görünümü gerekir: müşterinin ticari borcunun fatura para birimindeki tutarı ve tahsilatın gerçekleştiği varlığın miktarı. Kullanılan kurun kaynağı, zaman damgası ve hangi amaçla kullanıldığı açık olmalıdır. Teklif kuru, ödeme anındaki operasyonel karşılık ve muhasebe kaydındaki ölçüm aynı sayı olmak zorunda değildir. Bu fark, doğrudan gelir artışı ya da eksik ödeme olarak etiketlenmeden önce sözleşme koşulları ve şirketin muhasebe politikasıyla değerlendirilir. Dönüştürme ürününün varlığı, her tahsilatın otomatik olarak aynı anda nakde dönüştüğü anlamına gelmez.
Alıcıyla paylaşılan talep süresi dolarsa yeni talep oluşturun ve eskisinin durumunu kapatın; eski talep kimliğini silmeyin. Süresi geçen adrese yine de ödeme gelirse transferi yeni faturaya sessizce taşımak yerine istisna kuyruğuna alın. Aynı ağdaki benzer tutarlar birden çok açık faturaya denk düşebilir. Ağ ücreti ile sağlayıcı kesintisi de ayrı gösterilmelidir: müşterinin gönderdiği tutar, tahsil edildiği doğrulanan tutar ve işletmeye aktarılan net tutar farklı olabilir. Bu ayrım yapılmadığında bakiye farkı yanlışlıkla müşteriye borç yazılır.
Bir üretici, sevk öncesi avansla kalan tutarı iki ayrı vadede tahsil ediyorsa her taksit için ayrı ödeme talebi ve ortak sipariş bağı kurabilir. Avans için açılan talebi ikinci tahsilatın üzerine yazmak geçmişin izini siler. İhracatçıda ön ödeme düzeni siparişin üretim kararına nasıl bağlandığını anlatır; ERP tarafında ek ihtiyaç, her taksidin alacak hareketiyle bire bir veya açıkça belgelenmiş çoklu ilişkiyle eşleşmesidir.
Ödeme olaylarını tek bir “ödendi” durumuna indirmeyin
Bir transferin ağda görünmesi, yeterli onaya ulaşması, ödeme sağlayıcısı tarafından kabul edilmesi ve kullanılabilir bakiyeye geçmesi farklı olaylardır. ERP’ye bir olay günlüğü aktarın: ödeme talebi kimliği, işlem kimliği, varlık, ağ, bildirilen tutar, sağlayıcı olay kimliği, olay zamanı, ERP’ye geliş zamanı ve kaynak durum. Önceki olayı silmek yerine yeni durum satırı eklemek, geç gelen bildirimleri ve hata incelemesini kolaylaştırır. API bağlantısı ile veri aktarımı planlanırken ERP alanlarının sağlayıcı alanlarına eşlemesi işletmenin kendi uygulama tasarımı olarak belgelenmelidir.
Olayların geliş sırası her zaman ticari karar sırası değildir. Ağ bildirimi ERP’ye geç düşebilir; aynı olay yeniden iletilebilir. Bu nedenle aynı sağlayıcı olay kimliğinin ikinci kez alacak kapatmaması gerekir. İşlem kimliği de tek başına evrensel bir anahtar değildir: ağ ve varlık bilgisiyle birlikte tutulmalıdır. Kaydı oluşturan sistemle kayıt zamanı ayrıca saklanırsa “transfer ne zaman görüldü?” ve “muhasebe ne zaman işledi?” soruları karışmaz. Başarısız, iade edilmiş ya da eksik tutarlı ödemeler için doğrudan tamamlandı statüsüne geçişi engelleyen bir kontrol tanımlayın.
Burada en önemli operasyonel gözlem şudur: ödeme teyidi ile sevkiyat serbest bırakma kararı aynı alan olmamalıdır. Hangi teyit seviyesinin malın üretime veya nakliyeye çıkmasına yeterli sayılacağı ticari risk politikasıyla belirlenir. ERP, teyit seviyesini ve karar sahibini birlikte saklar. Yüksek değerli bir siparişte ödeme ağda izleniyor diye depodan ürün çıkması, sonradan mutabakatla düzeltilemeyecek bir operasyon hatasına dönüşebilir. Yetki ve onay akışı, ödeme olayından sonra kimin hangi kararı vermesi gerektiği açısından yararlı bir tamamlayıcıdır.
Örnek durum: alıcı aynı fatura için iki transfer gönderir; ilki eksik, ikincisi farkı kapatır. ERP iki işlem kimliğini aynı faturanın altında gösterir, toplam kabul edilen miktarı faturanın ödeme koşuluna göre değerlendirir ve fazla ödeme varsa ayrı yükümlülük oluşturur. İkinci transferi birincinin üstüne yazmak hem müşteri açıklamasını hem de olası iade kararının izini kaybettirir. Mutabakat kolaylığı, olay sayısını azaltmakla değil her olayın hangi alacak hareketine etkisi olduğunu korumakla sağlanır.
Sevkiyat belgesi ile alacak hareketi aynı iz üzerinde nasıl buluşur?
Ödeme geldiğinde sipariş tamamlanmış sayılmaz. Üretilen miktar ile sevk edilen miktar ayrılabilir; ticari faturadaki kalemler de kısmi sevkiyatla farklı tarihlerde teslim edilebilir. ERP’de sipariş, ticari fatura, sevkiyat kaydı ve ilgili teslim belgelerinin kimliklerini birbirine bağlayın. Belge dosyasının erişim yeri ile sürümü saklansın; yalnızca “yükleme yapıldı” notu denetlenebilir bir kanıt değildir. Vesaik mukabili ihracatta belge teslim sırası ödeme teyidinin belge akışına hangi noktada gireceğini düşünmek için somut bir örnektir.
Alacak alt hesabını ödeme ekranının durumu değil, sözleşmedeki koşul ve ilgili muhasebe politikası değiştirir. Fatura düzenlenmesi tek başına koşulsuz alacak doğduğu anlamına gelmez: alacak, müşteriden ödeme isteme hakkı ve ilgili edim geçerli politikaya göre tanındığında kaydedilir; avans niteliğindeki tutar ise ayrı izlenir. Kabul edilen tahsilat doğru alacağa tahsis edildiğinde uygun tutar kapanır. İhtilaflı, kimliği belirsiz veya koşul dışı ödeme bekleyen hesapta kalır. Kısmi sevkiyatın faturaya etkisi, iptal ve iade ihtimali ayrıca belgelenir. Muhasebe kayıt zamanı ile ağ işlem zamanını ayrı tutmak dönemsellik değerlendirmesini kolaylaştırır; hangi tarihin kayıt tarihi sayılacağı için şirket politikası ve ilgili muhasebe danışmanının görüşü gerekir.
Mal mukabili satışta sevkiyat tahsilattan önce gerçekleşebilir. Bu kez ağ olayları henüz yokken ERP’de vadesi gelen alacak ve sevkiyat kanıtı vardır. Mal mukabili ihracatta alacak yaşlandırması vadeyi takip ederken kullanılabilir; bu yazının ilave sorusu, tahsilat geldiğinde hangi sevkiyat ve hangi açık fatura satırının kapandığıdır. Her sevkiyatın tek faturaya, her faturanın tek transfere denk geleceği varsayımı büyüyen ihracat işinde hızla bozulur.
Karışıklığı azaltmak için satır düzeyinde bir ilişki tablosu kullanın: sipariş kalemi, sevk edilen miktar, fatura kalemi, ilgili alacak tutarı ve o alacağa tahsis edilen ödeme hareketi. Böylece müşteri “birinci parti için ödeme yaptım” dediğinde toplam sipariş bakiyesi değil, ilgili partiye düşen açık tutar gösterilebilir. Belgenin hazırlanması, müşteriye iletilmesi ve ödeme şartının gerçekleşmesi farklı tarihlerse her birini ayrı kaydedin. ERP veri zinciri bu ayrımları görünür kıldığı ölçüde işe yarar.
Tahsilat ile nakit kaydı arasındaki farkı nerede kapatmalı?
Kripto varlıkla ödeme kabul edilmesi ile işletmenin banka hesabında nakit görmesi aynı aşama değildir. ERP’de ağ üzerinde kabul edilen tutarı, ödeme sağlayıcısının hesap özetindeki hareketi, olası dönüştürmeyi ve banka hesabına ulaşan tutarı ayrı hareketler olarak izleyin. Her biri için referans kimliği, tarih, varlık veya para birimi, brüt ve net tutar ile kesinti türü bulunmalıdır. Bankaya aktarım yapılmayan bir tahsilatı “nakit bankada” diye sınıflandırmak likidite raporunu olduğundan güçlü gösterir.
Bir siparişin kârlılık hesabında komisyon, ağ maliyeti, dönüşüm farkı ve nakde erişim zamanı ayrı etkiler yaratabilir. Gerçek sipariş marjı hesabı satış sonrası maliyetleri görmeye yardımcı olur; burada ise amaç, bu maliyetleri hangi ödeme ve hangi sipariş satırıyla ilişkilendireceğinizi tanımlamaktır. Ödeme sağlayıcısının kesinti kaydı ile ERP’de gider kaydı aynı referansa bağlanmazsa finans ay sonunda farkı yalnızca toplamdan tahmin etmeye çalışır.
Pratikte bir ödeme iki ayrı günün raporuna düşebilir: ağda kabul tarihi bir gün, banka dekontu başka gün olabilir. Bunları yapay biçimde tek tarihe taşımak yerine ödeme aşamasına göre raporlayın. Tahsilatın kabulü, kullanılabilir bakiye, dönüştürme ve banka kaydı için ayrı zaman damgaları tutun. Böylece finans yöneticisi “alacak kapandı mı?”, hazine yöneticisi “bu para bugün kullanılabilir mi?” ve muhasebe “hangi dönemde hangi hareket kaydedildi?” sorularına aynı veri kaynağından farklı ama tutarlı yanıt alır.
Her işlemde banka çıkışı olmayabilir; varlık tutulabilir veya işletmenin onaylı süreçlerine göre başka bir ticari amaç için kullanılabilir. Bu durumda olmayan bir banka dekontu aramak yerine ilgili bakiyenin bulunduğu hesap ve sonraki hareketin referansı gösterilir. Uluslararası satış çözümüne bakarken de ürünün kapsamını işletmenizin mevcut muhasebe, banka ve onay süreçlerinden ayrı değerlendirin. Sağlayıcı raporu muhasebe politikanızı kendiliğinden belirlemez.
Ay sonu mutabakatında hangi fark kimin masasına düşer?
Ay kapanışında dört ayrı toplamı karşılaştırın: ERP’de faturaya tahsis edilen tahsilatlar, ödeme sağlayıcısının kabul edilen işlem dökümü, varlık veya dönüştürme hareketleri ve varsa banka girişleri. Bunların dönem sonu tutarlarının bire bir eşit olması her zaman beklenmez; her farkın nedeni ve sonraki akıbeti gösterilmelidir. Özellikle farklı tarihlerde kayda giren transfer, eksik ödeme, müşteri kaynaklı fazla ödeme ve henüz hesaba aktarılmamış bakiye için ayrı fark sınıfı kullanın. Karşılaştırmayı yalnızca toplam bazında yapmayın; önce işlem kimliği ve fatura bağı, sonra tutar üzerinden gidin.
Mutabakat tablosunda her açık farkın sahibi, keşif tarihi, ilgili fatura ve işlem kimlikleri, beklenen kanıt, çözüm tarihi ve alınan karar bulunur. Örneğin sağlayıcı raporunda görünen ama ERP’de bulunmayan transfer entegrasyon sorumlusuna; ERP’de kapanmış görünüp sağlayıcı teyidi olmayan fatura finans kontrolüne; banka dekontundaki net tutarla aktarım kaydı arasındaki fark hazineye atanabilir. Aynı satırı herkesin ayrı elektronik tablosunda tutması yerine tek istisna kuyruğu oluşturmak denetim izini güçlendirir. Sık sorulan sorular sayfası genel ürün soruları için bir başvuru noktasıdır; somut işlem farkı için ise kurum içindeki referanslar ve destek kaydı gerekir.
Kapanışın son adımı farkları zorla sıfırlamak değildir. Çözülemeyen kalem için geçici sınıflandırma, onay veren kişi ve gelecek dönemde yapılacak işlem belirtilir. ERP’de mutabakatı yapanla düzeltme kaydını onaylayan kişinin ayrılması, yanlış faturayı sessizce kapatma riskini azaltır. İlk ayda küçük bir örneklem üzerinde siparişten banka kaydına ve banka kaydından siparişe iki yönlü iz sürün. Bir yöndeki başarı diğer yöndeki eksikleri gizleyebilir: ERP’de eşleşmeyen tahsilatlar kadar sağlayıcı dökümünde olup ERP’ye hiç gelmeyen işlemler de aranmalıdır.
Sonuçta kullanılabilir model tek bir “ödendi” kutusu değil, kimlikleri ve zamanları korunan ticari bir izdir. Sipariş ve fatura yükümlülüğü tanımlar; ödeme talebi hangi varlık ve ağın beklendiğini belirtir; olaylar gerçekten neyin gerçekleştiğini gösterir; sevkiyat ve alacak ticari sonucu kaydeder; nakit hareketi ve ay sonu mutabakatı aradaki farkı açıklar. Önce bu bağları ve istisna sahiplerini tanımlayın, sonra otomasyonu genişletin. Böylece bir kayıt hatasını düzeltirken ticari işlemin geçmişini kaybetmezsiniz.
