GST इनवॉइस डेटा मॉडल: HSN और ऑर्डर्स के लिए न्यूनतम फ़ील्ड्स

GST इनवॉइस में आमतौर पर क्या गलत होता है

अधिकांश GST इनवॉइस की परेशानियाँ “जटिल कर” समस्याएँ नहीं होतीं। यह गायब या असंगत डेटा की समस्याएँ होती हैं। ऑडिट इसलिए फेल होता है क्योंकि चालान को साफ़-साफ़ यह नहीं जोड़ा जा सकता कि क्या बेचा गया था, किसे बेचा गया था, कहाँ सप्लाई हुई, और कर कैसे निकाला गया।

एक आम कारण HSN का अनुपस्थित होना, पुराना होना, या गलत स्तर पर लागू होना है। टीमें HSN को उत्पाद पर स्टोर कर सकती हैं, लेकिन चालान लाइन किसी अलग SKU नाम या वेरिएंट से बनती है, इसलिए HSN अंतिम दस्तावेज पर नहीं जाता। एक और सामान्य समस्या गलत कर विभाजन है: IGST चार्ज करना जब CGST और SGST होना चाहिए (या उल्टा), क्योंकि "place of supply" को शिपिंग पते से अनुमान लगाकर निर्णय किया गया और वह राज्य कोड स्टोर नहीं किया गया जिसकी वजह से फैसला हुआ।

फाइनेंस टीमें इसे तुरंत महसूस करती हैं। रीकंसिलीएशन रोज़ का क्लीनअप काम बन जाता है: चालान कुल ऑर्डर से मेल नहीं खाते, ऑर्डर पेमेंट गेटवे सेटलमेंट से मेल नहीं खाता, और रिफंड्स मैन्युअल नोट्स की शृंखला बन जाते हैं। यहाँ तक कि लाइन आइटम्स के बीच छोटे-छोटे राउंडिंग अंतर भी चालान PDF, GST रिपोर्ट और लेजर के बीच मेल ना खाने का कारण बन सकते हैं।

यहाँ वे पैटर्न हैं जो अधिकतर मेल-मिलाप की परेशानी पैदा करते हैं:

• उत्पाद और चालान लाइन्स के बीच समान HSN, GST दर, और करयोग्य मान फ़ील्ड नहीं होते।
• कर की गणना एक से अधिक जगह पर होती है (कार्ट बनाम चालान) और परिणाम अलग आते हैं।
• कुल केवल "ग्रैंड टोटल" के रूप में स्टोर होते हैं बिना टैक्सेबल वैल्यू और प्रत्येक कर घटक के ब्रेकडाउन के।
• चालान नंबरिंग एडिटेबल है या सीरीज़ में डुप्लिकेट हो रही है।
• रिफंड्स को नेगेटिव ऑर्डर के रूप में रिकॉर्ड किया जाता है बजाय सही क्रेडिट नोट के।

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

जिन रिकॉर्ड्स की सबसे छोटी सेटिंग जरूरी है

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

यहाँ वो मुख्य रिकॉर्ड हैं जिनकी दिन एक पर ज़रूरत होती है:

• Customer: किसने खरीदा (नाम, फोन/ईमेल, B2B के लिए GSTIN)
• Address: शिपिंग और बिलिंग, साथ में राज्य और place of supply संकेत
• Product (or Service): क्या बेचा गया, यूनिट, बेस प्राइस, और डिफ़ॉल्ट HSN/SAC
• Order: वाणिज्यिक इवेंट (कार्ट, डिस्काउंट, शिपिंग चार्ज, स्टेटस)
• Payment: पैसे कैसे आए/गए (गेटवे संदर्भ, मेथड, कैप्चर की गई रकम, तारीख)

एक Invoice को ऑर्डर से अलग होना चाहिए। ऑर्डर बदल सकते हैं (एडिट किया हुआ पता, कैंसिल किए आइटम, पार्टियल फुलफिल्मेंट)। इनवॉइस को नहीं होना चाहिए। उन्हें स्थिर नंबरिंग, तारीखें, और टोटल चाहिए जो बाद में "ड्रिफ्ट" न हों क्योंकि किसी ने बाद में ऑर्डर अपडेट कर दिया।

