प्रति-देश वैट रिपोर्टिंग और VIES सत्यापन का स्वचालन

प्लेटफॉर्म कोड में अधिकांश वैट बग्स (bugs) की जड़ एक धारणा होती है: यह मानना कि वैध VIES परिणाम का मतलब है कि आप बिक्री पर शून्य-दर (zero-rate) लागू कर सकते हैं। ऐसा नहीं है, और इस शॉर्टकट के आधार पर सिस्टम बनाने से ऐसे रिटर्न तैयार होते हैं जो तब तक सही दिखते हैं जब तक कोई ऑडिटर यह न पूछ बैठे कि परिवहन साक्ष्य या आपूर्ति के स्थान (place-of-supply) के सुसंगत रिकॉर्ड के बिना इंट्रा-EU छूट क्यों लागू की गई थी। "वैट नंबर सही है" और "इस आपूर्ति के साथ सही व्यवहार किया गया है" के बीच का अंतर ही वह जगह है जहाँ अधिकांश इंटीग्रेशन चुपचाप गलत हो जाते हैं।

यह गाइड बताती है कि Nordlet's accounting API को कार्यान्वयन संदर्भ के रूप में उपयोग करते हुए, क्लाउड अकाउंटिंग एपीआई के साथ प्रति-देश वैट रिपोर्टिंग और VIES सत्यापन को कैसे स्वचालित किया जाए। इसका लक्ष्य एक ऐसा सिस्टम तैयार करना है जो बिक्री के समय सही साक्ष्य कैप्चर करे, अपरिवर्तनीय लेज़र प्रविष्टियाँ (immutable ledger entries) पोस्ट करे, और बाद में स्प्रेडशीट में कुल योग (totals) को फिर से जोड़े बिना, योजना और सदस्य देश (Member State) के अनुसार समूहीकृत (grouped) रिटर्न-तैयार डेटा उत्पन्न करे।

VIES वास्तव में आपको क्या बताता है, और क्या नहीं

VIES, EU वैट सूचना विनिमय प्रणाली (EU VAT Information Exchange System) है। जब आप एक देश कोड और वैट नंबर सबमिट करते हैं, तो यह वास्तविक समय (real time) में संबंधित राष्ट्रीय डेटाबेस से पूछताछ करता है और यह लौटाता है कि वह वैट जानकारी वैध है या अंवैध। इसका दायरा बस इतना ही है। यह पुष्टि करता है कि नंबर पंजीकृत है और, जहाँ सदस्य देश इसका समर्थन करता है, इंट्रा-EU व्यापार के लिए सक्रिय है।

यह इंट्रा-कम्युनिटी आपूर्ति को छूट देने के अधिकार को स्थापित नहीं करता है। यूरोपीय आयोग इस बारे में स्पष्ट है। एक वैध VIES प्रतिक्रिया कई साक्ष्यों में से केवल एक साक्ष्य है। आपको अभी भी इस बात की पुष्टि करनी होगी कि ग्राहक वास्तविक प्राप्तकर्ता है, आपूर्ति इंट्रा-EU के रूप में योग्य है, परिवहन या प्रेषण का साक्ष्य मौजूद है, और चालान (invoice) पर आवश्यक रिवर्स-चार्ज की भाषा (wording) मौजूद है।

इसलिए पहला डिज़ाइन निर्णय संरचनात्मक है: VIES स्थिति और वैट उपचार (VAT treatment) को अलग-अलग फ़ील्ड में रखें। कभी भी viesStatus: valid को सीधे zeroRated: true से न जोड़ें। जिस क्षण आप उन दोनों अवधारणाओं को मिला देते हैं, आप साक्ष्य पर सवाल उठाए जाने पर किसी उपचार का बचाव करने की क्षमता खो देते हैं।

इंटीग्रेशन कोड लिखने से पहले की पूर्वापेक्षाएँ

किसी भी एंडपॉइंट को कॉल करने से पहले, उस दायरे को परिभाषित करें जिसकी आप रिपोर्टिंग कर रहे हैं। यह हिस्सा उबाऊ है और इसे छोड़ना महंगा पड़ता है।

