B2B ऑर्डर्स के लिए क्रेडिट लिमिट गेट और प्रति‑ग्राहक भुगतान शर्तें

What a credit limit gate solves (in plain language)

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

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

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

पेमेंट टर्म्स जोखिम को बदलते हैं क्योंकि वे तय करते हैं कि आपका पैसा कितनी देर के लिए बँधा रहेगा। प्रीपे कम जोखिम है क्योंकि कैश पहले आता है। Net 30 ठीक हो सकता है यदि खर्च सीमा के भीतर रहे और इनवॉइसेज़ समय पर भुगतान हों। Net 60 (या कस्टम टर्म्स) एक्सपोज़र को लंबा कर देता है।

एक गेट टीमों के बीच भ्रम भी कम करता है क्योंकि यह “क्या हम यह भेज सकते हैं?” को सेल्स, फाइनेंस और ऑप्स के लिए एक दृश्यमान, सुसंगत स्थिति में बदल देता है।

Define what you store per customer (limits, terms, exposure)

गेट तभी काम करता है जब कस्टमर रिकॉर्ड में कुछ फ़ील्ड हों जिन पर आपका बैकएंड नियम भरोसा कर सके। सूची को छोटा रखें और हर वैल्यू को समझाने में आसान बनाएं।

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

इसके बाद, भुगतान शर्तों को फ्री-टेक्स्ट न रखकर संरचित डेटा के रूप में स्टोर करें। एक साफ़ टाइप का उपयोग करें (Prepay, COD, Net 15, Net 30, Net 60) और जब प्रवर्तनीय हो तब नेट दिनों की संख्या स्टोर करें। इससे आपका ऑर्डर लॉजिक बिना अनुमान लगाए ब्रांच कर सकेगा।

व्यवहारिक प्रति‑ग्राहक सेट कुछ इस तरह दिखता है:

• क्रेडिट लिमिट राशि और मुद्रा
• भुगतान शर्तों का प्रकार और नेट दिन (यदि प्रासंगिक हों)
• अस्थायी ओवरराइड राशि (वैकल्पिक) और उसकी एक्स्पायरी टाइमस्टैम्प
• ओवरराइड नोट (क्यों दिया गया और किसने दिया)
• मैन्युअल होल्ड स्विच (एक “स्टॉप” बटन)

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

अंत में, होल्ड्स को स्पष्ट और कार्रवाई योग्य बनाने के लिए ऑर्डर स्टेटस का एक छोटा सेट रखें। उदाहरण: Approved, On hold, Released, Cancelled।

Data model you need for limits, terms, and order holds

आपके डेटा मॉडल को तीन सवालों का जवाब देना आसान बनाना चाहिए: कौन खरीद रहा है, किन शर्तों पर और वे पहले से कितना दे रहे हैं।

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

ऑर्डर्स को ट्रिगर और परिणाम दोनों कैप्चर करने चाहिए। भुगतान विधि, ऑर्डर टोटल, और एक ऐसा स्टेटस स्टोर करें जो “On hold” को दर्शा सके बिना "Pending" को ओवरलोड किए। एक होल्ड कारण जोड़ें ताकि लोग "क्रेडिट लिमिट से ऊपर" और अन्य मुद्दों (जैसे पता सत्यापन) में फर्क बता सकें।

एक न्यूनतम स्कीमा अक्सर शामिल करता है:

• Customers: credit_limit, payment_terms_code, hold_policy, credit_status
• Orders: total_amount, payment_method, status, hold_reason, held_at
• Invoices / AR: invoice_total, open_balance, due_date, status (open/paid/void)
• Credit overrides: customer_id, override_amount_or_limit, expires_at, approved_by
• Audit log: entity_type, entity_id, changed_fields, changed_by, changed_at, note

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

ओवरराइड्स को अलग टेबल में रखें। यह मुख्य क्रेडिट लिमिट में गंदे संपादन रोकता है और आपको अनुमोदन ट्रेल देता है।

How to calculate credit exposure and available credit

