तेज़ मंथ-एंड क्लोज़: नियंत्रण खोए बिना रिकंसिलिएशन ऑटोमेट करें

कल्पना कीजिए: तीन लोगों की एक finance टीम, महीना ख़त्म होने के चौथे कार्यदिवस की शाम 6:40 बजे (यह दृश्य काल्पनिक है)। बैंक feed में 1,000 लाइनें हैं। 540 हाथ से टिक हो चुकी हैं, पर गेटवे का 9,712.40 का एक payout अनमैच पड़ा है, क्योंकि वह किसी एक order की रक़म से नहीं मिलता।

असल में वह 23 orders का पैसा है: कुल 10,000.00, जिसमें से 287.60 फ़ीस कटी है। accountant यह जानता है, पर साबित करने के लिए "final_v7" नाम की spreadsheet में 23 invoice खोलने पड़ेंगे। management meeting कल है, और उसमें तीन हफ़्ते पुराने आँकड़ों पर बात होगी।

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

इस लेख में देखेंगे कि काम को आगे खींचकर, सब-ledger को अपने आप पोस्ट करने देकर और ruleों से बैंक reconciliation automate करके close का समय कैसे घटाया जाए, जबकि हर फ़ैसला इंसान के हाथ में ही रहे। साथ में एक हल किया हुआ उदाहरण, ज़िम्मेदार लोगों के नाम वाला close calendar और नज़र रखने लायक़ कुछ metric भी हैं।

छोटी टीमों को दस दिन या उससे ज़्यादा क्यों लगते हैं

पहले आँकड़े देख लें। APQC के जनरल अकाउंटिंग बेंचमार्किंग सर्वे में 2,300 संगठन शामिल थे; CFO.com की report के मुताबिक़ महीना बंद करने में माध्यिका 6.4 calendar दिन है, शीर्ष एक-चौथाई टीमें 4.8 दिन या उससे कम में निपटा लेती हैं, और सबसे पिछड़ी एक-चौथाई को 10 दिन या उससे ज़्यादा लगते हैं। यह सर्वे कुछ साल पुराना है और ट्रायल बैलेंस से calendar दिन गिनता है, इसलिए इसे मोटा पैमाना मानें, लक्ष्य नहीं।

असल सवाल यह है कि पिछड़ी टीमें धीमी क्यों हैं। वजहें लगभग हमेशा यही होती हैं:

• data देर से आता है। गेटवे के payout, courier का पैसा और supplier के बिल नए महीने के पहले दिन से पीछा करके मँगाने पड़ते हैं।
• system ledger से बात नहीं करते। बिक्री, payment, सैलरी और stock का data दोबारा टाइप होता है या journal बनाकर इम्पोर्ट किया जाता है।
• reconciliation हाथ से होता है। कोई एक आदमी हज़ारों बैंक लाइनों को invoice से एक-एक करके टिक करता है।
• सब कुछ एक व्यक्ति पर अटका रहता है। जो accountant spreadsheet को जानता है, वही अकेला रिव्यूअर भी है।
• ग़लतियाँ देर से पकड़ में आती हैं। पहले हफ़्ते का ग़लत टैक्स कोड पाँचवें हफ़्ते में सामने आता है।

continuous accounting: close को "बड़ा event" न बनाएँ

सबसे तेज़ close वह है जिसमें करने को कम से कम काम बचा हो। इस सोच को continuous accounting कहते हैं, और बात सीधी है: हर काम data मिलते ही कर डालें, और ledger को हमेशा लगभग सही रखें।

व्यवहार में इसका मतलब तीन बदलाव हैं:

• घटना के वक़्त ही पोस्ट करें। बिक्री, refund या सैलरी रन अपना journal उसी समय लिख दे, महीने के आख़िर में नहीं।
• रोज़ या हर हफ़्ते reconciliation करें। दस छोटे reconciliation एक बड़े से तेज़ निपटते हैं, और गड़बड़ी तब पकड़ में आती है जब सबको बात याद हो।
• सब कुछ नहीं, सिर्फ़ exception देखें। रूटीन आइटम system निपटा दे; लोगों के सामने वही आए जिस पर फ़ैसला चाहिए।

तब महीने का अंत एक चेकपॉइंट बन जाता है: आँकड़े पक्के करें, विवेक पर आधारित एंट्री बुक करें, पीरियड लॉक करें।

सब-ledger जो अपने आप पोस्ट करें

सब-ledger एक ब्योरेवार रिकॉर्ड है, जैसे कस्टमर invoice या stock मूवमेंट, जो जनरल ledger के एक control account में जुड़ता है। जब सब-ledger अपने आप पोस्ट करते हैं, तो रोज़मर्रा की गतिविधि के लिए जनरल ledger में हाथ से journal नहीं लिखने पड़ते।