• व्यवसाय किन देशों में स्थापित है या उसके पास कहाँ निश्चित प्रतिष्ठान हैं
• किन देशों में इसके पास वैट पंजीकरण हैं
• क्या यह वस्तुएं, सेवाएं, डिजिटल सेवाएं, या इनका मिश्रण बेचता है
• क्या लेनदेन B2B, B2C, या दोनों हैं
• क्या यह घरेलू पंजीकरण, OSS, IOSS, रिवर्स चार्ज, या मार्केटप्लेस डीम्ड-सप्लायर नियमों का उपयोग करता है
• एपीआई को कौन से आउटपुट उत्पन्न करने चाहिए: घरेलू रिटर्न डेटा, OSS/IOSS डेटा, लिथुआनिया के i.SAF जैसे चालान रजिस्टर, केवल लेज़र पोस्टिंग, या एक अलग फाइलिंग प्रदाता के लिए पेलोड (payloads)

यह महत्वपूर्ण है क्योंकि OSS हर लेनदेन को अपने में समाहित नहीं करता है। जिस देश में व्यवसाय का कोई प्रतिष्ठान है, वहाँ आपूर्ति की जाने वाली सेवाएं आम तौर पर OSS रिटर्न में नहीं, बल्कि उस देश के घरेलू रिटर्न में आती हैं। शुरुआत से ही प्रतिष्ठानों को अलग से मॉडल करें अन्यथा आप एकत्रीकरण (aggregation) के समय उन आपूर्तियों को गलत रूट कर देंगे।

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

केवल दर को नहीं, बल्कि कर निर्णय को मॉडल करना

एक टिकाऊ इंटीग्रेशन का मूल उत्पादों और दरों के बीच स्थित कर-श्रेणी (tax-category) परत है। उत्पादों को श्रेणियों में, श्रेणियों को देश-विशिष्ट कर कोड में, और फिर प्रभावी-दिनांकित दरों (effective-dated rates) में मैप करें:

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

वह असुरक्षित संस्करण जो रिपोर्टिंग ड्रिफ्ट का कारण बनता है, product SKU → 21% VAT है। एक ही उत्पाद पर अलग-अलग देशों में अलग-अलग दरें लागू होती हैं, और अवधि के बीच में दर बदल सकती है। Nordlet का अपना वैट अनुपालन मार्गदर्शन (VAT compliance guidance) उत्पादों को सीधे प्रतिशत से बांधने के बजाय बिल्कुल इस श्रेणी-आधारित मैपिंग की सिफारिश करता है।

आपकी कर-श्रेणी वर्गीकरण प्रणाली स्थिर और आंतरिक होनी चाहिए: मानक-दर वाली वस्तुएं, कम-दर वाली वस्तुएं, इलेक्ट्रॉनिक रूप से आपूर्ति की जाने वाली सेवाएं, सामान्य सेवाएं, छूट प्राप्त आपूर्ति, शून्य-दर वाली आपूर्ति, इंट्रा-EU B2B रिवर्स चार्ज, इंट्रा-EU दूरस्थ बिक्री, IOSS आयात, डीम्ड-सप्लायर लेनदेन। नीचे की ओर सब कुछ इस वर्गीकरण प्रणाली पर आधारित होता है।

एक असमकालिक साक्ष्य वर्कफ़्लो के रूप में VIES सत्यापन

आधिकारिक VIES सेवा दो-अक्षीय देश कोड और वैट नंबर लेने वाला एक SOAP/WSDL इंटरफ़ेस प्रदर्शित करती है। इसकी प्रलेखित त्रुटियां आपकी त्रुटि को संभालने (error handling) के लिए महत्वपूर्ण हैं: अमान्य इनपुट, वैश्विक और सदस्य देश समवर्ती सीमाएं (concurrency limits), सेवा अनुपलब्धता, सदस्य देश की अनुपलब्धता, और टाइमआउट। इन्हें एकल "विफल" बाल्टी के रूप में नहीं, बल्कि अलग-अलग परिणामों के रूप में मानें।

