बाज़ारियों (Marketplaces) के लिए डबल-एंट्री लेजर API क्या है?

कोई बाज़ार (marketplace) अपनी orders टेबल में भले ही बहुत मजबूत दिखाई दे, लेकिन पैसों के मामले में वह फिर भी गलत हो सकता है। ऑर्डर कहता है "भुगतान हो गया (paid)"। विक्रेता (seller) के डैशबोर्ड पर एक शेष राशि (balance) दिखाई देती है। लेकिन उस टेबल में ऐसी कोई चीज़ नहीं है जो यह साबित कर सके कि प्लेटफ़ॉर्म के पास कितना नकद है, वह प्रत्येक विक्रेता का कितना बकाया है, भुगतान का कितना हिस्सा कमीशन से होने वाली आय है, या अब कितना वैट (VAT) चुकाया जाना बाकी है। एक डबल-एंट्री लेजर API का अस्तित्व इन वित्तीय परिणामों को सही ढंग से दर्ज करने के लिए होता है, वह भी एक समय में एक संतुलित लेन-देन के साथ।

साधारण शब्दों में कहें तो: एक डबल-एंट्री लेजर API एक प्रोग्राम करने योग्य लेखांकन प्रणाली है। आपका एप्लिकेशन इसे एक वित्तीय घटना भेजता है, जैसे कि कैप्चर किया गया भुगतान या स्वीकृत भुगतान (payout), और लेजर उस घटना को नामित खातों में समान डेबिट और क्रेडिट वाले जर्नल के रूप में लिखता है। यह पैसे को एक जगह से दूसरी जगह नहीं ले जाता है। यह उस पैसे के बारे में सच्चाई दर्ज करता है जिसे कहीं और ले जाया गया है।

यहाँ "डबल-एंट्री लेजर" का क्या अर्थ है

लेजर खातों में होने वाले परिवर्तनों का रिकॉर्ड होता है, न कि नवीनतम शेष राशि को रखने वाली कोई टेबल। एक कामकाजी लेजर में तीन जुड़े हुए विचार होते हैं:

• खाता (Account): एक नामित वित्तीय स्थिति, जैसे कि पेमेंट प्रोसेसर प्राप्य (processor receivable), विक्रेता देय (seller payable), कमीशन आय, या वैट देय।
• लेन-देन (जर्नल): कई संतुलित पंक्तियों वाला एक परमाणु (atomic) वित्तीय घटना।
• प्रविष्टि (पोस्टिंग): उस लेन-देन के भीतर एक एकल डेबिट या क्रेडिट पंक्ति।

वह अपरिवर्तनीय नियम जो हर डिज़ाइन को जोड़े रखता है, वह सरल है: हर लेन-देन और हर मुद्रा (currency) के लिए कुल डेबिट, कुल क्रेडिट के बराबर होना चाहिए। लेजर API आमतौर पर स्टोरेज तक पहुँचने से पहले किसी भी असंतुलित राइट को अस्वीकार कर देते हैं। मॉडर्न ट्रेजरी (Modern Treasury) का दस्तावेजीकरण एक लेजर लेन-देन को ऐसे रूप में परिभाषित करता है जिसमें दो या दो से अधिक खाते शामिल होते हैं, जिनमें समान कुल के कम से कम एक डेबिट और एक क्रेडिट होता है, और यह पोस्ट किए गए लेन-देन को अपरिवर्तनीय (immutable) मानता है।

डबल-एंट्री का मतलब यह नहीं है कि इसमें हमेशा ठीक दो पंक्तियाँ हों। एक बाज़ार की अकेली बिक्री के लिए अक्सर एक डेबिट और कई क्रेडिट की आवश्यकता होती है। यही वह हिस्सा है जिसे लोग सबसे ज़्यादा गलत समझते हैं।

बाज़ारों को केवल भुगतान तालिका (payments table) के बजाय लेजर की आवश्यकता क्यों है

एक बाज़ार एक ही समय में कई वित्तीय रिश्तों को संभालता है। एक खरीदार भुगतान करता है। एक प्रोसेसर निपटान करता है। प्लेटफ़ॉर्म अस्थायी रूप से धन को नियंत्रित कर सकता है। विक्रेता एक हिस्सा अर्जित करता है। प्लेटफ़ॉर्म एक कमीशन रखता है। कर (Tax) देय हो जाता है। एक आरक्षित राशि (reserve) रोकी जा सकती है। बाद में, एक भुगतान (payout) पैसों को बाहर ले जाता है, और रिफंड या चार्जबैक इसके कुछ हिस्सों को उलट देते हैं।