स्रोत	जो अपने आप पोस्ट होना चाहिए	जो control रखना है
बिक्री और return	राजस्व, टैक्स, प्राप्य या नक़द, refund और क्रेडिट नोट	सेल्स सब-ledger का कुल योग राजस्व खातों के बराबर
payment और गेटवे	मिला हुआ नक़द, गेटवे फ़ीस, चार्जबैक, payout	हर payout के बाद गेटवे clearing account शून्य पर लौटे
courier settlement	COD में वसूली, courier फ़ीस, रास्ते में लौटते parcel	courier clearing बैलेंस खुले parcelों से मेल खाए
payroll	कुल वेतन, कटौतियाँ, नियोक्ता की लागत, नेट वेतन की देनदारी	payroll रजिस्टर पोस्ट हुए journal के बराबर
inventory और बिके माल की लागत	प्राप्ति, इश्यू, एडजस्टमेंट, transfer, हर बिक्री की लागत	stock वैल्युएशन report inventory account के बराबर

दो बातों पर ख़ास ध्यान दें। पहली, गेटवे और courier के clearing account आपकी पहली चेतावनी हैं: अगर वे शून्य पर नहीं लौटते, तो कोई payout या parcel कहीं खो गया है। दूसरी, हर सब-ledger को एक टाई-आउट चेक चाहिए, यानी सब-ledger के कुल और उसके control account की एक लाइन की तुलना, जो महीने में एक बार नहीं, रोज़ या हर हफ़्ते चले।

बैंक reconciliation: rule, मिलान और exception

हाथ के काम के सबसे ज़्यादा घंटे बैंक reconciliation में जाते हैं, और automation का फ़ायदा सबसे पहले यहीं दिखता है। मक़सद यह है कि जो लाइनें rule नहीं निपटा सके, इंसान सिर्फ़ उन्हीं को छुए।

मिलान की परतों का funnel

reconciliation को एक funnel की तरह सोचें। हर परत जो निपटा सकती है निपटा देती है, और बाक़ी नीचे भेज देती है।

1. सटीक rule। वही रक़म, वही रेफ़रेंस या invoice नंबर, कुछ दिनों के भीतर। ज़्यादातर काम यहीं निपट जाता है।
2. समूह वाले rule। एक बैंक डिपॉज़िट जो कई orders के योग में से फ़ीस घटाने पर बनता है, जैसे gateway payout या courier का remittance। rule डिपॉज़िट को उसके हिस्सों में बाँट देता है।
3. सुझाए गए मिलान। क़रीब-क़रीब मिलते हैं, पूरे नहीं: रक़म में मामूली फ़ीस का फ़र्क़, या रेफ़रेंस में स्पेलिंग की ग़लती। system एक मिलान सुझाता है और वजह भी दिखाता है।
4. मैन्युअल exception। जो बचता है, वह संभावित वजह के साथ किसी इंसान के पास जाता है।

funnel में एक लाइन का सफ़र: gateway payout

शुरुआती दृश्य वाला payout ही लें। बैंक में 9,712.40 की एक जमा आई है, साथ में गेटवे का batch रेफ़रेंस। सटीक rule यहाँ नाकाम रहता है, क्योंकि किसी एक order की रक़म यह नहीं है। तब समूह वाला rule गेटवे की settlement report पढ़ता है, उस batch के 23 order ढूँढ लेता है, और देखता है कि कुल बिक्री 10,000.00 है और फ़ीस 287.60। कुल में से फ़ीस घटाने पर बैंक की जमा के बराबर रक़म बनती है, इसलिए लाइन मिल जाती है और एक ही journal पोस्ट होता है।

account	डेबिट	क्रेडिट
बैंक	9,712.40
गेटवे फ़ीस (ख़र्च)	287.60
गेटवे clearing		10,000.00

23 orders का भुगतान आते समय clearing account में 10,000.00 जमा हुआ था, इसलिए अब वह शून्य पर लौट आता है। अगर बैंक ने 9,700.00 भेजे होते, तो 12.40 का फ़र्क़ rule तोड़ देता और लाइन "फ़ीस बेमेल" कारण-कोड के साथ अगली परत में गिर जाती। डिज़ाइन का मक़सद यही है: जिस payout का हिसाब नहीं मिलता, उसे ज़बरदस्ती पास नहीं किया जाता।

rule अपने पैटर्न से लिखें

