बिलिंग लेज़र स्कीमा जो मिलान करता है — चालान और भुगतान

क्यों बिलिंग डेटा मेल खाना बंद कर देता है

फाइनेंस के लिए “रिकॉन्साइल” का सरल वादा यह है: रिपोर्ट्स के कुल स्रोत रिकॉर्ड्स से मेल खाएँ और हर संख्या को ट्रेस किया जा सके। अगर किसी महीने में $12,430 कलेक्ट दिख रहा है, तो आप उसे ठीक-ठीक पोस्ट किए गए भुगतानों (और किसी भी रिफंड) से जोड़ कर दिखा सकें, देख सकें कि वे किन चालानों पर लागू हुए और हर अंतर को एक दिनांकित रिकॉर्ड से समझा सकें।

बिलिंग डेटा आमतौर पर तब मेल खाना बंद कर देता है जब डेटाबेस तथ्यों की बजाय नतीजों को स्टोर करता है। paid_amount, balance या amount_due जैसे कॉलम समय के साथ एप्लिकेशन लॉजिक द्वारा अपडेट हो जाते हैं। एक बग, एक रीट्राई, या एक मैनुअल “फिक्स” इतिहास को चुपचाप बदल सकता है। कुछ सप्ताह बाद, इनवॉइस तालिका कह सकती है कि इनवॉइस "paid" है, पर भुगतान रो जोड़ कर नहीं आते, या कोई रिफंड बिना मिलान किए हुए क्रेडिट के मौजूद हो।

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

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

इस लक्ष्य के लिए डिजाइन करें:

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

उदाहरण: अगर ग्राहक ने $100 दिए, फिर $20 का क्रेडिट मिला, तो आपकी रिपोर्ट्स को दिखाना चाहिए $100 कलेक्टेड, $20 क्रेडिटेड, और $80 नेट, बिना मूल इनवॉइस राशि को एडिट किए।

चालान, भुगतान, क्रेडिट और समायोजन अलग रखें

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

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

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

एक क्रेडिट मेमो वह है जो ग्राहक की देनदारी घटाता है बिना जरूरी रूप से पैसा वापस भेजे। एक रिफंड नकद बाहर जाना है। ये अक्सर साथ होते हैं, पर समान नहीं हैं।

• इनवॉइस: ऋणी और राजस्व (या डिफर्ड रेवन्यू) बढ़ाता है
• भुगतान: नकद बढ़ाता है और ऋणी घटाता है
• क्रेडिट मेमो: ऋणी घटाता है
• रिफंड: नकद घटाता है

एक समायोजन तब होता है जब टीम वास्तविकता और रिकॉर्ड मेल नहीं खाते और सुधार किया जाता है। समायोजनों में संदर्भ चाहिए ताकि फाइनेंस उन पर भरोसा कर सके। स्टोर करें कि किसने बनाया, कब पोस्ट किया गया, कारण कोड और छोटा नोट। उदाहरण: “राउंडिंग के कारण 0.03 लिख-ऑफ़,” या “लिगेसी बैलेंस माइग्रेट किया।”

एक व्यावहारिक नियम: पूछें, “क्या यह तब भी मौजूद होता अगर किसी ने गलती न की हो?” इनवॉइस, भुगतान, क्रेडिट मेमो और रिफंड मौजूद रहेंगे। समायोजन दुर्लभ होने चाहिए, स्पष्ट लेबल के साथ और समीक्षा में आसान।

ऐसा लेज़र मॉडल चुनें जिसे फाइनेंस ऑडिट कर सके

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

दस्तावेज़ बनाम पोस्टिंग्स (दोनों स्टोर करें)

लोगों को पढ़ने के लिए दस्तावेज़ रखें (इनवॉइस हेडर और लाइन्स, भुगतान रसीद, क्रेडिट मेमो)। पर पोस्टिंग के लिए केवल दस्तावेज़ टोटल पर निर्भर न रहें।

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

