ई-कॉमर्स में रिफंड और रिटर्न का हिसाब कैसे रखें

रिफंड एक नकारात्मक बिक्री नहीं है। यह चार अलग-अलग लेखांकन घटनाएं हैं जो एक ही कोट पहने हुए हैं।

---

यह जनवरी का दूसरा हफ्ता है। Q4 आपका सबसे अच्छा तिमाही था — अकेले दिसंबर में पिछले साल के पूरे पहले छमाही से अधिक राजस्व हुआ। फिर रिटर्न विंडो खुल गई।

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

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

यहाँ सहज ज्ञान है, सीधे शब्दों में कहा गया है: "एक रिफंड सिर्फ एक नकारात्मक बिक्री है। इसे घटाएं और आगे बढ़ें।"

यह झूठ है। यह सही लगता है क्योंकि ग्राहक का अनुभव सममित है — पैसा अंदर, पैसा बाहर। लेकिन आपकी किताबें ग्राहक के अनुभव को रिकॉर्ड नहीं कर रही हैं। वे चार अलग-अलग वित्तीय घटनाओं को रिकॉर्ड कर रही हैं, और एक रिफंड प्रत्येक को अलग तरह से उलट देता है। कुछ पूरी तरह से, कुछ आंशिक रूप से, और एक बिल्कुल भी नहीं।

ई-कॉमर्स में रिफंड का हिसाब कैसे रखें: एक रिफंड, चार लेजर

आइए इसे एक स्पष्ट रूप से काल्पनिक आदेश के साथ ठोस बनाते हैं।

दिसंबर में, एक ग्राहक ने कुल $120 में एक जैकेट खरीदा: उत्पाद के लिए $112, बिक्री कर में $8। आपके प्रोसेसर ने आपसे बिक्री पर $3.50 की प्रोसेसिंग फीस ली। जैकेट की लागत आपको थोक में $45 थी, जिसे आपने बेचे गए माल की लागत के रूप में दर्ज किया।

जनवरी में, ग्राहक इसे वापस कर देता है। यहाँ वह है जो वास्तव में आपकी किताबों में होना चाहिए।

1. राजस्व: कॉन्ट्रा-रेवेन्यू, आय हटाई नहीं गई

आपकी पहली प्रवृत्ति मूल बिक्री को हटाने या कम करने की हो सकती है। ऐसा न करें। वह दिसंबर की बिक्री वास्तव में हुई थी — इसे मिटाने से आपका सकल राजस्व आंकड़ा, आपकी रिफंड-दर दृश्यता और आपका ऑडिट ट्रेल नष्ट हो जाता है।

इसके बजाय, $112 को एक कॉन्ट्रा-राजस्व खाते में दर्ज किया जाता है — जिसे आमतौर पर "रिफंड और रिटर्न" या "बिक्री रिटर्न और भत्ते" कहा जाता है — जो आय के अंतर्गत आता है और इसका डेबिट बैलेंस होता है। सकल राजस्व बरकरार रहता है, वापसी अपने स्वयं के लाइन के रूप में दिखाई देती है, और शुद्ध राजस्व अंतर होता है। अब आप देख सकते हैं कि आपके स्टोर ने $112 की बिक्री की और $112 की वापसी की, जो "$0 हुआ" की जानकारी से बहुत अलग जानकारी है।

2. प्रोसेसिंग फीस: वह पैसा जो वापस नहीं आता

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

इसलिए ग्राहक को अपने पूरे $120 वापस मिल जाते हैं, लेकिन दिसंबर से आपका $3.50 शुल्क व्यय बना रहता है। इसे उलटने के लिए कोई प्रविष्टि नहीं है — शुल्क बस एक वास्तविक लागत के रूप में आपकी किताबों में बना रहता है। जिसका अर्थ है कि प्रत्येक वापसी चुपचाप आपको पैसे खर्च करती है, और वापसी-भारी सप्ताह के दौरान भुगतान "बिक्री घटा वापसी" की भविष्यवाणी से कम होगा। वह अंतर कोई त्रुटि नहीं है। यह शुल्क है।

3. बिक्री कर: देनदारी को रिवर्स करना, आय को नहीं

$8 की बिक्री कर कभी भी आपका पैसा नहीं था। जब आपने इसे एकत्र किया, तो यह एक बिक्री कर देय देयता खाते में चला गया — आप इसे राज्य के लिए रख रहे थे।

