Excel में Accounts Receivable Aging Report कैसे बनाएं (30, 60, 90 दिन)

एक aging report बकाया इनवॉइस को इस आधार पर अलग-अलग श्रेणियों (buckets) में बांटती है कि वे कितने दिनों से लंबित हैं, आमतौर पर 0–30, 31–60, 61–90 और 90 दिनों से अधिक। दो निर्णय यह तय करते हैं कि आपकी रिपोर्ट सही है या नहीं। पहला यह कि क्या आप due date से गणना करते हैं या invoice date से। दूसरा यह कि क्या आंशिक रूप से भुगतान किए गए इनवॉइस की पूरी राशि दिखाई जाती है या उसकी बची हुई राशि (remaining balance)।

इन दोनों में से एक भी गलती होने पर हर श्रेणी का कुल योग गलत हो जाता है, जो कि कोई रिपोर्ट न होने से भी बदतर है।

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

aging report किसी स्प्रेडशीट को क्यों बिगाड़ देती है

पहली समस्या तारीख से जुड़ा सवाल है। invoice date से गणना करने पर आपको यह पता चलता है कि कागजी कार्रवाई कितनी पुरानी है। due date से गणना करने पर आपको यह पता चलता है कि ग्राहक ने भुगतान में कितनी देरी की है, और कलेक्शन के लिए आपको इसी संख्या की आवश्यकता होती है।

दोनों ही तरीके अपनी जगह सही हैं और इनसे अलग-अलग रिपोर्ट बनती हैं। समस्या तब आती है जब स्प्रेडशीट में किसी ने यह दर्ज ही नहीं किया होता कि किस तरीके का उपयोग किया गया था।

दूसरी समस्या आंशिक भुगतान की है। $10,000 के इनवॉइस पर यदि $7,000 प्राप्त हो चुके हैं, तो $3,000 की राशि प्राप्य (receivable) बचती है, और इसे ठीक एक ही श्रेणी में $3,000 के रूप में दिखना चाहिए। open-items सूची के बजाय केवल इनवॉइस सूची के आधार पर बनाई गई aging reports चुपके से हर आंकड़े को बढ़ा-चढ़ाकर दिखाती हैं।

तीसरी समस्या यह है कि यह रिपोर्ट एक स्नैपशॉट होती है। श्रेणियों की गणना आज की तारीख के आधार पर की जाती है, इसलिए कल की फ़ाइल पहले ही पुरानी हो चुकी होती है, और हर बार रिपोर्ट को फिर से बनाने पर प्रत्येक पंक्ति (row) की दोबारा गणना करनी पड़ती है।

इसके बाद कुछ जटिल पंक्तियाँ होती हैं। क्रेडिट नोट्स, एडवांस पेमेंट (prepayments), विवादित इनवॉइस और बहु-मुद्रा शेष (multi-currency balances), इन सभी के लिए एक नियम की आवश्यकता होती है। फिर प्रत्येक नियम को उस अगले व्यक्ति के संपादन से बचना होता है जो फ़ाइल को खोलता है।

इनमें से कोई भी काम अकेले में कठिन नहीं है। वे इसलिए कठिन हो जाते हैं क्योंकि वे महीने में एक बार, एक साथ और समय-सीमा (deadline) के दबाव में सामने आते हैं।

इससे आपको क्या नुकसान होता है

एक ऐसी कलेक्शन सूची जिस पर आप काम नहीं कर सकते। श्रेणियों में बांटने का उद्देश्य यह जानना है कि सबसे पहले किसे कॉल करना है। एक ऐसी रिपोर्ट जो बकाया राशि को बढ़ा-चढ़ाकर दिखाती है, किसी को उस पैसे के पीछे भागने के लिए भेज देती है जो पहले ही आ चुका है।

हर महीने दोबारा काम करना। चूंकि श्रेणियां आज की तारीख के सापेक्ष होती हैं, इसलिए aging report कभी पूरी नहीं होती। हर चक्र में वही जुड़ाव (joins), वही फ़ॉर्मूले और वही मैन्युअल जाँचें दोहरानी पड़ती हैं।