एक सरल ऑडिट-फ्रेंडली मॉडल कुछ नियमों का पालन करता है:

• अपरिवर्तनीय एंट्रीज़: पोस्ट किए गए अमाउंट को कभी एडिट न करें; बदलाव नई एंट्री हों।
• स्पष्ट पोस्टिंग इवेंट: प्रत्येक दस्तावेज़ एक यूनिक रेफरेंस के साथ पोस्टिंग बैच बनाता है।
• बैलेंस्ड लॉजिक: एंट्रीज़ कंपनी-स्तर पर सही नेट करें (अक्सर डेबिट = क्रेडिट)।
• अलग तारीखें: दस्तावेज़ तारीख और पोस्टिंग तारीख अलग रखें।
• स्थायी रेफरेंस: बाहरी संदर्भ (इनवॉइस नंबर, भुगतान प्रोसेसर ID) आंतरिक IDs के साथ स्टोर करें।

नैचुरल कीज़ बनाम सर्वोगेट IDs

जोइन और परफॉर्मेंस के लिए सर्वोगेट IDs का उपयोग करें, पर एक स्थिर नैचुरल की भी रखें जो माइग्रेशन और री-इम्पोर्ट के बाद भी टिके। फाइनेंस लंबे समय बाद “Invoice INV-10483” पूछेगा। इनवॉइस नंबर और प्रोवाइडर IDs (जैसे भुगतान प्रोसेसर चार्ज ID) को फर्स्ट-क्लास फील्ड मानें।

इतिहास मिटाये बिना रिवर्सल

जब कुछ उलटना हो तो डिलीट या ओवरराइट न करें। रिवर्सल पोस्ट करें: नई एंट्रीज़ जो मूल राशियों का उल्टा हों, और उन्हें मूल पोस्टिंग से लिंक करें।

उदाहरण: गलत इनवॉइस पर लगाए गए $100 भुगतान के लिए पहले गलत पोस्टिंग रिवर्स करें, फिर सही इनवॉइस पर नया एप्लिकेशन पोस्ट करें।

चरण-दर-चरण स्कीमा ब्लूप्रिंट (तालिकाएँ और कुंजियाँ)

एक बिलिंग लेज़र स्कीमा तब अधिक विश्वसनीय रूप से मेल खाता है जब प्रत्येक दस्तावेज़ प्रकार की अपनी तालिका हो और आप उन्हें स्पष्ट आवंटन रिकॉर्ड्स से जोड़ें (बाद में संबंधों का अनुमान न लगाएं)।

कोर टेबल्स के साथ शुरू करें, हर एक में स्पष्ट प्राइमरी की (UUID या bigserial) और आवश्यक फॉरेन कीज़:

• customers: customer_id (PK), साथ में स्थिर पहचानें जैसे external_ref (unique)
• invoices: invoice_id (PK), customer_id (FK), invoice_number (unique), issue_date, due_date, currency
• invoice_lines: invoice_line_id (PK), invoice_id (FK), line_type, description, qty, unit_price, tax_code, amount
• payments: payment_id (PK), customer_id (FK), payment_date, method, currency, gross_amount
• credits: credit_id (PK), customer_id (FK), credit_number (unique), credit_date, currency, amount

फिर उन तालिकाओं को जोड़ें जो कुलों को ऑडिट करने योग्य बनाती हैं: आवंटन। एक भुगतान या क्रेडिट कई चालानों को कवर कर सकता है, और एक चालान कई भुगतानों से भरा जा सकता है।

जोइन टेबल्स अपने स्वयं के कीज़ के साथ रखें (सिर्फ कंपोजिट कीज़ नहीं):

• payment_allocations: payment_allocation_id (PK), payment_id (FK), invoice_id (FK), allocated_amount, posted_at
• credit_allocations: credit_allocation_id (PK), credit_id (FK), invoice_id (FK), allocated_amount, posted_at