जब आप ऑर्डर वापस करते हैं, तो उस देयता को उलटना पड़ता है: बिक्री कर देय $8 डेबिट करें, ताकि आप अब इसके ऋणी न रहें। इस चरण को छोड़ दें और आप एक ऐसी बिक्री पर कर जमा करेंगे जो अब मौजूद नहीं है। राज्य उस पैसे को वापस देने के बारे में प्रसिद्ध रूप से शिथिल हैं, इसलिए इसे पहले स्थान पर न भेजना बहुत बेहतर है।

4. इन्वेंट्री और COGS: केवल तभी जब माल बेचने योग्य वापस आए

यदि जैकेट बेचने योग्य स्थिति में वापस आती है, तो आप लागत पक्ष को उलट देते हैं: इन्वेंट्री $45 डेबिट करें, बेचे गए माल की लागत $45 क्रेडिट करें। जैकेट फिर से एक संपत्ति है।

यदि यह क्षतिग्रस्त, पहना हुआ वापस आता है, या बिल्कुल भी वापस नहीं आता है, तो आप कोई उलटफेर नहीं करते हैं — $45 COGS में उस लेनदेन की वास्तविक लागत के रूप में बना रहता है। यह एक निर्णय कॉल है जिसे सॉफ़्टवेयर आपके लिए पूरी तरह से नहीं कर सकता है, यही कारण है कि आपकी वापसी प्रक्रिया को एक "बेचने योग्य या नहीं" चेकपॉइंट की आवश्यकता है जो आपकी बहीखाता पद्धति को फीड करता है।

यहां हमारे $120 की वापसी के लिए पूरी तस्वीर है, यह मानते हुए कि जैकेट बेचने योग्य है:

पैर	खाता	डेबिट	क्रेडिट
राजस्व	रिफंड और रिटर्न (कॉन्ट्रा-राजस्व)	$112.00
बिक्री कर	बिक्री कर देय	$8.00
नकद निकालें	भुगतान प्रोसेसर क्लियरिंग खाता		$120.00
इन्वेंटरी	इन्वेंटरी	$45.00
बेचे गए माल की लागत	बेचे गए माल की लागत		$45.00

और शुल्क? इस प्रविष्टि में कहीं नहीं — मूल $3.50 ठीक वहीं रहता है जहाँ दिसंबर ने इसे रखा था। शुद्ध परिणाम: आप नकद में $120 खो देते हैं, आप हमेशा के लिए शुल्क में $3.50 खो देते हैं, और आपको $45 की जैकेट वापस मिल जाती है। एक वापसी वास्तव में यही है।

[छवि: एक वापसी को चार तीरों में विभाजित करते हुए एक आरेख — राजस्व, शुल्क, बिक्री कर, इन्वेंट्री — प्रत्येक एक अलग खाते में उतर रहा है]

जनवरी में होने वाले विशेष मामले

स्वच्छ चार-पैर वाला संस्करण एकल-आइटम ऑर्डर पर पूर्ण वापसी को कवर करता है। वास्तविक जनवरी अधिक अव्यवस्थित होते हैं। यहां वह वापसी लेखांकन है जिसका सामना ईकॉमर्स स्टोर वास्तव में करते हैं।

आंशिक रिफंड

$120 के ऑर्डर में से $40 वापस करें और प्रत्येक पैर आनुपातिक रूप से स्केल होता है — आंशिक कॉन्ट्रा-राजस्व, आंशिक बिक्री कर उलट — इन्वेंट्री को छोड़कर, जो आमतौर पर बिल्कुल भी नहीं चलता है, क्योंकि आंशिक वापसी का मतलब आमतौर पर ग्राहक ने माल रखा है। देर से डिलीवरी पर $40 का अनुनय वापसी राजस्व, कर और नकदी को छूती है। यह कभी भी COGS को नहीं छूती है।

क्रॉस-पीरियड रिफंड: दिसंबर की बिक्री, जनवरी में रिफंड की गई

जनवरी की किताबों के "ब्रेक" का यह सबसे बड़ा कारण है। बिक्री दिसंबर में होती है; वापसी जनवरी में होती है। आप उन्हें एक-दूसरे के विरुद्ध नेट करने के लिए दिसंबर को फिर से नहीं खोलते हैं — वापसी एक जनवरी की घटना है, जिसे जनवरी के प्रति-राजस्व में दर्ज किया जाता है।

