ई-इनवॉइसिंग अनिवार्यताएँ 2026–2028: बढ़ते कारोबारों को अपने सॉफ़्टवेयर से क्या चाहिए

सितंबर 2026 के एक सोमवार को 40 लोगों की एक थोक कंपनी की फ़ाइनेंस मैनेजर के पास एक छोटा-सा email आता है। उनके सबसे बड़े customer ने अभी-अभी structured invoices issue करना और receive करना शुरू किया है, और उसकी accounts payable टीम कहती है कि हर महीने जो 600 invoices जाते हैं, वे अब PDF में नहीं, machine-readable फ़ाइलों में चाहिए। (यह एक काल्पनिक दृश्य है, किसी असली कंपनी की कहानी नहीं।)

उनका system सिर्फ़ PDF बनाता है। 600 invoices हाथ से दोबारा type करने में हर एक पर दस मिनट लगें तो महीने के 100 घंटे चले जाते हैं, और एक tax ID ग़लत हुई तो invoice लौट आता है।

e-invoicing पहले data की समस्या है, compliance की बाद में। कई देशों की सरकारें अब structured invoices माँग रही हैं, यानी ऐसी files जिन्हें computer बिना किसी इंसानी मदद के read ले, और जो अक्सर किसी network या tax authority के platform से होकर गुज़रती हैं। जो software order record से इन्हें cleanly बना नहीं पाता, वह हर invoice को हाथ का काम बना देता है।

अगर आप दूसरे कारोबारों को बेचते हैं, उनसे ख़रीदते हैं, या दोनों करते हैं, तो इस लेख की तारीख़ें आप पर भी असर डाल सकती हैं, भले ही आप अपने देश से बाहर कभी न जाएँ। विदेश का कोई supplier अचानक आपको structured invoices भेजने लगे, या कोई customer आपका PDF लेना बंद कर दे, तो हैरानी नहीं होनी चाहिए।

इस लेख में e-invoicing के अलग-अलग models का फ़र्क़ है, 2026 से 2028 (और थोड़ा आगे तक) की प्रमुख mandates की timeline है, और इस बात की list कि आपके invoicing या ERP software को क्या-क्या संभालना आना चाहिए। तारीख़ें अगस्त 2026 तक सरकारी और पेशेवर स्रोतों से मिलाकर verify की गई हैं। इस क्षेत्र में rules और deadlines अक्सर बदलती हैं, इसलिए timeline को map की तरह देखें, legal advice की तरह नहीं।

e-invoice क्या है

email से भेजा गया PDF एक electronic document ज़रूर है, लेकिन इन laws के हिसाब से वह e-invoice नहीं है। e-invoice एक fixed, machine-readable format की file है, जिसकी हर field का मतलब पहले से तय होता है: seller की tax ID, buyer की tax ID, line items, tax rate, tax amount, payment terms।

यूरोप में सबसे आम standard EN 16931 है। यह तय करता है कि invoice में कौन-सा data होना ज़रूरी है। इसे दो मुख्य syntax में लिखा जाता है, UBL और UN/CEFACT CII, दोनों XML हैं। कई देशों में इस्तेमाल होने वाला Peppol BIS Billing 3.0 UBL पर बना है और EN 16931 का पालन करता है। यूरोप के बाहर देश अक्सर अपना format तय करते हैं, पर विचार ज़्यादातर वही रहते हैं।

Hybrid file भी valid हो सकती है, जैसे अंदर XML जड़ा PDF (Factur-X या ZUGFeRD)। वजह यह कि असली invoice वह XML है, और PDF सिर्फ़ पढ़ने की सुविधा के लिए एक copy है।

e-invoice के सफ़र के तीन तरीक़े

फ़ॉर्मैट बताता है कि invoice के अंदर क्या है। मॉडल बताता है कि वह विक्रेता से ख़रीदार तक कैसे पहुँचता है और रास्ते में उसे कौन देखता है। आपका वास्ता तीन मॉडलों से पड़ेगा।