भार और ऑडिट के तहत टिकने वाला वर्कफ़्लो कुछ इस तरह दिखता है:

1. वैट आईडी को सामान्यीकृत (normalize) करें: उपसर्ग (prefix) को बड़े अक्षरों में करें, अनुमत रिक्त स्थान या विराम चिह्न हटा दें, और उपयोगकर्ता द्वारा दर्ज किए गए मूल मान को अलग से रखें।
2. नेटवर्क कॉल करने से पहले देश कोड और नंबर के आकार का स्थानीय स्तर पर सत्यापन करें।
3. सामान्यीकृत नंबर को VIES में सबमिट करें।
4. सामान्यीकृत आईडी, अनुरोध और प्रतिक्रिया टाइमस्टैम्प, वैध/अवैध/प्रक्रिया-रहित स्थिति, कच्ची प्रतिक्रिया, कोई भी सेवा त्रुटि, ग्राहक और चालान आईडी, और एप्लिकेशन निर्णय को संग्रहीत करें।
5. एक परिभाषित, प्रलेखित अवधि के लिए सफल परिणामों को कैश्ड (cache) करें।
6. बैकऑफ़ के साथ क्षणिक तकनीकी विफलताओं (transient technical failures) का पुनः प्रयास करें।
7. अनसुलझे या विरोधाभासी मामलों को मैन्युअल समीक्षा के लिए रूट करें।
8. जब कोई कैश्ड परिणाम पुराना हो जाए या ऐसे लेनदेन से पहले जहां साक्ष्य महत्वपूर्ण हो, तब पुनः सत्यापन करें।

जब कोई ग्राहक जोड़ा जाता है तो Nordlet EU वैट नंबर की जांच करता है और जब पिछला परिणाम पुराना हो जाता है तो चालान भेजने से पहले इसकी फिर से जांच करता है, जो कि वह व्यवहार है जिसे आप यह दोहराना चाहते हैं कि जाँच प्लेटफ़ॉर्म में होती है या आपके अपने कोड में।

महत्वपूर्ण नियम: चेकआउट को VIES के साथ सिंक्रोनस न बनाएं। सेवा आउटेज कोई अमान्य नंबर नहीं है। यदि बिक्री के दौरान VIES का समय समाप्त हो जाता है, तो लेनदेन को समीक्षा के लिए रोक कर रखें या इसे एक अनंतिम स्थिति (provisional state) असाइन करें। किसी आयोग सेवा के अपटाइम पर चेकआउट को ब्लॉक करना एक सपोर्ट टिकट जनरेटर है, और किसी अच्छे ग्राहक को अमान्य के रूप में गलत वर्गीकृत करना उससे भी बदतर है।

उपचार से सत्यापन स्थिति को अलग करना

एक बार जब आपके पास VIES परिणाम आ जाता है, तो निर्णय इंजन के पास करने के लिए और अधिक काम होता है। इन्हें अलग-अलग फ़ील्ड के रूप में संग्रहीत करें:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

रिवर्स-चार्ज या छूट लागू करने से पहले, इंजन को यह परीक्षण करना चाहिए कि क्या ग्राहक वास्तव में प्राप्तकर्ता है, क्या ग्राहक देश और वैट उपसर्ग सुसंगत हैं, क्या आपूर्ति इंट्रा-EU के रूप में योग्य है, क्या विशेष आपूर्ति-स्थान नियम लागू होते हैं, क्या परिवहन साक्ष्य मौजूद है, क्या विक्रेता डीम्ड सप्लायर के रूप में कार्य कर रहा है, और क्या चालान में आवश्यक भाषा शामिल है। एक वैध VIES स्थिति जो इनमें से किसी भी अन्य परीक्षण में पास नहीं होती है, वह हरी झंडी नहीं है।

चालान के समय एक अपरिवर्तनीय वैट निर्णय बनाना

जब चालान बनाया जाता है, तो इसके साथ केवल अंतिम दर को ही नहीं, बल्कि संपूर्ण निर्णय को बनाए रखें:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

