शृंखला, एक-एक दस्तावेज़ करके
लीड-टू-कैश कोई रूपक नहीं है। यह दस्तावेज़ों का एक क्रम है, जिनमें से हर एक का जनरल लेज़र पर एक परिभाषित प्रभाव होता है, और उनमें से अधिकांश का कोई प्रभाव होता ही नहीं। किसका क्या प्रभाव है, इस पर भ्रम ही वह जगह है जहाँ से पैसा रिसता है।
लीड रुचि का एक रिकॉर्ड है। अवसर (opportunity) एक पूर्वानुमान ऑब्जेक्ट है, जिस पर किसी व्यक्ति ने अपेक्षित मूल्य और संभावना जोड़ी है। दोनों में से कोई लेज़र को नहीं छूता, और छूना भी नहीं चाहिए। कोटेशन एक प्रस्ताव है: वह मूल्य, दायरा और वैधता तय करता है, और हो सकता है कि वह कुछ भी आरक्षित न करे। सेल्स ऑर्डर ग्राहक द्वारा उस प्रस्ताव की स्वीकृति है। यह दोनों पक्षों की प्रतिबद्धता है और अक्सर ख़रीद, शेड्यूलिंग या उत्पादन का ट्रिगर भी, लेकिन यह अब भी कोई लेखा प्रविष्टि नहीं है। न राजस्व, न प्राप्य।
डिलीवरी या सेवा का पूरा होना वह घटना है जो आम तौर पर सबसे अधिक मायने रखती है, क्योंकि यहीं माल या सेवा का नियंत्रण हस्तांतरित होता है। इनवॉइस मान्यता का बिंदु है: यह प्राप्य खाते (accounts receivable) को डेबिट करता है, राजस्व को क्रेडिट करता है और आउटपुट टैक्स की देयता बनाता है। रसीद प्राप्य को नकद या बैंक के सामने चुकता करती है; वह कोई राजस्व मान्य नहीं करती, केवल पहले से मौजूद ऋण का निपटान करती है। क्रेडिट नोट इनवॉइस के कुछ हिस्से या पूरे इनवॉइस को रिवर्स करता है, और जहाँ टैक्स लगाया गया था, उसे भी रिवर्स करता है।
यही इस सिद्धांत का व्यावहारिक रूप है कि ऑर्डर बिल नहीं होते। केवल लेज़र में पोस्ट हुए दस्तावेज़ों का भुगतान होता है, उन्हीं की वसूली के लिए फ़ॉलो-अप होता है, और वही एजिंग में दिखते हैं। अगर कोई सिस्टम किसी को सेल्स ऑर्डर के सामने भुगतान लगाने देता है, या ऑर्डर मूल्य को मान्य राजस्व के साथ एक ही कॉलम में रिपोर्ट करता है, तो उसने महीने का समापन शुरू होने से पहले ही शृंखला तोड़ दी है।
- लीड और अवसर: पाइपलाइन रिकॉर्ड, लेज़र पर कोई प्रभाव नहीं।
- कोटेशन: वैधता अवधि वाला मूल्य-युक्त प्रस्ताव, लेज़र पर कोई प्रभाव नहीं।
- सेल्स ऑर्डर: पारस्परिक प्रतिबद्धता, लेज़र पर कोई प्रभाव नहीं, लेकिन यह स्टॉक, ख़रीद और शेड्यूलिंग को चलाता है।
- डिलीवरी नोट या सेवा साइन-ऑफ़: नियंत्रण हस्तांतरण का साक्ष्य, इससे इन्वेंटरी और बिक्री लागत में हलचल हो सकती है।
- इनवॉइस: प्राप्य डेबिट, राजस्व क्रेडिट, आउटपुट टैक्स दर्ज। मान्यता यहीं होती है।
- रसीद: नकद या बैंक डेबिट, प्राप्य क्रेडिट। यह निपटान है, राजस्व नहीं।
- क्रेडिट नोट: इनवॉइस मूल्य और टैक्स को रिवर्स करता है, और मूल दायित्व को बहाल करता है या बट्टे खाते में डालता है।
अलगाव की असली क़ीमत
जब CRM एक सिस्टम हो और लेज़र दूसरा, तो पहले दिन कुछ नाटकीय नहीं होता। नुक़सान उन छोटे-छोटे मिलानों में होता है जो लोग चुपचाप हाथ से करते हैं और फिर करना छोड़ देते हैं।
ग्राहक मास्टर डेटा दोबारा टाइप होता है, तो एक ही ख़रीदार दो स्पेलिंग और दो भुगतान शर्तों के साथ दो बार मौजूद रहता है। CRM में कोटेशन पर मोलभाव करके क़ीमत घटाई जाती है और इनवॉइस पुरानी प्राइस लिस्ट से बनता है, तो या तो ग्राहक विवाद करता है या किसी को उसे ठीक करने के लिए क्रेडिट नोट जारी करना पड़ता है। सेल्स मैनेजर द्वारा स्वीकृत छूट केवल CRM के किसी ऐसे फ़ील्ड में होती है जिसे इनवॉइसिंग स्क्रीन कभी पढ़ती ही नहीं। कमीशन इनवॉइस और वसूल हुए मूल्य के बजाय बुक किए गए ऑर्डर मूल्य पर गिना जाता है, यानी कंपनी ऐसे राजस्व पर कमीशन देती है जिसे उसने मान्य नहीं किया और कभी-कभी जो वसूल भी नहीं होगा। सेल्स तिमाही का एक आँकड़ा बताता है, फ़ाइनेंस दूसरा, और बैठक उस अंतर पर कार्रवाई करने के बजाय उसे समझाने में बीत जाती है।
इन सबकी जड़ एक ही है: एक सिस्टम में एक बार दर्ज किया गया मूल्य, जिसे हाथ से या इंपोर्ट से दूसरे सिस्टम में दोबारा दर्ज किया जाता है। हटाना दोबारा प्रविष्टि की प्रक्रिया को है, विसंगति को नहीं।
एक ग्राहक रिकॉर्ड, और प्राप्य विभाग को इसकी सबसे पहले परवाह क्यों
डुप्लिकेट ग्राहक को आम तौर पर सेल्स की साफ़-सफ़ाई की समस्या बताया जाता है। असल में यह सबसे पहले प्राप्य खातों (accounts receivable) की समस्या है। क्रेडिट एक्सपोज़र हर रिकॉर्ड के हिसाब से गिना जाता है, इसलिए दो रिकॉर्ड का मतलब है कि क्रेडिट लिमिट बिना किसी की स्वीकृति के प्रभावी रूप से दोगुनी हो गई। एजिंग दोनों में बँट जाती है, इसलिए कोई भी इतना बुरा नहीं दिखता कि उसकी वसूली के पीछे पड़ा जाए। भुगतान एक ही रेमिटेंस के रूप में आते हैं जो दो खातों में रखे इनवॉइसों को कवर करते हैं, और उनका आवंटन हाथ से करना पड़ता है।
ग्राहक रिकॉर्ड में वे फ़ील्ड होने चाहिए जिन पर दोनों विभाग निर्भर हैं, एक बार रखे हुए और दोनों द्वारा पढ़े जाने वाले: क़ानूनी नाम और व्यापारिक नाम, टैक्स पंजीकरण संख्या, क्रेडिट लिमिट, भुगतान शर्तें, निर्धारित प्राइस लिस्ट, मुद्रा, बिलिंग और डिलीवरी पते, और वसूली के लिए संपर्क व्यक्ति, जो हमेशा ख़रीद करने वाला संपर्क नहीं होता। सऊदी अरब और व्यापक खाड़ी क्षेत्र में टैक्स पंजीकरण संख्या कोई औपचारिकता नहीं है; यह अनुपालक टैक्स इनवॉइस का अनिवार्य फ़ील्ड है, और ग़लत या ख़ाली संख्या के साथ बना इनवॉइस फ़ॉर्मेटिंग की नहीं, अनुपालन की समस्या है।
क्रेडिट नियंत्रण, वादा किए जाने से पहले
लेज़र पहले से जानता है कि ग्राहक पर कितना बकाया है और वह कितना पुराना है। इनवॉइस पोस्ट होते ही एजिंग मौजूद होती है। प्रश्न यह है कि क्या सेल्सपर्सन उसे उस क्षण देख पाता है जब वह उसके व्यवहार को बदल सकती है, यानी शर्तें पेश करने से पहले, फ़ाइनेंस के उन्हें ठुकराने के बाद नहीं।
जिस पैटर्न से बचना है वह जाना-पहचाना है: कई इनवॉइस की नियत तारीख़ पार कर चुके ग्राहक को विस्तारित शर्तों का प्रस्ताव मिलता है, सौदा उसी आधार पर बंद होता है, और फिर फ़ाइनेंस के सामने दो ही रास्ते बचते हैं: शर्तें वापस लेकर संबंध बिगाड़ना, या ऐसा एक्सपोज़र स्वीकार करना जिसे किसी ने स्वीकृत नहीं किया। उस समय दोनों में से कोई भी परिणाम फ़ाइनेंस का निर्णय नहीं है; यह इस बात का परिणाम है कि सेल्सपर्सन को बकाया दिखाया ही नहीं गया।
जब सिस्टम एक ही हो तो यह व्यवस्था सरल है। वर्तमान बकाया, बकेट के अनुसार अतिदेय बकाया, क्रेडिट लिमिट और शेष गुंजाइश खाते पर और कोटेशन स्क्रीन पर दिखाई देती है। लिमिट से ऊपर के ऑर्डर के लिए स्वीकृति चाहिए, जो गलियारे में तय होने के बजाय ऑर्डर के साथ दर्ज होती है। Skyline Nexus इसी तरह काम करता है, क्योंकि CRM और प्राप्य लेज़र एक ही ग्राहक खाते को पढ़ते हैं, इसलिए सेल्स को दिखाया गया एक्सपोज़र वही बकाया है जिसे फ़ाइनेंस देख रहा है, उसकी कोई प्रति नहीं।
मान्यता का समय CRM डेटा में रहता है
IFRS 15 के तहत राजस्व तब मान्य होता है जब कोई परफ़ॉर्मेंस ऑब्लिगेशन पूरा होता है, यानी जब वादा किए गए माल या सेवा का नियंत्रण ग्राहक को हस्तांतरित होता है। यह किसी एक समय-बिंदु पर हो सकता है, जैसे डिलीवरी, या समय के साथ, जैसे कोई मेंटेनेंस अनुबंध या चरणबद्ध निर्माण परियोजना। मानक यह भी अपेक्षा करता है कि ट्रांज़ैक्शन प्राइस को अनुबंध के अलग-अलग परफ़ॉर्मेंस ऑब्लिगेशन्स में आवंटित किया जाए।
जो जानकारी यह सब तय करती है, वह व्यावसायिक दस्तावेज़ों में होती है। क्या वादा किया गया था, क्या अनुबंध में अलग-अलग डिलीवरेबल्स एक साथ बँधे हैं, हर एक कब डिलीवर या स्वीकार हुआ, किस पर और किसके सापेक्ष छूट दी गई। अगर CRM में वह अनुबंध और डिलीवरी डेटा है और अकाउंटिंग सिस्टम उसे कभी देखता ही नहीं, तो अवधि के अंत में कोई उसे स्प्रेडशीट में दोबारा बनाता है और ऑडिट ट्रेल उसी स्प्रेडशीट पर ख़त्म हो जाती है। जब ऑर्डर लाइनों में दायित्व हों और डिलीवरी रिकॉर्ड में तारीख़ें, तो डेफ़रल और रिलीज़ शेड्यूल याददाश्त से दोबारा गढ़ने के बजाय दस्तावेज़ों से निकलता है।
पाइपलाइन एक पूर्वानुमान है, राजस्व एक तथ्य
वेटेड पाइपलाइन इस बात का संभावना-समायोजित अनुमान है कि क्या बंद हो सकता है। मान्य राजस्व वह है जो लेज़र के अनुसार किसी अवधि में अर्जित हुआ, और उसका ऑडिट किया जा सकता है। ये अलग-अलग प्रश्नों के उत्तर देते हैं और इन्हें कभी एक आँकड़े के रूप में नहीं दिखना चाहिए।
जुड़ा हुआ सिस्टम इन्हें मिलाता नहीं; वह आपको इनके बीच ट्रेस करने देता है। पाइपलाइन के किसी आँकड़े से आप उसके पीछे के अवसरों तक पहुँच सकते हैं, फिर उन ऑर्डर तक जो वे बने, फिर उन ऑर्डर से बने इनवॉइस तक, फिर प्राप्त नकद तक। यही रास्ता पूर्वानुमान को सुधारने योग्य बनाता है: आप माप सकते हैं कि ऐतिहासिक रूप से कितना ऑर्डर मूल्य इनवॉइस किए गए राजस्व में बदला, और कितने समय में, और फिर उस पर बहस करने के बजाय पूर्वानुमान की विधि समायोजित कर सकते हैं।
क्या साझा होना चाहिए, और तब महीने का समापन कैसा लगता है
साझा करने का मतलब सब कुछ कॉपी करना नहीं है। इसका मतलब है रिकॉर्ड्स का एक परिभाषित समूह जो एक बार मौजूद हो और दोनों विभाग उसे पढ़ें, और घटनाओं का एक परिभाषित समूह जो बिना दोबारा प्रविष्टि के किसी दस्तावेज़ को अगले चरण तक ले जाए।
महीने के समापन पर इसका लाभ सीमित और ठोस है। एजिंग पूरी होती है क्योंकि हर इनवॉइस उसी सिस्टम के किसी ऑर्डर से आया। सेल्स जो राजस्व आँकड़ा बताता है और ट्रायल बैलेंस में जो राजस्व आँकड़ा है, वे एक ही हैं, क्योंकि आँकड़ा एक ही है। डेफ़र्ड राजस्व किसी व्यक्ति द्वारा रखे गए शेड्यूल के बजाय डिलीवरी रिकॉर्ड से समर्थित होता है। कमीशन लेज़र डेटा से गणना करके इनवॉइस या वसूल मूल्य पर उपार्जित होता है। क्रेडिट नोट उन इनवॉइसों से मिलाए जाते हैं जिन्हें वे रिवर्स करते हैं, इसलिए विवाद इस एहसास के बजाय कि वसूली धीमी है, एक आँकड़े के रूप में दिखते हैं। Skyline Nexus इसी कारण CRM, बिक्री, इन्वेंटरी और अकाउंटिंग को एक डेटाबेस में रखता है: इनवॉइस उसी ऑर्डर से बनता है जिसका वह हिस्सा है, और रसीद उसी इनवॉइस पर लगती है जिसे वह चुकता करती है।
- ग्राहक मास्टर: पहचान, टैक्स पंजीकरण संख्या, क्रेडिट लिमिट, शर्तें, प्राइस लिस्ट, मुद्रा, पते।
- उत्पाद और सेवा मास्टर, उन्हीं प्राइस लिस्ट और टैक्स उपचार के साथ जिनका इनवॉइस वास्तव में उपयोग करेगा।
- स्वीकृत छूट और उनके स्वीकृतिकर्ता, किसी नोट में नहीं बल्कि दस्तावेज़ पर संग्रहीत।
- ऑर्डर लाइनें जो बिना दोबारा टाइप किए इनवॉइस लाइनों तक पहुँचें।
- डिलीवरी और स्वीकृति की तारीख़ें, क्योंकि मान्यता का समय वही तय करती हैं।
- लाइव प्राप्य बकाया और एजिंग, CRM स्क्रीन से पढ़ने योग्य।
- इनवॉइस, रसीद और क्रेडिट नोट के संदर्भ, मूल अवसर से वापस जुड़े हुए।
सामान्य प्रश्न
क्या सेल्स ऑर्डर से कोई लेखा प्रविष्टि बनती है?
नहीं। सेल्स ऑर्डर ख़रीदार और विक्रेता के बीच एक प्रतिबद्धता है; यह स्टॉक आरक्षित कर सकता है, ख़रीद ट्रिगर कर सकता है और शेड्यूलिंग चला सकता है, लेकिन जनरल लेज़र में कुछ भी पोस्ट नहीं करता। लेखा प्रविष्टि इनवॉइस से बनती है, जो प्राप्य खाते को डेबिट करता है, राजस्व को क्रेडिट करता है और आउटपुट टैक्स की देयता दर्ज करता है।
डुप्लिकेट ग्राहक रिकॉर्ड प्राप्य खातों की समस्या क्यों हैं?
क्रेडिट लिमिट और एजिंग हर ग्राहक रिकॉर्ड के हिसाब से गिनी जाती हैं, इसलिए डुप्लिकेट चुपचाप स्वीकृत क्रेडिट एक्सपोज़र को दोगुना कर देता है और अतिदेय बकाया को दो खातों में बाँट देता है, जिससे कोई भी खाता इतना गंभीर नहीं दिखता कि उसकी वसूली के पीछे पड़ा जाए। भुगतान भी एक ही रेमिटेंस के रूप में आते हैं जो दोनों रिकॉर्ड में रखे इनवॉइसों को कवर करते हैं, जिससे हाथ से आवंटन करना पड़ता है।
IFRS 15 का CRM डेटा से क्या संबंध है?
IFRS 15 राजस्व तब मान्य करता है जब कोई परफ़ॉर्मेंस ऑब्लिगेशन पूरा होता है, यानी जब माल या सेवा का नियंत्रण हस्तांतरित होता है, चाहे किसी एक समय-बिंदु पर या समय के साथ। उस समय का साक्ष्य, यानी क्या वादा किया गया, क्या डिलीवर हुआ और कब स्वीकार हुआ, उन अनुबंध और डिलीवरी रिकॉर्ड में रहता है जिन्हें CRM दर्ज करता है, इसलिए मान्यता इस बात पर निर्भर है कि वह डेटा लेज़र तक पहुँचे।
क्या पाइपलाइन मूल्य और मान्य राजस्व को कभी एक साथ रिपोर्ट किया जाना चाहिए?
इन्हें एक-दूसरे तक ट्रेस किया जा सकना चाहिए, लेकिन कभी एक ही आँकड़े के रूप में प्रस्तुत नहीं करना चाहिए। पाइपलाइन उन सौदों का संभावना-भारित पूर्वानुमान है जो बंद हो सकते हैं, जबकि मान्य राजस्व किसी बंद अवधि का ऑडिट योग्य लेज़र आँकड़ा है; दोनों को मिलाने से ऐसा आँकड़ा बनता है जिसका न सेल्स के लिए कोई अर्थ है, न फ़ाइनेंस के लिए।
CRM और अकाउंटिंग सिस्टम के बीच न्यूनतम कौन-सा डेटा साझा होना चाहिए?
कम से कम: एक ग्राहक रिकॉर्ड जिसमें टैक्स पंजीकरण संख्या, क्रेडिट लिमिट, भुगतान शर्तें, प्राइस लिस्ट और मुद्रा हो; कोटेशन और इनवॉइसिंग दोनों द्वारा उपयोग की जाने वाली एक उत्पाद और प्राइस लिस्ट; दस्तावेज़ पर संग्रहीत स्वीकृत छूट; डिलीवरी और स्वीकृति की तारीख़ें; और सेल्स स्क्रीन से दिखने वाला लाइव प्राप्य बकाया। इन्हें साझा करने से वह दोबारा टाइपिंग ख़त्म होती है जिसके कारण कोटेशन और इनवॉइस आपस में मेल नहीं खाते।
यह मार्गदर्शिका सामान्य जानकारी है, कर, लेखांकन या कानूनी सलाह नहीं। नियम हर देश में अलग होते हैं और समय के साथ बदलते हैं; कोई भी कदम उठाने से पहले अपने कर प्राधिकरण या किसी योग्य सलाहकार से वर्तमान स्थिति की पुष्टि करें।
इस गाइड को Skyline Nexus ERP में अमल में लाएँ
Solo · पहले 3 महीनों के लिए $9.50/माह से, फिर $19/माह
लॉन्च ऑफ़र 31 जन. 2027 तक · पहला महीना मुफ़्त