एक payments टेबल आपको किसी ऑर्डर की व्यावसायिक स्थिति बता सकती है। यह आपको मज़बूती से यह नहीं बता सकती है:

• कितना प्रोसेसर प्राप्य या नकद मौजूद है
• प्रत्येक विक्रेता को कितना बकाया है
• कितनी आय प्लेटफ़ॉर्म से संबंधित है
• कितना वैट देय है, और किस देश में
• रिफंड या विवादों के मुकाबले क्या आरक्षित रखा गया है
• क्या किसी भुगतान ने सही विक्रेता देयता को कम किया है
• क्या प्रोसेसर का निपटान प्लेटफ़ॉर्म की उम्मीद के मुताबिक है

बाज़ार लेखांकन के लिए डबल-एंट्री लेजर API पर Nordlet की गाइड इस बात को स्पष्ट रूप से रेखांकित करती है: एप्लिकेशन टेबल उत्पाद की स्थिति का वर्णन करती हैं, जबकि लेजर उस स्थिति के वित्तीय परिणामों को दर्ज करता है। यह एक ऐसी बात पर भी जोर देती है जिसे दोहराना सार्थक है, कि पेमेंट-प्रसारक रिपोर्ट मिलान के लिए इनपुट हैं, न कि पूर्ण डबल-एंट्री बहीखाता।

बाज़ार की एक काम की गई बिक्री (Worked marketplace sale)

मान लीजिए कि एक खरीदार €100 का भुगतान करता है, विक्रेता को €85 मिलने का अधिकार है, और प्लेटफ़ॉर्म का कमीशन €15 है। स्पष्टता के लिए वैट और प्रोसेसर शुल्क को छोड़ दें।

खाता (Account)	डेबिट	क्रेडिट	कारण
पेमेंट प्रोसेसर प्राप्य	€100		प्रोसेसर प्लेटफ़ॉर्म को कैप्चर किए गए भुगतान का बकाया है
विक्रेता देय (Seller payable)		€85	प्लेटफ़ॉर्म विक्रेता का बकायेदार है
कमीशन आय		€15	प्लेटफ़ॉर्म ने अपना कमीशन अर्जित किया
कुल	€100	€100	संतुलित

यहाँ महत्वपूर्ण वर्गीकरण यह है कि विक्रेता को देय €85 एक देयता (liability) है, न कि प्लेटफ़ॉर्म की आय। IFRS वैचारिक फ्रेमवर्क के तहत, देयता किसी आर्थिक संसाधन को स्थानांतरित करने का वर्तमान दायित्व है। किसी बाज़ार को खरीदार द्वारा भुगतान किए जाने के मात्र आधार पर विक्रेता की पूरी बिक्री आय को अपनी आय के रूप में रिपोर्ट नहीं करना चाहिए। आप एजेंट, प्रिंसिपल, या माने गए आपूर्तिकर्ता के रूप में कार्य करते हैं या नहीं, यह उपचार को बदलता है, लेकिन लेजर की प्रक्रिया वही रहती है।

जब विक्रेता भुगतान के लिए पात्र हो जाता है, तो कोई नई आय मान्यता प्राप्त नहीं होती है। आप देयता का निपटान करते हैं:

खाता (Account)	डेबिट	क्रेडिट
विक्रेता देय (Seller payable)	€85
बैंक या भुगतान समाशोधन (payout clearing)		€85
कुल	€85	€85

यदि प्रोसेसर निपटान से पहले €3 का शुल्क लेता है, तो नकदी का आवागमन तीन पंक्तियों वाली जर्नल बन जाता है: बैंक कैश में €97, प्रोसेसिंग खर्च में €3, और प्रोसेसर प्राप्य से बाहर €100। स्थिति में हर बदलाव का एक स्रोत और एक गंतव्य होता है।

API कैसे काम करता है, चरण दर चरण

1. आपका एप्लिकेशन किसी व्यावसायिक घटना का पता लगाता है। एक भुगतान कैप्चर किया जाता है, एक ऑर्डर पूरा किया जाता है, एक भुगतान अनुमोदित किया जाता है, एक रिफंड जारी किया जाता है, एक चार्जबैक खुलता है, एक निपटान आता है। आपका डेटाबेस अभी भी परिचालन स्थिति का मालिक है। लेजर मौद्रिक प्रभाव को दर्ज करता है।