Post-audit

विक्रेता स्ट्रक्चर्ड invoice बनाकर किसी भी तय रास्ते से भेज देता है। उस समय कर प्राधिकरण प्रक्रिया में नहीं होता। उसे data बाद में मिलता है, समय-समय पर report के ज़रिए, या वह audit के दौरान invoice जाँचता है। विक्रेता के लिए यह सबसे हल्का मॉडल है, पर ग़लतियाँ बाद में पकड़ में आती हैं।

Clearance

invoice पहले कर प्राधिकरण के platform पर जाता है। platform उसे जाँचता है, एक यूनीक पहचान और मंज़ूरी दे सकता है, और उसके बाद ही वह ख़रीदार तक पहुँचता है। पोलैंड का KSeF और सऊदी अरब का integration चरण इसी तर्ज़ पर चलते हैं। हर invoice का साफ़ स्टेटस मिलता है, पर platform के चालू रहने पर निर्भर रहना पड़ता है, इसलिए backup प्रक्रिया डिज़ाइन का हिस्सा होनी चाहिए।

Peppol और चार-कोनों वाला मॉडल

Peppol एक खुला network है, जिसे OpenPeppol एसोसिएशन चलाती है। आपको हर ग्राहक से अलग से नहीं जुड़ना पड़ता; आप सिर्फ़ एक प्रमाणित एक्सेस पॉइंट से जुड़ते हैं। आपका एक्सेस पॉइंट ख़रीदार का एक्सेस पॉइंट खोजकर invoice आगे पहुँचा देता है। कोना 1 आपका system है, कोना 2 आपका एक्सेस पॉइंट, कोना 3 ख़रीदार का एक्सेस पॉइंट और कोना 4 ख़रीदार का system। कुछ देश पाँचवाँ कोना जोड़ देते हैं: data की एक कॉपी कर प्राधिकरण को भी जाती है।

कई देश इन तरीक़ों को मिलाकर चलाते हैं। कोई देश आदान-प्रदान के लिए Peppol अपनाता है और उसके ऊपर रियल-टाइम रिपोर्टिंग भी जोड़ देता है। इसीलिए सिर्फ़ डेडलाइन नहीं, हर उस बाज़ार का मॉडल भी देखिए जहाँ आप कारोबार करते हैं। network के बारे में और जानकारी peppol.org पर मिल सकती है।

2025 से 2030 तक की समय-रेखा

नीचे की तालिका में प्रमुख अनिवार्यताएँ हैं। यह चुनी हुई सूची है, पूरी नहीं। कई देशों में B2G (कारोबार से सरकार) के नियम पहले से लागू हैं, और कुछ देश अभी क़ानून ही लिख रहे हैं।

