ऐसे खर्च अप्रूवल नियम बनाएँ, जिन्हें फ़ाइनेंस टीम आसानी से समझा सके

फ़ाइनेंस टीमों को स्पष्ट अप्रूवल नियम क्यों चाहिए

«हर खर्च को मैनेजर मंज़ूर करे» जैसा सरल नियम तब काम नहीं करता, जब खर्च कई टीमों, बजटों या राशि सीमाओं से जुड़ने लगे। सेल्स मैनेजर समझ सकता है कि किसी कर्मचारी को क्लाइंट के साथ डिनर की ज़रूरत क्यों है, लेकिन उसे यह पता नहीं हो सकता कि कॉस्ट सेंटर में बजट बचा है या फ़ाइनेंस को भी उस खर्च की समीक्षा करनी होगी।

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

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

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

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

नियम सरल भाषा में लिखें। हर नियम में यह स्पष्ट होना चाहिए:

• क्या अप्रूवल शुरू करता है, जैसे राशि, खर्च का प्रकार या कॉस्ट सेंटर
• अनुरोध को कौन मंज़ूर करेगा और वह क्या जाँचेगा
• दूसरी मंज़ूरी कब चाहिए
• सामान्य अप्रूवर अनुपस्थित होने पर क्या होगा
• अपवाद को कौन मंज़ूर कर सकता है

फ़ाइनेंस, मैनेजर और कर्मचारी नियम को एक ही तरह समझें। नीति पर सहमति बनने के बाद AppMaster जैसा नो-कोड प्लेटफ़ॉर्म नियमों के नक्शे को फ़ॉर्म, अप्रूवल प्रोसेस और नोटिफ़िकेशन में बदल सकता है, बिना नीति के फैसलों को स्क्रीन डिज़ाइन में छिपाए।

हर अनुरोध के लिए ज़रूरी जानकारी से शुरुआत करें

अप्रूवर के पास इतना संदर्भ होना चाहिए कि वह टिप्पणियों में अतिरिक्त जानकारी माँगे बिना निर्णय ले सके। फ़ाइनेंस को फ़ॉर्म बनाने या खर्च अप्रूवल वर्कफ़्लो सेट करने से पहले ज़रूरी जानकारी पर सहमति कर लेनी चाहिए।

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

हर अनुरोध में ये मूल बातें एक समान प्रारूप में दर्ज होनी चाहिए:

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

ज़रूरी फ़ील्ड को वास्तविक निर्णय से जोड़ें। $25 का मासिक सॉफ़्टवेयर सब्सक्रिप्शन हो तो सप्लायर, राशि, कॉस्ट सेंटर और कारोबारी उद्देश्य काफ़ी हो सकते हैं। $4,000 के लैपटॉप के लिए उपयोगकर्ता, बदलने का कारण और एसेट अनुरोध संख्या भी चाहिए हो सकती है। हर अनुरोध के लिए एक लंबा फ़ॉर्म खराब डेटा देता है और कर्मचारियों को परेशान करता है।

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

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

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

अप्रूवल सीमाओं का स्पष्ट नक्शा बनाएँ

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

याद रखने में आसान, कम संख्या वाली श्रेणियाँ रखें। विभाग का मैनेजर $500 तक के अनुरोध मंज़ूर कर सकता है, फ़ाइनेंस मैनेजर $501 से $2,500 तक और विभाग प्रमुख इससे बड़ी राशि मंज़ूर कर सकता है। आम तौर पर कम श्रेणियों से मार्ग तय करने की गलतियाँ भी कम होती हैं।

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

खर्च का प्रकार भी महत्वपूर्ण है। $1,000 का क्लाइंट डिनर और $1,000 का लैपटॉप हमेशा एक जैसी समीक्षा नहीं माँगते। उपकरण के लिए IT या प्रोक्योरमेंट की मंज़ूरी चाहिए हो सकती है, जबकि सामान्य सीमा के भीतर यात्रा के लिए केवल कर्मचारी का मैनेजर काफ़ी हो सकता है।

नीति पर सहमति बनाते समय ऐसी सरल तालिका रखें:

