IFRS और आपका ERP

IFRS वास्तव में कौन अपनाता है, और कौन नहीं

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

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

• सऊदी अरब में SOCPA द्वारा अनुमोदित IFRS अनिवार्य है; SOCPA ही अनुमोदित मानक और कोई भी अतिरिक्त स्थानीय आवश्यकताएँ व प्रकटीकरण जारी करता है।
• कनाडा में सार्वजनिक रूप से जवाबदेह उद्यमों के लिए IFRS अनिवार्य है; निजी उद्यम इसके बजाय ASPE लागू कर सकते हैं, जो एक अलग कनाडाई फ़्रेमवर्क है।
• संयुक्त राज्य अमेरिका घरेलू फ़ाइलर्स के लिए FASB द्वारा निर्धारित US GAAP का उपयोग करता है। US GAAP, IFRS नहीं है, और दोनों केवल शब्दों में नहीं, सार में भी अलग हैं।
• IFRS for SMEs एक अलग, हल्का मानक है जिसमें मान्यता, मापन और प्रकटीकरण की आवश्यकताएँ कम हैं; यह वहीं उपलब्ध है जहाँ क्षेत्राधिकार इसकी अनुमति देता है।
• व्यापक MENA क्षेत्र में अपनाने की स्थिति देश और संस्था के प्रकार के अनुसार बदलती है, इसलिए किसी क्षेत्रीय डिफ़ॉल्ट को मान लेने के बजाय लागू फ़्रेमवर्क की पुष्टि करें।

IFRS 15: राजस्व पहले डेटा की समस्या है, नीति की बाद में

IFRS 15 पाँच चरणों का मॉडल देता है: ग्राहक के साथ अनुबंध की पहचान करें, अनुबंध में परफ़ॉर्मेंस ऑब्लिगेशन (निष्पादन दायित्व) पहचानें, ट्रांज़ैक्शन प्राइस तय करें, उस प्राइस को परफ़ॉर्मेंस ऑब्लिगेशन्स में आवंटित करें, और हर दायित्व पूरा होने पर या पूरा होते-होते राजस्व को मान्यता दें। पढ़ने में चरण सरल लगते हैं। असली काम इन्हें वास्तविक अनुबंधों पर लागू करने में है।

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

IFRS 15 को सपोर्ट करने वाला सिस्टम अनुबंध को एक स्वतंत्र ऑब्जेक्ट के रूप में रखता है: उसके भीतर के दायित्व, हर दायित्व को आवंटित प्राइस, समय के साथ राजस्व मान्य होने की स्थिति में प्रगति मापने की विधि और साक्ष्य, परिवर्तनीय प्रतिफल (variable consideration) और उस पर लगाई गई कोई भी सीमा, और इन सबसे बनने वाला मान्यता शेड्यूल, जो अपनी ही लय पर जनरल लेज़र में पोस्ट होता है। Skyline Nexus अनुबंध-स्तर के राजस्व शेड्यूल को बिलिंग शेड्यूल से अलग रखता है, ताकि मान्य राजस्व, बिल की गई राशि और उनसे बनने वाला कॉन्ट्रैक्ट एसेट या लायबिलिटी, तीनों को उसी अनुबंध तक ट्रेस किया जा सके जिससे वे बने।

IFRS 16 लीज़ और वह डेटा जो सिस्टम में होना ही चाहिए

IFRS 16 के तहत पट्टेदार (lessee) सामान्यतः लीज़ को बैलेंस शीट पर लाता है, एक राइट-ऑफ़-यूज़ एसेट और उसके सापेक्ष लीज़ लायबिलिटी को मान्यता देते हुए; अल्पकालिक लीज़ और कम मूल्य की एसेट्स की लीज़ के लिए सीमित छूट उपलब्ध है। आय विवरण पर प्रभाव का स्वरूप भी बदल जाता है: सीधे किराया व्यय की जगह राइट-ऑफ़-यूज़ एसेट का मूल्यह्रास और लायबिलिटी पर ब्याज आ जाते हैं।

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

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

IAS 16, IAS 2, IAS 21 और IAS 36 की रूपरेखा

IAS 16 संपत्ति, संयंत्र और उपकरण (PPE) को नियंत्रित करता है। किसी एसेट के अलग-अलग उपयोगी जीवन वाले महत्वपूर्ण हिस्सों का मूल्यह्रास अलग-अलग किया जाता है, इसीलिए कंपोनेंटाइज़ेशन एक संरचनात्मक आवश्यकता है, रिपोर्टिंग की पसंद नहीं। मानक उपयोगी जीवन और अवशिष्ट मूल्य का अनुमान माँगता है, जिसकी कम से कम हर वर्ष समीक्षा हो, और ऐसी मूल्यह्रास विधि माँगता है जो उस पैटर्न को दर्शाए जिसमें एसेट के लाभ उपभोग होते हैं। प्रारंभिक मान्यता के बाद संस्था एसेट के वर्ग के अनुसार कॉस्ट मॉडल और रीवैल्यूएशन मॉडल में से चुनती है, और रीवैल्यूएशन मॉडल अपने साथ मापन और प्रकटीकरण के अपने दायित्व लाता है।

IAS 2 इन्वेंटरी को लागत और शुद्ध वसूली योग्य मूल्य (NRV) में से कम पर मापता है; लागत FIFO या भारित औसत लागत फ़ॉर्मूले से निर्धारित होती है, जो समान प्रकृति और उपयोग की इन्वेंटरी पर एकरूपता से लागू हो। IFRS के तहत LIFO की अनुमति नहीं है, हालाँकि US GAAP में यह अब भी उपलब्ध है। यह एक अंतर ही रिपोर्ट किए गए बिक्री लागत और क्लोज़िंग इन्वेंटरी को उल्लेखनीय रूप से बदल सकता है, और यही सबसे स्पष्ट कारणों में से एक है कि कोई समूह यह नहीं मान सकता कि उसकी अमेरिकी कॉस्टिंग कॉन्फ़िगरेशन किसी IFRS रिपोर्टिंग संस्था पर वैसे ही लागू हो जाएगी।