देश या क्षेत्र	क्या शुरू हो रहा है	प्रमुख तारीख़ें	मॉडल
जर्मनी	स्ट्रक्चर्ड invoice पाना, फिर जारी करना (घरेलू B2B)	पाना: सभी कारोबारों के लिए 1 जनवरी 2025 से। जारी करना: पिछले साल का टर्नओवर €8,00,000 से ऊपर हो तो 1 जनवरी 2027; सबके लिए 1 जनवरी 2028	फ़ॉर्मैट-आधारित, कोई केंद्रीय platform नहीं
बेल्जियम	VAT-पंजीकृत कारोबारों के बीच स्ट्रक्चर्ड B2B इनवॉइसिंग	1 जनवरी 2026। रियल-टाइम रिपोर्टिंग 2028 के लिए प्रस्तावित है	Peppol BIS 3.0 की सिफ़ारिश
क्रोएशिया	रियल-टाइम फ़िस्कलाइज़ेशन के साथ B2B e-invoicing	VAT-पंजीकृत कारोबारों के लिए 1 जनवरी 2026	आदान-प्रदान और कर प्राधिकरण को रिपोर्टिंग
पोलैंड	राष्ट्रीय KSeF प्रणाली	PLN 20 करोड़ से ऊपर टर्नओवर के लिए 1 फ़रवरी 2026; बाक़ी VAT-पंजीकृत कारोबारों के लिए 1 अप्रैल 2026; माइक्रो-उद्यमी और जुर्माने 1 जनवरी 2027 से	Clearance
फ़्रांस	मंज़ूर platform के ज़रिए पाना; जारी करना चरणों में	1 सितंबर 2026: हर कारोबार invoice पाएगा; बड़ी और मझोली कंपनियाँ जारी करेंगी। 1 सितंबर 2027: SME और माइक्रो-कारोबार जारी करेंगे	मंज़ूर platform और एक केंद्रीय डायरेक्टरी
स्पेन	रॉयल डिक्री 238/2026 के तहत B2B e-invoicing	31 मार्च 2026 को प्रकाशित। मंत्रालय के एक लंबित आदेश के 12 महीने बाद (टर्नओवर €8 मिलियन से ऊपर) या 24 महीने बाद (बाक़ी)। अलग Verifactu बिलिंग-software नियम: 1 जनवरी 2027 और 1 जुलाई 2027	सरकारी platform और आपस में जुड़ने वाले निजी platform
संयुक्त अरब अमीरात	राष्ट्रीय e-invoicing प्रणाली	1 जुलाई 2026 से स्वैच्छिक; AED 5 करोड़ या उससे ऊपर टर्नओवर के लिए 1 जनवरी 2027 से अनिवार्य; बाक़ी कारोबार 2027 में बाद में	Peppol-आधारित, मान्यता-प्राप्त सेवा प्रदाता
सऊदी अरब	चरणबद्ध ZATCA फ़ेज़ 2 (integration)	वेव 24 (SAR 3,75,000 से ऊपर): 30 जून 2026 तक। वेव 25 (SAR 1,87,500 से ऊपर): 1 फ़रवरी 2027 तक	Clearance और रिपोर्टिंग
मलेशिया	टर्नओवर के हिसाब से चरणों में MyInvois	सबसे बड़ों के लिए 1 अगस्त 2024 से। RM1 मिलियन से कम पर छूट। RM1 से 5 मिलियन वाले वर्ग के लिए जुर्माना-मुक्त राहत अवधि 31 दिसंबर 2027 तक	कर प्राधिकरण द्वारा सत्यापन
यूरोपीय संघ	ViDA: सीमा-पार B2B के लिए e-invoicing और डिजिटल रिपोर्टिंग	मार्च 2025 में अपनाया गया। 1 जुलाई 2030 से लागू; सदस्य देश चाहें तो घरेलू नियम पहले भी ला सकते हैं	मानक के रूप में EN 16931

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

अनिवार्यता को सही ढंग से कैसे पढ़ें

चार सवाल किसी सुर्ख़ी को काम की योजना में बदल देते हैं।

• पाना या जारी करना? जर्मनी और फ़्रांस ने पहले invoice पाना अनिवार्य किया। छोटे कारोबार को भी स्ट्रक्चर्ड invoice भेजने की मजबूरी से पहले उसे खोलना और प्रोसेस करना आना चाहिए।
• कौन-से लेन-देन? ज़्यादातर अनिवार्यताएँ सिर्फ़ घरेलू B2B पर लागू होती हैं। B2C और सीमा-पार बिक्री आम तौर पर अलग नियमों में आती है, जहाँ अक्सर e-invoicing नहीं, e-reporting माँगी जाती है।
• कौन-सा आकार? टर्नओवर की सीमा तय करती है कि आप किस वेव में हैं। सीमा के क़रीब हों तो पहले वाली तारीख़ मानकर चलें।
• जुर्माने कब से? छूट की अवधि में बिना जुर्माने के टेस्टिंग हो सकती है। जैसे पोलैंड जनवरी 2027 से जुर्माने लागू करता है, और मलेशिया में छोटे करदाताओं के लिए राहत की खिड़की है। जुर्माना हो या न हो, नियम न मानने वाले invoice ग्राहक लौटा सकते हैं।