ऐसा कुल योग जो लेज़र से मेल नहीं खाता। जब श्रेणियों का कुल योग प्राप्य शेष (receivables balance) से मेल नहीं खाता, तो रिपोर्ट अपनी विश्वसनीयता खो देती है। इसका कारण ढूंढने में आमतौर पर रिपोर्ट को शुरू से बनाने से भी अधिक समय लग जाता है।

एक aging report पर इसलिए भरोसा किया जाता है क्योंकि इसका कुल योग लेज़र से मेल खाता है। यदि यह विफल हो जाता है, तो इसके बारे में कोई और बात मायने नहीं रखती।

वे तरीके जिन्हें लोग आज़माते हैं

विकल्प 1: फ़ॉर्मूले को छूने से पहले परिभाषाओं को ठीक करें

शीट के शीर्ष पर चार चीजें लिखें। आप किस तारीख से गणना कर रहे हैं, और श्रेणियों की सीमाएं क्या हैं। राशि सकल (gross) है या भुगतानों को घटाकर (net of payments) है, और संदर्भ तिथि (as-of date) क्या है।

इसमें केवल दस मिनट लगते हैं और यह सबसे आम विवादों को रोकता है। Journal of Accountancy इसी तरह की रिपोर्ट बनाने की प्रक्रिया को समझाता है, जिसमें सबसे पहले सेटअप को सही करने पर समान जोर दिया गया है।

यह आपके स्रोत को भी तय करता है। आपको बची हुई राशि के साथ एक open-items एक्सट्रैक्ट चाहिए, न कि अब तक जारी किए गए प्रत्येक इनवॉइस की सूची।

इसकी सीमा यह है कि परिभाषाएं किसी चीज़ की गणना नहीं करती हैं। वे केवल आपको गलत गणना करने से रोकती हैं।

विकल्प 2: श्रेणी कॉलम बनाएं, फिर कुल योग को पिवट करें

विलंबित दिनों (days overdue) की गणना संदर्भ तिथि (as-of date) में से due date को घटाकर करें, फिर उस संख्या को एक श्रेणी लेबल से जोड़ें। TODAY आपको एक लाइव संदर्भ तिथि देता है, और DATEDIF दो तारीखों के बीच के दिनों की संख्या बताता है।

लेबल के लिए, छह महीने बाद देखने पर नेस्टेड IF स्टेटमेंट की तुलना में IFS अधिक पठनीय होता है। फिर SUMIFS के साथ ग्राहक और श्रेणी के अनुसार कुल योग निकालें, जिससे प्रत्येक पंक्ति के आधार पर गणना की जांच करना आसान रहता है।

जब रिपोर्ट को दूसरों के साथ साझा किया जाना हो, तो TODAY के बजाय एक निश्चित (hard-coded) संदर्भ तिथि (as-of date) का उपयोग करें। एक ऐसी फ़ाइल जो अगले सप्ताह अपने आप गणना को बदल देती है, वह किसी के इनबॉक्स में पहले से मौजूद संस्करण से मेल नहीं खाएगी।

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

विकल्प 3: आंकड़ों के बगल में एक नियमों का टैब रखें

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

यही वह चीज़ है जो रिपोर्ट को तब भी उपयोगी बनाए रखती है जब इसे कोई और चलाता है। हालांकि, महीने के अंत की समय-सीमा नजदीक होने पर इसी टैब को अक्सर छोड़ दिया जाता है।

इसकी सीमा यह है कि नियमों का टैब केवल निर्णयों को दर्ज करता है, उन्हें लागू नहीं करता। किसी को अभी भी हर चक्र में प्रत्येक नियम को लागू करना पड़ता है। स्प्रेडशीट में लेनदेन का मिलान करने के बारे में हमारी गाइड उस मिलान कार्य को कवर करती है जो इसे आधार प्रदान करता है।

