e-Way Bill अब अधिक सख़्त हो रहे हैं —1 अगस्त 2026 से शिप-टू GSTIN अनिवार्य होगा

लखनऊ के किसी निर्माता या व्यापारी के लिए, जो माल किसी जॉब-वर्कर, किसी शाखा कार्यालय, या ख़रीदार के किसी पृथक डिलीवरी पते पर भेजता है, एक छोटा-सा डेटा फ़ील्ड शीघ्र ही उस अंतर का कारण बनने वाला है जो यह तय करेगा कि e-way bill सुचारू रूप से जनरेट होता है या डिस्पैच के समय अस्वीकृत हो जाता है। गुड्स एंड सर्विसेज़ टैक्स नेटवर्क (GSTN) ने 17 जून 2026 की एक परामर्शिका जारी की है, जिसके अनुसार 1 अगस्त 2026 से e-Invoice और e-Way Bill API के व्यापक लेन-देनों में "शिप-टू GSTIN" फ़ील्ड अनिवार्य हो जाएगी — साथ ही एक नई, स्वैच्छिक सुविधा भी शुरू की गई है जिससे डिलीवरी पूर्ण होने के बाद e-way bill को औपचारिक रूप से बंद किया जा सकेगा। इनमें से कोई भी परिवर्तन सीजीएसटी अधिनियम के किसी प्रावधान में संशोधन नहीं करता; दोनों ही सिस्टम-स्तरीय परिवर्तन हैं। परंतु उत्तर प्रदेश के किसी भी व्यवसाय के लिए, जो ERP, GST सुविधा प्रदाता (GSP), या एप्लिकेशन सर्विस प्रोवाइडर (ASP) के माध्यम से e-invoice या e-way bill जनरेट करता है, यह वह प्रकार का परिवर्तन है जो वास्तविक व्यवधान पैदा करता है यदि इसकी जानकारी जुलाई के अंतिम सप्ताह में ही मिले।

परामर्शिका वास्तव में क्या कहती है

GSTN की पूर्ववर्ती 20 मई 2026 की परामर्शिका ने सबसे पहले यह संकेत दिया था कि Bill-to/Ship-to लेन-देनों में शिप-टू GSTIN अनिवार्य रूप से दर्ज किया जाएगा, तथा जहाँ कंसाइनी अपंजीकृत हो, वहाँ "URP" (Unregistered Person) मान दर्ज किया जाएगा। इसके बाद व्यापार संघों, ERP विक्रेताओं, GSP, ASP और निजी Invoice Registration Portals ने इस बारे में स्पष्टीकरण माँगा कि जहाँ e-way bill को e-invoice के साथ ही जनरेट किया जाता है, या बाद में Invoice Reference Number (IRN) का उपयोग करके जनरेट किया जाता है, वहाँ यह अपेक्षा कैसे लागू होगी। GSTN की 17 जून 2026 की अनुवर्ती परामर्शिका इसी प्रश्न का उत्तर देती है, और साथ ही नीचे वर्णित स्वैच्छिक e-way bill क्लोज़र सुविधा भी प्रस्तुत करती है। दोनों परिवर्तन जून के मध्य से Sandbox वातावरण में परीक्षण हेतु जारी किए गए, और 1 अगस्त 2026 से Production में प्रभावी होंगे।

अनिवार्य शिप-टू GSTIN कहाँ-कहाँ लागू होगा

यह अपेक्षा किसी एक स्क्रीन या एक API तक सीमित नहीं है। GSTN की परामर्शिका पाँच विशिष्ट प्रवाहों (flows) को सूचीबद्ध करती है जहाँ यह लागू होती है: IRN और e-way bill को एक साथ जनरेट करना; किसी विद्यमान IRN का उपयोग करके बाद में e-way bill जनरेट करना; वास्तविक Bill-to/Ship-to लेन-देन (जहाँ ख़रीदार और कंसाइनी अलग-अलग व्यक्ति हों); "combination" लेन-देन जिनमें Bill-to/Ship-to और Bill-from/Dispatch-from दोनों शामिल हों; और, पृथक रूप से, डिलीवरी के बाद e-way bill की नई स्वैच्छिक क्लोज़र प्रक्रिया।

• IRN और e-way bill को एक साथ जनरेट करना: जब भी शिप-टू लीगल नाम और पता दर्ज किए गए हों और e-way bill जनरेशन का अनुरोध भी किया गया हो, तो फ़ील्ड ShipDtls.Gstin सशर्त रूप से अनिवार्य हो जाएगी।
• विद्यमान IRN का उपयोग करके e-way bill जनरेट करना: इस API में ExpShipDtls के अंतर्गत एक नई फ़ील्ड, Gstin, जोड़ी गई है और अब यह अनिवार्य है। एक वैकल्पिक ट्रेड नेम फ़ील्ड, TrdNm, भी जोड़ी गई है।
• जहाँ कोई GSTIN लागू नहीं होता: जहाँ भी शिप-टू पक्ष अपंजीकृत हो, या लेन-देन पर GSTIN वास्तव में लागू न होता हो, वहाँ "URP" मान अभी भी दर्ज किया जा सकता है।

वे सत्यापन जो अब किसी बिल को सीधे अस्वीकृत कर सकते हैं