अंत में, समायोजनों को अलग रखें ताकि फाइनेंस देख सके क्या बदला और क्यों। एक adjustments तालिका लक्ष्य रिकॉर्ड को invoice_id (nullable) के साथ संदर्भित कर सकती है और डेल्टा राशि स्टोर कर सकती है, बिना इतिहास को फिर से लिखे।

पैसा पोस्ट करते समय हर जगह ऑडिट फ़ील्ड्स जोड़ें:

• created_at, created_by
• reason_code (write-off, rounding, goodwill, chargeback)
• source_system (manual, import, Stripe, support tool)

क्रेडिट, रिफंड और राइट-ऑफ बिना टूटी हुई कुलों के

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

एक क्रेडिट यह दिखाना चाहिए कि आपने क्यों ग्राहक की देनदारी घटाई। यदि यह एक चालान पर लागू है, तो एक क्रेडिट मेमो रिकॉर्ड करें और उसे उस चालान पर आवंटित करें। यदि यह कई चालानों पर लागू है, तो उसी क्रेडिट मेमो को कई चालानों पर आवंट करें। क्रेडिट एक दस्तावेज़ ही रहता है जिसके कई आवंटन हो सकते हैं।

रिफंड भुगतान-जैसी घटनाएँ होती हैं, न कि निगेटिव पेमेंट्स। रिफंड नकद बाहर जाना है, अतः इसे अपनी रिकॉर्ड के रूप में रखें (अक्सर संदर्भ के लिए मूल भुगतान से जुड़ा हुआ), फिर इसे भुगतान की तरह ही आवंटित करें। इससे बैंक स्टेटमेंट में आने वाले इनकम और आउटगोइंग दोनों स्पष्ट रहते हैं।

आंशिक भुगतान और आंशिक क्रेडिट भी एक ही तरह काम करते हैं: भुगतान या क्रेडिट कुल अपनी अलग पंक्ति पर रखें, और प्रत्येक चालान पर कितना लगाया गया यह आवंटन रो में रखें।

डबल काउंटिंग रोकने वाले पोस्टिंग नियम

ये नियम अधिकांश “रहस्यमयी अंतर” हटा देते हैं:

• कभी निगेटिव भुगतान न स्टोर करें। रिफंड रिकॉर्ड का उपयोग करें।
• पोस्ट करने के बाद इनवॉइस टोटल कभी घटाएँ मत। क्रेडिट मेमो या समायोजन का उपयोग करें।
• दस्तावेज़ों को एक बार पोस्ट करें (posted_at), और पोस्टिंग के बाद राशि एडिट न करें।
• इनवॉइस बैलेंस को बदलने वाली केवल पोस्टेड आवंटन का योग होना चाहिए।
• राइट-ऑफ एक कारण कोड के साथ समायोजन होता है, जिसे चालान पर क्रेडिट की तरह आवंटित किया जाता है।

टैक्स, फीस, मुद्रा और राउंडिंग के निर्णय

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

टैक्स और फीस: इन्हें लाइन लेवल पर रखें

लाइन-आइटम के अनुसार टैक्स और फीस रखें, न कि केवल इनवॉइस-लेवल समरी। अलग-अलग उत्पादों पर अलग टैक्स रेट हो सकती है, फीस टैक्सेबल या नॉन-टैक्सेबल हो सकती है, और छूट अक्सर सिर्फ किसी हिस्से पर लागू होती है। अगर आप केवल tax_total रखते हैं, तो आप अंततः एक केस से ठोकर खाएँगे जिसे आप समझा नहीं पाएंगे।

रखें:

• रॉ लाइन्स (क्या बेचा गया, qty, यूनिट प्राइस, डिस्काउंट)
• कैलकुलेटेड लाइन टोटल्स (line_subtotal, line_tax, line_total)
• इनवॉइस समरी टोटल्स (subtotal, tax_total, total)
• प्रयुक्त टैक्स रेट और टैक्स प्रकार
• फीस को अपनी अलग लाइन आइटम के रूप में रखें (उदा., “Payment processing fee”)