कर की सटीकता का आधार Line Items हैं। हर ऑर्डर लाइन आइटम (और बाद में हर चालान लाइन आइटम) में सही मात्रा, यूनिट प्राइस, डिस्काउंट और उस विशिष्ट आइटम के लिए टैक्स ब्रेकडाउन होना चाहिए। यहीं HSN/SAC और GST दरें वास्तव में लागू होती हैं।

एक ऐसी डिटेल जो फाइनेंस टीमों को बचाती है: snapshots स्टोर करें। जब आप चालान जनरेट करते हैं, तो उत्पाद विवरण, HSN/SAC, कर दर और प्राइसिंग को चालान लाइन में कॉपी कर दें। वर्तमान प्रोडक्ट मास्टर पर निर्भर न रहें, क्योंकि दरें और नाम बदलते हैं।

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

यदि आप इसे Koder.ai में बनाते हैं, तो हर ऑब्जेक्ट को पहले एक साधारण स्क्रीन (create, view, edit) के रूप में ट्रीट करें, फिर जब snapshots और लाइन-लेवल फ़ील्ड्स मौजूद हों तब इनवॉइस जनरेशन जोड़ें।

HSN और SAC: मॉडल में कहाँ इन्हें रखें

HSN (सामानों के लिए) और SAC (सेवाओं के लिए) केवल "इनवॉइस-ओनली" विवरण नहीं हैं। ये उत्पाद या सेवा पर परिभाषा से शुरू होते हैं, और जब आप चालान बनाते हैं तब इन्हें हर चालान लाइन पर कॉपी किया जाता है। इससे मिश्रित कार्ट सही रहते हैं और ऑडिट आसान होते हैं क्योंकि हर लाइन अपने आप खड़ी रहती है।

एक व्यावहारिक न्यूनतम डेटा मॉडल इस तरह दिखता है:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (मैनुअल लाइन्स के लिए वैकल्पिक), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Product पर HSN/SAC रखने से आपका एडमिन टीम इसे एक जगह में मेन्टेन कर सकती है। उसे InvoiceLine पर कॉपी करना ही पिछले चालानों को स्थिर बनाता है। भले ही बाद में उत्पाद बदल जाए, चालान तब भी वही दिखाएगा जो बिक्री के समय सच था। यह reconciliation में टूटने नहीं देने वाले GST इनवॉइस मॉडल का मूल है।

HSN स्टोरेज के लिए, इसे सरल रखें: code आवश्यक है, description वैकल्पिक है, और effective_from date वैकल्पिक है अगर आप परिवर्तन इतिहास चाहते हैं। अधिकांश टीमों को हर लाइन आइटम पर description की जरूरत नहीं होती, लेकिन यह असाधारण मामलों की जाँच करते समय फाइनेंस के लिए मददगार हो सकता है।

मिश्रित कार्ट सामान्य हैं: एक चालान में कई लाइन आइटम और इसलिए कई HSN/SAC कोड हो सकते हैं। एक चालान पर एक ही कोड मजबूर न करें। टोटल्स चालान स्तर पर रोल अप होते हैं, जबकि वर्गीकरण लाइन स्तर पर रहता है।

चेंज मैनेजमेंट में लोग फंसते हैं। एक छोटा नियम सेट इस्तेमाल करें:

• जारी किए गए चालान लाइन्स पर HSN/SAC कभी ओवरराइट न करें।
• अगर किसी उत्पाद का HSN/SAC बदलता है, तो भविष्य के ऑर्डर्स के लिए Product अपडेट करें केवल।
• यदि आप इतिहास ट्रैक करते हैं, तो पुराना रिकॉर्ड एडिट करने के बजाय नया effective_from रिकॉर्ड जोड़ें।

एडमिन स्क्रीन के लिहाज से, आपको केवल एक जगह चाहिए जहाँ Product टैक्स फ़ील्ड एडिट हों, और चालान लाइन पर एक रीड-ओनली व्यू कि चालान बनाए जाने पर क्या कैप्चर हुआ था। यदि आप ये स्क्रीन जल्दी बना रहे हैं, तो Koder.ai जैसी टूल्स इस मॉडल से बेसिक CRUD पेज और डेटा टेबल्स जनरेट कर सकती हैं कम प्रयास में।

पार्टी विवरण: GSTIN, पते, और place of supply

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