जब दो लोगों की मंज़ूरी चाहिए, तो स्पष्ट करें कि वे क्रम से मंज़ूर करेंगे या एक साथ, और भुगतान से पहले दोनों के निर्णय ज़रूरी हैं या नहीं। $1,800 का सॉफ़्टवेयर अनुरोध पहले कॉस्ट सेंटर मैनेजर और फिर फ़ाइनेंस के पास जा सकता है। प्रतिबंधित प्रोजेक्ट बजट पर लगाया गया $3,000 का अनुरोध बजट मालिक और फ़ाइनेंस, दोनों की मंज़ूरी माँग सकता है, भले ही कर्मचारी का मैनेजर पहले ही इसे मंज़ूर कर चुका हो।

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

कॉस्ट सेंटर के आधार पर ज़िम्मेदारी तय करें

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

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

मालिकाना व्यवस्था सरल रखें:

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

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

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

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

डेलीगेट और अनुपस्थिति के नियम तय करें

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

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

एक व्यावहारिक नियम यह हो सकता है कि विभाग मैनेजर नियोजित छुट्टी के दौरान अधिकतम 30 दिनों के लिए एक डेलीगेट नियुक्त कर सके। अनुपस्थिति इससे लंबी हो तो फ़ाइनेंस नियुक्ति की समीक्षा और नवीनीकरण करे। इससे यह जाँचने का स्पष्ट समय मिलता है कि डेलीगेट के पास अभी भी सही अधिकार है या नहीं।

अप्रूवल ट्रेल स्पष्ट रखें

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

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

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

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

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

देरी पैदा करने से पहले अपवाद मार्ग तय करें

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

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

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

हर अपवाद का मालिक तय करें

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

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

जवाब की समय सीमा और एस्केलेशन जोड़ें

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

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

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

किसी वास्तविक अनुरोध को शुरू से अंत तक देखें

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

नोटिफ़िकेशन भेजने से पहले वर्कफ़्लो राशि और कॉस्ट सेंटर पढ़ता है। तय नियमों के अनुसार $1,000 से $2,500 की खरीद के लिए कॉस्ट सेंटर मालिक और फ़ाइनेंस समीक्षक की मंज़ूरी चाहिए। अनुरोध पहले मार्केटिंग बजट मालिक के पास जाता है।

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

दोनों की मंज़ूरी मिलने पर सिस्टम निर्णय, अप्रूवर के नाम और समय दर्ज करता है। कोऑर्डिनेटर को स्टेटस अपडेट मिलता है और वह खरीदारी आगे बढ़ा सकता है। फ़ाइनेंस अनुरोध अस्वीकार करे तो रिकॉर्ड में कारण रहता है, जैसे «वर्तमान कॉन्ट्रैक्ट समाप्त होने तक मौजूदा रिपोर्टिंग टूल का इस्तेमाल करें»।

कॉस्ट सेंटर मालिक अनुपस्थित हो

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

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

अनुरोध में अपवाद की ज़रूरत हो

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

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

यह उदाहरण उन क्षेत्रों की जाँच करता है, जहाँ अक्सर भ्रम होता है: राशि सीमा, मालिकाना, अस्थायी कवरेज और अपवाद। हर मार्ग का मालिक और दर्ज परिणाम तय होने के बाद ही अनुरोध स्क्रीन बनाएँ।

अप्रूवल नियमों की आम गलतियों से बचें

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

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

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

कुछ जाँचें अधिकांश भ्रम रोक सकती हैं:

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

आखिरी नियम हितों के टकराव से प्रक्रिया की रक्षा करता है। अनुरोधकर्ता कॉस्ट सेंटर चुन सकता है, लेकिन अप्रूवर का चयन स्वीकृत नियमों से वर्कफ़्लो करे। सेल्स मैनेजर $900 का क्लाइंट डिनर सेल्स कॉस्ट सेंटर पर भेजे, तो अनुरोध उस बजट मालिक के पास जाए, न कि पसंदीदा मैनेजरों की सूची में।

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

फ़ॉर्म बनाने से पहले जल्दी से जाँच करें

अस्पष्ट नियमों को फ़ॉर्म ठीक नहीं कर सकता। प्रस्तावित अप्रूवल नक्शे को एक छोटे दस्तावेज़ में रखें, जिसे फ़ाइनेंस, बजट मालिक और ऑपरेशंस कर्मचारी आसानी से पढ़ सकें।

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

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

