Marketplace Seller Subledgers: Revenue vs Payables

A practitioner's guide to separating customer cash, platform commission, seller payables, reserves, and payouts with balanced journal entries and a working order-to-payout data model.

Nordlet Team · 12 सितंबर 2026 · 15 मिनट पढ़ने में

मार्केटप्लेस एकाउंटिंग (marketplace accounting) में सबसे आम गलती खरीदार (buyer) के कुल भुगतान (gross payment) को प्लेटफॉर्म का रेवेन्यू (revenue) मान लेना है। कोई ग्राहक €100 का भुगतान करता है, वह €100 प्रोसेसर अकाउंट में जमा होता है, और कोई व्यक्ति पूरी राशि को सेल्स (sales) में दर्ज कर देता है। बहीखाता (books) कुछ समय के लिए मिलान में रहता है, रेवेन्यू शानदार दिखता है, और फिर कोई ऑडिटर पूछता है कि विक्रेता की देनदारी (seller liability) कहाँ है। वह है ही नहीं, क्योंकि विक्रेता के €90 को कभी भी बकाया राशि के रूप में रिकॉर्ड ही नहीं किया गया था।

इसका समाधान संरचनात्मक (structural) है, न कि केवल दिखावटी। एक मार्केटप्लेस को एक ऐसे लेज़र मॉडल (ledger model) की आवश्यकता होती है जो पहली प्रविष्टि से ही पाँच अलग-अलग पूलों को अलग रखे: ट्रांजिट में रखा गया ग्राहक का नकद, प्लेटफॉर्म कमीशन रेवेन्यू, विक्रेता देय राशि (seller payables), शुल्क (fees), और रिज़र्व। पेआउट (payouts) छठी ऐसी गतिविधि है जो देय राशि का निपटान (settle) करती है, न कि अपने आप में कोई रेवेन्यू या खर्च की गतिविधि। यह मार्गदर्शिका संतुलित जर्नल एंट्रीज़ (journal entries) और उस डेटा मॉडल को दिखाती है जो उन पूलों को अलग रखते हैं।

प्रिंसिपल बनाम एजेंट के निष्कर्ष से शुरुआत करें

किसी भी अकाउंट की संरचना से पहले, प्लेटफॉर्म को यह तय करना होगा कि वह क्या बेच रहा है। ASC 606 के तहत, इसका मूल्यांकन प्रत्येक निर्दिष्ट वस्तु या सेवा (specified good or service) के आधार पर किया जाता है, और उत्तर यह निर्धारित करता है कि रेवेन्यू ग्रॉस (gross) है या नेट (net)। एक प्लेटफॉर्म किसी एक फ्लो के लिए प्रिंसिपल (principal) और दूसरे के लिए एजेंट हो सकता है।

विक्रेता के सामान की किसी सामान्य मार्केटप्लेस बिक्री के लिए, प्लेटफॉर्म आमतौर पर एक एजेंट होता है। यह विक्रेता के उत्पाद को खरीदार तक पहुँचाने की व्यवस्था करता है, यह इन्वेंट्री जोखिम (inventory risk) नहीं उठाता है, और इसका प्रतिफल (consideration) एक कमीशन होता है। Deloitte का ASC 606 के तहत प्रिंसिपल-बनाम-एजेंट मार्गदर्शन (principal-versus-agent guidance under ASC 606) नियंत्रण (control) के इर्द-गिर्द परीक्षण को तैयार करता है: वादे को पूरा करने की ज़िम्मेदारी, इन्वेंट्री जोखिम, और मूल्य निर्धारण का विवेक इसके संकेतक हैं, न कि कोई ऐसी चेकलिस्ट जो अंतर्निहित नियंत्रण मूल्यांकन को ओवरराइड करती है।