आख़िरी बात व्यवहार में बहुत मायने रखती है। सरकार भले सब्र रखे, किसी बड़े ग्राहक की अकाउंट्स पेएबल टीम नहीं रखती। उन्हें स्ट्रक्चर्ड invoice लेने हैं, तो वे आपसे वही माँगेंगे।

आपके इनवॉइसिंग या ERP software को क्या संभालना चाहिए

अनिवार्यताएँ अलग दिखती हैं, पर software से माँगें लगभग एक जैसी हैं। अपने system को इसी सूची पर परखिए।

स्ट्रक्चर्ड data, अतिरिक्त क़दमों वाला PDF नहीं

invoice order या सेल्स रिकॉर्ड से सीधे स्ट्रक्चर्ड data के रूप में बनना चाहिए: यूरोप के लिए UBL या CII में EN 16931, बाक़ी जगह स्थानीय फ़ॉर्मैट। जोखिम वहाँ है जहाँ system पहले PDF बनाता है और फिर किसी बाहरी टूल से उस PDF को पढ़वाकर XML निकलवाता है। हर बदलाव में कुछ सटीकता खो जाती है। बेहतर डिज़ाइन में PDF और स्ट्रक्चर्ड invoice दोनों एक ही रिकॉर्ड से निकलते हैं, इसलिए दोनों में अंतर आ ही नहीं सकता।

मास्टर data की गुणवत्ता

स्ट्रक्चर्ड invoice सख़्त होते हैं। टैक्स ID छूट जाए, देश का कोड ग़लत हो, या पता ग़लत फ़ील्ड में खुले टेक्स्ट की तरह लिखा हो, तो invoice रिजेक्ट हो जाता है। किसी भी डेडलाइन से पहले इन्हें ठीक कर लीजिए:

• ग्राहकों और suppliers की टैक्स ID, जहाँ प्राधिकरण जाँच की सुविधा देता है वहाँ जाँच के साथ;
• क़ानूनी नाम और संरचित पते, जिनमें देश, शहर और पोस्टकोड अलग फ़ील्ड में हों;
• जहाँ देश इनका इस्तेमाल करता है वहाँ रूटिंग आइडेंटिफ़ायर, जैसे Peppol ID या बायर रेफ़रेंस;
• हर उत्पाद और सेवा की कर श्रेणी और छूट का कारण।

नंबरिंग, क्रेडिट नोट और सुधार

ज़्यादातर व्यवस्थाओं में invoice नंबर यूनीक और क्रमवार होने चाहिए, और क्लियर हो चुके invoice को आम तौर पर बदला नहीं जा सकता। ग़लती असली invoice का हवाला देने वाले क्रेडिट नोट से सुधारी जाती है, फिर नया invoice बनता है। आपके software में असली invoice नंबर से जुड़ा सही क्रेडिट-नोट फ़्लो होना चाहिए, «डिलीट करके दोबारा जारी करो» वाला बटन नहीं। आंशिक क्रेडिट, क़ीमत में सुधार और return, सब इसी रास्ते से चलते हैं।

स्टेटस tracking और रिजेक्शन

network वाली व्यवस्था में «भेज दिया» का मतलब कहानी का अंत नहीं है। invoice स्वीकार हो सकता है, रिजेक्ट हो सकता है, कतार में रुका रह सकता है या भुगतान के लिए मंज़ूर हो सकता है। आपका software हर invoice का स्टेटस सहेजे, वसूली देखने वालों को दिखाए, और रिजेक्शन आने पर किसी को alert करे। रिजेक्शन के साथ पढ़ने लायक़ कारण और सुधारकर दोबारा भेजने का साफ़ तरीक़ा होना चाहिए, लॉग में पड़ा स्टैक ट्रेस नहीं।