गणित पर सहमति बनानी चाहिए और लिखित होनी चाहिए, फिर ऐप और फाइनेंस रिपोर्ट्स में स्थिर रूप से उपयोग की जानी चाहिए।

एक सामान्य बेसलाइन है:

Credit exposure = unpaid invoices + open order value

फिर:

Available credit = credit limit - credit exposure

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

कुछ समायोजन आश्चर्य रोकते हैं:

• आंशिक भुगतान केवल तभी अनपेड़ इनवॉइसेज़ घटाते हैं जब नकद वास्तव में प्राप्त हो ("इनिशिएटेड" पेमेंट पर नहीं)।
• क्रेडिट नोट्स और रिफंड केवल तब एक्सपोज़र घटाते हैं जब उन्हें जारी कर दिया जाए और उपयोग के लिए अनुमोदित किया जाए।
• रद्द ऑर्डर्स तुरंत ओपन ऑर्डर वैल्यू से हटनी चाहिए।
• रिटर्न्स आम तौर पर तब एक्सपोज़र घटाते हैं जब क्रेडिट नोट मंजूर हो, न कि रिटर्न अनुरोध पर।

टाइमिंग फ़ॉर्मूला जितना महत्वपूर्ण है उतना ही:

• ऑर्डर क्रिएशन पर या ऑर्डर अप्रूवल पर (एक चुनें और सुसंगत रहें)
• इनवॉइस जारी करने पर (ओपन ऑर्डर्स से अनपेड़ इनवॉइसेज़ में वैल्यू मूव करें)
• पेमेंट पोस्टिंग पर (एक्सपोज़र रिलीज़ करें)

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

Step by step: build the backend rule that holds orders

गेट सबसे अच्छा तब काम करता है जब यह हर बार ऑर्डर बनते या बदलते समय स्वतः चलता है।

1. ऑर्डर को पहले ड्राफ्ट के रूप में सेव करें, भले ही खरीदार एक क्लिक में सबमिट कर दे। कस्टमर ID, ऑर्डर टोटल, मुद्रा और पेमेंट टर्म्स का स्नैपशॉट कैप्चर करें ताकि बाद के ग्राहक प्रोफ़ाइल एडिट्स इतिहास को न बदल दें।

2. ग्राहक का वर्तमान एक्सपोज़र निकालें (आपकी परिभाषा के आधार पर)। नए ऑर्डर टोटल को जोड़कर प्रोजेक्टेड एक्सपोज़र की गणना करें।

3. एक सरल निर्णय लागू करें:

• अगर प्रोजेक्टेड एक्सपोज़र क्रेडिट लिमिट के भीतर है, तो ऑर्डर को Approved मार्क करें।
• अगर प्रोजेक्टेड एक्सपोज़र लिमिट से ऊपर है, तो ऑर्डर को On hold सेट करें।

4. ऑर्डर होल्ड होने पर उन विवरणों को रिकॉर्ड करें जो बाद में निर्णय समझाने में आसान बनाते हैं:

• होल्ड कारण (उदाहरण: “Credit limit exceeded by $2,450”)
• अगला कार्रवाई वाला (उदाहरण: “AR team” या कोई विशिष्ट मैनेजर)
• उन इनपुट्स के साथ एक ऑडिट रिकॉर्ड जो इस्तेमाल हुए थे (उस समय की लिमिट, एक्सपोज़र कम्पोनेंट्स, किसने चेक ट्रिगर किया, टाइमस्टैम्प)

5. उन घटनाओं पर एक्सपोज़र को फिर से चेक करें जो नंबर बदलती हैं, सिर्फ़ क्रिएशन पर नहीं। सामान्य ट्रिगर्स हैं: टोटल बदलने वाले एडिट, शिपमेंट (अगर आपकी नीति शिपमेंट को कमिटमेंट मानती है), इनवॉइसिंग, और पेमेंट पोस्टिंग।

Approvals and notifications so held orders don’t get stuck