EU चालान नियमों के लिए आपूर्तिकर्ता और ग्राहक विवरण, चालान संख्या, विवरण, कर योग्य राशि, वैट दर, वैट राशि, और किसी भी रिवर्स-चार्ज या छूट की जानकारी की आवश्यकता होती है। क्रेडिट नोट और संशोधनों को मूल चालान के लिए एक स्पष्ट संदर्भ की आवश्यकता होती है।

Nordlet का लेज़र अपरिवर्तनीय (immutable) है, इसलिए सुधार बंद रिकॉर्ड में संपादन के बजाय क्रेडिट नोट या रिवर्सिंग प्रविष्टियों जैसी नई प्रविष्टियों के माध्यम से होते हैं। उस मॉडल के आसपास अपने उपभोक्ता का निर्माण करें, भले ही आपका स्टोरेज तकनीकी रूप से ओवरराइट कर सके। एक बंद चालान को संपादित करने से मूल फाइलिंग और सुधार के बीच का संबंध नष्ट हो जाता है, जो कि ठीक वही वंशानुक्रम (lineage) है जिसका पालन एक ऑडिटर करता है।

पोस्टिंग, वेबहुक, और आइडपोटेंसी

एक बिक्री दोहरे-प्रविष्टि लेखांकन प्रविष्टियों (double-entry accounting entries) को पोस्ट करती है जो देश और योजना द्वारा विभाजित वाणिज्यिक लेनदेन और वैट देयता दोनों को संरक्षित करती है। एक घरेलू बिक्री पोस्ट कर सकती है:

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable - DE - domestic

एक इंट्रा-EU B2B रिवर्स-चार्ज बिक्री बिना आउटपुट वैट के राजस्व और रिवर्स-चार्ज साक्ष्य के संदर्भ के साथ पोस्ट करती है। खातों का सटीक चार्ट आपका है; जो मायने रखता है वह यह है कि रिपोर्टिंग आयाम प्रत्येक पोस्टिंग से जुड़े रहते हैं: सदस्य देश, योजना, कर श्रेणी, दर, अवधि, स्रोत चालान, और सुधार वंशानुक्रम।

पोलिंग के बजाय वेबहुक के साथ स्थिति परिवर्तन संचालित करें। Nordlet sale_invoice.paid जैसे इवेंट उत्सर्जित करता है, डिलीवरी पर हस्ताक्षर करता है, और बैकऑफ़ के साथ पुनः प्रयास करता है। प्रत्येक राइट को एक नियतात्मक आइडपोटेंसी कुंजी (deterministic idempotency key) दें:

sale:{platform_order_id}:invoice:{invoice_version}

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

OSS के लिए समूहीकरण और रिटर्न-तैयार निर्यात का उत्पादन

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

यूनियन योजना रिटर्न उपभोग के सदस्य देश द्वारा आपूर्तियों को अलग करता है और पहचान के सदस्य देश से सेवाओं, अन्य निश्चित प्रतिष्ठानों से सेवाओं, और विभिन्न सदस्य देशों से प्रेषित वस्तुओं के बीच अंतर करता है। यह मानक और कम दरों के लिए कर योग्य और वैट राशियों को अलग से रिपोर्ट करता है। छूट प्राप्त और शून्य-दर वाली आपूर्ति पूरी तरह से OSS रिटर्न से बाहर रहती हैं।

कुछ परिचालन विवरण जो लोगों को उलझाते हैं:

• यूनियन और गैर-यूनियन OSS अवधि त्रैमासिक होती हैं; IOSS मासिक होता है। रिटर्न और भुगतान अगले महीने के अंत तक देय हैं।
• हर अवधि के लिए एक शून्य रिटर्न (nil return) आवश्यक है, तब भी जब कोई प्रासंगिक आपूर्ति नहीं की गई हो। एक अवधि चेकलिस्ट तैयार करें और स्वचालित रूप से शून्य-मूल्य रिटर्न बनाएं।
• OSS रिटर्न यूरो में बनाए जाते हैं, जहाँ रूपांतरण की आवश्यकता होती है, कर अवधि के अंतिम दिन ECB संदर्भ दर का उपयोग करके। स्रोत मुद्रा, FX दर, दर तिथि, परिवर्तित राशि और पद्धति को संग्रहीत करें।

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