इससे फाइनेंस टोटल्स फिर से बना सकेगा और सुनिश्चित कर सकेगा कि टैक्स हर बार एक ही तरीके से कैल्कुलेट हुआ था।

मल्टी-करेंसी: जो हुआ उसे और आप कैसे रिपोर्ट करते हैं, दोनों स्टोर करें

यदि आप मल्टी-करेंसी सपोर्ट करते हैं, तो लेन-देन मुद्रा और रिपोर्टिंग मुद्रा दोनों के मान रिकॉर्ड करें। एक व्यवहारिक न्यूनतम है: हर मॉनेटरी दस्तावेज़ पर currency_code, पोस्टिंग समय पर प्रयुक्त fx_rate, और अलग रिपोर्टिंग रकम (amount_reporting) यदि आपकी बुक्स एक मुद्रा में क्लोज़ होती हैं।

उदाहरण: ग्राहक को 100.00 EUR + 20.00 EUR VAT बिल किया गया। उन EUR लाइन्स और टोटल्स स्टोर करें, साथ में वह fx_rate जो इनवॉइस पोस्ट करते समय इस्तेमाल किया गया और रिपोर्टिंग के लिए कन्वर्टेड टोटल्स।

राउंडिंग का अपना इलाज हो। एक राउंडिंग नियम चुनें (प्रति लाइन या प्रति इनवॉइस) और उसी पर टिके रहें। जब राउंडिंग से अंतर हो, तो उसे स्पष्ट रूप से एक राउंडिंग समायोजन लाइन के रूप में रिकॉर्ड करें बजाय चुपचाप टोटल्स बदलने के।

स्टेटस, पोस्टिंग डेट्स, और क्या न स्टोर करें

जब कोई टीम “स्टेटस” को अकाउंटिंग सच्चाई के शॉर्टकट के रूप में उपयोग करती है, तो रिकॉन्सिलिएशन गड़बड़ा जाता है। स्टेटस को वर्कफ़्लो लेबल के रूप में ट्रीट करें, और पोस्टेड लेज़र एंट्रीज़ को सच्चाई मानें।

स्टेटस को सख्त और साधारण रखें। हर एक का जवाब होना चाहिए: क्या यह दस्तावेज़ अब totals को प्रभावित कर सकता है?

• Draft: केवल आंतरिक, पोस्टेड नहीं, रिपोर्ट्स पर नहीं आना चाहिए
• Issued: फ़ाइनल और भेजा गया, पोस्ट होने के लिए तैयार (या पहले से पोस्ट हो चुका)
• Void: रद्द; अगर इसे पोस्ट किया गया था तो इसे रिवर्स करना होगा
• Paid: पोस्टेड भुगतानों और क्रेडिट्स द्वारा पूरी तरह से सेटल
• Refunded: रिफंड एक पोस्टेड रिफंड के जरिए बाहर भेजा गया

तिथियाँ अधिकांश टीमों की अपेक्षा से ज़्यादा मायने रखती हैं। फाइनेंस पूछेगा, “यह किस महीने का है?” और आपका उत्तर UI लॉग्स पर निर्भर नहीं होना चाहिए।

• issued_at: जब इनवॉइस फ़ाइनल हुआ
• posted_at: जब यह अकाउंटिंग रिपोर्ट्स में गिना जाता है
• settled_at: जब फंड क्लियर हुए या भुगतान की पुष्टि हुई
• voided_at / refunded_at: जब रिवर्सल प्रभावी हुआ

क्या न स्टोर करें: व्युत्पन्न संख्याएँ जो आप लेज़र से फिर से नहीं बना सकते। balance_due, is_overdue, और customer_lifetime_value जैसे फ़ील्ड्स कैश्ड व्यू के रूप में ठीक हैं पर तभी जब आप हमेशा इन्हें इनवॉइस, भुगतान, क्रेडिट, आवंटन और समायोजन से पुनर्गणना कर सकें।