शुरू में “seller”, “buyer”, और “ship-to” को अलग पार्टियों की तरह समझें, भले ही वे समान व्यक्ति हों। यह बाद में हैकिंग को रोकेगा जब ग्राहक अलग शिपिंग पता जोड़ता है या जब आप एक से अधिक GST रजिस्ट्रेशन से बेचते हैं।

न्यूनतम फ़ील्ड्स (buyer और seller)

फ़ील्ड्स को साधारण और स्पष्ट रखें। ये वही होते हैं जो आमतौर पर चालान और रिपोर्ट्स में चाहिए होते हैं:

• कानूनी नाम (जैसा चालान पर दिखे)
• ट्रेड नाम (वैकल्पिक, पर उपयोगी)
• GSTIN (विक्रेता के लिए आवश्यक; खरीदार के लिए nullable)
• फोन/ईमेल (हमेशा अनिवार्य नहीं, पर सपोर्ट के लिए मददगार)
• पता की लाइनें, शहर, राज्य, देश, PIN/पोस्टल कोड

स्टेट को मानव-पठनीय नाम और स्टेट कोड दोनों के रूप में स्टोर करें, क्योंकि रिपोर्टिंग और place-of-supply नियम अक्सर कोड पर निर्भर होते हैं।

बिलिंग बनाम शिपिंग और place of supply

ऑर्डर पर दोनों बिलिंग और शिपिंग पते कैप्चर करें, सिर्फ ग्राहक प्रोफ़ाइल पर नहीं। प्रोफ़ाइल बदलती है; चालान नहीं होना चाहिए।

Place of supply को चालान पर एक विशेष स्टेट कोड के रूप में स्टोर करें (इसे चालान समय पर ऑर्डर से कॉपी करें)। बाद में इसे "रीकैलकुलेट" न करें। यदि आपकी नियमावली "ship-to state" है, तो उस परिणाम को स्टोर करें, साथ में वह राज्य जो आपने फैसला करने में उपयोग किया। इससे ऑडिट और विवाद आसान होते हैं।

B2B बनाम B2C: कब GSTIN अनिवार्य है

B2B के लिए, खरीदार GSTIN सामान्यतः अनिवार्य है और इसे एंट्री करते समय लंबाई और फॉर्मैट के लिए मान्य किया जाना चाहिए। B2C के लिए, GSTIN खाली रह सकता है, पर फिर भी पूरा पता और राज्य चाहिए ताकि यह तय हो सके कि CGST/SGST या IGST लागू होगा।

एक सरल नियम जो अधिकतर सिस्टम में काम करता है: यदि खरीदार का GSTIN मौजूद है, तो B2B मानेँ; यदि नहीं, तो B2C मानेँ। यदि अपवाद चाहिए, तो explicit customer_type फ़ील्ड स्टोर करें।

मल्टी-एंटिटी विक्रेता (कई GSTINs)

यदि आपके ब्रांच या बिजनेस यूनिट्स के अलग GST रजिस्ट्रेशन हैं, तो "Seller Entity" को अपना अलग रिकॉर्ड बनाएं जिसमें अपनी GSTIN और पता हो। हर ऑर्डर को ठीक एक seller entity रेफर करना चाहिए, और हर चालान को वे डिटेल्स कॉपी करनी चाहिए ताकि ऐतिहासिक चालान तब भी सटीक रहें जब बाद में विक्रेता का पता बदले।

Koder.ai जैसे टूल्स इन रिकॉर्ड्स के लिए एडमिन फ़ॉर्म जल्दी जनरेट कर सकते हैं, पर संरचना महत्वपूर्ण है: अलग seller entity, ऑर्डर-टाइम स्नैपशॉट्स, और एक स्पष्ट place-of-supply स्टेट कोड।

उन टैक्स गणना फ़ील्ड्स को स्टोर करें जो जरूरी हैं

सबसे सामान्य विभाजन सरल है: यदि place of supply और supplier एक ही राज्य में हैं, तो कर CGST + SGST है। यदि अलग राज्य हैं, तो IGST है। आपका सिस्टम बाद में "टोटल्स से फिर से गणना" न करे क्योंकि छोटे अंतर (राउंडिंग, डिस्काउंट, शिपिंग) वही कारण हैं जो मेल-मिलाप बिगाड़ते हैं।