नीचे का चित्र एक invoice को clearance व्यवस्था में आगे बढ़ते दिखाता है। वह दो जगह लौट सकता है, और दोनों बार नतीजा एक ही है: data ठीक करना।

आर्काइविंग और audit ट्रेल

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

कनेक्टिविटी और API

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

एक से ज़्यादा देश

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

तैयारी की चेकलिस्ट

इसे जल्दी से ख़ुद को परखने के लिए इस्तेमाल कीजिए। इनमें से कई के जवाब «नहीं» या «पता नहीं» हों, तो देर मत कीजिए।

• हमें पता है कि देश और अपने टर्नओवर के हिसाब से कौन-सी अनिवार्यताएँ हम पर लागू होती हैं।
• हमें पता है कि हर एक सिर्फ़ पाने की है, जारी करने की है या दोनों की, और जुर्माने कब से शुरू होंगे।
• हमारा system order से सीधे स्ट्रक्चर्ड invoice (EN 16931 या स्थानीय फ़ॉर्मैट) बना सकता है।
• कम से कम हमारे प्रमुख ग्राहकों और suppliers की टैक्स ID और संरचित पते पूरे हैं।
• क्रेडिट नोट असली invoice से जुड़े हैं और ज़रूरी रेफ़रेंस साथ रखते हैं।
• भेजे गए हर invoice का स्टेटस दिखता है, और रिजेक्शन पर alert आता है।
• मिले हुए स्ट्रक्चर्ड invoice अपने-आप पढ़े जा सकते हैं, दोबारा टाइप नहीं करने पड़ते।
• मूल स्ट्रक्चर्ड फ़ाइलें क़ानूनी अवधि तक बिना बदले सुरक्षित रखी जाती हैं।
• एक्सेस पॉइंट या platform के connection और उसके सर्टिफ़िकेट के लिए हमारे पास एक तय ज़िम्मेदार व्यक्ति है।
• डेडलाइन से पहले हमने पूरे फ़्लो को सैंडबॉक्स में परखा है।

छह चरणों की प्रोजेक्ट योजना

ज़्यादातर बढ़ते कारोबारों के लिए यह काम एक-दो तिमाहियों में निपट जाता है। इस क्रम में चलने से काम संभालना आसान रहता है।

1. अपनी ज़िम्मेदारियों का नक्शा बनाइए। जिन देशों में आप invoice करते हैं या जहाँ से ख़रीदते हैं, उनकी अनिवार्यता, आपकी वेव और जुर्माने की शुरुआत की तारीख़ लिख लीजिए। सबसे नज़दीकी तारीख़ को कैलेंडर में डालकर पीछे की ओर हिसाब लगाइए।
2. invoice के प्रवाह की पड़ताल कीजिए। आज एक invoice कैसे बनता, मंज़ूर होता, भेजा जाता, चुकाया जाता और आर्काइव होता है, इसे शुरू से अंत तक देखिए। हर हाथ से होने वाला क़दम और शामिल हर टूल नोट कर लीजिए।
3. मास्टर data ठीक कीजिए। टैक्स ID, पते और कर श्रेणियाँ साफ़ कीजिए। यह काम उबाऊ है और सबसे ज़्यादा समय लेता है, इसलिए इसे सबसे पहले शुरू कीजिए।
4. connection का रास्ता चुनिए। प्रमाणित एक्सेस पॉइंट या मंज़ूर platform, कर प्राधिकरण से सीधा integration, या आपके software के साथ आने वाला प्रोवाइडर, इनमें से तय कीजिए। प्रति invoice क़ीमत, सपोर्ट, अपटाइम और छोड़ने की शर्तों की तुलना कीजिए।
5. कॉन्फ़िगर और test कीजिए। फ़ॉर्मैट, नंबरिंग और क्रेडिट-नोट फ़्लो सेट कीजिए। सैंडबॉक्स में असली हालात चलाकर देखिए: सामान्य बिक्री, discount, return, रिजेक्शन, आंशिक क्रेडिट, विदेशी ग्राहक।
6. धीरे-धीरे लाइव कीजिए और निगरानी रखिए। कुछ ग्राहकों से शुरुआत कीजिए, रिजेक्शन की दर देखिए और कारण सुधारिए। फ़ाइनेंस टीम को समझाइए कि रिजेक्शन का मतलब क्या है और उसे कौन संभालेगा।