IAS 21 फ़ंक्शनल करेंसी, यानी उस प्राथमिक आर्थिक परिवेश की मुद्रा जिसमें संस्था काम करती है, और प्रेज़ेंटेशन करेंसी, यानी वह मुद्रा जिसमें विवरण प्रस्तुत किए जाते हैं, में अंतर करता है। लेन-देन फ़ंक्शनल करेंसी में लेन-देन की तारीख की दर पर दर्ज होते हैं। हर रिपोर्टिंग तिथि पर मौद्रिक मदों का क्लोज़िंग रेट पर पुनः रूपांतरण होता है, जबकि ऐतिहासिक लागत पर मापी गई गैर-मौद्रिक मदों का नहीं। इसे सही ढंग से करने के लिए सिस्टम को केवल रूपांतरित आँकड़ा रखने के बजाय लाइन-स्तर पर मूल लेन-देन मुद्रा, राशि और दर सुरक्षित रखनी होगी।

IAS 36 इम्पेयरमेंट (क्षति) से संबंधित है। संक्षेप में, संस्था हर रिपोर्टिंग तिथि पर आकलन करती है कि क्या कोई संकेत है कि किसी एसेट में इम्पेयरमेंट हो सकता है, और यदि है, तो वह वसूली योग्य राशि का अनुमान लगाती है, जो निपटान लागत घटाकर उचित मूल्य और उपयोग मूल्य (value in use) में से अधिक होती है। जहाँ कैरिंग अमाउंट वसूली योग्य राशि से अधिक हो, वहाँ इम्पेयरमेंट हानि बनती है। गुडविल सहित कुछ एसेट्स का परीक्षण संकेतों की परवाह किए बिना हर वर्ष होता है। निर्णय तैयार करने वाले (preparer) के पास रहते हैं; सॉफ़्टवेयर का योगदान है परीक्षण के लिए एक भरोसेमंद कैरिंग अमाउंट, और परिणाम तथा जहाँ अनुमति हो वहाँ उसके रिवर्सल को दर्ज करने की जगह।

ईमानदार बात: कोई भी सॉफ़्टवेयर IFRS प्रमाणित नहीं है

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

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

वेंडर से क्या पूछें

ऐसे प्रश्न पूछें जिनका उत्तर केवल प्रदर्शन (डेमो) से दिया जा सके। नीचे के हर उत्तर को स्लाइड में बताया नहीं, बल्कि वास्तविक डेटा के साथ उत्पाद में दिखाया जाना चाहिए, और हर आउटपुट बीच में किसी स्प्रेडशीट के बिना जनरल लेज़र से मेल खाना चाहिए।

Skyline Nexus एसेट्स को कंपोनेंट स्तर पर रखता है, हर लेन-देन को उसकी मूल मुद्रा में लागू दर के साथ दर्ज करता है, और ऐसे फ़िक्स्ड एसेट और लीज़ शेड्यूल बनाता है जिन्हें ऑडिटर लेज़र से मिला सके। यह इस बारे में एक कथन है कि सिस्टम क्या रखता है और क्या बनाता है। निर्णय आपके ही रहते हैं, और राय आपके ऑडिटर की ही रहती है।

• क्या फ़िक्स्ड एसेट रजिस्टर एक ही एसेट के ऐसे कंपोनेंट रख सकता है जिनका उपयोगी जीवन, विधि और रीवैल्यूएशन इतिहास अलग हो, और क्या वह ऐसा रजिस्टर बना सकता है जो लेज़र से रिकॉन्साइल हो?
• क्या राजस्व को अनुबंध और परफ़ॉर्मेंस ऑब्लिगेशन के स्तर पर, बिलिंग शेड्यूल से स्वतंत्र रूप से, शेड्यूल किया जा सकता है, और क्या कॉन्ट्रैक्ट एसेट व लायबिलिटी उसी शेड्यूल से निकलते हैं?
• क्या लीज़ को अवधि, भुगतान, डिस्काउंट रेट और पुनर्मापन इतिहास के साथ रखा जा सकता है, और क्या उनसे लायबिलिटी व राइट-ऑफ़-यूज़ एसेट के शेड्यूल और मैच्योरिटी विश्लेषण बनते हैं?
• क्या बहु-मुद्रा लेन-देन-स्तर पर दर्ज होती है, मूल मुद्रा, राशि और दर सुरक्षित रखते हुए, और क्या रिपोर्टिंग तिथि पर मौद्रिक और गैर-मौद्रिक मदों के साथ अलग-अलग व्यवहार होता है?
• क्या इन्वेंटरी कॉस्टिंग को FIFO या भारित औसत के रूप में कॉन्फ़िगर किया जा सकता है, और क्या शुद्ध वसूली योग्य मूल्य के राइट-डाउन दर्ज होते हैं तथा जहाँ मानक अनुमति दे वहाँ रिवर्स किए जा सकते हैं?
• क्या अपरिवर्तनीय ऑडिट ट्रेल, अवधि लॉकिंग, और पोस्टिंग व कॉन्फ़िगरेशन बदलावों पर भूमिका-आधारित नियंत्रण मौजूद है?
• क्या वही मूल डेटा दोबारा प्रविष्टि किए बिना किसी सहायक कंपनी के लिए अलग फ़्रेमवर्क, जैसे ASPE या US GAAP, को सपोर्ट कर सकता है?