VAT नंबर प्रारूप: हर देश में क्या बदलता है

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

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

VAT नंबर क्या है?

यह एक टैक्स पंजीकरण पहचानकर्ता है। जो कारोबार मूल्य वर्धित कर के दायरे में आता है, वह संबंधित देश के कर प्राधिकरण के पास पंजीकरण कराता है और उसे एक नंबर मिलता है; फिर वही नंबर इनवॉइस पर, रिटर्न में और उस सीमा-पार रिपोर्टिंग में दिया जाता है जिसकी मांग यूरोपीय शैली के सिस्टम करते हैं।

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

यह कंपनी पंजीकरण नंबर भी नहीं है, व्यापक अर्थ में टैक्स पहचानकर्ता भी नहीं है, और लाइसेंस भी नहीं है। एक कारोबार के पास एक साथ कई ऐसे पहचानकर्ता हो सकते हैं, और जो कारोबार पूरी तरह घरेलू स्तर पर व्यापार करता है, उसे VAT नंबर की ज़रूरत कभी पड़े ही नहीं।

कारोबार को इसकी ज़रूरत असल में कब पड़ती है?

इस फ़ील्ड की जो छवि बनी हुई है उससे कहीं ज़्यादा बार, और कुछ बार-बार आने वाली स्थितियों में।

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

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

देश दर देश क्या बदलता है?

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

उस शुरुआती निरीक्षण से आगे, फ़र्क़ ठीक वही हैं जो सख़्त नियम तोड़ देते हैं।

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

वैध प्रारूप और पंजीकृत कारोबार एक ही बात है?

नहीं, और इन दोनों के बीच का फ़ासला इस फ़ील्ड के बारे में समझने लायक सबसे उपयोगी चीज़ है।

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

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

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

टीमों को अपने नियम ख़ुद लिखने से बचना चाहिए?

क्योंकि नियम राष्ट्रीय हैं, समय-समय पर संशोधित होते हैं, और बहुत हैं; और क्योंकि घर का बनाया सत्यापक एक रखरखाव का बोझ है जो सबसे कम दिखने वाली दिशा में नाकाम होता है।

सोचें कि स्वयं लिखा नियम असल में क्या करता है। वह एक देश की बनावट दर्ज कर लेता है। उसे एक या दो देशों के कुछ उदाहरणों पर टेस्ट किया जाता है। वह एक ही सामान्य एरर दिखाता है। और जब कोई कर प्राधिकरण बनावट बदल देता है, तो कुछ नहीं बताता — नियम बस असली ग्राहकों को अस्वीकार करने लगता है, धीरे-धीरे, उन देशों में जहां टीम का कोई व्यापार नहीं है। नाकामी चुपचाप होती है और उसकी कीमत सेल्स टीम चुकाती है।

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

डेवलपर्स के लिए: प्रारूप जांच और रजिस्टर जांच अलग फ़ंक्शन हैं

ज़िम्मेदारी को दो फ़ंक्शनों में बांटें, दो अलग रिटर्न प्रकारों के साथ, और इन्हें एक ही एरर संदेश साझा न करने दें।

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

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

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

अगले कदम

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