चार्ट ऑफ़ अकाउंट्स की डिज़ाइन

चार्ट ऑफ़ अकाउंट्स किसलिए होता है

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

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

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

खाता इस प्रश्न का उत्तर देता है कि यह किस प्रकार की चीज़ है। किराया व्यय। व्यापारिक प्राप्य। माल की बिक्री। यह राशि की प्रकृति बताता है, और उसे केवल इसी प्रश्न का उत्तर देना चाहिए। यह कहाँ हुआ, किसके लिए, कौन-सी परियोजना, कौन-सा विभाग, कौन-सी उत्पाद श्रेणी: ये सब वास्तविक प्रश्न हैं, और इनमें से कोई भी राशि की प्रकृति के बारे में नहीं है।

खातों की भरमार वाली विफलता

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

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

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

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

खाते बनाम डाइमेंशन

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

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

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

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

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

नंबरिंग

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

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

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

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

कंट्रोल अकाउंट, और जिनमें सीधे पोस्टिंग नहीं होनी चाहिए

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

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

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

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

जो विवरण आपको बनाने हैं, उनके लिए डिज़ाइन

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

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

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

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

बहु-इकाई और समेकन

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

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

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

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

वास्तव में इसे कैसे डिज़ाइन करें

विधि छोटी है, और अनुशासन उसका पालन करने में है, न कि सीधे खाता सूची पर कूद जाने में, जो आमतौर पर होता है।

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

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

बाद में इसे बदलने की क़ीमत

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

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

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

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

डिज़ाइन ग़लत होने के संकेत

अधिकांश व्यवसाय अपने चार्ट ऑफ़ अकाउंट्स की समीक्षा नहीं करते क्योंकि कोई घटना उन्हें ऐसा करने पर मजबूर नहीं करती। ये वे संकेत हैं कि यह आपको महँगा पड़ रहा है, और ये सभी किसी परियोजना के बिना दिखाई देते हैं।

इनमें से कोई भी अकेले घातक नहीं है। कई एक साथ हों, तो इसका अर्थ है कि संरचना व्यवसाय के उन तथ्यों को समेटे है जो तब से बदल चुके हैं, और उस पर बनी हर रिपोर्ट चुपचाप वह लागत ढो रही है।

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

गवर्नेंस

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

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

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

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

एक उचित डिफ़ॉल्ट

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

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

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