साझा सीमा। ये तीनों विकल्प यह मानकर चलते हैं कि आप एक साफ-सुथरे open-items एक्सट्रैक्ट से शुरुआत कर रहे हैं। जब स्रोत एक मूल इनवॉइस निर्यात और एक अलग भुगतान फ़ाइल हो, तो वास्तविक काम श्रेणियों में बांटने से पहले उन्हें आपस में जोड़ना होता है।

Powerdrill Bloom के साथ aging report कैसे बनाएं

चरण 1: अपना इनवॉइस और भुगतान डेटा अपलोड करें

open-items निर्यात, या इनवॉइस और भुगतान फ़ाइलों को एक साथ अपलोड करें। Powerdrill Bloom अपलोड होते ही कॉलम का विश्लेषण करता है, जिससे किसी भी श्रेणी की गणना होने से पहले ही छूटी हुई due dates, खाली राशियां और डुप्लिकेट इनवॉइस नंबर सामने आ जाते हैं।

चरण 2: प्राकृतिक भाषा में श्रेणियों के नियमों का वर्णन करें

नियमों को बनाने के बजाय केवल उन्हें बताएं। जैसे कि आप किसी विशिष्ट तिथि के अनुसार due date से गणना कर रहे हैं। श्रेणियों की सीमाएं बताएं, और कहें कि राशियां प्राप्त भुगतानों को घटाकर होनी चाहिए।

फिर उसी चरण में जांच के लिए कहें। पूछें कि किन इनवॉइस का भुगतान इनवॉइस राशि से अधिक है, और किनकी due dates उनकी invoice dates से पहले की हैं। फिर पूछें कि क्या श्रेणियों का कुल योग प्राप्य शेष से मेल खाता है।

चरण 3: चार्ट, रिपोर्ट या डेक निर्यात करें

प्रति-ग्राहक aging तालिका, श्रेणियों के वितरण का चार्ट, या सबसे पुराने शेष के क्रम में व्यवस्थित कलेक्शन सूची प्राप्त करें।

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

	मैन्युअल तरीका	Powerdrill Bloom
इनवॉइस को भुगतानों से जोड़ना	प्रति फ़ाइल लुकअप फ़ॉर्मूले	दोनों अपलोड करें और पूछें
संदर्भ तिथि (as-of date) बदलना	दोबारा गणना और सत्यापन करना	नई तारीख बताएं
आंशिक भुगतानों को समायोजित करना	मैन्युअल बैलेंस कॉलम	भुगतानों को घटाकर शेष राशि मांगें
कुल योग को लेज़र से मिलाना	हर चक्र में मैन्युअल जांच	पूछें कि क्या कुल योग मेल खाता है

बीच की पंक्तियों में ही पूरा महीना निकल जाता है। श्रेणियों में बांटना तो केवल अंकगणित है; एक साफ-सुथरी open-items सूची प्राप्त करना ही वास्तविक काम है।

आम गलतियाँ

due date के बजाय गलती से invoice date से गणना करना। कलेक्शन के लिए, due date लगभग हमेशा सही होती है। आप जो भी चुनें, उसे रिपोर्ट पर अवश्य लिखें.

बची हुई राशि के बजाय इनवॉइस की पूरी राशि दिखाना। आंशिक रूप से भुगतान किए गए इनवॉइस को उसकी बकाया राशि के साथ श्रेणी में रखा जाना चाहिए। पूरी राशि दिखाने से हर कुल योग बढ़ जाता है।

TODAY फ़ंक्शन को साझा की गई फ़ाइल की गणना को बदलने देना। रिपोर्ट भेजने से पहले संदर्भ तिथि (as-of date) को फ्रीज कर दें, अन्यथा दो लोग एक ही फ़ाइल में अलग-अलग आंकड़े देखेंगे।

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