परिणाम: जनवरी का शुद्ध राजस्व खराब दिखता है, क्योंकि यह दिसंबर की बिक्री के बिना दिसंबर की मात्रा से रिटर्न ले जा रहा है। यह कोई बहीखाता त्रुटि नहीं है। यह वास्तविकता है, और इसे स्पष्ट रूप से देखना ही लक्ष्य है। इसका मतलब यह भी है कि आपके दिसंबर के नंबर थोड़े अधिक हैं जो आपने अंततः रखे — जनवरी की इन्वेंट्री दांव लगाने से पहले याद रखने योग्य है जो Q4 की शीर्ष पंक्ति पर आधारित है।

चार्जबैक बनाम रिफंड

चार्ज-बैक रवैये के साथ वापसी नहीं है — यह एक अलग तंत्र है। ग्राहक का बैंक प्रोसेसर के माध्यम से पैसे वापस ले लेता है, आप पर आमतौर पर ऊपर से विवाद शुल्क लिया जाता है (जो, वापसी के विपरीत, आप केवल तभी वापस पा सकते हैं जब आप जीत जाते हैं), और यह सब हफ्तों तक अनसुलझा रह सकता है।

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

पूर्ण विवाद जीवनचक्र और हार बनाम जीत के लिए सटीक प्रविष्टियों के लिए, हमारी चार्ज-बैक लेखांकन मार्गदर्शिका देखें।

रद्दीकरण एक तीसरी प्रजाति है, और यह देखना उचित है कि सिंक सॉफ़्टवेयर अंतर को कैसे मॉडल करता है। लेजरपोर्ट में, "रद्द किए गए ऑर्डर के लिए QB ऑर्डर रद्द करें" सेटिंग तब क्विकबुक्स लेनदेन को रद्द कर देती है जब पहले से सिंक किया गया ऑर्डर रद्द हो जाता है — एक शून्य, न कि विलोपन और न ही वापसी, इसलिए रिकॉर्ड आपके ऑडिट ट्रेल के लिए बना रहता है जबकि राजस्व बाहर निकल जाता है; वे ऑर्डर जो कभी सिंक होने से पहले रद्द हो जाते हैं, उन्हें बस छोड़ दिया जाता है। इसके विपरीत, एक वापसी हमेशा मूल बिक्री के विरुद्ध एक जुड़ा हुआ उलटा दस्तावेज़ उत्पन्न करती है। और यदि आप नकद वापस करने के बजाय स्टोर क्रेडिट जारी करते हैं, तो वह एक चौथी घटना है: गिफ्ट कार्ड और स्टोर क्रेडिट को राजस्व के रूप में नहीं, बल्कि देनदारियों के रूप में दर्ज किया जाता है — वही तर्क जैसा कि ऊपर बिक्री कर खंड में है, उस माल पर लागू होता है जो आप अब बकाया हैं।

रीस्टॉकिंग फीस

यदि आप 10% रीस्टॉकिंग शुल्क लेते हैं, तो आप हमारे $120 के ऑर्डर पर $108 वापस करते हैं, लेकिन प्रति-राजस्व प्रविष्टि अभी भी पूर्ण उत्पाद राशि पर आधारित होती है — $12 जो आपने रखे थे, वह अपनी आय लाइन (रीस्टॉकिंग शुल्क आय) के रूप में दर्ज किया जाता है या वापसी की कमी के रूप में। किसी भी तरह से, इसे "पर्याप्त" वापसी राशि में चुपचाप गायब न होने दें, क्योंकि यह आपके वापसी कुल और आपके नकद-आउट कुल के बीच का अंतर है जो हमेशा मेल खाता है।

वह संरचना जो इसे व्यवस्थित रखती है

आप जनवरी में एक बार में एक प्रविष्टि के साथ वापसी लेखांकन को ठीक नहीं करते हैं। आप इसे संरचना के साथ ठीक करते हैं, एक बार सेट करते हैं। तीन भाग:

एक समर्पित प्रति-राजस्व खाता। यदि रिफंड वर्तमान में आपकी आय पंक्ति को अदृश्य रूप से कम कर रहे हैं, तो आय के तहत "रिफंड और रिटर्न" बनाएं और हर रिफंड को वहां रूट करें। आपका P&L तुरंत आपको आपकी रिफंड दर बताना शुरू कर देता है — अधिकांश स्टोर मालिक संख्या से आश्चर्यचकित होते हैं।

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

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

ऑटोमेशन इसे कहाँ उठाता है