अच्छे rule उन exception से निकलते हैं जिन्हें आपने पिछले महीने सँभाला था। अगर payment गेटवे 2.9% और एक तय रक़म फ़ीस काटता है, तो उसे समूह वाले rule में ही लिख दें। अगर courier हर मंगलवार पिछले हफ़्ते की डिलीवरी का पैसा भेजता है, तो remittance batch के आधार पर मिलान करें। हर महीने ruleों की हिट रेट देखें, और जो rule ग़लत मिलान देते हैं उन्हें हटा दें।

exception को data की तरह देखें

हर exception के साथ एक कारण-कोड जुड़ा हो: बेमेल डिपॉज़िट, डुप्लिकेट payment, invoice नहीं मिला, बैंक चार्ज, समय का अंतर। एक तिमाही बाद गिनती बता देती है कि पीछे की कौन-सी प्रक्रिया ठीक करनी है। यह एक ही exception को बार-बार निपटाने से कहीं ज़्यादा काम की बात है।

AI कहाँ काम आता है, और फ़ैसला इंसान कहाँ करे

जहाँ rule ख़त्म होते हैं, यानी funnel के उन सिरों पर, मशीन लर्निंग और भाषा मॉडल काम आते हैं। दो काम उनके लिए ख़ास तौर पर ठीक हैं:

• मिलान के सुझाव। पुराने व्यवहार के आधार पर बताना कि बैंक का कोई धुँधला विवरण किस कस्टमर या supplier का है।
• गड़बड़ी के संकेत। डुप्लिकेट payment, किसी supplier के लिए असामान्य रक़म, या अजीब समय पर पोस्ट हुआ journal उभारकर दिखाना।

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

automation के साथ ज़िम्मेदारियों का बँटवारा (segregation of duties) भी चाहिए। जो reconciliation तैयार करे, वही उसका अकेला अनुमोदक न हो; जो मिलान के rule बदल सकता है, वह नतीजे पर दस्तख़त भी न करे। तीन लोगों की टीम में भी छोटी exception report पर दूसरी जोड़ी आँखें सस्ता बीमा हैं।

accrual, prepayment और cut-off

accrual अकाउंटिंग में, जिसे IFRS अनिवार्य करता है, आय और ख़र्च उसी पीरियड के होते हैं जिससे वे जुड़े हैं, उस पीरियड के नहीं जब पैसा हाथ बदलता है। इसीलिए बाक़ी सब कुछ चाहे जितना automateेड हो, close में कुछ विवेक वाली एंट्री लगती ही हैं।

• accrual उन ख़र्चों को दर्ज करते हैं जो हो चुके पर जिनका बिल अभी नहीं आया: जैसे अगले महीने आने वाला बिजली-पानी का बिल, या ठेकेदार का 28 तारीख़ को पूरा किया काम।
• prepayment पहले से चुकाए ख़र्च, जैसे सालाना software या बीमा, को उन महीनों में बाँट देता है जिनमें उसका फ़ायदा मिलता है।
• cut-off तय करता है कि लेन-देन किस पीरियड का है: आख़िरी दिन भेजा गया माल, पैसा मिल चुका पर अभी डिलीवर न हुआ order, 30 तारीख़ की तारीख़ वाला पर 3 तारीख़ को मिला supplier का बिल।

इसमें से ज़्यादातर को template बनाया जा सकता है। बार-बार आने वाले prepayment एक शेड्यूल बन जाते हैं, जो हर महीने एक लाइन पोस्ट करता है। बार-बार आने वाले accrual रिवर्सिंग journal बन जाते हैं, जिन्हें system ख़ुद बनाता है और अगले महीने के पहले दिन पलट देता है। इंसान के पास सिर्फ़ अपवाद रहते हैं: विवादित बिल, एकबारगी प्रोजेक्ट, या ऐसा अनुमान जिसकी वजह लिखनी पड़े।

ज़िम्मेदार लोगों और दिनों वाला close calendar

close तब जल्दी निपटता है जब हर काम का एक मालिक और एक तय दिन हो, जिसे एक बार लिखकर हर महीने दोहराया जाए। नीचे का calendar automateेड सब-ledger वाली छोटी टीम के लिए एक काल्पनिक लक्ष्य है।

कब	काम	ज़िम्मेदार
महीने भर रोज़	exception सूची देखना; गेटवे और courier clearing account निपटाना	अकाउंट्स क्लर्क
हर हफ़्ते	आख़िरी कार्यदिवस तक बैंक reconciliation; सब-ledger टाई-आउट	अकाउंट्स क्लर्क; रिव्यू accountant करेगा
कार्यदिवस 1	cut-off जाँच; शिपमेंट, प्राप्तियाँ और सैलरी सही पीरियड में हैं या नहीं, यह पक्का करना	ऑपरेशंस लीड और accountant
कार्यदिवस 2	accrual, prepayment शेड्यूल, डेप्रिसिएशन, stock गिनती के एडजस्टमेंट	accountant
कार्यदिवस 3	अंतिम reconciliation, मैन्युअल journal का रिव्यू, बजट से वेरिएंस रिव्यू	finance मैनेजर
कार्यदिवस 4	पीरियड लॉक, report जारी करना, मैनेजमेंट को ब्रीफ़ करना	finance मैनेजर