कम से कम, कर संख्याएँ चालान लाइन स्तर पर स्टोर करें, न कि सिर्फ़ चालान हेडर पर। इस तरह आप चालान पर हर रुपये की व्याख्या कर सकते हैं और उसे उत्पाद, HSN, और राजस्व से मेल कर सकते हैं।

एक व्यावहारिक न्यूनतम प्रति चालान लाइन इस तरह दिखता है:

• taxable_value (लाइन-लेवल डिस्काउंट आवंटन के बाद)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (उपयोग किया गया विभाजन स्टोर करें)
• cgst_amount, sgst_amount, igst_amount (गणना की गई राशियाँ स्टोर करें)
• line_total (taxable_value + कर राशियाँ)

डिस्काउंट्स वह जगह हैं जहाँ सिस्टम जटिल हो जाते हैं। एक नियम तय करें और इसे साफ़ स्टोर करें। यदि डिस्काउंट कीमत को टैक्स से पहले घटाता है (आम तौर पर आइटम डिस्काउंट और कूपन के लिए), तो ओरिजिनल ग्रॉस अमाउंट, डिस्काउंट अमाउंट, और परिणामस्वरूप taxable value स्टोर करें। यदि आपके पास ऑर्डर-लेवल कूपन है, तो उसे लाइन्स पर आवंटित करें (आम तौर पर प्रत्येक लाइन के प्री-डिस्काउंट taxable value के अनुपात में) और हर लाइन का आवंटित डिस्काउंट स्टोर करें ताकि आपका टैक्स गणित समझने योग्य रहे।

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

शिपिंग और हैंडलिंग को छिपा-पट्टा एड-ऑन न समझें। इन्हें एक अलग चालान लाइन की तरह ट्रिट करें जिसमें अपना HSN/सेवा कोड और कर दर नियम हों। उदाहरण के लिए, दो उत्पाद और एक शिपिंग फ़ीस वाला ऑर्डर तीन लाइनों में बदल जाता है, प्रत्येक के साथ स्टोर की गई taxable value और कर घटक राशियों के साथ, जिससे फाइनेंस रीकंसिलीएशन बहुत आसान हो जाता है।

चालान दस्तावेज़ डेटा: नंबरिंग, तारीखें, टोटल्स, स्टेटस

एक बार कर की गणना हो जाने के बाद भी, चालान में वे "दस्तावेज़" फ़ील्ड होने चाहिए जो इसे वैध, ऑडिटेबल और बाद में मिलाने योग्य बनाते हैं। GST इनवॉइस डाटा मॉडल में इनवॉइस हेडर को एक कानूनी रिकॉर्ड की तरह ट्रीट करें: यह भविष्य में उत्पाद या ग्राहक डेटा बदलने पर भी स्थिर रहना चाहिए।

हेडर बेसिक्स से शुरू करें: invoice number, issue date (चालान पर लिखी तारीख), invoice type (tax invoice, export, B2B, B2C, आदि), और currency। भले ही आप ज्यादातर INR में इनवॉइस करते हों, करेंसी स्टोर करने से एक्सपोर्ट या मल्टी-करेंसी मार्केटप्लेस के लिए समस्याएँ कम होती हैं।

नंबरिंग वह जगह है जहाँ टीमें जलती हैं। एक सीरीज़ या प्रीफ़िक्स रखें (उदा. “FY25-INV-”), वित्तीय वर्ष स्टोर करें, और डेटाबेस लेवल पर यूनिकनेस को लागू करें। एडमिन में "next number" कंट्रोल्स भी स्टोर करें ताकि दो एडमिन एक ही नंबर एक साथ इश्यू न कर सकें।

टोटल्स को स्पष्ट रूप से स्टोर करें, सिर्फ डेराइव्ड न रखें। सबटोटल (taxable value), कुल कर, ग्रैंड टोटल, और अलग round-off राशि सेव करें। यदि आप बाद में लाइन आइटम्स से फिर से गणना करते हैं, तो छोटे नियम परिवर्तन से पुराने चालान फाइल किए गए रिटर्न से मेल खाना बंद कर सकते हैं।

स्टेटस वास्तविक लाइफसाइकल को परिलक्षित करने चाहिए और जरूरत पड़ने पर रिकॉर्ड को लॉक कर देना चाहिए:

