IRIS का बग, क़िस्त का हिसाब: FBR को लिखी लाहौर टैक्स बार की चिट्ठी में दर्ज एक सॉफ़्टवेयर ग़लती

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

IRIS क्या है, और यह मामला उस तक कैसे पहुँचता है

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

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

ग़लती कहाँ बैठती है

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

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

रिटर्न एक क़ानूनी दस्तावेज़ है, और यही असली मुद्दा है

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

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

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

कमेटी का गणित: सुसंगत, पर सत्यापित नहीं

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

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

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

उलटा कोण: असली सवाल बग नहीं, जवाबदेही है

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

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

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

आगे की बात

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

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