शुरुआत के लिए एक छोटी क़दम-सूची:

1. पिछले महीने जितने journal हाथ से पोस्ट किए, सबकी सूची बनाएँ और हर एक का स्रोत लिखें।
2. हर स्रोत के लिए सोचें: क्या कोई सब-ledger इसे अपने आप पोस्ट कर सकता था?
3. बैंक reconciliation को मासिक से साप्ताहिक करें, फिर सबसे ज़्यादा दोहराए जाने वाले पाँच पैटर्न के rule लिखें।
4. बार-बार आने वाले accrual और prepayment को template बना लें।
5. हर काम के लिए मालिक और अंतिम दिन तय करके close calendar लिखें।
6. नई प्रक्रिया को एक बार पुरानी के साथ-साथ चलाएँ, नतीजे मिलाएँ, फिर पुरानी बंद कर दें।

तेज़ close से क्या संभव होता है

चार दिन में निपटने वाले close से मैनेजमेंट पुराना हिसाब पढ़ने की जगह आगे की दिशा तय करने लगता है, क्योंकि बजट बनाम वास्तविक और फ़ोरकास्ट की समीक्षा तब होती है जब कुछ करने का वक़्त बचा हो। एक मिनट का यह टूर लाइव ledger पर बने बजट, पूँजीगत ख़र्च और फ़ोरकास्ट दिखाता है।

वे metric जो बताते हैं कि close बेहतर हो रहा है

हर महीने कुछ ही संख्याएँ ट्रैक करें, और उन्हें टीम के सामने रखें।

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

एक काल्पनिक उदाहरण: जो टीम पहले महीने में 120 मैन्युअल journal पोस्ट करती है और 55% बैंक लाइनें अपने आप निपटाती है, वह छह महीने में 40 journal और 85% का लक्ष्य रख सकती है। सटीक संख्याओं से ज़्यादा अहम दिशा है।

जिन ग़लतियों से बचें

• टूटी प्रक्रिया को automate करना। पहले exception की वजह ठीक करें; उसके इर्द-गिर्द automation चलाने से समस्या बस छिप जाती है।
• बिना सीमा के ऑटो-पोस्टिंग। रक़म की सीमा तय करें और उससे ऊपर मंज़ूरी ज़रूरी करें।
• ruleों को पुराना पड़ने देना। साल भर पहले जो rule सही था, आज वह शायद ग़लत supplier से मिला रहा हो।
• लॉक को छोड़ देना। अगर बंद पीरियड कभी भी बदला जा सकता है, तो close पूरा हुआ ही नहीं।

अब शाम 6:40 बजे वाली उसी टीम पर लौटें। गेटवे के लिए समूह वाला rule हो, तो 9,712.40 का payout रातों-रात अपने 23 orders से मिल जाता है और 287.60 का एक फ़ीस journal पोस्ट हो जाता है। feed खुलने से पहले ही rule 1,000 में से लगभग 880 लाइनें निपटा चुके होते हैं। accountant की शाम उन क़रीब 120 लाइनों पर जाती है जिन्हें इंसान चाहिए: 70 सुझाव, जिन्हें पक्का करना है, और 50 exception, जिनमें हर एक का एक मालिक है। चौथे दिन की मीटिंग में पिछले हफ़्ते के आँकड़ों पर बात होती है, पिछली तिमाही के नहीं।

मुख्य बातें

• धीमा close अक्सर देर से आए data, हाथ के journal और हाथ के मिलान की वजह से होता है, धीमे लोगों की वजह से नहीं।
• काम को महीने के भीतर ले आएँ: घटना के वक़्त पोस्टिंग, साप्ताहिक reconciliation, सिर्फ़ exception का रिव्यू।
• सब-ledger को अपने आप पोस्ट करने दें, और हर हफ़्ते हर एक को उसके control account से मिलाएँ।
• बैंक reconciliation को funnel की तरह बनाएँ: सटीक rule, समूह rule, सुझाव, फिर exception।
• सुझावों और गड़बड़ी के संकेतों के लिए AI इस्तेमाल करें, पर मंज़ूरी इंसान के हाथ में रखें और हर फ़ैसले का लॉग रखें।
• close के दिन, मैन्युअल journal, ऑटो-मैच रेट और exception नापें, और हर महीने टीम को दिखाएँ।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।