2. आप एक संरचित अनुरोध भेजते हैं। इसमें आमतौर पर घटना का प्रकार, राशि और मुद्रा, ऑर्डर या भुगतान आईडी, खरीदार और विक्रेता पहचानकर्ता, कमीशन, कर डेटा, शामिल खाते, प्रभावी और पोस्टिंग तिथियाँ, एक आइडपोटेंसी की (idempotency key), और प्रोसेसर तथा उत्पाद रिकॉर्ड से जुड़ी मेटाडेटा शामिल होती है। Nordlet का सार्वजनिक API उदाहरण विक्रेता आईडी, बिक्री प्रकार, राशि, मुद्रा और वैट देश तथा दर के साथ एक वैचारिक बिक्री अनुरोध दिखाता है।

3. API मान्य करता है। यह जाँचता है कि डेबिट और क्रेडिट संतुलित हैं, खाते मौजूद हैं और पोस्ट किए जाने योग्य हैं, मुद्रा समर्थित है, राशि सटीक माइनर-यूनिट हैंडलिंग का उपयोग करती है, अलग परिणाम के लिए आइडपोटेंसी की का पुनउपयोग नहीं किया गया है, अवधि खुली है, और आवश्यक मेटाडेटा मौजूद है। एक असफल जाँच पीछे कोई आंशिक जर्नल नहीं छोड़ती है।

4. यह परमाणु रूप से (atomically) पोस्ट करता है। पूरा लेन-देन एक इकाई के रूप में लिखा जाता है। आप कभी भी मिलान करने वाले क्रेडिट के असफल होने पर डेबिट को दर्ज करने में सक्षम नहीं होने चाहिए। एक बाज़ार के लिए, एक आंशिक विभाजन बिना किसी संबंधित नकदी के स्पष्ट विक्रेता शेष बना सकता है, या विक्रेता दायित्व के बिना पुस्तक कमीशन बना सकता है।

5. शेष और रिपोर्ट लेजर से प्राप्त होते हैं। पोस्ट करने के बाद, आप खाता शेष, विक्रेता लंबित और उपलब्ध शेष, ट्रायल बैलेंस, जनरल-लेजर गतिविधि, वैट सारांश, और पिछली तिथि के अनुसार इतिहास पढ़ सकते हैं। विक्रेता शेष को पोस्टिंग से पुनर्निर्माण योग्य होना चाहिए, न कि किसी परिवर्तनशील (mutable) फ़ील्ड से भरोसा किया जाना चाहिए।

6. वेबहुक आपके उत्पाद को सूचित करते हैं। sale_invoice.paid, एक पोस्ट किया गया जर्नल, एक उपलब्ध भुगतान, या मिलान अपवाद जैसी घटनाएँ आपके पास भेजी जाती हैं। उन्हें आइडपोटेंट तरीके से प्रोसेस करें। एक वेबहुक एक सूचना है, न कि वित्तीय घटना को दूसरी बार लागू करने की अनुमति। API सम्मेलनों में स्कोप, आइडपोटेंसी की, त्रुटि आकृतियाँ, और वेबहुक हस्ताक्षर विस्तार से शामिल हैं।

विक्रेता का बैलेंस कोई एकल संख्या नहीं है

अधिकांश बाज़ार विक्रेता के बैलेंस को एक ही आँकड़े के रूप में मानकर मुसीबत में पड़ जाते हैं। पैसे को विभिन्न स्थितियों में होना चाहिए:

स्थिति (State)	अर्थ
लंबित (Pending)	विक्रेता हकदार हो सकता है, लेकिन रिलीज की शर्तें पूरी नहीं हुई हैं
उपलब्ध (Available)	भुगतान के लिए पात्र
आरक्षित (Reserved)	रिफंड, रिटर्न या विवादों के खिलाफ रोका गया
भुगतान किया गया (Paid out)	ट्रांसफर द्वारा दायित्व का निपटान
नकारात्मक (Negative)	रिफंड, चार्जबैक या शुल्क उपलब्ध धनराशि से अधिक हैं