एक होल्ड तब ही उपयोगी है जब वह त्वरित, ट्रैक करने योग्य निर्णय की ओर ले जाए।

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

What to show on the approval screen

स्क्रीन को छोटा रखें, पर अप्रूवर को जो संख्या चाहिए वे दिखाएँ:

• क्रेडिट लिमिट, वर्तमान एक्सपोज़र, उपलब्ध क्रेडिट
• ऑर्डर टोटल और यह लिमिट से कितना ऊपर जाएगा
• फाइल पर मौजूद पेमेंट टर्म्स और अनुरोधित टर्म्स (यदि अलग हों)
• कस्टमर स्टेटस नोट्स का छोटा सेट (उदाहरण: “new account” या “past due once”)
• एक अनिवार्य टिप्पणी फील्ड

निर्णय के बाद एक अप्रूवल लॉग एंट्री लिखें (ऑर्डर ID, निर्णय, अप्रूवर, टाइमस्टैम्प, टिप्पणी)। यह ऑडिट ट्रेल बनता है और देरी समझाने में मदद करता है।

Notifications and time limits

जब ऑर्डर होल्ड हो जाए तो सही लोगों को तुरंत नोटिफाई करें, उन चैनलों का उपयोग करें जिन्हें आपकी टीम वाकई पढ़ती है (ईमेल, SMS, या Telegram)। रिमाइंडर और एस्केलेशन जोड़ें ताकि होल्ड चुपचाप न बैठे। एक व्यवहारिक पैटर्न: 2 घंटे बाद रिमाइंडर, 24 घंटे बाद एस्केलेशन, और 72 घंटे में ऑटो-कैंसल अगर कोई समीक्षा न करे।

अगर पूरी रिलीज़ जोखिम भरी हो, तो कंडीशनल रिलीज़ की अनुमति दें (आंशिक शिपमेंट, अग्रिम जमा, छोटी भुगतान शर्तें) और शर्त रिकॉर्ड करें ताकि फुलफिलमेंट और इनवॉइसिंग एक ही प्लान के अनुसार हों।

Operational flow: what happens after an order is held

होल्ड किए गए ऑर्डर को एक सामान्य ऑर्डर की तरह ट्रीट करें बस एक स्पष्ट फर्क के साथ: यह तब तक आगे नहीं बढ़ सकता जब तक होल्ड सुलझ न जाए।

सेल्स, ऑप्स और फाइनेंस सबको वही होल्ड सिग्नल दिखाई देना चाहिए। "On credit hold" जैसा स्टेटस और एक कारण फील्ड जोड़ें (उदाहरण: "Exposure exceeds limit by $1,240")। एक छोटा आंतरिक नोट जोड़ें ताकि लोग अनुमान न लगाएँ।

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

कस्टमर कम्युनिकेशन के लिए संदेश तटस्थ और व्यावहारिक रखें, एक स्पष्ट अगला कदम के साथ। उदाहरण:

• “Your order is temporarily paused for a routine account review. Reply to confirm payment timing, or request a partial shipment.”
• “We can ship as soon as payment is received or the credit limit is adjusted. Which option works best?”
• “We can split the order and ship the items that fit within your available credit.”

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

कई मीट्रिक्स को ट्रैक करें ताकि गेट स्वस्थ रहे: होल्ड किए गए ऑर्डर्स की संख्या, 24 घंटे में रिलीज़ प्रतिशत, औसत समय रिलीज़ तक, और होल्ड के प्रमुख कारण।

Example scenario: a wholesale order that exceeds the threshold

एक व्होलसेल ग्राहक, BrightSide Supplies, के पास Net 30 पेमेंट टर्म्स और 50,000 की क्रेडिट लिमिट है।

उनकी अनपेड़ इनवॉइसेज़ का कुल 38,000 है। वे 15,000 का नया ऑर्डर करते हैं।