एपीआई यहाँ क्या डिलीवर करता है, उसके बारे में सटीक रहें। Nordlet चालान और लेज़र से OSS और IOSS रिटर्न की गणना करता है जिसमें पूर्व-अवधि के सुधार शामिल हैं, लिथुआनिया (FR0600), जर्मनी (UStVA) और पोलैंड (JPK_V7M) के लिए घरेलू रिटर्न पैक भेजता है, और लिथुआनिया के लिए VMI-तैयार i.SAF रजिस्टर उत्पन्न करता है। वह रिटर्न-तैयार डेटा है। एक एपीआई कॉल हर राष्ट्रीय गेटवे के माध्यम से हर देश का वैट रिटर्न दाखिल नहीं करता है, और आपकी ओर से किसी प्राधिकरण को कोई रिटर्न सबमिट नहीं किया जाता है। लेखांकन, रिटर्न जनरेशन, निर्यात, गेटवे सबमिशन और भुगतान पुष्टिकरण को अपने सिस्टम में अलग-अलग राज्यों के रूप में रखें। EU वैट इंजन गाइड उन मामलों का दस्तावेजीकरण करती है जिन्हें इंजन हल करता है और कहाँ इसकी चेतावनियां फायर होती हैं।

अवधि को लॉक करना

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

सामान्य विफलता मोड और उनसे कैसे बचें

विफलता मोड	यह क्यों होता है	शमन (Mitigation)
शून्य-दर के लिए वैध VIES परिणाम को पर्याप्त मानना	VIES छूट के अधिकार स्थापित नहीं करता है	परिणाम के साथ ग्राहक, आपूर्ति, परिवहन और चालान साक्ष्य संग्रहीत करें
कोई पंजीकरण नहीं होने के प्रमाण के रूप में अमान्य परिणाम मानना	नंबर इंट्रा-EU व्यापार के लिए सक्रिय नहीं हो सकता है, या डेटाबेस पीछे हो सकता है	अमान्य, प्रक्रिया-रहित और तकनीकी विफलता के बीच अंतर करें; विवादों को समीक्षा के लिए रूट करें
चेकआउट को VIES के साथ सिंक्रोनस बनाना	समवर्ती सीमाएं (concurrency limits), टाइमआउट, आउटेज	असमकालिक सत्यापन, अल्पकालिक कैशिंग, बैकऑफ़, अनंतिम राज्य (provisional states)
परिणामों को हमेशा के लिए कैश करना	पंजीकरण और सक्रियण स्थिति बदलती है	टाइमस्टैम्प और समाप्ति संग्रहीत करें; पुराना होने पर चालान भेजने से पहले पुनः जांच करें
उत्पादों को सीधे वैट प्रतिशत से मैप करना	दरें और छूट देश और तिथि पर निर्भर करती हैं	उत्पाद से श्रेणी, देश कोड से प्रभावी-दिनांकित दर
स्प्रेडशीट से OSS का पुनर्निर्माण करना	कुल योग में सुधार, प्रेषण देश, साक्ष्य छूट जाते हैं	हर प्रविष्टि पर आयामों के साथ अपरिवर्तनीय लेज़र से प्राप्त करें
घरेलू-स्थापना सेवाओं को OSS में शामिल करना	कुछ सेवाएं घरेलू रिटर्न से संबंधित होती हैं	प्रतिष्ठानों को अलग से मॉडल करें, एकत्रीकरण से पहले योजना द्वारा रूट करें
शून्य रिटर्न (nil returns) छोड़ना	OSS को हर अवधि में रिटर्न की आवश्यकता होती है	एक चेकलिस्ट तैयार करें और स्वचालित रूप से शून्य-मूल्य रिटर्न बनाएं
सुधार के लिए बंद चालान संपादित करना	फाइलिंग-से-सुधार लिंक को नष्ट कर देता है	बाद की अवधि में क्रेडिट नोट और रिवर्सिंग प्रविष्टियों का उपयोग करें