प्रोसेसर मॉडल इस बात को दर्शाते हैं। Stripe के अलग-अलग चार्ज और ट्रांसफर फ्लो एक प्लेटफ़ॉर्म को अपने खाते को चार्ज करने की अनुमति देते हैं, फिर शुल्क, रिफंड और चार्जबैक के साथ जुड़े हुए खातों में कुछ हिस्सों को ट्रांसफर करते हैं जो प्लेटफ़ॉर्म बैलेंस पर आते हैं। Adyen का बाज़ार मॉडल उपयोगकर्ता बैलेंस खातों को अलग करता है, जो भुगतान तक धन रखते हैं, एक दाईयता बैलेंस खाते से जो रिफंड या चार्जबैक से नकारात्मक बैलेंस को अवशोषित कर सकता है। ये आपके लेजर के लिए उपयोगी इनपुट हैं। ये आपका संपूर्ण लेखांकन मॉडल नहीं हैं।

भुगतान (Payouts) और विक्रेता की कमाई अलग-अलग समय पर होती है

एक विक्रेता सोमवार को कमा सकता है और अगले सोमवार को भुगतान प्राप्त कर सकता है। उन बिंदुओं के बीच, एक ऑर्डर पूरा हो जाता है, एक रिजर्व रखा जाता है, एक भुगतान बैच बनाया जाता है, एक प्रोसेसर शुल्क को छोड़कर इसका निपटान करता है, और एक बैंक जमा आ जाता है। एक लेजर को ऑर्डर को अंतिम "paid" के साथ अधिलेखित करने के बजाय प्रत्येक चरण को संरक्षित करना होगा। यही वह चीज़ है जो आपको ऑर्डर गतिविधि, विक्रेता पात्रता, निपटान, भुगतान की शुरुआत और बैंक रसीद के बीच समय के अंतर को समझाने की अनुमति देती है।

रिफंड और चार्जबैक: उलट दें, दोबारा न लिखें

रिफंड और चार्जबैक मूल भुगतान से जुड़ी नई घटनाएँ हैं। एक अपरिवर्तनीय (immutable) लेजर में, आप एक रिवर्सिंग प्रविष्टि के बाद एक सुधारात्मक प्रविष्टि के साथ सुधार करते हैं, ताकि मूल ऑडिट के लिए दिखाई देता रहे। मॉडर्न ट्रेजरी पोस्ट किए गए लेनदेन को अपरिवर्तनीय मानता है और पुनः प्रयास पर डुप्लिकेट वस्तुओं को रोकने के लिए आइडपोटेंसी की का समर्थन करता है।

एक रिफंड आमतौर पर नकदी या खरीदार प्राप्य को कम करता है, विक्रेता देय को उलट देता है, नीति के आधार पर कमीशन के हिस्से को उलट सकता है, कर को समायोजित कर सकता है, और रिफंड रिजर्व का उपभोग कर सकता है। एक चार्जबैक नकदी या प्रोसेसर प्राप्य को कम करता है, विक्रेता या प्लेटफ़ॉर्म द्वारा देय राशि को फिर से खोल सकता है, एक विवाद व्यय और प्रोसेसर शुल्क दर्ज करता है, और एक रिजर्व खाते के माध्यम से धन ले जाता है।

मिलान (Reconciliation): लेजर को वास्तविक धन से जोड़ना

एक लेजर आंतरिक रूप से संतुलित हो सकता है और बाहरी दुनिया के बारे में फिर भी गलत हो सकता है। मिलान आंतरिक रिकॉर्ड की तुलना बाहरी साक्ष्य से करता है: प्रोसेसर निपटान रिपोर्ट, बैंक स्टेटमेंट, भुगतान फाइलें, रिफंड और विवाद रिकॉर्ड।

एक काम करने वाला लूप इस प्रकार दिखता है:

1. निपटान या बैंक बैच आयात करें।
2. प्रत्येक पंक्ति का मिलान किसी ऑर्डर, भुगतान, रिफंड, शुल्क, भुगतान या विवाद से करें।
3. अपेक्षित सकल, कटौतियों, रिजर्व और शुद्ध की तुलना करें।
4. पुष्टि किए गए आंदोलनों को लेजर में पोस्ट करें।
5. बेमेल वस्तुओं को एक नामित सस्पेंस खाते में भेजें।
6. अपवादों की जाँच करें।
7. अवधि को लॉक करें।

Nordlet की मिलान सामग्री बिल्कुल यही वर्णन करती है, निपटान बैचों को आयात करना, चार्ज और रिफंड लाइनों का मिलान करना, और चालान का अनुमान लगाने के बजाय बेमेल रसीदों को सस्पेंस पर भेजना। दो जाँचें मायने रखती हैं और कोई भी दूसरे की जगह नहीं लेती है: डबल-एंट्री सत्यापन पूछता है कि क्या प्रत्येक जर्नल संतुलित है, और मिलान पूछता है कि क्या यह प्रोसेसर, बैंक और व्यावसायिक घटना से सहमत है।