यह बात लेज़र डिज़ाइन में होना क्यों ज़रूरी है, सिर्फ किसी मेमो में नहीं, इसका कारण यह है कि यह निष्कर्ष हर डाउनस्ट्रीम एंट्री को संचालित करता है। यदि प्लेटफॉर्म एक एजेंट है, तो विक्रेता का हिस्सा अर्जित होते ही एक देनदारी बन जाता है। यदि यह फ़ुलफ़िल्मेंट या वारंटी सेवा के लिए प्रिंसिपल है, तो वह हिस्सा प्लेटफॉर्म का रेवेन्यू है। इस निष्कर्ष को डेटा के रूप में सहेजें:

principal_agent_role
specified_good_or_service
commission_rule_id
control_assessment_version
effective_from / effective_to

दो साल बाद नेट कमीशन लाइन को देखने वाले समीक्षक को यह पता होना चाहिए कि ग्रॉस का उपयोग क्यों नहीं किया गया था। जैसा कि BillingPlatform ने ASC 606 प्रिंसिपल बनाम एजेंट (ASC 606 principal vs agent) पर उल्लेख किया है, "मार्केटप्लेस" लेबल इस सवाल का समाधान नहीं करता है। नियंत्रण विश्लेषण (control analysis) करता है।

एक भी जर्नल नियम लिखने से पहले विक्रेता के बैलेंस को परिभाषित करें

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

कम से कम, इन्हें ट्रैक करें:

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

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

चार्ट ऑफ़ अकाउंट्स और वे आयाम (dimensions) जो मायने रखते हैं

काम करने योग्य शुरुआती संरचना समाशोधन खातों (clearing accounts), देनदारियों और रेवेन्यू को अलग रखती है, और हर महत्वपूर्ण पोस्टिंग पर विक्रेता आयाम (seller dimension) को साथ रखती है।

उद्देश्य (Purpose)	अकाउंट या आयाम (Account or dimension)	ट्रीटमेंट (Treatment)
निपटान की प्रतीक्षा कर रहे प्रोसेसर फंड	पेमेंट प्रोसेसर क्लियरिंग	क्लियरिंग एसेट
बैंक में जमा प्रोसेसर पेआउट	बैंक	एसेट
विक्रेता की अर्जित लेकिन अवैतनिक राशि	विक्रेता देय राशि (Seller payables)	देनदारी (Liability)
विक्रेता-स्तरीय विवरण	`seller_id` आयाम	देनदारी विवरण, रेवेन्यू नहीं
प्लेटफॉर्म कमीशन	कमीशन रेवेन्यू	रेवेन्यू
वैट या बिक्री कर (Sales tax)	कर देय (Tax payable)	देनदारी
प्रोसेसर शुल्क	भुगतान-प्रसंस्करण खर्च (Payment-processing expense)	खर्च (Expense)
विक्रेता रिज़र्व	रिज़र्व देयता	अनुबंध-निर्भर
रिफंड	कॉन्ट्रा-रेवेन्यू या रिफंड	मूल ट्रीटमेंट को उलटता है
चार्जबैक	नुकसान, प्राप्य (receivable), या विक्रेता वसूली	निर्भर करता है कि नुकसान कौन उठाता है
बैंक पुष्टि की प्रतीक्षा कर रहे पेआउट	विक्रेता पेआउट क्लियरिंग	क्लियरिंग अकाउंट
आवंटित न की गई राशि	सस्पेंस	अस्थायी अपवाद

हर महत्वपूर्ण प्रविष्टि में विक्रेता, ऑर्डर, पेआउट बैच, प्रोसेसर, मुद्रा (currency), कानूनी इकाई, कर उपचार, इवेंट प्रकार, बाहरी संदर्भ, और कोई भी रिवर्सल लिंक होना चाहिए। इनके बिना, विक्रेता सबलेज़र किसी व्यक्तिगत बैलेंस को साबित नहीं कर सकता है और जनरल लेज़र कुल योग को साबित नहीं कर सकता है।

