ब्लॉग
अँधेरी मेज़ पर पीतल के स्केल से तीन कागज़ी पट्टियों को सीध में लाता एक हाथ।

17 अगस्त 20265 मिनट का पाठАдминистратор

रिकंसिलिएशन में फ़र्क शून्य निकला: फिर भी दिन बंद करने की वजह क्यों नहीं

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

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

एक काल्पनिक दिन देखें

मान लीजिए प्रोवाइडर के पास ओपनिंग बैलेंस 10 000 है, आवक 250 000, रिफ़ंड 8 000, फ़ीस 4 500 और बैंक को पेआउट 232 500। तब हिसाब से क्लोज़िंग बैलेंस 10 000 + 250 000 − 8 000 − 4 500 − 232 500 = 15 000 है। अगर रिपोर्ट भी यही 15 000 दिखाती है, तो बैलेंस की हलचल समझ में आ गई। लेकिन अभी यह साबित करना बाकी है कि रिफ़ंड सही ऑर्डर के हैं, फ़ीस सही गिनी गई है और पेआउट सच में मिल गया है।

मान लीजिए बैंक में अभी 232 500 क्रेडिट नहीं हुए। पैसा दोबारा भेजने के बजाय बैच के रेफ़रेंस और अपेक्षित तारीख के साथ "रास्ते में पेआउट" वाली एंट्री बनाएँ। अगर दो पेमेंट की रकम एक जैसी 1 200 है, तो रकम का मेल उनमें से किसी को भी चुनने का आधार नहीं देता। गायब आइडेंटिफ़ायर के लिए अतिरिक्त पुष्टि चाहिए। वरना दो गलतियाँ एक-दूसरे को छिपा सकती हैं।

शून्य अंतर की भी जाँच की जा सकती है

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

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

इनपुट की पूर्णता का कंट्रोल भी बनाए रखें: पंक्तियों की संख्या, शुरुआती और आखिरी तारीखें, करेंसी, अवधि की शुरुआत और अंत, एक्सपोर्ट के सभी हिस्सों की मौजूदगी। अगर रिपोर्ट तय 23:59 की जगह 17:00 बजे कट जाती है, तो शाम के "खोए" पेमेंट ढूँढना सिर्फ़ झूठी समस्याओं की एक और कतार बनाएगा। पहले पूरा स्रोत वापस लाएँ।

पहले दिन की सीमाएँ तय करें

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

हर रिपोर्ट एक ही काम नहीं करती। Stripe बताता है कि Balance summary अवधि की हलचल और पेआउट दिखाती है, लेकिन पेआउट को खास पेमेंट से नहीं जोड़ती। इसलिए यह रिपोर्ट बैलेंस जाँचने के लिए ठीक है, हर पेआउट की संरचना दोबारा बनाने के लिए नहीं। स्रोत: Stripe, Balance summary report।

तीन स्तरों पर मिलान करें

  1. 1.ऑर्डर और ट्रांज़ैक्शन। अंदरूनी आइडेंटिफ़ायर को प्रोवाइडर के आइडेंटिफ़ायर, इवेंट के प्रकार, रकम और करेंसी से जोड़ें। रिफ़ंड को मूल पेमेंट का रेफ़रेंस देना चाहिए, लेकिन वह अलग ट्रांज़ैक्शन बना रहे।
  2. 2.ट्रांज़ैक्शन और सेटलमेंट बैच। ग्रॉस आवक, रिफ़ंड, फ़ीस और दूसरे पुष्ट एडजस्टमेंट इकट्ठा करें। बैच की नेट रकम जाँचें।
  3. 3.बैच और बैंक। उपलब्ध आइडेंटिफ़ायर, करेंसी और रकम से पेआउट को बैंक क्रेडिट से मिलाएँ। तारीखों में स्वीकार्य अंतर रकम की टॉलरेंस से अलग तय करें।

Adyen की Settlement details report में ट्रांज़ैक्शन, फ़ीस, डिपॉज़िट के एडजस्टमेंट और पेआउट होते हैं; MerchantPayout रिकॉर्ड बैच को बैंक क्रेडिट से जोड़ने में मदद करता है। यह इस बात का उदाहरण है कि सिर्फ़ सफल पेमेंट की एक्सपोर्ट रिकंसिलिएशन के लिए काफ़ी क्यों नहीं। स्रोत: Adyen, Settlement details report।

अंतर की कतार को कारण बताना चाहिए

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

Stripe की पेआउट रिकंसिलिएशन रिपोर्ट ऑटोमैटिक पेआउट के लिए बनी है; इंस्टेंट पेआउट के लिए Stripe शामिल ट्रांज़ैक्शन की संरचना अपने आप तय नहीं करता। इसलिए रिकंसिलिएशन का तरीका पेआउट के खास मोड को ध्यान में रखकर चुनना चाहिए। स्रोत: Stripe, Payout reconciliation report।

अंतर की उम्र वादा किए गए इवेंट से गिनें

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

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

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

दिन बंद होने के बाद क्या खुला रहता है

मेल को संख्या और रकम दोनों के हिसाब से दिखाएँ। P2P सर्विस के लिए यूज़र्स के बीच देनदारियों के बँटवारे का मिलान करें: कुल बैंक बैलेंस का मेल यह साबित नहीं करता कि हर यूज़र का बैलेंस सही है।

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

स्रोत

  1. 1.docs.stripe.com/reports/balance
  2. 2.docs.adyen.com/reporting/settlement-reconciliation/transaction-level/settlement-details-report
  3. 3.docs.stripe.com/reports/payout-reconciliation

टिप्पणियाँ · 0

अभी कोई टिप्पणी नहीं — पहले बनें।

लॉग इन · टिप्पणी करने के लिए लॉग इन करें।