हम पहले क्या करेंगे

यदि हम कल इस इंटीग्रेशन को शुरू कर रहे होते, तो हम किसी भी रिपोर्टिंग एंडपॉइंट को छूने से पहले कर-श्रेणी परत (tax-category-layer) और वैट निर्णय रिकॉर्ड का निर्माण करते। वर्गीकरण प्रणाली को स्थिर करें, उत्पादों को श्रेणियों में मैप करें, और निर्णय रिकॉर्ड को कच्चे देश के संकेतों के साथ-साथ उस कारण को कैप्चर करने दें कि आपूर्ति का स्थान क्यों चुना गया था। बाकी सब कुछ - VIES, पोस्टिंग, OSS समूहीकरण, निर्यात - उस मॉडल के सही होने पर निर्भर करता है।

फिर हम VIES को चार अलग-अलग राज्यों के साथ एक असमकालिक साक्ष्य चरण के रूप में तारबद्ध करेंगे, और इसे उत्पादन के करीब ले जाने से पहले बदसूरत मामलों (टाइमआउट, प्रक्रिया-रहित परिणाम, बेमेल उपसर्ग) के लिए फिक्सचर के साथ एक सैंडबॉक्स कंपनी के खिलाफ चलाएंगे। उपरोक्त विफलता मोड लगभग पूरी तरह से टाले जा सकते हैं यदि डेटा मॉडल पहली पोस्टिंग से साक्ष्य और रिपोर्टिंग आयामों को वहन करता है।

FAQ

क्या एक वैध VIES प्रतिक्रिया का मतलब है कि मैं इंट्रा-EU B2B बिक्री को शून्य-दर दे सकता हूँ?

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

क्या VIES सत्यापन को चेकआउट को ब्लॉक करना चाहिए?

इसे नहीं करना चाहिए। VIES का समय समाप्त हो सकता है या समवर्ती सीमाओं (concurrency limits) तक पहुँच सकता है, और एक आउटेज अमान्य नंबर के समान नहीं है। असमकालिक रूप से सत्यापित करें, एक प्रलेखित अवधि के लिए सफल परिणामों को कैश्ड करें, क्षणिक विफलताओं का पुनः प्रयास करें, और बिक्री को विफल करने के बजाय एक अनंतिम स्थिति (provisional state) के साथ समीक्षा के लिए अस्पष्ट मामलों को रोक कर रखें।

क्या क्लाउड अकाउंटिंग एपीआई मेरे वैट रिटर्न को स्वचालित रूप से दाखिल कर सकता है?

यह सुधारों सहित अपरिवर्तनीय लेज़र से गणना किए गए, योजना और सदस्य देश द्वारा समूहीकृत रिटर्न-तैयार डेटा उत्पन्न कर सकता है। क्या यह प्रत्येक राष्ट्रीय फाइलिंग गेटवे के माध्यम से भी सबमिट करता है यह उत्पाद और देश पर निर्भर करता है। Nordlet OSS और IOSS रिटर्न की गणना करता है, लिथुआनिया, जर्मनी और पोलैंड के लिए घरेलू रिटर्न पैक भेजता है, और लिथुआनिया के लिए VMI-तैयार i.SAF रजिस्टर उत्पन्न करता है, लेकिन यह कर प्राधिकरण को आपकी ओर से कुछ भी सबमिट नहीं करता है। लेखांकन, रिटर्न जनरेशन, निर्यात, गेटवे सबमिशन और भुगतान को यह मानकर अलग-अलग राज्यों के रूप में मानें कि एक कॉल हर जगह फाइल करती है।

अवधि लॉक होने के बाद मैं सुधारों को कैसे संभालूँ?

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

आगे की पठन सामग्री

• क्लाउड अकाउंटिंग एपीआई के साथ यूरोपीय संघ (EU) वैट अनुपालन का स्वचालन
• SaaS प्लेटफॉर्म में क्लाउड अकाउंटिंग एपीआई का इंटीग्रेशन
• वैट नंबर (VIES) की जाँच करें, यूरोपीय आयोग