आप सबलेज़र को प्रति विक्रेता एक देयता खाते के रूप में, seller_id को एक आयाम के रूप में रखने वाले एक कुल देय खाते के रूप में, या देय, रिज़र्व और पेआउट क्लियरिंग में विभाजित रूप में लागू कर सकते हैं। कुछ दर्जन विक्रेताओं को पार करने के बाद कुल-प्लस-आयाम दृष्टिकोण (aggregate-plus-dimension approach) बेहतर ढंग से स्केल करता है। अपने अकाउंटेंट के साथ मॉडल चुनें, क्योंकि सुरक्षा नियम और स्थानीय भुगतान विनियमन यह प्रभावित कर सकते हैं कि फंड को कैसे प्रस्तुत किया जाना चाहिए। पोस्टिंग के पीछे के तंत्र के लिए, मार्केटप्लेस एकाउंटिंग के लिए डबल-एंट्री लेज़र API (double-entry ledger APIs for marketplace accounting) पर हमारा लेख उन लेज़र प्रिमिटिव्स को कवर करता है जिन पर यह मॉडल आधारित है।

अलग-अलग विक्रेता और प्लेटफॉर्म लाइनों के साथ बिक्री पोस्ट करें

एक एजेंट बिक्री लें: ग्राहक €100 का भुगतान करता है, प्लेटफॉर्म कमीशन €10 है, विक्रेता €90 कमाता है। जिस बिंदु पर कमीशन और विक्रेता का अधिकार अर्जित होता है:

अकाउंट (Account)	डेबिट (Debit)	क्रेडिट (Credit)
पेमेंट प्रोसेसर क्लियरिंग	€100
विक्रेता देय राशि - विक्रेता A		€90
कमीशन रेवेन्यू		€10

वह नियंत्रण जो मायने रखता है: €90 एक देनदारी को क्रेडिट करता है, रेवेन्यू को नहीं। प्लेटफॉर्म €10 को मान्यता देता है। यह वह परिणाम है जिस तक एक एजेंट के लिए ASC 606 का मार्केटप्लेस उदाहरण पहुंचता है, जहाँ प्लेटफॉर्म विक्रेता की पूरी बिक्री राशि के बजाय अपने कमीशन को मान्यता देता है।

यदि कर अलग से एकत्र किया जाता है, तो कर-देय लाइन जोड़ें और कर निष्कर्ष के अनुसार विक्रेता या प्लेटफॉर्म के आंकड़े को कम करें। सुविधा के लिए कर को कमीशन या विक्रेता देय राशि में शामिल न करें।

प्रोसेसर शुल्क को रेवेन्यू और देयता गणना से बाहर रखें

तीन चीजें लगातार भ्रमित करती हैं: प्लेटफॉर्म कमीशन, प्रोसेसर शुल्क, और पेआउट राशि। वे अलग-अलग हैं, और वे अलग-अलग खातों को प्रभावित करती हैं।

ग्राहक €100 का भुगतान करता है, कमीशन €10 है, प्रोसेसर €3 अपने पास रखता है।

यदि अनुबंध वही है तो कमीशन रेवेन्यू €10 रहता है।
€3 प्रोसेसर शुल्क एक खर्च है।
विक्रेता देय राशि €90 है जब तक कि विक्रेता अनुबंध यह न कहे कि विक्रेता प्रसंस्करण शुल्क वहन करता है। केवल तभी यह विक्रेता से लिए गए मिलान वाले €3 के साथ गिरकर €87 हो जाती है।

बैंक में आने वाले केवल नेट €97 को पोस्ट करने से एक ही बार में सकल बिक्री, कमीशन और शुल्क मिट जाते हैं। हमारा पेमेंट रीकंसिलेशन संदर्भ (payment reconciliation reference) भी यही बात कहता है: निपटान को विघटित (decompose) करें, प्रोसेसर शुल्क को खर्च के रूप में मानें, और नेट जमा को कभी भी रेवेन्यू की जगह न लेने दें।

उपलब्धता, रिज़र्व और पेआउट को अलग-अलग घटनाओं के रूप में मॉडल करें