इनवॉइस के बजाय ग्राहक के अनुसार श्रेणियों में बांटना। श्रेणियां प्रति इनवॉइस होती हैं, फिर उन्हें प्रति ग्राहक जोड़ा जाता है। किसी ग्राहक की औसत अवधि निकालने से सबसे पुराना आइटम छिप जाता है, जिसकी आपको वास्तव में आवश्यकता होती है।

लेज़र से कभी मिलान न करना। श्रेणियों का कुल योग प्राप्य नियंत्रण शेष के बराबर होना चाहिए। इस जांच को छोड़ने पर रिपोर्ट केवल दिखावे की रह जाती है।

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

निष्कर्ष

गणना की तारीख तय करें, बची हुई राशि का उपयोग करें, संदर्भ तिथि को फ्रीज करें, और कुल योग को लेज़र से मिलाएं। ये चार चीजें एक ऐसी रिपोर्ट (जिस पर लोग कार्रवाई कर सकें) और एक ऐसी तालिका (जिस पर लोग बहस करें) के बीच का अंतर तय करती हैं।

जो चीज़ इसे थकाऊ और समय लेने वाली बनाती है वह यह है कि यह पूरी प्रक्रिया आज की तारीख के सापेक्ष होती है, इसलिए यह कभी खत्म नहीं होती। हर चक्र में वही जुड़ाव और जांचें फिर से सामने आ जाती हैं।

यदि आपके महीने का अंत इसी काम में निकल जाता है, तो अपने इनवॉइस और भुगतान निर्यात पर Powerdrill Bloom आज़माएं। PDF वित्तीय विवरणों को चार्ट में बदलने के बारे में हमारी गाइड और AI cash flow analysis पेज भी देखें।

अक्सर पूछे जाने वाले प्रश्न

प्राप्य खातों (accounts receivable) की aging report में मानक श्रेणियां क्या हैं?

अधिकांश रिपोर्टों में 0–30, 31–60, 61–90 और 90 दिनों से अधिक की श्रेणियों का उपयोग किया जाता है, जिसमें अक्सर एक वर्तमान या अभी देय नहीं कॉलम भी होता है। ये सीमाएं एक परंपरा हैं न कि कोई नियम, इसलिए यह स्पष्ट रूप से बताएं कि आपने किसका उपयोग किया है।

क्या मुझे इनवॉइस की गणना invoice date से करनी चाहिए या due date से?

यदि आप यह जानना चाहते हैं कि ग्राहक ने भुगतान में कितनी देरी की है, तो due date का उपयोग करें, जो कि कलेक्शन का सामान्य उद्देश्य होता है। यदि आप यह जानना चाहते हैं कि कागजी कार्रवाई कितनी पुरानी है, तो invoice date का उपयोग करें।

मैं आंशिक भुगतान को कैसे संभालूं?

मूल इनवॉइस राशि के बजाय बची हुई राशि दिखाएं, और उस राशि को एक ही श्रेणी में रखें। इनवॉइस सूची के बजाय open-items एक्सट्रैक्ट से काम करने पर यह प्रक्रिया अपने आप पूरी हो जाती है.

मुझे किन Excel फ़ंक्शंस की आवश्यकता होगी?

संदर्भ तिथि (as-of date) के लिए TODAY या एक निश्चित तारीख, और विलंबित दिनों के लिए DATEDIF। IFS श्रेणी लेबल निर्धारित करता है, और SUMIFS ग्राहक तथा श्रेणी के अनुसार कुल योग निकालता है। इनमें से कोई भी जटिल नहीं है; परिभाषाएं ही सबसे कठिन हिस्सा हैं।

रिपोर्ट को कितनी बार फिर से बनाया जाना चाहिए?

कम से कम मासिक रूप से, और यदि कलेक्शन सक्रिय है तो साप्ताहिक रूप से, क्योंकि प्रत्येक श्रेणी संदर्भ तिथि के सापेक्ष होती है। आपके द्वारा साझा किए जाने वाले प्रत्येक संस्करण पर उस तारीख को फ्रीज कर दें।