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

कोटेशन से उधार पर पहले शिपमेंट तक

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

ग्राहक रिकॉर्ड: एक बार दर्ज, जोड़ते समय जाँचा गया

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

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

ग्राहक को अपनी सूची में जोड़ने से पहले दो मुफ़्त आधिकारिक जाँच काफ़ी हैं, वही दो जिनका वर्णन हमने ख़रीदार की ओर से कोटेशन से परचेज़ ऑर्डर तक: सत्यापित सप्लायर, पक्की कीमत में किया था:

  • ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) पर VAT पंजीकरण जाँच। करदाताओं और आम जनता के लिए खुली सेवा, जहाँ आप VAT नंबर, वाणिज्यिक पंजीकरण नंबर या VAT प्रमाणपत्र नंबर से खोजते हैं और प्रतिष्ठान की पंजीकरण स्थिति देखते हैं।
  • वाणिज्य मंत्रालय पर वाणिज्यिक रजिस्टर लुकअप। एक तुरंत और मुफ़्त सेवा, जहाँ आप प्रतिष्ठान के नाम या एकीकृत राष्ट्रीय नंबर से खोजते हैं।

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

SIMAH के ज़रिए क्रेडिट जाँच का क्या? SIMAH क्रेडिट सूचना कंपनियों में से एक है, और सऊदी सेंट्रल बैंक (SAMA) की रूलबुक में प्रकाशित क्रेडिट सूचना कानून के कार्यान्वयन विनियम उपभोक्ता को ऐसा प्राकृतिक या विधिक व्यक्ति परिभाषित करते हैं जिसके क्रेडिट लेन-देन हों, इसलिए व्यवसाय भी इसमें शामिल हैं। लेकिन यह जाँच हर उस कंपनी के लिए खुली नहीं है जो इसे चाहे: विनियमों के तहत सदस्य वह संस्था है जिसने किसी क्रेडिट सूचना कंपनी के साथ क्रेडिट सूचना आदान-प्रदान अनुबंध पर हस्ताक्षर किए हैं, और अनुच्छेद 40(1) सदस्य से पूछताछ करने से पहले उपभोक्ता की लिखित सहमति लेने की अपेक्षा करता है। इसलिए इस रास्ते के लिए सदस्यता चाहिए, और किसी भी पूछताछ से पहले आपके ग्राहक की लिखित सहमति चाहिए।

क्रेडिट लिमिट और भुगतान शर्तें: मालिक तय करता है, सिस्टम जाँचता है

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

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

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

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

  • फ़ैक्ट्री या वितरक। हर हफ़्ते दोहराए जाने वाले ऑर्डर, इसलिए जाँच हर ऑर्डर और हर लोडिंग ऑर्डर पर चलती है, और कोई ट्रक लिमिट पार कर चुके ग्राहक के लिए किसी की जानकारी के बिना नहीं निकलता।
  • मेंटेनेंस कंपनी, प्रॉपर्टी ऑपरेटर या होटल। मासिक अनुबंध या कॉरपोरेट खाता, जहाँ इनवॉइस जारी होने से पहले सेवाएँ जमा होती रहती हैं, इसलिए तस्वीर से आम तौर पर बिल न किया गया हिस्सा ही ग़ायब रहता है।
  • ठेकेदार। यहाँ लिमिट ऑर्डर स्तर पर नहीं, अनुबंध स्तर पर पढ़ी जाती है; इस पर हम थोड़ी देर में लौटेंगे।

लिमिट से ऊपर जाना: कारण के साथ दर्ज मंज़ूरी, फ़ोन कॉल नहीं

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

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

गारंटी: उधार पर बेचने से पहले मालिक क्या चुनता है

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

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

Nafith वचन-पत्र बनाने का एक इलेक्ट्रॉनिक प्लेटफ़ॉर्म है, जिसे न्याय मंत्रालय की प्रवर्तन सेवाओं की गाइड स्वीकृत इलेक्ट्रॉनिक प्लेटफ़ॉर्म के उदाहरण के रूप में बताती है, और यह सऊदी अरब में पंजीकृत व्यक्तियों और प्रतिष्ठानों को सेवा देता है। प्लेटफ़ॉर्म के अनुसार वचन-पत्र बनाने का अनुरोध लेनदार, यानी आप, जारी करते हैं, और फिर देनदार इसे राष्ट्रीय सिंगल साइन-ऑन Nafath के ज़रिए मिले पुष्टि कोड से मंज़ूर करता है, जिसे देनदार द्वारा वचन-पत्र बनाना माना जाता है। मंज़ूरी के बाद वचन-पत्र में बदलाव नहीं हो सकता; लेनदार इसे रद्द कर सकता है, देनदार नहीं। प्लेटफ़ॉर्म एक ही अनुरोध से जुड़े अलग-अलग नियत तिथियों वाले कई वचन-पत्रों की भी अनुमति देता है, जिनमें से हर एक को अलग से प्रवर्तन में लाया जा सकता है, जो किस्तों में भुगतान के समझौते के लिए उपयुक्त है।

यह क्यों मायने रखता है? क्योंकि प्रवर्तन कानून का अनुच्छेद 9 कहता है कि अनिवार्य प्रवर्तन केवल किसी निश्चित राशि के देय अधिकार के लिए निष्पादन योग्य दस्तावेज़ से ही संभव है, और बिंदु 4 वाणिज्यिक पत्रों को निष्पादन योग्य दस्तावेज़ों में गिनता है; वचन-पत्र एक वाणिज्यिक पत्र है। इसलिए जिस वचन-पत्र का अपनी तारीख़ पर भुगतान नहीं होता वह पहले मुक़दमे के बिना सीधे प्रवर्तन में जाता है। न्याय मंत्रालय की गाइड बताती है कि Nafith जैसे स्वीकृत प्लेटफ़ॉर्म से जारी दस्तावेज़ Najiz पर स्वचालित ट्रैक (वर्चुअल कोर्ट) से दाख़िल किए जाते हैं: आवेदक वचन-पत्र का नंबर डालता है और उसका विवरण अपने आप लोड हो जाता है। और संशोधित कानून का अनुच्छेद 46 कहता है कि अगर देनदार प्रवर्तन आदेश की सूचना मिलने के 5 दिन के भीतर भुगतान नहीं करता, या भुगतान के लिए पर्याप्त संपत्ति का खुलासा नहीं करता, तो उसे डिफ़ॉल्टर माना जाता है, और प्रवर्तन न्यायाधीश तुरंत ऐसे उपायों का आदेश देता है जिनमें यात्रा प्रतिबंध और किसी लाइसेंसशुदा क्रेडिट सूचना कंपनी को भुगतान न होने की सूचना देना शामिल है।

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

ठेकेदार: अनुबंध पर बैलेंस के रूप में अग्रिम भुगतान और रिटेंशन

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

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

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

Origami का नज़रिया

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

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

इस हफ़्ते का अभ्यास: अपने बीस सबसे बड़े उधार ग्राहकों की समीक्षा करें

किसी भी सिस्टम से पहले, आपको यह तस्वीर चाहिए कि उधार बिक्री और उस लिमिट के बीच वास्तव में क्या होता है जिसे आप मौजूद मानते हैं। एक फ़ाइनेंस मैनेजर और एक सेल्स मैनेजर इसे एक या दो बैठकों में कर सकते हैं:

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

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

अगले भाग में

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

स्रोत