कैप्चर और निपटान किए गए नकदी के बीच पैसा कई बार स्थिति बदलता है। प्रत्येक संक्रमण अपनी खुद की प्रविष्टि का हकदार है, और रिज़र्व रेवेन्यू में कभी भी अस्पष्ट कटौती नहीं है।

जब उपलब्ध फंड रिज़र्व में चले जाते हैं:

अकाउंट (Account)	डेबिट (Debit)	क्रेडिट (Credit)
विक्रेता देय राशि - विक्रेता A	€15
विक्रेता रिज़र्व देयता		€15

जब रिज़र्व जारी (release) होता है, तो इसे उलट दें (reverse)। विक्रेता की कुल देनदारी बदली नहीं है; इसकी स्थिति बदली है। Stripe उन रिज़र्व लेनदेन का दस्तावेजीकरण करता है जो रिज़र्व को बढ़ाते और जारी करते हैं, साथ ही लंबे समय से चले आ रहे नकारात्मक बैलेंस के लिए संग्रह ट्रांसफर भी करते हैं, यही वजह है कि इन्हें एक ही नेटिंग प्रविष्टि के बजाय पहचान योग्य खातों की आवश्यकता होती है।

पेआउट को उनका अपना दो-चरण उपचार मिलता है। अनुमोदन पर:

अकाउंट (Account)	डेबिट (Debit)	क्रेडिट (Credit)
विक्रेता देय राशि - विक्रेता A	€90
विक्रेता पेआउट क्लियरिंग		€90

पुष्ट बैंक निपटान पर:

अकाउंट (Account)	डेबिट (Debit)	क्रेडिट (Credit)
विक्रेता पेआउट क्लियरिंग	€90
बैंक		€90

यदि पेआउट विफल हो जाता है, तो क्लियरिंग को वापस विक्रेता देय राशि में उलट दें। पेआउट एक देनदारी का निपटान है, न कि कोई खर्च। इसे एक खर्च के रूप में मानना उस बिक्री के मुकाबले दो बार गिनती करता है जिसने पहले ही देय राशि रिकॉर्ड कर ली थी। Stripe शुरुआत से पेआउट स्थिति (pending, in_transit, paid, failed, canceled) और अपेक्षित आगमन तिथि को अलग करता है, और उन तिथियों को एक टाइमस्टैम्प में संकुचित नहीं होना चाहिए।

ऑर्डर-से-पेआउट डेटा मॉडल

सबलेज़र घटनाओं पर चलता है, एप्लिकेशन की वर्तमान ऑर्डर स्थिति पर नहीं। विक्रेता को प्रभावित करने वाली हर घटना में एक ही लिफाफा (envelope) होता है:

seller_id, event_id, order_id
event_type (बिक्री, रिफंड, चार्जबैक, reserve_hold, reserve_release, payout, समायोजन)
effective_date, posting_date
currency, direction, gross, commission, fees, reserve
refund_ref / dispute_ref
payout_batch_id
reversal_of
source_status, idempotency_key

परिवर्तनीय (mutable) फ़ील्ड को सहेजने के बजाय उन घटनाओं से आप समापन शेष (closing balance) की गणना करते हैं:

विक्रेता समापन शेष
= शुरुआती शेष
+ विक्रेता क्रेडिट
− विक्रेता डेबिट
− पेआउट
± रिज़र्व संचलन
± सुधार

प्रत्येक बाहरी घटना के लिए एक टिकाऊ इडपोटेंसी कुंजी (idempotency key) की आवश्यकता होती है ताकि पुनः प्रयास और डुप्लिकेट वेबहुक किसी विक्रेता को दो बार क्रेडिट न करें या पेआउट का दो बार भुगतान न करें। जो पैटर्न काम करते हैं:

विक्रेता जर्नल इवेंट: seller_id:order_id:event_type:version
पेआउट बैच: processor:payout_id
प्रोसेसर इवेंट: processor:event_type:processor_event_id