एक छोटा उदाहरण: एक भुगतान रीट्राई आपके गेटवे पर दो बार हिट हुआ। बिना idempotency_key, आप दो भुगतान स्टोर कर लेते हैं, इनवॉइस को "paid" मार्क कर देते हैं, फिर फाइनेंस को अतिरिक्त $100 दिखेगा। हर बाहरी चार्ज प्रयास पर एक यूनिक idempotency_key रखें और डेटाबेस स्तर पर डुप्लीकेट्स को रिजेक्ट करें।

फाइनेंस जो रिपोर्ट्स चाहता है, पहले दिन से

एक बिलिंग लेज़र स्कीमा अपनी परीक्षा तब पास करता है जब फाइनेंस बेसिक सवालों का त्वरित और हर बार वही उत्तर पा सके।

अधिकांश टीमें इनसे शुरू करती हैं:

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

एजिंग में आवंटन सबसे ज़्यादा मायने रखते हैं। एजिंग "इनवॉइस टोटल माइनस पेमेंट्स टोटल" नहीं है। यह है: किसी तारीख तक प्रत्येक इनवॉइस पर क्या खुला है। इसके लिए आपको यह स्टोर करना होगा कि हर भुगतान, क्रेडिट या समायोजन किस इनवॉइस पर कब पोस्ट किया गया।

कैश रिसीव्ड भुगतान तालिका द्वारा संचालित होना चाहिए, न कि इनवॉइस स्टेटस द्वारा। ग्राहक समय से पहले, देरी से, या आंशिक रूप से भुगतान कर सकता है।

रेवन्यू बनाम कैश यही कारण है कि इनवॉइस और भुगतान अलग रहने चाहिए। उदाहरण: आप 30 मार्च को $1,000 का इनवॉइस जारी करते हैं, 5 अप्रैल को $600 प्राप्त करते हैं, और 20 अप्रैल को $100 का क्रेडिट देते हैं। राजस्व मार्च में (इनवॉइस पोस्टिंग), नकद अप्रैल में (भुगतान पोस्टिंग), और क्रेडिट पोस्ट होने पर रिसीवेबल घटाता है। आवंटन इन्हें एक साथ जोड़ते हैं।

उदाहरण परिदृश्य: एक ग्राहक, चार दस्तावेज़ प्रकार

एक ग्राहक, एक माह, चार दस्तावेज़ प्रकार। प्रत्येक दस्तावेज़ को एक बार स्टोर किया जाता है, और पैसा आवंटन तालिका के माध्यम से चलता है (कभी-कभी इसे “applications” कहा जाता है)। इससे अंतिम बैलेंस फिर से निकालना और ऑडिट करना आसान होता है।

मान लीजिए ग्राहक C-1001 (Acme Co.)।

बनाए गए रिकॉर्ड्स

invoices

payments

credits (क्रेडिट मेमो, गुडविल क्रेडिट, आदि)

adjustments (बाद में किया गया सुधार, नया सेल नहीं)

allocations (यही वह चीज़ है जो असल में बैलेंस को रीकॉन्सिल करती है)

इनवॉइस बैलेंस कैसे निकाला जाता है

INV-10 के लिए ऑडिटर स्रोत पंक्तियों से खुला बैलेंस फिर से बना सकता है:

open_balance = invoice.total + sum(adjustments) - sum(allocations)

तो: 120.00 + 5.00 - (70.00 + 20.00) = 35.00 बकाया।

"35.00" को ट्रेस करने के लिए:

• इनवॉइस टोटल (INV-10) से शुरू करें
• उसी इनवॉइस से जुड़ी पोस्ट की गई समायोजनों (ADJ-3) को जोड़ें
• इनवॉइस पर लागू प्रत्येक पोस्टेड आवंटन (AL-900, AL-901) घटाएँ
• पुष्टि करें कि प्रत्येक आवंटन असली स्रोत दस्तावेज़ (PAY-77, CR-5) की ओर इशारा करता है
• टाइमलाइन समझाने के लिए तारीखें और posted_at सत्यापित करें