लिखित नियमों को कठिन मामलों पर आज़माएँ:

• सक्रिय कॉस्ट सेंटर पर लगाया गया $1,200 का होटल अनुरोध, जिसका सामान्य मालिक उपलब्ध है
• कॉस्ट सेंटर मालिक की छुट्टी के दौरान भेजा गया अनुरोध
• सामान्य सीमा से अधिक ज़रूरी मरम्मत, जिसे तेज़ अपवाद मार्ग चाहिए
• वैध खर्च, जिसमें कॉस्ट सेंटर नहीं है, या ऐसा कॉस्ट सेंटर जिसका वर्तमान मालिक नहीं है

हर मामले का अपेक्षित परिणाम लिखें: अनुरोध किसे मिलेगा, कौन मंज़ूर कर सकता है, कौन-सा प्रमाण चाहिए और किसी के जवाब न देने पर क्या होगा। अगर दो लोग एक ही मामले को अलग तरह से समझते हैं, तो नियम पर और काम चाहिए।

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

सहमत नियमों से वर्कफ़्लो बनाएँ

फ़ाइनेंस के रूटिंग नक्शे पर सहमत होने के बाद हर नियम को ऐसे डेटा में बदलें, जिसे ऐप्लिकेशन सहेज और इस्तेमाल कर सके। अनुरोध में राशि, मुद्रा, कॉस्ट सेंटर, खर्च का प्रकार, अनुरोधकर्ता, कारोबारी कारण, रसीद और तारीख जैसे फ़ील्ड चाहिए। कर्मचारियों को स्पष्ट स्टेटस भी दिखने चाहिए: Draft, Submitted, Waiting for manager, Waiting for finance, Approved, Rejected और Needs correction।

नीति को स्क्रीन लेआउट से अलग रखें। $500 की सीमा को $750 करना या नया कॉस्ट सेंटर मालिक नियुक्त करना नियम बदलने जितना आसान होना चाहिए, हर फ़ॉर्म फिर से बनाने जितना नहीं।

अनुरोध स्क्रीन से पहले रूटिंग बनाएँ

पहले रूटिंग की शर्तें बनाएँ। $250 से कम अनुरोध कॉस्ट सेंटर मैनेजर को जा सकता है। $250 से $2,000 तक के अनुरोध में मैनेजर और फ़ाइनेंस दोनों चाहिए हो सकते हैं। $2,000 से अधिक अनुरोध में विभाग प्रमुख भी शामिल हो सकता है। क्लाइंट मनोरंजन के लिए किसी भी राशि पर रसीद और फ़ाइनेंस समीक्षा ज़रूरी हो सकती है।

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

लॉजिक स्थिर होने के बाद अनुरोध स्क्रीन बनाएँ। रूटिंग नियमों और फ़ाइनेंस समीक्षा के लिए ज़रूरी जानकारी तथा संबंधित दस्तावेज़ लें। अतिरिक्त सवाल लोगों को धीमा करते हैं और अक्सर असंगत जवाब पैदा करते हैं।

वास्तविक अनुरोधों का परीक्षण करें

रिलीज़ से पहले फ़ाइनेंस को ऐप्लिकेशन में वास्तविक स्थितियों का परीक्षण करना चाहिए:

• सामान्य ऑपरेटिंग कॉस्ट सेंटर पर लगाया गया $90 का सॉफ़्टवेयर सब्सक्रिप्शन
• $600 का होटल दावा, जिसे मैनेजर और फ़ाइनेंस समीक्षा चाहिए
• $3,500 का उपकरण अनुरोध, जिसे अतिरिक्त मंज़ूरी चाहिए
• सामान्य अप्रूवर की अनुपस्थिति में भेजा गया अनुरोध
• गायब रसीद वाला अनुरोध, जिसे फ़ाइनेंस सुधार के लिए लौटाता है

हर परीक्षण में चुने गए अप्रूवर, अनुरोधकर्ता का स्टेटस, रिमाइंडर का समय और ऑडिट रिकॉर्ड जाँचें। अगर फ़ाइनेंस एक या दो वाक्यों में मार्ग नहीं समझा सकता, तो कर्मचारियों के इस्तेमाल से पहले नियम सरल करें।

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