• Draft (संपादन योग्य)
• Issued (नंबर असाइन, PDF जनरेट)
• Cancelled (ऑडिट के लिए रखा गया, डिलीट नहीं)
• Refunded (पेमेंट रिवर्स्ड, हो सकता है क्रेडिट नोट की जरूरत पड़े)
• Credit noted (लिंक्ड क्रेडिट नोट जारी)

अंत में, जेनरेट किए गए आर्टिफैक्ट मेटाडेटा स्टोर करें: PDF टेम्पलेट वर्ज़न, जनरेशन टाइमस्टैम्प, और एक फाइल आइडेंटिफायर। एक हैश वैकल्पिक है, पर उपयोगी है यदि आपको साबित करना हो कि PDF बदल नहीं गया।

उदाहरण: यदि एक सपोर्ट एजेंट टेम्पलेट अपडेट के बाद PDF री-जनरेट करता है, तो चालान टोटल और नंबर एक जैसे रहने चाहिए, पर स्टोर किया गया टेम्पलेट वर्ज़न समझाता है कि PDF लेआउट अलग दिखता है।

प्रोडक्ट्स, टैक्स और ग्राहक विवरण के लिए एडमिन स्क्रीन

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

प्रोडक्ट मास्टर (SKU से HSN/SAC)

प्रोडक्ट मास्टर वही जगह है जहाँ अधिकतर भविष्य के मिसमैच शुरू होते हैं, इसलिए इसे कड़ा रखें। प्रत्येक SKU के पास ठीक एक डिफ़ॉल्ट HSN (या सेवाओं के लिए SAC) होना चाहिए, साथ में डिफ़ॉल्ट GST दर और कोई अपवाद जो सिर्फ़ कुछ तारीखों के लिए लागू हों।

एक व्यावहारिक प्रोडक्ट स्क्रीन आमतौर पर चाहिए:

• SKU और प्रोडक्ट नाम (जैसा आप प्रिंट करना चाहते हैं)
• HSN/SAC कोड, GST दर, और टैक्स कैटेगरी (यदि आप उपयोग करते हैं)
• Active from/to तारीखें (ताकि बदलाव पुराने चालानों को ओवरराइट न करें)
• प्राइस ओवरराइड्स (विशेष MRP या चैनल-विशेष प्राइसिंग के लिए)
• स्थिति (active/inactive) और निष्क्रियकरण का स्पष्ट कारण

टैक्स सेटअप (दरें और इन्ट्रा बनाम इंटर-स्टेट इनपुट)

"कैलकुलेटर" UI से बचें। इसके बजाय वे इनपुट स्टोर करें जो आपका सिस्टम लगातार लागू कर सके: रेट टेबल्स, आप जो place of supply नियम फॉलो करते हैं, और आप कैसे तय करते हैं कि इन्ट्रा-स्टेट बनाम इंटर-स्टेट (आम तौर पर supplier state और ship-to state की तुलना करके)।

टैक्स स्क्रीन को इस बात पर केंद्रित रखें: कैटेगरी/HSN समूह के अनुसार कर दर, प्रभावी तारीखें, और जब खरीदार वैध GSTIN देता है तब क्या होना चाहिए।

ग्राहक और कंपनी प्रोफ़ाइल (कौन चालान पर है)

ग्राहक स्क्रीन को GSTIN और उसकी वैलिडेशन स्टेटस कैप्चर करनी चाहिए, साथ में डिफ़ॉल्ट बिलिंग और शिपिंग पते। उपयोगकर्ताओं को फ्रीफॉर्म राज्यों में टाइप करने न दें; एक नियंत्रित सूची इस्तेमाल करें ताकि "KA" और "Karnataka" दो अलग मान न बन जाएँ।

आपकी कंपनी प्रोफ़ाइल स्क्रीन समान रूप से महत्वपूर्ण है: कानूनी नाम, GSTIN, पंजीकृत पता, और इनवॉइस सीरीज़ सेटिंग्स (प्रीफ़िक्स, नेक्स्ट नंबर, और वित्तीय वर्ष की सीमाएँ)। इसे परमिशन्स के साथ लॉक करें क्योंकि बदलाव भविष्य के हर दस्तावेज़ को प्रभावित करते हैं।

ऑडिट लॉग बेसिक्स (ट्रस्ट और ट्रेसिबिलिटी)