सामान्य गलतियाँ जो रिकॉन्सिलिएशन तोड़ देती हैं

अधिकांश रिकॉन्सिलिएशन समस्याएँ “मैथ बग्स” नहीं होतीं। ये नियमों की कमी होती हैं, जिससे वही वास्तविक-विश्व घटना अलग-अलग तरीकों से रिकॉर्ड हो जाती है, यह निर्भर करता है कि किसने उसे छुआ।

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

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

वे पैटर्न जो आमतौर पर कुलों को तोड़ते हैं:

• बिना सख्त रिवर्सल नियम और मूल रो के रेफरेंस के निगेटिव रो का उपयोग
• जारी करने के बाद पुराने इनवॉइस को एडिट करना बजाय समायोजन या क्रेडिट नोट पोस्ट करने के
• गेटवे ट्रांज़ैक्शन IDs और आंतरिक IDs को बिना मैपिंग तालिका के मिलाना और स्रोत की स्पष्टता न रखना
• एप्लिकेशन को टोटल्स कंप्यूट करने देना जबकि सपोर्टिंग रो (tax, fee, rounding, allocations) गायब हों
• "पैसा हिलना" (कैश मूवमेंट) को "पैसा आवंटित होना" (किस इनवॉइस का भुगतान हुआ) से न अलग करना

आखिरी बिंदु सबसे ज़्यादा भ्रम पैदा करता है। उदाहरण: एक ग्राहक $100 देता है, फिर आप $60 को इनवॉइस A पर और $40 को इनवॉइस B पर अप्लाई करते हैं। भुगतान एक नकद मूवमेंट है, पर यह दो आवंटनों को बनाता है। अगर आप केवल "payment = invoice" स्टोर करते हैं, तो आप आंशिक भुगतान, ओवरपेमेंट या पुनरावंटन को सपोर्ट नहीं कर पाएँगे।

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

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

त्वरित रिकॉन्सिलिएशन चेक्स

छोटे सैंपल (एक ग्राहक, एक महीना) और फिर पूरे डेटा पर ये चेक चलाएँ:

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

कुछ और कदम ताकि उपयोगी सिस्टम शिप हो सके

एक बार आपका स्कीमा ठोस हो जाए, उसके चारों ओर ऑपरेशनल वर्कफ़्लो बनाएं:

• एडमिन स्क्रीन जिससे इनवॉइस, भुगतान, क्रेडिट और समायोजन बनाना, पोस्ट करना और रिवर्स करना संभव हो, साथ में जरूरी नोट्स
• एक रीकॉन्सिलिएशन व्यू जो दस्तावेज़ और आवंटनों को साथ में दिखाए, कौन पोस्ट किया और कब
• फाइनेंस जो एक्सपोर्ट चाहिए (posting date के अनुसार, ग्राहक के अनुसार, GL मैपिंग के अनुसार अगर हो) के अनुसार एक्सपोर्ट्स
• एक पीरियड क्लोज़ वर्कफ़्लो: क्लोज़ महीनों के लिए पोस्टिंग तिथियों को लॉक करें, और देर से फिक्स के लिए रिवर्सल एंट्रीज़ की आवश्यकता रखें
• टेस्ट सीनारियोज़ (रिफंड, आंशिक भुगतान, राइट-ऑफ) जो अपेक्षित कुलों से मेल खाते हों

यदि आप एक तेज़ रास्ता चाहते हैं जो एक काम करने योग्य इन-हाउस फाइनेंस पोर्टल दे, तो AppMaster (appmaster.io) आपकी मदद कर सकता है: PostgreSQL स्कीमा मॉडल करें, APIs जनरेट करें, और एडमिन स्क्रीन एक ही स्रोत से बनाएँ—ताकि पोस्टिंग और आवंटन नियम ऐप के विकास के साथ समान बने रहें।