डिज़ाइन विवरण जो तय करते हैं कि आप इसे सही करते हैं या नहीं

आइडपोटेंसी (Idempotency): कुंजी को एक स्थिर घटना से बांधें, जैसे कि payment_captured:pi_123। एक पुनः प्रयास मूल परिणाम लौटाता है, दूसरा जर्नल नहीं।

परमाणुकता (Atomicity): एक घटना की सभी पंक्तियाँ एक साथ पोस्ट होती हैं या कोई भी नहीं होती है।

अपरिवर्तनीयता और उत्क्रमण (Immutability and reversals): पोस्ट किया गया इतिहास साधारण अपडेट के माध्यम से संपादनीय नहीं है। सुधार ऐसी जुड़ी हुई प्रविष्टियाँ बनाते हैं जो मूल राशि, तिथि, वर्गीकरण, कारण और लेखक को सुरक्षित रखती हैं।

सटीक धन (Precise money): कोई बाइनरी फ्लोटिंग पॉइंट नहीं। पूर्णांक माइनर यूनिट या सटीक दशमलव, स्पष्ट मुद्रा, और विभाजन के लिए एक नियतात्मक गोलाई नियम (rounding rule) का उपयोग करें। बिना किसी नियम के विक्रेताओं और शुल्कों में €100 को विभाजित करें, और एक भटका हुआ सेंट आपके बैलेंस को तोड़ देगा।

प्रभावी बनाम पोस्टिंग तिथियाँ: जब खरीदार ने भुगतान किया, जब विक्रेता ने कमाया, जब बैंक ने निपटान किया, और जब प्रविष्टि पोस्ट की गई, वे अलग-अलग तिथियाँ हैं। उन्हें मिलाना अवधि रिपोर्टिंग और कर समय को अविश्वसनीय बनाता है।

बहु-मुद्रा (Multi-currency): डेबिट और क्रेडिट एक मुद्रा के भीतर संतुलित होने चाहिए। रूपांतरण के लिए शुल्क, राउंडिंग और किसी भी FX लाभ या हानि के खातों के साथ एक स्पष्ट दर घटना की आवश्यकता होती है। currency फ़ील्ड स्वीकार करना लेजर को FX इंजन नहीं बनाता है।

लेजर API आपके लिए क्या नहीं करेगा

यह आपके खातों के चार्ट का निर्णय नहीं करेगा। आपको अभी भी यह निर्धारित करना होगा कि आप प्रिंसिपल हैं या एजेंट, कमीशन कब अर्जित किया जाता है, कौन सी पार्टी प्रोसेसर शुल्क वहन करती है, रिफंड कमीशन को कैसे प्रभावित करते हैं, और वैट की गणना और रिपोर्ट कैसे की जाती है। Nordlet का अपना मार्गदर्शन पहले पैसे के प्रवाह को मैप करना, खातों के चार्ट का मसौदा तैयार करना, किसी लेखाकार से इसकी समीक्षा करवाना, और फिर स्केलिंग से पहले ऑर्डर से लेकर भुगतान और मिलान तक एक पूर्ण प्रवाह को लागू करना है।

यह कर के सवालों को हल नहीं करेगा। वैट खरीदार और विक्रेता के स्थान, उत्पाद के प्रकार, पंजीकरण की स्थिति और माने-आपूर्तिकर्ता नियमों पर निर्भर करता है; EU वैट गाइड यह निर्धारित करती है कि इंजन क्या प्राप्त करता है और यह मानव के लिए क्या चिह्नित करता है। Nordlet का वैट कवरेज EU और EEA केंद्रित है, इसलिए यह अमेरिकी बिक्री कर या लैटिन अमेरिकी ई-चालान तक नहीं फैला है। और यह परिचालन अस्पष्टता को हल नहीं करेगा, क्या रिटर्न विंडो बंद हो गई है, क्या भुगतान अवरुद्ध किया जाना चाहिए, क्या भुगतान धोखाधड़ी है। वे आपके निर्णय हैं। लेजर उनके वित्तीय परिणाम को दर्ज करता है।

Nordlet कहाँ फिट बैठता है