आपको जटिल सिस्टम की ज़रूरत नहीं, पर आपको एक ट्रेल चाहिए। लॉग करें कि किसने HSN/SAC, GST दरें, इनवॉइस सीरीज़ सेटिंग्स, या कंपनी GSTIN बदला, साथ में पुराना मान, नया मान, टाइमस्टैम्प, और कारण।

यदि आप ये स्क्रीन Koder.ai जैसी टूल में बना रहे हैं, तो ऑडिट लॉगिंग और प्रभावी तारीखों को पहले दिन से प्राथमिक फ़ील्ड्स की तरह ट्रिट करें। इन्हें जल्दी जोड़ना महंगा नहीं है और बाद में फाइनेंस रिव्यू में घंटे बचाते हैं।

स्टेप बाय स्टेप: ऑर्डर से कानूनी रूप से अनुपालन चालान तक

एक अनुपालन चालान फैंसी फॉर्मैटिंग से ज़्यादा सही समय पर सही तथ्यों को फ्रीज़ करने के बारे में है। यदि आप अपना GST इनवॉइस डाटा मॉडल इस फ्लो के चारों ओर डिज़ाइन करते हैं, तो फाइनेंस का काम सरल मैच बन जाता है, ना कि साप्ताहिक जाँच।

1) ग्राहक ने असल में क्या खरीदा इसे फ्रीज़ करें

टैक्स निकालने से पहले, एक ऑर्डर स्नैपशॉट लॉक करें: आइटम्स, मात्राएँ, यूनिट प्राइस, डिस्काउंट्स, शिपिंग/हैंडलिंग चार्जेस, ग्राहक GSTIN (यदि कोई), बिलिंग और शिपिंग पते, और place of supply संकेत। स्नैपशॉट बदलना नहीं चाहिए भले ही प्रोडक्ट प्राइस या HSN मैपिंग बाद में बदले।

2) स्नैपशॉट को चालान लाइन्स में बदलें (कॉपी किए गए टैक्स एट्रिब्यूट्स के साथ)

स्नैपशॉट से टैक्स निकालें और चालान लाइन्स जेनरेट करें। हर चालान लाइन को उस समय की HSN/SAC, कर दर(एं), taxable value, और उपयोग की गई कर राशियाँ कॉपी करनी चाहिए, बजाय इसके कि बाद में लाइव लुकअप किया जाए।

3) चालान जारी करें और इसे अपरिवर्तनीय बनाएं

चालान नंबर असाइन करें और issue तारीख दें, फिर चालान को issued मार्क करें। इस बिंदु से चालान रिकॉर्ड पर प्राइसिंग, कर दरें, HSN कोड, और पते एडिट करने से ब्लॉक करें। यदि कुछ अनुमति देनी है तो केवल गैर-वित्तीय नोट्स और आंतरिक टैग्स तक सीमित रखें।

4) अंतिम दस्तावेज़ बनाएं और टोटल्स स्टोर करें

जारी किए गए चालान से PDF/प्रिंट व्यू जनरेट करें, फिर रिपोर्ट किए जाने वाले अंतिम टोटल्स स्टोर करें: taxable total, CGST/SGST/IGST टोटल्स, राउंडिंग, और ग्रैंड टोटल। अतिरिक्त सुरक्षा के लिए, एक दस्तावेज़ वर्ज़न या चेकसम स्टोर करें ताकि सिद्ध किया जा सके कि प्रिंटआउट स्टोर किए गए नंबरों से मेल खाता है।

5) कानूनी तरीके से बदलाव हैंडल करें

जारी करने के बाद, बदलाव नियमों के अनुसार होने चाहिए, न कि सीधे एडिट से:

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

यदि आप यह फ्लो अपने एडमिन स्क्रीन में बिल्ट करते हैं (Koder.ai-स्टाइल प्लानिंग मोड मैपिंग के लिए सहायक है), तो आपकी टीम जल्दी से चालान जनरेट कर सकती है बिना बाद में रीकंसिलीएशन तोड़ने के।

रीकंसिलीएशन को सरल बनाएं: पेमेंट्स, रिफंड्स, और रजिस्टर

रीकंसिलीएशन तब गड़बड़ होता है जब पेमेंट्स को ऑर्डर पर एक सिंगल "paid/unpaid" फ़्लैग के रूप में ट्रीट किया जाता है। पेमेंट्स और रिफंड्स को अलग रिकॉर्ड्स के रूप में रखें जो ऑर्डर और चालान की ओर पॉइंट करें, ताकि फाइनेंस बैंक सेटलमेंट्स को इतिहास बदलने बिना मैच कर सके।

