Form 3CD का प्रत्येक क्लॉज़ और सब-क्लॉज़ उसके शीर्षक, विवरण और जिस सेक्शन का वह उत्तर देता है, उससे मैप किया गया है — ताकि कुछ भी ऐसा फ्री-टेक्स्ट बॉक्स न रहे जिसे आप याददाश्त से भरें। आप पूरी रिपोर्ट को एक ग्रिड के रूप में देखते हैं, और हर आँकड़ा कहाँ से आया।
डेटा-भारी क्लॉज़ — डेप्रिसिएशन (18), TDS/TCS टेबल (34), s.43B और देय-तिथि परीक्षण (26, 20) — आपके इम्पोर्ट किए गए लेजर को पढ़ने वाले नियम-आधारित इंजनों द्वारा गणना किए जाते हैं: वही इनपुट, वही आउटपुट, हर बार, ताकि समीक्षक किसी ब्लैक बॉक्स पर भरोसा करने के बजाय कार्य को पुनः निष्पादित कर सके। निर्णय वाले क्लॉज़ — ICDS (13/14), s.37 (21(a)), डीम्ड डिविडेंड (36A), GST विभाजन (44) — स्वतः निष्कर्षित नहीं किए जाते: इंजन कैंडिडेट और जो नियम वह लागू करेगा उसे सामने लाता है, और स्थिति आपको वापस सौंप देता है। कोई नियम इंजन यह नहीं जान सकता कि 'विविध व्यय — शर्मा' किसी पार्टनर का निजी ऑर्डर है; वह लाइन को फ्लैग करता है, निर्णय आप लेते हैं।
वही पुष्ट रिपोर्ट e-filing JSON (CBDT कोड, वर्तमान यूटिलिटी के विरुद्ध स्कीमा-सत्यापित), सरकारी-प्रारूप वर्कबुक और एक DOCX के रूप में तैयार होती है। एक स्रोत, तीन रेंडर — जो JSON आप अपलोड करते हैं वह उस वर्कबुक से मेल खाता है जिसकी आप समीक्षा करते हैं और उस DOCX से जो आप क्लाइंट के साथ फाइल करते हैं।
हर पूर्व-भरा क्लॉज़ तब तक ड्राफ्ट के रूप में रहता है जब तक ऑडिटर उसकी पुष्टि न कर दे। इंजन प्रस्ताव देता है; निर्णय आप करते हैं। मानवीय हस्ताक्षर के बिना कुछ भी JSON, वर्कबुक या DOCX तक नहीं पहुँचता।
क्लॉज़ 8A s.115BAC रिजीम स्थिति को सामने लाता है; क्लॉज़ 13 और 14 ICDS समायोजन और s.145A समावेशी पद्धति को सामने लाते हैं — लागू सेक्शन और नियम के साथ कैंडिडेट के रूप में प्रस्तावित, ताकि आप इन्हें वर्गीकृत करें। ये व्याख्या पर निर्भर करते हैं, इसलिए इंजन ड्राफ्ट करता है और उद्धृत करता है; वह समायोजन को आपके लिए कभी निष्कर्षित नहीं करता।
डेप्रिसिएशन शेड्यूल एसेट रजिस्टर और परिवर्धन से ब्लॉक-वार गणना किया जाता है — दरें, उपयोग-में-लाई गई तिथियाँ और WDV रोल-फॉरवर्ड — पुनरुत्पाद्य रूप से, ताकि क्लॉज़ 18 उन्हीं संख्याओं से मेल खाए जो आपकी गणना उपयोग करती है। वास्तव में यांत्रिक: वही रजिस्टर अंदर, वही शेड्यूल बाहर।
क्लॉज़ 20 कर्मचारियों के अंशदान को s.36(1)(va) के तहत देय-तिथि के विरुद्ध परखता है; क्लॉज़ 26 s.43B भुगतान-आधार स्वीकृति और अस्वीकृति लागू करता है, जिसमें s.43B(h) MSME समय-निर्धारण भी शामिल है। तिथि परीक्षण, गणना किए गए — समय-अंतर उस तिथि के साथ सामने लाए गए जो उन्हें तय करती है।
s.40(a) के तहत क्लॉज़ 21(b) — जिसमें अनिवासी भुगतानों पर 100% अस्वीकृति शामिल है जहाँ कर नहीं काटा गया — मिलान की गई TDS स्थिति से सीधे गणना किया जाता है, पुनः टाइप नहीं किया जाता। s.37 के तहत क्लॉज़ 21(a) अलग है: इंजन कैंडिडेट लेजर लाइनें (निजी, पूँजीगत या दंडात्मक प्रकृति की) नियम के साथ सामने लाता है, पर कौन-सी क्या है यह आप तय करते हैं — वह किसी लाइन को आपकी ओर से पूँजीगत-बनाम-राजस्व कभी निर्णीत नहीं करता।
क्लॉज़ 34 की TDS और TCS टेबल कटौती-एवं-संग्रह मिलान से गणना की जाती हैं — सेक्शन-वार कटौती-योग्य बनाम कटौती की गई बनाम जमा की गई — जिसमें कमी और s.201(1A) विलंबित-जमा ब्याज जोखिम फ्लैग किए जाते हैं। क्लॉज़ 27(a) CENVAT/ITC केवल उन क्लाइंट्स के लिए ले जाया जाता है जो अभी भी लेगेसी बैलेंस चला रहे हैं; अधिकांश वर्तमान फाइलों में यह एक फुटनोट है, काम नहीं।
क्लॉज़ 36A s.2(22)(e) के तहत डीम्ड-डिविडेंड स्थिति ड्राफ्ट करता है और क्लॉज़ 44 GST व्यय विभाजन — दोनों आपके निर्णय के लिए कैंडिडेट के रूप में, क्योंकि 2(22)(e) संचित लाभ और लाभकारी शेयरधारिता पर निर्भर करता है जिसे लेजर नहीं बताता, और क्लॉज़ 44 केवल तभी टिकता है जब GST डेटा वास्तव में बहियों से मेल खाता हो। सहायक इंजन — s.40(b) के तहत पार्टनर पारिश्रमिक, s.2(22)(e) के तहत डीम्ड डिविडेंड और s.206AB/206CCA अनुपालन — जिन क्लॉज़ को वे छूते हैं उन्हें फीड करते हैं, स्थिति आप पर छोड़ते हुए।
हर पूर्व-भरा आँकड़ा टाइमस्टैम्प किया गया है, जो नियम उसने लागू किया उसे उद्धृत करता है, और जिस स्रोत लेजर पंक्ति से वह आया उससे जुड़ता है — आपकी वर्किंग-पेपर फाइल में एक्सपोर्ट योग्य और पंक्ति-दर-पंक्ति पुनः-निष्पादन-योग्य, ऐसी संख्या नहीं जो बिना किसी मूल के प्रकट हो।
फ्लैग और अपवाद उस मटीरियलिटी से गेट किए जाते हैं जो आप SA 320 के तहत निर्धारित करते हैं, और पैसे-दर-पैसे सूचीबद्ध करने के बजाय एकत्रित किए जाते हैं — सीमा से नीचे की मदें कतार में बाढ़ लाने के बजाय रोल अप हो जाती हैं। एक जूनियर केवल वही देखता है जो गेट पार करता है; जो अस्वीकृतियाँ और समय-अंतराल मायने रखते हैं वे आप तक पहुँचते हैं, ताकि समीक्षा सिकुड़े, न कि पुनः-टाइपिंग की जगह सॉफ्ट फ्लैग छाँटने में बदल जाए।
Tally, Busy या Excel से इम्पोर्ट करें, एकमुश्त चार्ट-ऑफ-अकाउंट्स मैपिंग के साथ ताकि इंजन जाने कि कौन-से समूह मरम्मत बनाम पूँजी और पंजीकृत बनाम अपंजीकृत हैं — क्योंकि किन्हीं दो क्लाइंट्स के COA मेल नहीं खाते। खाली या विकृत GSTIN और PAN, संशोधित दस्तावेज़ और बहु-पंजीकरण क्लाइंट प्रति पंजीकरण रोल अप किए जाते हैं, और जो पंक्तियाँ मैप नहीं होतीं वे चुपचाप अनुमानित न होकर आपकी समीक्षा के लिए रोकी जाती हैं। यह गंदी फाइल को सहन करता है; यह यह दिखावा नहीं करता कि मैपिंग आपकी पुष्टि के लिए नहीं है।
चूँकि JSON, वर्कबुक और DOCX एक पुष्ट स्रोत से रेंडर होते हैं, एक पीयर समीक्षक अपलोड की गई e-filing JSON को वर्किंग-पेपर वर्कबुक और हस्ताक्षरित रिपोर्ट से जोड़ सकता है — वही आँकड़ा, तीन जगह, बिना किसी मौन विचलन के।
अब डेप्रिसिएशन और 43B के आँकड़े क्लॉज़-दर-क्लॉज़ हाथ से कॉपी करना नहीं। यांत्रिक क्लॉज़ गणना किए हुए और उद्धृत आते हैं; निर्णय वाले क्लॉज़ नियम के साथ ड्राफ्ट होकर आते हैं, ताकि केवल निर्णय के लिए ही किसी व्यक्ति की ज़रूरत हो।
केवल वे क्लॉज़ खोलें जिन्हें निर्णय चाहिए, सभी 44 नहीं। हर ड्राफ्ट किया गया आँकड़ा उसकी लेजर पंक्ति और उसके सेक्शन से जुड़ा है, ताकि समीक्षा पुनर्निर्माण नहीं, पुष्टि हो।
रिपोर्ट बचाव-योग्य है — हर क्लॉज़ नियम-उद्धृत, मटीरियलिटी-गेटेड, और SA 230 के तहत पुनः-निष्पादन-योग्य, JSON, वर्कबुक और DOCX पीयर समीक्षा के लिए मेल खाते हुए, और निर्णय वाले क्लॉज़ स्पष्ट रूप से आपके निष्कर्ष के लिए चिह्नित।