Nordlet प्लेटफ़ॉर्म और बाज़ारों के लिए बनाया गया एक लेखांकन API है, जिसमें एक अपरिवर्तनीय डबल-एंट्री लेजर, भुगतान, EU वैट हैंडलिंग, REST एंडपॉइंट्स, टाइप किए गए SDK, और एक सतह के माध्यम से पहुँचा जा सकने वाला वेबहुक शामिल है। इसकी विशिष्ट पसंद तीसरे पक्ष के चेकआउट के बजाय आपके अपने उत्पाद के भीतर सन्निहित लेखांकन है। इस लेखन के समय उत्पाद डिज़ाइन पार्टनर के लिए सैंडबॉक्स के साथ शुरुआती पहुँच में है, इसलिए इसे श्रेणी के एक मजबूत उदाहरण के रूप में मानें और प्रतिबद्ध होने से पहले अपने स्वयं के मामले के लिए उत्पादन परिपक्वता, अपटाइम और क्षेत्राधिकार कवरेज का मूल्यांकन करें।

बाज़ार और प्लेटफ़ॉर्म डेवलपर्स के लिए, उपयोगी मानसिक मॉडल भुगतान की आवाज़ और वित्तीय सच्चाई के बीच का विभाजन है। आपका प्रोसेसर पैसे को स्थानांतरित करता है। एक डबल-एंट्री लेजर API दर्ज करता है कि किसे क्या देना है, आपने क्या कमाया है, आप क्या कर और रिजर्व रखते हैं, और क्या बाहरी दुनिया आपकी पुस्तकों से मेल खाती है।

FAQ

क्या डबल-एंट्री लेजर API और पेमेंट प्रोसेसर एक ही हैं?

नहीं। एक प्रोसेसर फंड को अधिकृत करता है, कैप्चर करता है, निपटान करता है और कभी-कभी भुगतान करता है। एक लेजर API उन घटनाओं के लेखांकन परिणामों को दर्ज करता है। अधिकांश बाज़ार दोनों का उपयोग करते हैं, मूवमेंट के लिए Stripe या Adyen जैसे प्रोसेसर और किताबों के लिए एक लेजर।

क्या मैं केवल अपने प्रोसेसर के डैशबोर्ड को जनरल लेजर के रूप में उपयोग कर सकता हूँ?

आप कोशिश कर सकते हैं, और यह अंततः ऑडिट में विफल हो जाएगा। प्रोसेसर रिपोर्टिंग शुल्क, फीस, ट्रांसफर और निपटान दिखाती है, लेकिन यह आमतौर पर आपके पूर्ण विक्रेता दायित्वों, कर देनदारियों, गैर-प्रोसेसर खर्चों या लेखांकन समायोजन का प्रतिनिधित्व नहीं करती है। इसे मिलान इनपुट के रूप में मानें।

क्या संतुलित लेजर का मतलब है कि मेरी किताबें सही हैं?

केवल यह कि आपकी प्रविष्टियाँ डेबिट-क्रेडिट नियम को पूरा करती हैं। पूरी तरह से संतुलित लेन-देन अभी भी गलत खाते में, गलत विक्रेता को, या गलत कर उपचार के साथ पोस्ट किया जा सकता है। संतुलन आवश्यक है, पर्याप्त नहीं। मिलान वह है जो बाकी को पकड़ता है।

यदि लेजर अपरिवर्तनीय (immutable) है, तो मैं गलतियों को कैसे ठीक करूँ?

आप एक रिवर्सिंग प्रविष्टि और फिर एक सुधारात्मक प्रविष्टि पोस्ट करते हैं। मूल दिखाई देता रहता है, जो कि पूरी बात है। अपरिवर्तनीयता ऑडिट ट्रेल की रक्षा करती है, यह आपकी त्रुटियों को नहीं फंसाती है।

क्या लेखांकन API मुझे स्वचालित रूप से अनुपालन (compliant) बनाता है?

नहीं। यह लेखांकन संरचना को लागू करता है और प्रयोग करने योग्य रिकॉर्ड तैयार करता है। कानूनी अनुपालन अभी भी आपके क्षेत्राधिकार, संविदात्मक भूमिका, कर उपचार, भुगतान नियमों, KYC और AML प्रक्रियाओं, और रिपोर्टिंग दायित्वों पर निर्भर करता है।

आगे की पढाई

• बाज़ार लेखांकन के लिए डबल-एंट्री लेजर API
• डबल-एंट्री लेजर को परिभाषित करना, Formance