पेमेंट और रिफंड रिकॉर्ड्स अलग रखें (चालान को एडिट न करें)

एक अनुपालन चालान जारी होने के बाद स्थिर रहना चाहिए। यदि ग्राहक हिस्सों में पे कर रहा है, या आप बाद में रिफंड कर रहे हैं, तो उस मूवमेंट को पेमेंट या रिफंड एंट्री के रूप में रिकॉर्ड करें, न कि चालान टोटल्स में परिवर्तन करके।

रीकंसिलीएशन को आम तौर पर आसान बनाने वाले न्यूनतम फ़ील्ड्स:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (वैकल्पिक पर मददगार): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (यदि जारी), gateway_refund_id, amount, reason, refunded_at, status
• Reconciliation keys जिन्हें आप कभी री-यूज़ न करें: order_id, invoice_id, payment_id, refund_id, credit_note_id

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

फाइनेंस व्यू और एक्सपोर्ट्स जो घंटे बचाते हैं

फाइनेंस को एक सिंगल स्क्रीन दें जो यह जवाब दे: क्या जारी हुआ, क्या भुगतान हुआ, क्या अभी भी खुला है, और क्या रिवर्स हुआ। इसमें एजिंग (0-7, 8-30, 31-60, 60+ दिन) और संबंधित पेमेंट/रिफंड एंट्रीज़ तक ड्रिल-डाउन शामिल करें।

महीने में अधिकतर टीमें जिन एक्सपोर्ट्स की जरूरत होती है:

• Invoice register (issued, cancelled, credit-noted)
• Tax summary by rate and HSN/SAC (आपके GST इनवॉइस डाटा मॉडल का समर्थन करता है)
• Payment vs invoice reconciliation (invoice_id, payment totals, balance)
• Refund and credit note register
• Gateway settlement report (payout_id से invoice/payment मैपिंग)

उदाहरण: एक ऑर्डर Rs 10,000 है, आज Rs 6,000 पे हुए और अगले हफ्ते Rs 4,000। चालान Rs 10,000 पर रहता है। आपकी फाइनेंस व्यू बैलेंस Rs 4,000 दिखाती है जब तक दूसरा सेटलमेंट नहीं आता, फिर बिना जारी दस्तावेज़ बदले उसे फुली पे किया हुआ दिखाया जाता है।

सामान्य जाल जो अनुपालन और मेल-मिलाप की समस्याएँ पैदा करते हैं

अधिकांश GST इनवॉइस समस्याएँ "टैक्स लॉजिक" की नहीं बल्कि रिकॉर्ड कीपिंग की होती हैं: PDF पर जो नंबर हैं वे फाइनेंस एक्सपोर्ट्स से मेल नहीं खाते, या चालान को महीनों बाद समझाया नहीं जा सकता।

पहला जाल है केवल व्यू समय पर GST की गणना करना। यदि आप हर बार किसी चालान को खोलने पर CGST/SGST/IGST की गणना करते हैं, तो किसी दर परिवर्तन, राउंडिंग नियम परिवर्तन, या बग फिक्स के बाद परिणाम अलग हो जाएंगे। डेराइव्ड इनपुट्स स्टोर करने के साथ-साथ जारी किए जाने पर उपयोग किए गए कर ब्रेकडाउन को स्टोर करें।

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

यहाँ वे मिसमैच पैटर्न हैं जो सबसे अधिक दिखते हैं:

• place of supply गायब है या स्टेट कोड गलत है, इसलिए IGST लागू हो रहा है जबकि CGST+SGST होना चाहिए (या उल्टा)।
• उत्पाद HSN/SAC या कर दर अपडेट की गई और पुराने ऑर्डर नई वैल्यू से फिर से कैल्क्युलेट हो गए।
• कर स्टोर तो है, पर UI, PDF जनरेशन, और CSV एक्सपोर्ट्स के बीच राउंडिंग नियम अलग हैं।
• डिस्काउंट्स एक जगह पर कर के बाद और दूसरी जगह कर से पहले लागू हो रहे हैं।
• रिफंड्स को नेगेटिव लाइन आइटम्स के रूप में रिकॉर्ड किया गया है बिना मूल चालान के स्पष्ट लिंक के।