अनिवार्य फ़ील्ड के साथ-साथ, GSTN ने ऐसे सत्यापन (validations) भी जोड़े हैं जिन्हें 1 अगस्त से पहले किसी अनुपालन टीम को जान लेना चाहिए। किसी वास्तविक Bill-to/Ship-to लेन-देन में, शिप-टू GSTIN, बिल-टू GSTIN के समान नहीं हो सकता — दोनों को अलग-अलग व्यक्ति माना जाता है, और यदि शिप-टू फ़ील्ड में बिल-टू GSTIN ही दोहराया जाता है तो सिस्टम उसे अस्वीकृत कर देगा। सिस्टम यह भी जाँचता है कि एक वैध GSTIN दर्ज किया गया है, कि शिप-टू स्टेट कोड GSTIN से मेल खाता है, और कि शिप-टू पिन कोड उसी राज्य से संबंधित है। Sandbox वातावरण में इन जाँचों के लिए संकेतात्मक त्रुटि कोड सूचीबद्ध हैं — उदाहरण के लिए, शिप विवरण दिए जाने पर शिप-टू GSTIN का अनुपस्थित होना, बिल-टू/शिप-टू GSTIN का दोहराया जाना, तथा स्टेट-कोड या पिन-कोड में असंगति — अतः डिस्पैच के समय अस्वीकृत हुआ कोई e-way bill अत्यंत संभावना है कि इन्हीं फ़ील्डों में से किसी एक से जुड़ा हो।

दो अपवाद जो जानने योग्य हैं: निर्यात, तथा B2B/SEZ

परामर्शिका निर्यात तथा B2B/SEZ लेन-देनों के साथ भिन्न व्यवहार करती है, और यह अंतर व्यावहारिक दृष्टि से महत्वपूर्ण है। निर्यात e-way bill के लिए, IRN चरण में दिए गए शिप विवरण — जिसमें GSTIN भी शामिल है — को उस IRN का उपयोग करके e-way bill जनरेट करते समय बदला जा सकता है, और जहाँ निर्यात परिदृश्य पर कोई घरेलू पंजीकृत शिप-टू GSTIN लागू नहीं होता, वहाँ "URP" की अनुमति है। B2B और SEZ लेन-देनों के लिए स्थिति उलट है: IRN चरण में तय किए गए शिप विवरण को बाद में e-way-bill-by-IRN चरण में बदला नहीं जा सकता — हालाँकि यदि IRN चरण में GSTIN ख़ाली छोड़ दिया गया था, तो इसे लागू सत्यापनों के अधीन e-way bill जनरेट करते समय जोड़ा जा सकता है। GSTN ने यह भी स्पष्ट किया है कि कोई पुराना IRN, जो Bill-to और Ship-to दोनों फ़ील्डों में समान GSTIN के साथ जनरेट किया गया था, नई "अलग होना चाहिए" वाली जाँच में फँसे बिना एक सामान्य e-way bill जनरेट करता रहेगा।

जो शिप-टू फ़ील्ड कभी वैकल्पिक कागज़ी कार्रवाई हुआ करती थी, वह अब एक कठोर सत्यापन बनने जा रही है — यही वह अंतर है जो e-way bill के जनरेट होने और डिस्पैच पर माल रुक जाने के बीच है।

e-way bill बंद करने का एक नया — किंतु अभी भी वैकल्पिक — तरीक़ा

दूसरा, असंबंधित परिवर्तन e-way bill के लिए एक स्वैच्छिक क्लोज़र सुविधा है, जिसका उद्देश्य यह दर्ज करना है कि डिलीवरी वास्तव में पूर्ण हो चुकी है। इसका उपयोग आपूर्तिकर्ता, प्राप्तकर्ता, लेन-देन में शामिल परिवहनकर्ता, या उस चालक/प्राधिकृत व्यक्ति द्वारा किया जा सकता है जिसका मोबाइल नंबर इस प्रयोजन हेतु दर्ज कराया गया था। क्लोज़र e-way-bill-वार अथवा तिथि-वार किया जा सकता है, या तो लॉगिन के बाद GST पोर्टल के माध्यम से, या एक नई क्लोज़र API के माध्यम से जिसमें e-way bill नंबर, क्लोज़र तिथि, और टिप्पणियाँ आवश्यक हैं — यह उन व्यवसायों के लिए उपयोगी है जो इसे अपने ERP या लॉजिस्टिक्स सिस्टम में एकीकृत करना चाहते हैं।

फ़िलहाल दो व्यावहारिक बातें ध्यान देने योग्य हैं: पहली, अभी कोई पृथक "बंद" (Closed) स्टेटस नहीं है — इस स्थिरीकरण अवधि के दौरान विद्यमान स्टेटस (Active, Cancelled, Discarded) ही लागू रहते हैं, अतः बंद किया गया e-way bill सिस्टम में दृश्यमान रूप से अपना स्टेटस नहीं बदलता। दूसरी, e-way bill को बंद चिह्नित किए जाने के बाद भी ट्रांसपोर्टर अद्यतन करने, वैधता बढ़ाने, या वाहन अद्यतन करने जैसी कार्रवाइयाँ संभव बनी रहती हैं — GSTN ने इसे एक अस्थायी छूट बताया है जिसे सिस्टम स्थिर होने के बाद सख़्त किया जाएगा। क्लोज़र प्रयोजन हेतु चालक के मोबाइल नंबर को दर्ज करने के लिए भी अभी कोई API नहीं है (यह फ़िलहाल केवल पोर्टल के माध्यम से ही संभव है), और यह पता लगाने के लिए भी कोई API नहीं है कि कौन-से बिल पहले ही बंद चिह्नित किए जा चुके हैं।

1 अगस्त 2026 से पहले क्या करें