Stripe की अपनी वेबहुक मार्गदर्शिका चेतावनी देती है कि डुप्लिकेट घटनाएं होती हैं, इसलिए डुप्लिकेट का पता लगाना वैकल्पिक नहीं है। पोस्ट की गई प्रविष्टियाँ अपरिवर्तनीय (immutable) रहती हैं। सुधार एक रिवर्सिंग प्रविष्टि प्लस एक संशोधित प्रविष्टि के माध्यम से जाते हैं, और यह आपका अपना इवेंट लिफाफा है जो reversal_of लिंक और कारण को वहन करता है। लेज़र पोस्टिंग रखता है, वह लिंक नहीं: Nordlet अपने API संदर्भ में जर्नल लेनदेन के लिए create, get और list को उजागर करता है और कोई update या delete नहीं, इसलिए सुधार हमेशा संपादन के बजाय एक नया लेनदेन होता है।

रिफंड और चार्जबैक वापस लिंक करते हैं, वे कभी नहीं तैरते

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

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

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

प्रति माह नहीं, प्रति पेआउट मिलान करें

पोस्ट करने से पहले हर प्रोसेसर निपटान को विघटित करें, और एक महीने को एकत्रित करने के बजाय प्रत्येक पेआउट का मिलान करें:

सकल शुल्क (Gross charges)
− रिफंड
− प्रोसेसर शुल्क
− चार्जबैक
± रिज़र्व और समायोजन
= नेट प्रोसेसर पेआउट

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

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

सामान्य विफलता मोड

विफलता मोड (Failure mode)	यह नुकसान क्यों पहुँचाता है (Why it hurts)	नियंत्रण (Control)
सकल ग्राहक भुगतान रेवेन्यू के रूप में पोस्ट किया गया	रेवेन्यू को फुलाता है, विक्रेता की देनदारी छुपाता है	अर्जन घटना पर देय और कमीशन को विभाजित करें
केवल नेट जमा पोस्ट किया गया	सकल, शुल्क, रिफंड, रिज़र्व खो देता है	हर निपटान को विघटित करें
खर्च के रूप में बुक किया गया पेआउट	देनदारी निपटान को गलत बताता है	पेआउट पर विक्रेता देय राशि को डेबिट करें
एक विक्रेता बैलेंस फील्ड	पेंडिंग, उपलब्ध, आरक्षित, भुगतान को मिलाता है	बैलेंस राज्यों को स्पष्ट रूप से ट्रैक करें
पेआउट के समय गणना किया गया कमीशन	रेवेन्यू पेआउट शेड्यूलिंग का अनुसरण करता है	अर्जित होने पर कमीशन को पहचानें
रेवेन्यू कटौती के रूप में माना जाने वाला रिज़र्व	समय और जोखिम को अस्पष्ट करता है	होल्ड, रिलीज़, उपभोग को अलग से ट्रैक करें
नवीनतम पेआउट पर लागू रिफंड	ऑर्डर एट्रिब्यूशन को तोड़ता है	मूल लेनदेन से रिफंड लिंक करें
पोस्ट की गई प्रविष्टियों का संपादन	ऑडिट ट्रेल को नष्ट करता है	उलटें और रीपोस्ट करें
रीप्ले किए गए वेबहुक	डुप्लिकेट क्रेडिट और पेआउट	इडपोटेंसी कुंजियाँ, डुप्लिकेट पहचान
केवल राशि और तिथि पर मिलान	विभिन्न वस्तुएं टकराती हैं	पेआउट आईडी, लेनदेन आईडी, विक्रेता, मुद्रा पर मिलान करें

मैं पहले क्या करूँगा

चार्ट ऑफ़ अकाउंट्स को छूने से पहले पैसों के प्रवाह को मैप करें। भुगतान कैप्चर से लेकर रिज़र्व रिलीज़ तक हर घटना को लिखें, और चिह्नित करें कि कौन सी रेवेन्यू बनाती हैं, कौन सी देनदारी बनाती हैं, और कौन सी केवल स्थिति को स्थानांतरित करती हैं।

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

