Kripto ödeme mutabakatı, doğrulanmış tahsilatların hangi siparişlere ait olduğunu kanıtlamak ve ardından kalan her farkı açıklamak demektir. Cüzdan bakiyesi tek başına ne sattığınızı, hangi müşterinin ödeme yaptığını veya bir transferin gerçekten satış olup olmadığını göstermez.
Birbirine bağlı üç kayıt kullanın: sipariş, ödeme sağlayıcısının ödeme kaydı ve işletmenize ulaşan transfer. Bu rehber, küçük işletme ekipleri için günlük kapanış süreci sunar; muhasebe veya vergi danışmanlığı değildir. Buradaki kontroller kendi kayıtlarınız için önerilerdir; Yolfi'nin ödemeleri otomatik olarak dışa aktardığı, mutabakatını yaptığı veya muhasebeleştirdiği anlamına gelmez.
Siparişleri, ödeme kayıtlarını ve transferleri ayrı tutun
Sipariş, ticari anlaşmayı tanımlar. Ödeme kaydı, talebi ve bu talebin işlenmesini açıklar. Blokzincir transferi ise varlık hareketinin kanıtıdır. Birbirleriyle ilişkilidirler, ancak birbirlerinin yerine geçmezler.
Bir siparişin birden fazla ödeme denemesi olabilir. Bir işlem, birden fazla token transferi içerebilir. Kendi cüzdanlarınız arasındaki hareket, yeni bir müşteri ödemesi değildir. Her satırı tek sipariş ve tek işlem hash'i modeline zorlamak yerine bu ilişkileri kaydedin.
| Kayıt | Saklanması gereken asgari alanlar | Yanıtladığı soru |
|---|---|---|
| Sipariş | Sipariş referansı, müşteri referansı, fatura para birimi ve tutarı, sipariş durumu | Müşterinin borcu neydi? |
| Ödeme talebi | Sağlayıcı referansı, ilişkili sipariş, talep edilen varlık ve ağ, alıcı adresi, tutar ve varsa son geçerlilik zamanı | Hangi ödeme talimatları verildi? |
| Doğrulanmış transfer | Ağ, varlık tanımlayıcısı, işlem hash'i, gerekiyorsa transferin işlem içindeki konumu, alıcı, tutar, blok ve onay kanıtı | Gerçekte ne ulaştı? |
| Tahsilat dağıtımı | Transfer referansı, sipariş referansı, borca uygulanan tutar, inceleyen kişi ve zaman | Hangi tahsilat hangi borcu kapattı? |
| Düzeltme | İade veya iç transfer referansı, gerekçe, onay ve ilişkili kayıt | Varlık hareketi neden satışlardan farklı? |
Müşterilerin kişisel verilerini herkese açık blokzincir notlarında değil, erişimi kontrollü işletme kayıtlarında tutun. Mutabakat tablosuna asla özel anahtar veya kurtarma ifadesi kaydetmeyin.
Yalnızca sembolü veya hash'i değil, transferi tanımlayın
Tokenlar için sembolün yanında ağı ve doğrulanmış sözleşme ya da mint adresini de saklayın. USDC etiketi, farklı zincirlerdeki varlıkları veya aynı sembolü kullanan ilgisiz bir tokenı ayırt etmeye yetmez. Tahsilatları kabul etmeden önce tanımlayıcıları varlık hakkında yetkili bir kaynaktan doğrulayın.
EVM token transferlerinde kullanılabilecek benzersiz bir referans; zincir tanımlayıcısı, işlem hash'i ve günlük indeksinin, doğrulanmış token sözleşmesiyle birlikte tutulmasıdır. Bir işlem birden fazla transfer olayı ürettiğinde işlem hash'i tek başına yeterince ayrıntılı değildir. Diğer zincirlerde, o zincire uygun talimat veya olay tanımlayıcıları gerekir; EVM biçimini her yere uygulamayın.
Ethereum JSON-RPC belgeleri, işlem makbuzlarını, durumu ve günlükleri birbirinden ayırır. ERC-20 ödemelerinde ilgili token transfer olayını inceleyin: işlemin üst düzey alıcısı, işletmenin tahsilat adresi yerine bir sözleşme olabilir. Bir işlemin başarılı olması, beklediğiniz varlığın ve tutarın size ulaştığını tek başına kanıtlamaz.
Transfer geçmişi hizmeti kullanıyorsanız sorgu kapsamını ve tüm sayfaları saklayın. Etherscan token transfer uç noktası, zincir, adres, sözleşme, blok aralığı ve sayfalama filtreleri sunar. İlk sayfa, günün tüm kayıtları değildir. Blokzincir gezgini verileri destekleyici kanıttır; tahsilatları siparişlere dağıtmanın yerini tutmaz.
Günlük kapanışı sabit bir sırayla yapın
1. Kesim zamanını belirleyin ve kayıtları toplayın
İşletmeniz için bir saat dilimi ve başlangıcı dahil, bitişi hariç kesin bir raporlama aralığı seçin. Hem bu aralığı hem de sorgularda kullanılan UTC zaman damgalarını kaydedin. Raporunuzun transferleri blok zamanına, sağlayıcının onay zamanına veya belgelenmiş başka bir esasa göre mi grupladığını belirtin.
Döneme ait sipariş ve ödeme kayıtlarının yanı sıra önceki dönemlerden açık kalan kalemleri de toplayın. Her işletme tahsilat adresi ve desteklenen ağ için transferleri mevcut kayıtlarınızdan veya doğrulanmış blokzincir verilerinden edinin. Kontrol etmeden bir yönetim panelinin ya da API'nin belirli bir dışa aktarma özelliği olduğunu varsaymayın.
Verilerin alındığı zamanı ve blok aralığını koruyun. Kesim zamanına yakın görülen bir transfer, onay politikanızı ancak daha sonra karşılayabilir; önceki günün kanıtlarını açıklamasız değiştirmek yerine bu transferi beklemede tutun.
2. Hassasiyeti kaybetmeden standartlaştırın
Varlık miktarlarını, yerel para birimindeki fatura değerlerinden ayrı tutun. Token tutarlarını tam taban birimleriyle veya doğrulanmış basamak hassasiyetine sahip kesin ondalık değerlerle saklayın. Farklı ağlardaki USDC tutarlarını açıklamasız tek bir bakiyede toplamayın; ikisi de dolar değerini hedefliyor diye USDT ile USDC'yi birleştirmeyin.
Muhasebe kayıtlarınızda yerel para birimi cinsinden değer gerekiyorsa muhasebe politikanızın gerektirdiği değerleme kaynağını, zaman damgasını ve yöntemi kaydedin. Stablecoin sembolü, her tahsilatı tam bir ABD doları üzerinden kaydetme talimatı değildir. Bulunduğunuz ülkede ücretlerin ve değer değişimlerinin nasıl ele alınacağını muhasebecinize sorun.
3. Eşleştirin ve yalnızca bir kez dağıtın
Güvenilir sipariş ve sağlayıcı referanslarından başlayın. Tahsilatı bir siparişe dağıtmadan önce varlığı, ağı, alıcıyı, tutarı ve onay kanıtını doğrulayın. Birden fazla siparişte aynı tutar talep ediliyorsa yalnızca tutar ve zaman, müşterinin kimliğini kanıtlamaz.
Her transfer kaydı için benzersizliği zorunlu kılın ve dağıtılan toplamı transferin kullanılabilir tutarıyla sınırlayın. Bir tahsilat ancak işletme süreciniz buna izin veriyorsa ve toplam kontrol ediliyorsa birden fazla onaylı dağıtımda kullanılabilir. Aynı bildirimin iki kez alınması, ikinci bir tahsilat oluşturmamalı veya siparişin iki kez serbest bırakılmasına yol açmamalıdır.
4. İstisnaları kapanış toplamlarından ayırın
Eşleşmemiş tahsilatları, ödenmemiş siparişleri ve bekleyen onayları görünür tutun. Her fark için bir sorumlu, gerekçe ve sonraki adım belirleyin. Tutar anlaşmazlıklarında doğaçlama olarak yeniden tam tutarlı bir ödeme talebi göndermek yerine eksik ve fazla ödeme rehberini kullanın.
Varlık veya zincir uyuşmazlıklarını yanlış ağda ödeme rehberine yönlendirin. Birinin hesap tablosundaki rengini değiştirmesi, bir istisnanın çözüldüğü anlamına gelmez.
5. Hareketleri mutabık hale getirin ve kapanışı onaylayın
Her ağdaki her varlık için doğrulanmış giriş ve çıkışları kullanarak açılış bakiyesinden kapanış bakiyesine geçişi açıklayın. Satış tahsilatlarını, iadeleri, iç transferleri ve diğer hareketleri ayrı sınıflandırın. Ağ ücretlerini gerçekten harcanan varlıkta kaydedin; ağın yerel coin'iyle ödenen işlem ücretini stablecoin tahsilatından sessizce düşmeyin.
Bu bakiye hareket dökümünü gelir hesabı olarak değil, eksiksizlik kontrolü olarak kullanın. Dökümdeki net artış, her siparişin doğru tahsilatla eşleştirildiğini kanıtlamaz; muhasebeleştirilen gelir farklı muhasebe kurallarına tabi olabilir.
Uydurma müşteri verileri olmadan kapanış örneği
Bu açıklayıcı örnek, tek bir ağdaki tek bir USDC varlığını ele alır. Tüm hareketler seçilen kesim zamanı ve onay politikasına uygundur.
| Hareket | USDC |
|---|---|
| Açılış bakiyesi | 400 |
| Doğrulanmış müşteri tahsilatları | +250 |
| İşletmenin başka bir cüzdanından transfer | +100 |
| Onaylanmış müşteri iadesi | -20 |
| İşletmenin başka bir cüzdanına transfer | -150 |
| Kapanış bakiyesi | 580 |
Bakiye 180 USDC arttı, ancak müşteri tahsilatları 250 USDC idi. Bu rakamların hiçbiri otomatik olarak muhasebeleştirilen gelire eşit değildir. İç transferler satış oluşturmadan bu cüzdanın bakiyesini değiştirir; iade ise ilk siparişine bağlı kalır. Ağın yerel coin'iyle ödenen ağ ücretleri, o varlığa ait ayrı hareket dökümünde yer almalıdır.
İncelemeyi yapan kişi ayrıca 250 USDC'nin her bölümünün bir siparişe dağıtıldığını veya açıkça çözümlenmemiş olarak sınıflandırıldığını kontrol etmelidir. Açılış ve kapanış bakiyelerinin tutması, yanlış müşteriye bağlanmış bir tahsilatı ortaya çıkarmaz.
Kayıt zincirinde Yolfi'nin yeri
Yolfi'nin ödeme linkleri sayfası, ödeme linki oluşturmayı, ödemeleri takip etmeyi ve fonları doğrudan cüzdanınıza almayı açıklar. Bu, işletmeye cüzdan tahsilatlarının yanında bir ödeme talebi bağlamı sağlar; bu kayıtları siparişlere bağlama gereğini ortadan kaldırmaz.
Gerçek bir ödeme kabul etmeden önce mevcut kurulumunuzda sunulan varlığı, ağı ve alıcı adresini kontrol edin. Erişebildiğiniz ödeme referansını ve kendi sipariş referansınızı saklayın. Otomatik mutabakat süreci tasarlamadan önce mevcut entegrasyonunuzun hangi kayıtları sağladığını doğrulayın. Herkese açık bir pazarlama sayfasından dışa aktarma biçimleri, muhasebe entegrasyonları veya eşleştirme kuralları hakkında çıkarım yapmayın.
Peşinat veya aşama bazlı ödeme alan hizmet işletmeleri için serbest çalışanlara yönelik ödeme linki rehberi, konunun ticari yönünü açıklar. Peşinatın tamamı ödenmiş bir proje sanılmaması için bu kapsamı ödeme kanıtıyla birlikte saklayın.
Sık sorulan sorular
Yalnızca cüzdan bakiyelerini kullanarak mutabakat yapabilir miyim?
Hayır. Bakiyeler hareket kontrolünü destekleyebilir; ancak siparişin kime ait olduğunu, iç transferleri, bekleyen borçları veya bir tahsilatın gelir sayılıp sayılmadığını açıklayamaz.
Bir işlem hash'i her zaman tek bir ödeme midir?
Hayır. Bir işlem birden fazla transfer içerebilir. Ağı ve zincire uygun transfer tanımlayıcısını saklayın, ardından ilgili tahsilatı doğru siparişe dağıtın.
Ödeme günlük kesim zamanından sonra onaylanırsa ne olur?
İlk gözlemi saklayın ve kalemi belgelenmiş beklemeden onaylandıya geçiş sürecinizde ilerletin. Kapanmış bir dönemi sessizce yeniden yazmak yerine tutarlı bir raporlama esası uygulayın ve düzeltme izini koruyun.
Mutabakat için otomatik muhasebe yazılımı gerekir mi?
Her zaman değil. Kesin tutarları, benzersiz referansları, kanıtları ve inceleme geçmişini koruyan kontrollü bir hesap tablosu, düşük işlem hacminde işe yarayabilir. İşlem hacmi veya hata riski manuel kontrolleri güvenilmez hale getirdiğinde veritabanına ya da muhasebe entegrasyonuna geçin.
Farkı zorla sıfırlamak yerine kanıtla kapatın
İşe yarayan bir günlük kapanış; eşleştirilmiş tahsilatlar, sınıflandırılmış cüzdan hareketleri ve sorumluları belirlenmiş kısa bir istisna listesiyle sonuçlanır. Çözümlenmemiş kalemleri gizlemeyi gerektirmez. Açık ödeme linki talimatlarıyla başlayın, sipariş ilişkisini koruyun ve hangi kalemlerin kapatılabileceğini doğrulanmış transfer kanıtları belirlesin.