उपरोक्त सब कुछ हाथ से किया जा सकता है। यह ठीक उसी तरह का दोहराव वाला, एक साथ चार-चीजों वाला काम है जो सॉफ्टवेयर को करना चाहिए, और यहीं पर एक सिंक टूल अपनी कीमत वसूलता है।

LedgerPort की रिफंड हैंडलिंग Shopify और WooCommerce स्टोर के लिए इस संरचना को स्वचालित रूप से लागू करती है: रिफंड बिक्री को ओवरराइट करने के बजाय एक प्रति-राजस्व खाते में पोस्ट होते हैं, बिक्री कर उलट की गणना प्रति रिफंड की जाती है, बिना रिटर्न वाले प्रसंस्करण शुल्क अलग रखे जाते हैं ताकि भुगतान अभी भी मेल खाते हों, और क्रॉस-पीरियड रिफंड सही महीने में बिना आपके बंद खातों को छुए आते हैं। स्केल प्लान पर, भुगतान जर्नल में शुल्क और रिफंड पहले से ही अलग-अलग होते हैं — मूल्य निर्धारण मुफ्त से शुरू होता है, सशुल्क प्लान $25/माह से और 14-दिन की मनी-बैक गारंटी के साथ।

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

इसे चालू करना एक सेटिंग है: सिंक कॉन्फ़िगरेशन » ऑर्डर के तहत, भुगतान-स्थिति ट्रिगर के रूप में रिफंडेड, आंशिक रूप से रिफंडेड, या दोनों की जाँच करें।

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

WooCommerce पर: रिफंड प्रति-गेटवे प्लंबिंग होते हैं

ऊपर दी गई कहानी Shopify एडिशन है। WooCommerce पर, रिफंड अपने आप में एक फर्स्ट-क्लास सिंक एंटिटी हैं: LedgerPort प्लगइन एक समर्पित refund.created वेबहुक रजिस्टर करता है, इसलिए रिफंड जारी करने से ऑर्डर में एडिट से अनुमान लगाने के बजाय अपना सिंक इवेंट फायर होता है। और क्योंकि अलग-अलग गेटवे रिफंड को अलग-अलग तरीके से सेटल करते हैं, रिफंड सिंक को सिंक कॉन्फ़िगरेशन » भुगतान में प्रति गेटवे कॉन्फ़िगर किया गया है: आपके स्टोर में LedgerPort द्वारा पता लगाया गया प्रत्येक भुगतान गेटवे अपने स्वयं के रिफंड-सक्षम टॉगल, अपने स्वयं के क्लियरिंग खाते और अपने स्वयं के रिफंड संदर्भ नंबरिंग — एक प्रीफिक्स/सफिक्स प्रारूप या WooCommerce रिफंड आईडी — प्राप्त करता है, ताकि QuickBooks में प्रत्येक रिफंड उसे बनाने वाले सटीक स्टोर इवेंट का पता लगा सके।

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

एक ईमानदार चेतावनी: कोई भी टूल आपको यह नहीं बता सकता कि लौटाया गया जैकेट बेचा जा सकता है या नहीं। इन्वेंट्री लेग को अभी भी रिटर्न डेस्क पर एक मानव निर्णय की आवश्यकता होती है। ऑटोमेशन जो हटाता है वह उस निर्णय के बाद सब कुछ है।

रिफंड कभी भी मजेदार नहीं होते। लक्ष्य वह नहीं है।

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

जो बदलता है वह यह है कि चुभन पठनीय हो जाती है। भुगतान मेल खाता है। कर देनदारी सही है। दिसंबर बंद रहता है। रिफंड दर आपके पेट में एक बुरी भावना के बजाय एक रिपोर्ट पर एक संख्या है। रिफंड संकट होने से बोरिंग होने तक जाते हैं — और बुककीपिंग में बोरिंग होना ही लक्ष्य है।

यदि आपका जनवरी वर्तमान में इस पोस्ट के शीर्ष पर दिखाई देने वाले की तरह दिख रहा है — भुगतान कम हो रहा है, दिसंबर की वापसी जनवरी को परेशान कर रही है, शुल्क गायब हो गए हैं — तो चार-पैर वाली संरचना ही समाधान है, और आप इसे अगले वापसी लहर से पहले चला सकते हैं। LedgerPort के साथ मुफ्त में शुरुआत करें और इसे आपके लिए अगले वापसी को सही ढंग से बुक करने दें →