एक तेज़ उदाहरण: आप कर्नाटक के ग्राहक को बेचते हैं, पर शिपिंग पता महाराष्ट्र में है। यदि आपका सिस्टम गलती से बिलिंग स्टेट को place of supply ले लेता है, तो आप CGST+SGST चार्ज कर सकते हैं बजाय IGST के। यदि आप कर को ऑन-द-फ्लाई फिर से कैल्क्युलेट भी करते हैं, तो वह त्रुटि चुपचाप बाद में "ठीक" हो सकती है, जिससे फाइनेंस के पास वे नंबर रह जाते हैं जो जारी दस्तावेज़ से मेल नहीं खाते।

जब आप एडमिन स्क्रीन बनाते हैं (कस्टम हों या Koder.ai जैसे प्लेटफ़ॉर्म द्वारा), छोटे गार्डरैल्स जोड़ें: जारी चालानों को लॉक करें, कॉम्प्यूटेड टैक्स टाइप के बगल में place-of-supply इनपुट्स दिखाएँ, और जारी करने पर उपयोग किए गए HSN, दर और राउंडिंग का अपरिवर्तनीय स्नैपशॉट रखें।

त्वरित चेकलिस्ट और अगले कदम

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

प्रति-चालान चेक्स (इश्यू से पहले)

• हर लाइन आइटम पर HSN/SAC मौजूद है और वह उत्पाद/सेवा से मेल खाता है जो असल में बेची गई थी।
• GSTIN नियम सही ढंग से लागू हैं (B2B बनाम B2C), और बिलिंग व शिपिंग विवरण आपस में विरोधाभासी नहीं हैं।
• Place of supply स्टोर है और कर विभाजन तार्किक है (CGST/SGST बनाम IGST)।
• टोटल्स बिल्कुल मिलते हैं: taxable value, प्रत्येक कर घटक, राउंडिंग, और ग्रैंड टोटल।
• एक बार जारी होने पर, चालान लॉक है (कोई साइलेंट एडिट नहीं)। फिक्सेस क्रेडिट नोट या कैंसिलेशन फ्लो के ज़रिये होते हैं, इतिहास फिर से लिखकर नहीं।

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

डाटा + वर्कफ़्लो चेक्स (फाइनेंस को साफ रखने के लिए)

• चालान नंबरिंग यूनिक और आपके पॉलिसी अनुसार अनुक्रमिक है, और केवल "issue" समय पर जेनरेट होती है।
• आपने उपयोग की गई गणितीय कर राशियाँ स्टोर की हैं, सिर्फ दरें नहीं, ताकि रिपोर्ट्स तब भी स्थिर रहें जब बाद में दरें बदलें।
• स्पष्ट स्टेटस स्टेप्स मौजूद हैं: draft -> issued -> cancelled (और अलग क्रेडिट नोट दस्तावेज़)।
• रिपोर्ट्स अवधि द्वारा मेल खाते हैं: इनवॉइस रजिस्टर टोटल्स को कैप्चर किए गए पेमेंट्स, प्रोसेस्ड रिफंड्स, और आउटस्टैंडिंग रिसीवेबल्स से जोड़ना चाहिए।
• ऑडिट फ़ील्ड्स हमेशा मौजूद हों: created by, issued at, और कैंसिलेशन या क्रेडिट नोट के लिए कारण नोट।

अगले कदम: पहले स्क्रीन और वैलिडेशन्स इम्प्लीमेंट करें, फिर इटेरेट करें। Koder.ai में Planning Mode का उपयोग करें ताकि रिकॉर्ड्स और एडमिन स्क्रीन (HSN/SAC मैपिंग वाले प्रोडक्ट, ग्राहक/GSTIN विवरण, टैक्स नियम, और चालान) का ड्राफ्ट बन सके। ऐप जेनरेट करें, कुछ असली ऑर्डर्स एंड-टू-एंड टेस्ट करें, फिर स्नैपशॉट्स और रोलबैक का उपयोग करके सुरक्षित रूप से वर्कफ़्लो को परिष्कृत करें। जब आपको अधिक कस्टमाइज़ेशन या रिव्यू की जरूरत हो, तो स्रोत कोड एक्सपोर्ट करें और अपने सामान्य प्रॉसेस के साथ विकसित करते रहें।