जिन ग़लतियों से बचें

• डेडलाइन वाले महीने का इंतज़ार करना। डेडलाइन के पास प्रोवाइडर ऑनबोर्डिंग, सर्टिफ़िकेट और टेस्टिंग की कतारें लंबी हो जाती हैं।
• इसे सिर्फ़ IT का काम समझना। नियम फ़ाइनेंस जानता है, ग्राहकों का data सेल्स के पास है और connection IT के पास। तीनों को साथ बैठना होगा।
• PDF कन्वर्टर ख़रीद लेना। पहले दिन वह नियम के मुताबिक़ लग सकता है, लेकिन पहले क्रेडिट नोट पर ही अटक जाता है।
• आने वाले invoice को नज़रअंदाज़ करना। पाने की अनिवार्यता अक्सर पहले शुरू होती है, और supplier invoice को अपने-आप प्रोसेस करने में ही सबसे ज़्यादा समय बचता है।
• अगले देश को भूल जाना। जो डिज़ाइन एक बाज़ार में चले पर आगे बढ़ाया न जा सके, उसे दो साल के भीतर दोबारा बनाना पड़ता है।

अब उसी थोक कंपनी पर लौटिए। उनका system अब स्ट्रक्चर्ड invoice उसी order रिकॉर्ड से बनाता है जिससे PDF बनता है, ग्राहक जोड़ते समय ही टैक्स ID जाँच लेता है, और हर invoice का स्टेटस सहेजता है। 600 invoice बिना दोबारा टाइप किए निकल जाते हैं। महीने में जो गिने-चुने लौटते हैं, उनके साथ पढ़ने लायक़ कारण होता है; एक क्लर्क ख़रीदार का छूटा रेफ़रेंस भरकर उसी दिन दोबारा भेज देता है। 100 घंटे की टाइपिंग ख़त्म, और सोमवार सुबह की वह हड़बड़ी भी।

मुख्य बातें

• e-invoice एक स्ट्रक्चर्ड, मशीन से पढ़ी जाने वाली फ़ाइल है, PDF नहीं। यूरोप में आम मानक EN 16931 है, UBL या CII सिंटैक्स में।
• हर देश का मॉडल जानिए: post-audit, clearance या Peppol-जैसा आदान-प्रदान, कभी-कभी अतिरिक्त रिपोर्टिंग के साथ।
• प्रमुख तारीख़ें: बेल्जियम और क्रोएशिया जनवरी 2026, पोलैंड फ़रवरी और अप्रैल 2026, फ़्रांस सितंबर 2026 (SME सितंबर 2027), जर्मनी में जारी करना 2027 और 2028 से, यूरोपीय संघ का सीमा-पार नियम जुलाई 2030। स्पेन, UAE, सऊदी अरब और मलेशिया अपने-अपने कार्यक्रम से चरणबद्ध ढंग से बढ़ रहे हैं।
• आपके software में ये सब होना चाहिए: स्ट्रक्चर्ड invoice बनाना, साफ़ मास्टर data, क्रेडिट नोट, स्टेटस tracking, आर्काइविंग और लचीली कनेक्टिविटी।
• डेडलाइन खिसकती रहती हैं और सीमाएँ अलग-अलग हैं, इसलिए कोई फ़ैसला करने से पहले कर प्राधिकरण या अकाउंटेंट से अपने यहाँ के नियम जाँच लें।
• शुरुआत data और पाने वाले पक्ष से कीजिए; connection जो भी चुनें, दोनों की ज़रूरत पड़ेगी।

अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।