Stripe Connect Marketplace Accounting Workflow

marketplace (मार्केटप्लेस) अकाउंटिंग से जुड़ी अधिकांश समस्याएं एक ही गलती से शुरू होती हैं: Stripe बैंक पेआउट (payout) को रेवेन्यू (revenue दर्ज करना। पेआउट असल में दर्जनों अलग-अलग आर्थिक लेन-देन का शुद्ध शेष (net residue) होता है, और इसे आय की एक अकेली लाइन के रूप में पोस्ट करने से प्लेटफ़ॉर्म का कमीशन, सेलर की देयता (liability), तथा उसके भीतर छिपी हर फ़ीस और विवाद (dispute) की जानकारी छिप जाती है। एक सही वर्कफ़्लो बहीखाते (ledger) में कुछ भी दर्ज करने से पहले पेआउट के इन सभी हिस्सों को अलग-अलग विभाजित करता है।

यह गाइड Stripe Connect बैलेंस-ट्रांजेक्शन की प्रत्येक श्रेणी को उसके उचित अकाउंटिंग स्थान पर पहुँचाती है: प्राप्य राशियां (receivables), कमीशन रेवेन्यू, सेलर देयताएं, प्रोसेसिंग खर्च और सस्पेंस खाता। यह Nordlet के दस्तावेजीकृत (documented) इम्पोर्ट और सेटलमेंट एंडपॉइंट्स को पोस्टिंग तंत्र के रूप में उपयोग करती है, एक उदाहरण सहित सेटलमेंट प्रक्रिया को समझाती है, और अंत में एक मिलान चेकलिस्ट (reconciliation checklist) के साथ समाप्त होती है जिसे आप हर क्लोजिंग से पहले चला सकते हैं।

कुछ भी डिज़ाइन करने से पहले Connect चार्ज मॉडल को पहचानें

जब तक आपको यह पता न हो कि प्रत्येक भुगतान प्रवाह (payment flow) कौन से चार्ज मॉडल का उपयोग करता है, तब तक अकाउंटिंग नियम नहीं लिखे जा सकते। यह मॉडल तय करता है कि किस पार्टी के Stripe बैलेंस पर चार्ज लगेगा, कौन फ़ीस का भुगतान करेगा, और रिफ़ंड तथा विवाद सबसे पहले कहाँ असर डालेंगे।

Connect मॉडल	चार्ज कहाँ बनाया जाता है	Stripe फ़ीस कौन वहन करता है	रिफ़ंड/विवाद किसे कम करते हैं	अकाउंटिंग परिणाम
डायरेक्ट चार्ज (Direct charges)	कनेक्टेड अकाउंट	प्रत्येक पार्टी के अनुसार कॉन्फ़िगर करने योग्य	कनेक्टेड अकाउंट बैलेंस	प्लेटफ़ॉर्म अपनी एप्लिकेशन फ़ीस को रेवेन्यू के रूप में दर्ज करता है; सेलर की भुगतान गतिविधि मुख्य रूप से कनेक्टेड-अकाउंट लेज़र पर रहती है
डिस्टिनेशन चार्ज (Destination charges)	प्लेटफ़ॉर्म, एक कनेक्टेड अकाउंट में तत्काल ट्रांसफर के साथ	प्लेटफ़ॉर्म	प्लेटफ़ॉर्म	प्लेटफ़ॉर्म ग्राहक की प्राप्य राशि (receivable) और Stripe फ़ीस दर्ज करता है; सेलर का हिस्सा एक पेबल (payable) है, रेवेन्यू नहीं
अलग चार्ज और ट्रांसफर (Separate charges and transfers)	प्लेटफ़ॉर्म चार्ज, फिर एक या अधिक अलग ट्रांसफर	प्लेटफ़ॉर्म	प्लेटफ़ॉर्म	चार्ज और सेलर ट्रांसफर अलग-अलग घटनाएं हैं; सेलर की देयता को ग्राहक चार्ज से स्वतंत्र रूप से ट्रैक किया जाता है

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

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

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

सिंगल रो इम्पोर्ट करने से पहले फंड के प्रवाह (flow) को मैप करें

इम्पोर्ट करने से पहले, प्रत्येक प्रवाह के लिए एक पेज का ट्रांजेक्शन मैप तैयार करें:

Customer payment
  -> Stripe charge / payment balance transaction
  -> Stripe fee
  -> platform application fee (commission)
  -> transfer to connected account
  -> refund or dispute (if applicable)
  -> Stripe payout
  -> bank receipt

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

सही Stripe सोर्स रिपोर्ट चुनें

स्वचालित-पेआउट सेटलमेंट बैचों के लिए, Stripe की Payout reconciliation, itemized रिपोर्ट का उपयोग करें। यह प्रति बैलेंस ट्रांजेक्शन एक पंक्ति देती है, पंक्तियों को reporting_category के अनुसार समूहीकृत करती है, प्रत्येक को automatic_payout_id के साथ जोड़ती है, और सकल (gross), फ़ीस तथा शुद्ध (net) कुल प्रदान करती है। Stripe की रिपोर्ट चयन गाइड इस रिपोर्ट का दस्तावेजीकरण करती है और उपलब्ध Connect फ़ील्ड के रूप में charge_id, connected_account_id, और destination_payment_id की पुष्टि करती है।

जहाँ स्वचालित पेआउट सक्षम नहीं हैं (कुछ मैनुअल-पेआउट व्यवस्थाएं), वहाँ इसके बजाय बैलेंस रिपोर्ट का उपयोग करें। डैशबोर्ड पेआउट सारांश को पोस्टिंग के लिए पर्याप्त सबूत न मानें। सारांश केवल बैच कुल को साबित करता है; केवल आइटमराइज़्ड रिपोर्ट ही घटकों को समझाती है।

Stripe पुराने type फ़ील्ड के बजाय reporting_category के अनुसार वर्गीकृत करने की अनुशंसा करता है, और प्रत्येक पंक्ति में एक source आईडी होती है जो अंतर्निहित ऑब्जेक्ट (underlying object) से जुड़ती है। समय की पाबंदी पर ध्यान दें: Stripe का कहना है कि दैनिक रिपोर्ट डेटा सामान्य रूप से अगले दिन दोपहर तक उपलब्ध हो जाता है, और त्वरित पेआउट (instant payouts) को व्यक्तिगत ट्रांजेक्शन के साथ स्पष्ट रूप से नहीं जोड़ा जा सकता है, इसलिए उन्हें अलग ट्रांजेक्शन-हिस्ट्री मिलान की आवश्यकता होती है।

श्रेणी के अनुसार प्रत्येक बैलेंस ट्रांजेक्शन को वर्गीकृत करें

प्राथमिक वर्गीकरणकर्ता के रूप में reporting_category का उपयोग करें, फिर source_id, charge_id, और विवरणों की जांच करें। महत्वपूर्ण मैपिंग इस प्रकार है:

Stripe गतिविधि	रिपोर्टिंग श्रेणी	अकाउंटिंग व्याख्या
ग्राहक चार्ज, कार्ड या स्थानीय भुगतान विधि	charge	ग्राहक-वित्तपोषित प्राप्य राशि या बिक्री सेटलमेंट
रिफ़ंड	refund	मूल ग्राहक भुगतान का उलटफेर (reversal)
Stripe द्वारा काटी गई प्रोसेसिंग फ़ीस	fee	भुगतान प्रोसेसिंग खर्च
प्लेटफ़ॉर्म एप्लिकेशन फ़ीस	platform_earning	कमीशन रेवेन्यू
रिफ़ंड की गई एप्लिकेशन फ़ीस	platform_earning_refund	कमीशन रेवेन्यू में कमी
कनेक्टेड अकाउंट में ट्रांसफर	transfer	सेलर देयता में कमी
उल्टा किया गया ट्रांसफर (Reversed transfer)	transfer_reversal	कनेक्टेड अकाउंट से रिकवरी
चार्जबैक	dispute	चार्जबैक नुकसान; स्रोत विवाद ऑब्जेक्ट की जांच करें
जीता हुआ या उलट किया गया चार्जबैक	dispute_reversal	पहले दर्ज किए गए चार्जबैक की रिकवरी
बैंक को पेआउट	payout	बैंक गतिविधि, रेवेन्यू नहीं
उल्टा किया गया पेआउट	payout_reversal	फंड्स की Stripe बैलेंस में वापसी
रोका गया रिज़र्व	connect_reserved_funds / risk_reserved_funds	प्रतिबंधित फंड, डिफ़ॉल्ट रूप से कोई खर्च नहीं
लंबे समय से चला आ रहा नेगेटिव बैलेंस कलेक्शन	connect_collection_transfer	फंडिंग या रिकवरी घटना जिसके लिए जोखिम नीति की आवश्यकता है

एक शब्दावली चेतावनी: पुराना बैलेंस-ट्रांजेक्शन type फ़ील्ड उन्हीं घटनाओं के लिए अलग-अलग लेबल का उपयोग करता है, जिनमें payment, application_fee, और adjustment शामिल हैं। Stripe का बैलेंस ट्रांजेक्शन प्रकार दस्तावेज़ीकरण दोनों शब्दावली को सूचीबद्ध करता है। किसी type मान को reporting_category नियम में न मिलाएँ, और dispute_loss जैसी कोई ऐसी श्रेणी न बनाएं जिसे Stripe एक्सपोर्ट न करता हो। यदि किसी एक्सपोर्ट में ऐसा लेबल है जिसे आप नहीं पहचानते हैं, तो एक्सपोर्ट किए गए मान को सुरक्षित रखें और स्रोत ऑब्जेक्ट के मुकाबले इसकी पुष्टि करें।

सामान्य मार्केटप्लेस गतिविधि को लेज़र में पोस्ट करें

डिस्टिनेशन चार्ज या अलग चार्ज और ट्रांसफर पर काम करने वाले प्लेटफ़ॉर्म के लिए, वैचारिक प्रविष्टियाँ (conceptual entries) ये हैं।

ग्राहक चार्ज (ग्राहक का पैसा Stripe क्लियरिंग बैलेंस में प्रवेश करता है):

Dr Stripe clearing        Gross customer charge
    Cr Trade receivables   Gross customer charge

Stripe प्रोसेसिंग फ़ीस:

Dr Stripe fee expense      Stripe fee
    Cr Stripe clearing     Stripe fee

जब तक आपकी अकाउंटिंग नीति स्पष्ट रूप से मांग और समर्थन न करे, तब तक रेवेन्यू में से Stripe फ़ीस को नेट (net) न करें।

प्लेटफ़ॉर्म कमीशन (आपका रेवेन्यू, जो सेलर को देय राशि में से काटा जाता है):

Dr Seller payable          Commission amount
    Cr Commission revenue   Commission amount

सेलर ट्रांसफर (देय राशि का निपटान, कोई खर्च नहीं):

Dr Seller payable          Transfer amount
    Cr Stripe clearing      Transfer amount

ट्रांसफर कभी भी अपने आप में कोई खर्च नहीं होता है। चार्ज आते ही सेलर का हिस्सा एक देयता (liability) बन जाता है, और ट्रांसफर उस देयता को चुका देता है। Nordlet के सेटलमेंट पोस्टिंग नियम इस प्रकार हैं: platform_earning पंक्तियाँ कमीशन रेवेन्यू में पोस्ट होती हैं जबकि transfer पंक्तियाँ सेलर की देयता को कम करती हैं। Nordlet API में पोस्टिंग नियमों के माध्यम से प्रत्येक कंपनी के लिए डिफ़ॉल्ट पोस्टिंग कुंजियाँ settlements.commissionRevenue (डिफ़ॉल्ट 5001), settlements.sellerPayable (डिफ़ॉल्ट 4499), settlements.fees (डिफ़ॉल्ट 6800), और settlements.suspense (डिफ़ॉल्ट 4440) हैं, जिन्हें बदला जा सकता है।

मूल बिक्री के मुकाबले रिफ़ंड संभालें, न कि ढीली बैंक मदों के रूप में

एक रिफ़ंड मूल चार्ज या इनवॉइस से जुड़ता है। वैचारिक रूप से:

Dr Refunds / sales reversals    Refund amount
    Cr Trade receivables         Refund amount

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

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

विवादों (Disputes) को रिफ़ंड से अलग मानें

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

प्लेटफ़ॉर्म की तरफ से हारा हुआ विवाद:

Dr Chargeback loss / receivable reopened   Disputed amount
Dr Dispute-fee expense                      Dispute fee
    Cr Stripe clearing                      Combined amount

यदि सेलर नुकसान उठाता है और रिकवरी की पुष्टि हो जाती है:

Dr Seller payable / recovery account   Recoverable amount
    Cr Chargeback recovery              Recoverable amount

केवल इसलिए सेलर रिकवरी बुक न करें क्योंकि ट्रांसफर रिवर्सल का अनुरोध किया गया था। सत्यापित करें कि रिवर्सल बनाया गया था, सफल रहा, और Stripe बैलेंस में दिखाई देता है। यदि विवाद जीत लिया जाता है, तो Stripe dispute_reversal पंक्ति के माध्यम से विवादित राशि वापस कर देता है; चार्जबैक नुकसान को उलट दें और किसी भी विवाद शुल्क को अलग से संभालें जिसे Stripe वापस नहीं करता है। Nordlet उसी फ़ाइल से या पहले के इम्पोर्ट से पहले से मिलान किए गए चार्ज के charge_id का उपयोग करके चार्जबैक पंक्तियों का मिलान करता है।

सेटलमेंट का एक काम किया हुआ उदाहरण

एक स्वचालित पेआउट बैच लें। आइटमराइज़्ड रिपोर्ट में शामिल हैं:

• एक charge पंक्ति: सकल 100.00, Stripe फ़ीस 3.20, शुद्ध 96.80
• एक platform_earning पंक्ति: 15.00, प्लेटफ़ॉर्म का कमीशन
• एक transfer पंक्ति: कनेक्टेड सेलर को 81.80
• पिछली बिक्री से एक refund पंक्ति: सकल 20.00, इस बैच में सेटल हो रही है
• एक payout पंक्ति: बैंक में जाने वाला बैच टोटल

Stripe की सेटलमेंट पहचान के बाद, पेआउट की संरचना:

Gross charges                100.00
- refunds                     20.00
- Stripe fees                  3.20
- transfers                   81.80
= net to platform balance     -5.00

platform_earning पंक्ति दूसरी बार पैसे नहीं ले जाती है। यह उस 15.00 को नाम देती है जो फ़ीस और सेलर ट्रांसफर के बाहर होने के बाद प्लेटफ़ॉर्म बैलेंस में रहता है, ताकि प्लेटफ़ॉर्म इसका अनुमान लगाने के बजाय कमीशन रेवेन्यू को पहचान सके।

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

Nordlet के सेटलमेंट एंडपॉइंट के माध्यम से इम्पोर्ट और पोस्ट करें

पेआउट-स्तरीय मिलान के लिए, उपयोग करें:

POST /v1/bank/settlements/import

Stripe प्रदाता और आइटमराइज़्ड CSV के साथ। Nordlet पंक्तियों को automatic_payout_id द्वारा समूहीकृत करता है, प्रत्येक पेआउट को सकल, फ़ीस और शुद्ध कुल के साथ एक सेटलमेंट बैच में बदलता है, पहले से पोस्ट किए गए पेआउट के पुनः-इम्पोर्ट को छोड़ देता है, सेटलमेंट संरचना से payout पंक्तियों को छोड़ देता है, और ऑर्डर, इनवॉइस, PaymentIntent, चार्ज, सोर्स, या मेटाडेटा संदर्भों का उपयोग करके चार्ज, रिफ़ंड और विवाद पंक्तियों का ऑटो-मिलान करता है। Stripe आइटमराइज़्ड रिपोर्ट को प्रति अनुभाग एक फ़ाइल में विभाजित करता है, इसलिए चार्ज, रिफ़ंड और फ़ीस फ़ाइलों को एक साथ इम्पोर्ट करें: जो पंक्तियाँ ऐसे पेआउट से संबंधित हैं जो पहले से इम्पोर्ट किया गया है लेकिन अभी तक पोस्ट नहीं किया गया है, वे मौजूदा बैच में मिल जाती हैं। यह फ़ाइलों और सेटलमेंट एंडपॉइंट्स द्वारा संचालित एक इम्पोर्ट-एंड-पोस्ट वर्कफ़्लो है, न कि कोई लाइव Stripe कनेक्टर; सुविधाएँ पेज सूचीबद्ध करता है कि बैंक और सेटलमेंट पक्ष क्या कवर करता है।

क्रम में मिलान करें: इनवॉइस से चार्ज, मूल चार्ज से रिफ़ंड, मूल चार्ज से विवाद, कमीशन उपचार से कमीशन पंक्तियाँ। Stripe फ़ीस, समायोजन, रिज़र्व और पेआउट पंक्तियों को इनवॉइस मिलान से बाहर रखें। Nordlet की भुगतान मिलान शब्दावली (payment reconciliation glossary) बताती है कि फ़ीस और समायोजन लाइनों को डिज़ाइन द्वारा इनवॉइस से मिलाया नहीं जा सकता; अनसुलझे पैसे ले जाने वाले आइटम को सस्पेंस में भेजें। मैनुअल सुधार bank/settlements/match { lineId, invoiceId } का उपयोग करता है, जिसमें अनमैच करने के लिए null invoiceId होता है।

फिर एक संतुलित बैच पोस्ट करें:

POST /v1/bank/settlements/post

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

मिलान चेकलिस्ट (Reconciliation checklist)

प्रत्येक क्लोजिंग से पहले इन दावों (assertions) को चलाएं:

• कोई डुप्लीकेट balance_transaction_id नहीं
• कोई डुप्लीकेट (provider, payout_id) सेटलमेंट बैच नहीं
• लाइन net का योग बैच नेट के बराबर है
• बैच नेट बैंक पेआउट के बराबर है, समय और मुद्रा नीति के अधीन
• प्रत्येक रिफ़ंड का एक मूल चार्ज या एक लॉग किया गया अपवाद है
• प्रत्येक विवाद का एक विवाद या चार्ज संदर्भ है
• प्रत्येक ट्रांसफर की एक कनेक्टेड-अकाउंट आईडी है
• प्रत्येक platform_earning पंक्ति का एक परिभाषित कमीशन उपचार है
• सस्पेंस शून्य या पूरी तरह से समीक्षित है, जिसमें पोस्टिंग चेतावनी में नामित कोई भी अपरिचित श्रेणियां शामिल हैं
• स्वीकृत अग्रिम या रिकवरी नीति के बिना सेलर पेबल नेगेटिव नहीं है
• पोस्ट किए गए बैचों को चुपचाप से फिर से इम्पोर्ट या रीपोस्ट नहीं किया जा सकता है
• कंपनी की मूल मुद्रा के अलावा किसी अन्य मुद्रा में पेआउट पेआउट-तारीख की दर से रूपांतरित होता है, प्रत्येक इनवॉइस की अपनी दर के मुकाबले अंतर को वास्तविक विनिमय लाभ या हानि के रूप में बुक किया जाता है; मुद्रा मिलाने वाला पेआउट इम्पोर्ट पर अस्वीकार कर दिया जाता है

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

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

FAQ

क्या Stripe पेआउट प्लेटफ़ॉर्म का रेवेन्यू है?

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

मुझे किस Stripe रिपोर्ट के मुकाबले मिलान करना चाहिए?

Payout reconciliation, itemized रिपोर्ट, क्योंकि यह reporting_category, automatic_payout_id, और सकल, फ़ीस तथा शुद्ध राशियों के साथ प्रति बैलेंस ट्रांजेक्शन एक पंक्ति देती है। एक डैशबोर्ड पेआउट सारांश केवल बैच कुल को साबित करता है। जहाँ स्वचालित पेआउट सक्षम नहीं हैं, वहाँ इसके बजाय बैलेंस रिपोर्ट का उपयोग करें।

क्या सेलर को किए गए ट्रांसफर को खर्च के रूप में बुक किया जाना चाहिए?

नहीं। ग्राहक चार्ज आते ही सेलर का हिस्सा एक देयता बन जाता है, और ट्रांसफर उस देयता को चुका देता है। ट्रांसफर को खर्च के रूप में बुक करने से लागत की दोहरी गिनती (double-counts) होती है और सेलर पेबल स्थायी रूप से बढ़ा हुआ रहता है।

Stripe की उस पंक्ति का क्या होता है जिसकी श्रेणी इम्पोर्टर को पहचान नहीं है?

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

बाद के पेआउट में सेटल होने वाले रिफ़ंड को कैसे संभाला जाता है?

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

आगे की पढाई

• बैंक और पेमेंट इम्पोर्ट, जिसमें Stripe सेटलमेंट मिलान शामिल है
• भुगतान मिलान: PSP पेआउट को लेज़र से मिलाना
• मार्केटप्लेस सेलर सबलेज़र: रेवेन्यू बनाम पेबल्स
• Connect इंटीग्रेशन में चार्ज कैसे काम करते हैं (Stripe)