सस्पेंस बैलेंस खाली होने के साथ पहले महीने के साफ-सुथरे बंद होने के बाद ही अवधि लॉकिंग चालू करें। बहुत जल्दी लॉक करना सिर्फ गलतियों को फ्रीज करता है।

Nordlet बॉक्स से बाहर इन पंक्तियों के साथ निपटान पोस्ट करता है: प्लेटफॉर्म का कमीशन कमीशन रेवेन्यू में जाता है, विक्रेता का हिस्सा विक्रेता देय राशि में जाता है, प्रोसेसर शुल्क भुगतान-प्रसंस्करण खर्च में जाता है, और सस्पेंस खाते में अभी तक विशेषता नहीं दी गई कोई भी चीज़ जाती है। लेज़र अवधि तब तक खुली रहती है जब तक आप उन्हें स्पष्ट रूप से लॉक नहीं करते हैं, इसलिए सस्पेंस खाली होने के बाद पहले महीने को बंद किया जा सकता है। सुविधाएँ पृष्ठ (features page) सूचीबद्ध करता है कि क्या शामिल है।

FAQ

क्या खरीदार का भुगतान कभी प्लेटफॉर्म रेवेन्यू होता है?

केवल उन विशिष्ट वस्तुओं या सेवाओं के लिए जहाँ प्लेटफॉर्म प्रिंसिपल है। विक्रेता के सामान की एजेंट मार्केटप्लेस बिक्री के लिए, रेवेन्यू कमीशन है और विक्रेता का हिस्सा एक देनदारी है। एक प्लेटफॉर्म एक ही ऑर्डर में फ़ुलफ़िल्मेंट सेवा के लिए प्रिंसिपल और अंतर्निहित सामान के लिए एजेंट हो सकता है, इसलिए मूल्यांकन कंपनी के अनुसार नहीं, बल्कि निर्दिष्ट वस्तु या सेवा के अनुसार होता है।

क्या रिज़र्व को रेवेन्यू कम करना चाहिए?

नहीं। एक रिज़र्व समय और जोखिम आवंटन है, न कि रेवेन्यू समायोजन। जब आप उन्हें रखते हैं तो फंड को विक्रेता देय राशि से रिज़र्व देयता में ले जाएँ, और जब आप जारी करते हैं तो उलट दें। इस बात से रेवेन्यू और कमीशन प्रभावित नहीं होते हैं कि विक्रेता का पैसा वर्तमान में आरक्षित है या नहीं।

मैं वेबहुक पुनरप्रयासों से डुप्लिकेट पेआउट को कैसे रोकूँ?

प्रत्येक बाहरी घटना के लिए एक इडपोटेंसी कुंजी संलग्न करें, जैसे पेआउट बैचों के लिए processor:payout_id, और लिखने पर डुप्लिकेट घटनाओं का पता लगाएं। प्रदाता स्पष्ट रूप से चेतावनी देते हैं कि डुप्लिकेट वेबहुक डिलीवरी होती है, इसलिए लेज़र को इसे फिर से पोस्ट करने के बजाय दूसरे प्रयास को अस्वीकार करना होगा।

क्या विक्रेता का बैलेंस नकारात्मक हो सकता है?

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

मासिक कुल के बजाय प्रत्येक पेआउट का मिलान क्यों करें?

क्योंकि जब आप किसी महीने को एकत्रित करते हैं तो समय के अंतर और त्रुटियां रद्द हो जाती हैं, इसलिए व्यक्तिगत लेनदेन गलत होने पर भी कुल मिलान हो सकता है। पेआउट और लेनदेन आईडी पर मिलान किए गए प्रति-पेआउट मिलान, बंद होने से पहले गायब घटनाओं, डुप्लिकेट और गलत तरीके से आरोपित चार्जबैक को सतह पर लाते हैं।