प्रोजेक्टेड एक्सपोज़र = 38,000 + 15,000 = 53,000। चूंकि 53,000 50,000 लिमिट से ऊपर है, ऑर्डर होल्ड पर रखा जाता है और फाइनेंस को समीक्षा के लिए रूट किया जाता है। सेल्स अभी भी ऑर्डर देख सकते हैं, पर यह तब तक पैक, शिप या इनवॉइस नहीं हो सकता जब तक जोखिम कम न हो।

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

Quick checklist before you turn it on

प्रोडक्शन में गेट चालू करने से पहले एक छोटा प्री‑फ्लाइट पास कर लें। कुछ घंटे की टेस्टिंग से बाद में दिनों का काम बच सकता है।

5–10 विविध ग्राहकों का एक छोटा टेस्ट सेट लें: एक Net 30 और कम लिमिट वाला, एक उच्च लिमिट वाला, एक प्रीपेड, एक जिसके कई ओपन इनवॉइसेज़ हों, और एक जो अक्सर चेकआउट के बाद ऑर्डर एडिट करता हो।

दो बातों की पुष्टि करें:

• एक्सपोज़र मैथ अकाउंटिंग की उम्मीदों से मेल खाता है (जिसे आप गिनते हैं और जो आप नहीं गिनते)
• होल्ड नियम सही समय पर चलता है: ऑर्डर क्रिएशन और किसी भी एडिट पर जो एक्सपोज़र बढ़ाता है (क्वांटिटी चेंज, प्राइस चेंज, शिपिंग ऐड, डिस्काउंट हटाना)

एक होल्ड ऑर्डर को एंड-टू‑एंड वॉक करें और पुष्टि करें कि होल्ड कारण स्पष्ट है, शिपिंग और इनवॉइसिंग ठीक वैसा ही व्यवहार कर रहे हैं जैसा सोचा गया था, नोटिफिकेशन सही लोगों को जा रहे हैं, और एक पेमेंट रिवर्सल सुरक्षित रूप से फिर से होल्ड कर सकता है (या फ़्लैग कर सकता है)।

Common mistakes and how to avoid them

अधिकांश समस्याएँ तकनीकी नहीं होतीं। वे तब होती हैं जब नियम गलत नंबर चेक करता है, या लोग इसे बायपास करना सीख लेते हैं।

सामान्य गलती के बिंदु:

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

रोकथाम को सरल रखें: एक वाक्य में एक्सपोज़र परिभाषित करें, किसी भी मनी‑चेंजिंग एडिट पर गेट फिर चलाएँ, ओवरराइड्स के लिए कारण और अप्रूवर आवश्यक रखें, और अपवाद प्रकार कम रखें।

Next steps: implement the gate in your order app and iterate

सबसे छोटा संस्करण शुरू करें जो वास्तविक जोखिम रोकता हो: "अगर इस ऑर्डर के बाद एक्सपोज़र ग्राहक की लिमिट से अधिक हो जाता है, तो ऑर्डर को On hold सेट करें।" इसे एक सप्ताह चलाएँ, फिर केवल वही अपवाद जोड़ें जिन्हें आप स्पष्ट रूप से नाम दे सकें (उदाहरण: फाइनेंस द्वारा अप्रूव्ड अस्थायी ओवरराइड)।

अगर आप हैंड‑कोडिंग के बिना ऑर्डर ऐप बना रहे हैं तो AppMaster (appmaster.io) एक व्यवहारिक विकल्प हो सकता है: आप विजुअली कस्टमर्स, ऑर्डर्स, इनवॉइसेज़ और ओवरराइड्स मॉडल कर सकते हैं, फिर होल्ड लॉजिक को एक बैकएंड बिजनेस प्रोसेस के रूप में लागू कर सकते हैं जो क्रिएट, एडिट, इनवॉइसिंग और पेमेंट्स पर एक्सपोज़र को फिर से गणना करता है।

पहला रिलीज़ साधारण और पूर्वानुमेय रखें। इसे उन सुधारों के आधार पर बेहतर बनाएं जो फाइनेंस और ऑप्स रोज़ मर्रा की ज़रूरतों में देखते हैं।