एम्बेडेड अकाउंटिंग: मार्केटप्लेस के लिए खुद बनाएं (Build vs Buy) या खरीदें

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

Nordlet Team · 29 अगस्त 2026 · 10 मिनट पढ़ने में

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

यह लेख इसी फैसले को जानबूझकर और सही तरीके से लेने के बारे में है। इसमें चर्चा की गई है कि इस काम में असल में क्या शामिल है, खुद को धोखा दिए बिना इसका खर्च कैसे निकालें, और वे कौन सी खास स्थितियां हैं जिनमें इसे खुद बनाना ही सही जवाब होता है—क्योंकि कभी-कभी ऐसा करना वाकई जरूरी होता है।

यहां "एम्बेडेड अकाउंटिंग" (embedded accounting) का क्या मतलब है

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

मार्केटप्लेस के लिए इसमें कम से कम ये चीजें शामिल होती हैं: प्राप्त खरीदार भुगतान (buyer payments), विक्रेताओं को दी जाने वाली देय राशि, अर्जित कमीशन, पेमेंट प्रोसेसिंग शुल्क, आपके शुल्क और मूल सप्लाई पर लगने वाला वैट (VAT), रिफंड, चार्जबैक, रिजर्व, पेआउट, और इन सबका बैंक या पेमेंट प्रोवाइडर के साथ मिलान (reconciliation)।

अगर आप खुद बनाते हैं, तो आप असल में क्या बना रहे हैं

लेजर (ledger) खुद में बहुत छोटा हिस्सा है। टीमें अक्सर पहले आइटम का दायरा (scope) तय करती हैं और बाकी सब उन्हें बाद में पता चलता है।

घटक (Component)	इसमें क्या शामिल है
जर्नल और खाते (Journal and accounts)	संतुलित एंट्रियां, खातों का चार्ट (chart of accounts), खाते के प्रकार, शुरुआती बैलेंस
इम्यूटेबिलिटी (Immutability)	केवल डेटा जोड़ने वाला (append-only) स्टोरेज, उलटफेर और सुधार का वर्कफ़्लो, जगह पर सीधे बदलाव (in-place edits) की अनुमति नहीं
अवधि नियंत्रण (Period control)	क्लोजिंग, लॉकिंग, देर से आने वाली पोस्टिंग को अस्वीकार करना, ऑडिट रिकॉर्ड के साथ नियंत्रित रूप से दोबारा खोलना
आइडपोटेंसी (Idempotency)	कुंजियां, पिछली प्रतिक्रियाओं का स्टोरेज, बदले गए पेलोड पर टकराव का पता लगाना
मनी हैंडलिंग (Money handling)	सटीक दशमलव या छोटे यूनिट (minor-unit) का गणित, मुद्रा कोड (currency codes), FX दरें और उनके स्रोत, राउंडिंग खाते
वैट इंजन (VAT engine)	वैधता तिथियों के साथ प्रति-देश दरें, सप्लाई का स्थान, रिवर्स चार्ज, डीम्ड सप्लायर नियम, छूट
वैट पहचान जांच (VAT identification checks)	आधिकारिक रजिस्ट्री के खिलाफ वैलिडेशन, कैशिंग, टाइमस्टैम्प, अनुरोध पहचानकर्ता (request identifiers), विफलताओं के लिए एक मैनुअल समीक्षा कतार
दस्तावेज (Documents)	चालान (invoices), क्रेडिट नोट, श्रृंखला और वर्ष के अनुसार गैप-मुक्त नंबरिंग, पीडीएफ रेंडरिंग, डिलीवरी
ई-इनवॉइसिंग (E-invoicing)	संरचित प्रारूप जैसे EN 16931 UBL, और अधिदेशित होने पर प्रति-देश राष्ट्रीय प्रारूप
बैंक इंजेशन (Bank ingestion)	स्टेटमेंट इम्पोर्ट या सहमति प्राप्त बैंक कनेक्शन, पहले से इम्पोर्ट किए गए लेन-देन को हटाना (deduplication)
मिलान (Reconciliation)	मिलान नियम, स्कोरिंग, आंशिक मिलान, अपवाद जिन्हें कोई इंसान हल कर सके
पेआउट (Payouts)	भुगतान फ़ाइल जनरेशन, पेआउट बैचिंग, पेआउट का मूल आइटम के साथ मिलान
रिपोर्टिंग (Reporting)	ट्रायल बैलेंस, बैलेंस शीट, लाभ और हानि, नकदी प्रवाह (cash flow), वैट सारांश, पुरानी बकाया राशि (aged debt)
टैक्स रजिस्टर और रिटर्न (Tax registers and returns)	आपके देश जो भी मांगते हैं, उसी फॉर्मेट में जिसे अथॉरिटी स्वीकार करती है
ऑडिट (Audit)	अभिनेता (actor), कार्रवाई, एंटिटी, और खुद बदलाव, हर म्यूटेशन के लिए क्वेरी करने योग्य
रिटेंशन और एक्सपोर्ट (Retention and export)	OSS रिकॉर्ड के लिए दस साल का रिटेंशन, पूर्ण डेटा एक्सपोर्ट, बचाव योग्य आर्काइव

इन सत्रह पंक्तियों में से लगभग दो ही वे हिस्से हैं जिनकी कल्पना ज्यादातर टीमें तब करती हैं जब वे कहती हैं "हम एक लेजर बनाएंगे"।

लागत का ईमानदारी से आकलन करना

यहां कोई भी आंकड़ा आपकी टीम पर निर्भर करता है, इसलिए निम्नलिखित को किसी पक्के报价 (quote) के बजाय एक तरीके के रूप में देखें। ऊपर दिए गए घटकों को लें, अपनी टीम की गति के आधार पर प्रत्येक को इंजीनियर-सप्ताह में आकार दें, और फिर तीन ऐसे सुधार लागू करें जिन्हें अनुमान लगाते समय आमतौर पर छोड़ दिया जाता है।

पहला सुधार: अनुपालन घटक (compliance components) वन-टाइम नहीं होते हैं। दरें बदलती हैं, सीमाएं बदलती हैं, प्रारूप बदलते हैं, और यूरोपीय संघ का वैट इन द डिजिटल एज पैकेज अपने साथ निश्चित तारीख वाले दायित्व लाता है - 1 जनवरी 2027 से OSS और IOSS में बदलाव, 1 जुलाई 2028 से विस्तारित प्लेटफॉर्म नियम, 1 जुलाई 2030 से क्रॉस-बॉर्डर डिजिटल रिपोर्टिंग। खुद बनाने का मतलब है कि इन सभी माइग्रेशन की जिम्मेदारी आपकी है।

दूसरा सुधार: शुद्धता का काम (correctness work) फीचर के काम से ज्यादा लंबा चलता है। पहला वर्जन सुचारू रास्तों (happy path) को संभाल लेता है। लंबी पूंछ (long tail) वाली समस्याओं में पेआउट के बाद रिफंड, आंशिक रिफंड, हफ्तों बाद आने वाले चार्जबैक, मुद्रा राउंडिंग, डुप्लीकेट वेबहुक और ऐसे सेटलमेंट फाइलें शामिल हैं जो आपके रिकॉर्ड से मेल नहीं खाते। यहीं पर कैलेंडर गायब हो जाता है (यानी महीनों और वर्षों का समय निकल जाता है)।

तीसरा सुधार: अकाउंटेंट एक स्टेकहोल्डर है, न कि केवल एक समीक्षक (reviewer)। जो बही-खाते कोई फाइनेंस प्रोफेशनल साइन नहीं करेगा, वे पूरे नहीं हुए हैं, और यह फीडबैक किसी निर्माण कार्य के काफी अंत में मिलता है।

एक उपयोगी सैनिटी चेक: सबसे छोटे विश्वसनीय निर्माण का मूल्य तय करें - लेजर, सुधार, अवधि लॉकिंग, आइडपोटेंसी, मनी हैंडलिंग, एक देश का वैट, चालान, बैंक इम्पोर्ट, मिलान और बुनियादी रिपोर्ट सेट - और इसकी तुलना मीटर से चलने वाली सेवा (metered service) के एक साल के खर्च से करें। Nordlet की प्रकाशित योजनाएं प्रति माह €10 से शुरू होती हैं जिसमें 3,000 अनुरोध शामिल हैं और €300 प्रति माह तक जाती हैं जिसमें 200,000 अनुरोध शामिल हैं। यदि किसी चीज़ को खुद बनाने में एक अकेले इंजीनियर-वर्ष का एक छोटा सा हिस्सा खर्च होता है, तो यह उसे खुद बनाने के पक्ष में एक ठोस तर्क है। यदि इसमें कई इंजीनियर-वर्ष और स्थायी रखरखाव का खर्च आता है, तो दोनों की तुलना बनती ही नहीं है, और जैसे-जैसे नियम बदलते हैं, यह अंतर हर साल और बढ़ता जाता है।

जब खुद बनाना वाकई सही होता है

तीन मामले, और तीनों असली हैं।

आपका लेजर ही आपका प्रोडक्ट है। यदि आप एक पेमेंट प्लेटफॉर्म, एक बैंकिंग प्रोडक्ट, या एक ऐसा वॉलेट बना रहे हैं जहां समवर्तीता (concurrency) के तहत बैलेंस का व्यवहार ही आपका मुख्य अंतर (differentiator) है, तो लेजर मुख्य हिस्सा है और यह आपका अपना होना चाहिए। खरोंच से सब कुछ बनाने के बजाय लेजर इन्फ्रास्ट्रक्चर उत्पादों पर विचार करें, और वैधानिक लेखांकन (statutory accounting) को अलग रखें।

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

आपका वॉल्यूम मीटरेड प्राइसिंग को गलत साबित करता है। अत्यधिक लेन-देन दरों पर, प्रति-अनधिकृत अनुरोध (per-request) मूल्य निर्धारण आकर्षक नहीं रह जाता है। इसे मानने से पहले वास्तविक आंकड़ों के साथ इसका मॉडल तैयार करें, क्योंकि यहां "अत्यधिक" (extreme) उस स्तर से कहीं अधिक है जिस तक अधिकांश प्लेटफॉर्म पहुंच पाते हैं।

जब खरीदना सही होता है

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

खरीदना तब भी सही फैसला होता है जब आपके दायित्व कई देशों से जुड़े हों। प्रति-देश वैट नियम, साक्ष्य बनाए रखना (evidence retention), और ई-इनवॉइसिंग के नियम एक स्थायी रखरखाव का काम हैं, और एक विक्रेता उस काम की लागत को अपने हर ग्राहक के बीच बांट देता है (amortises)। Nordlet VIES वैलिडेशन, OSS और IOSS रिटर्न कंप्यूटेशन, i.SAF रजिस्टर और Peppol के लिए EN 16931 UBL के साथ प्रति-देश EU VAT को किसी प्रोजेक्ट के रूप में शेड्यूल करने के बजाय सीधे अपने प्रोडक्ट के हिस्से के रूप में प्रदान करता है।

वह बीच का रास्ता जिस पर ज्यादातर टीमें पहुंचती हैं

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

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

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

प्रतिबद्ध होने से पहले क्या तय करना चाहिए

क्या आपका लेजर कोई खास अंतर (differentiator) पैदा करता है या सिर्फ एक दायित्व है? ईमानदारी से सोचें; ज्यादातर चीजें सिर्फ दायित्व होती हैं।
कितने देश हैं, और हर देश की क्या मांग है? सिर्फ दरें, या रिटर्न, या रजिस्टर, या सबमिशन।
आपकी सुधार नीति (correction story) क्या है? पेआउट के बाद रिफंड और देर से आने वाले चार्जबैक वे मामले हैं जो एक कमजोर डिजाइन की पोल खोल देते हैं।
बही-खातों पर हस्ताक्षर कौन करता है? डिजाइन तय होने के बाद नहीं, बल्कि उससे पहले उस व्यक्ति को शामिल करें।
दस साल के रिटेंशन की क्या योजना है? लेन-देन के वर्ष के अंत से दस वर्षों तक OSS रिकॉर्ड सुरक्षित रखे जाने चाहिए, और आर्काइव कोई बैकअप नहीं बल्कि एक पूरा सिस्टम होता है।
तीन साल बाद माइग्रेशन कैसा दिखेगा? दोनों दिशाओं में। पहले दिन ही एक टेस्ट एक्सपोर्ट बनाएं और उसे काम करते रहें।

FAQ

मार्केटप्लेस लेजर बनाने में कितना समय लगता है?

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

क्या हम `balance` कॉलम से शुरुआत करके बाद में माइग्रेट कर सकते हैं?

आप कर सकते हैं, और कई लोग ऐसा करते भी हैं, लेकिन यह मानकर चलें कि माइग्रेशन का काम मूल निर्माण से भी कठिन होगा। बदलने योग्य (mutable) बैलेंस से इतिहास को दोबारा बनाना तभी संभव है जब आपने हर उस घटना को सहेजा हो जिसने इसे बदला है - जिसका मतलब है, केवल तभी जब आपके पास पहले से ही एक लेजर था।

क्या एम्बेडेड अकाउंटिंग API हमारी फाइनेंस टीम की जगह ले सकता है?

नहीं। यह मैनुअल रिकॉर्डिंग और मिलान को हटा देता है। फिर भी कोई न कोई महीने का हिसाब बंद करता है, अपवादों की समीक्षा करता है, महत्वपूर्ण निर्णय लेता है, और रिटर्न दाखिल करता है।

अगर लेजर इम्यूटेबल है, तो GDPR का क्या होगा?

मौद्रिक तथ्यों और छद्म नामों (pseudonymous references) को इम्यूटेबल रिकॉर्ड में रखें, और व्यक्तिगत विवरणों को उनके अपने रिटेंशन और डिलीशन प्रोसेस के साथ एक अलग सिस्टम में रखें। इम्यूटेबिलिटी वित्तीय घटना पर लागू होती है, न कि उससे जुड़े हर एट्रिब्यूट पर।

क्या ओपन-सोर्स अकाउंटिंग सॉफ्टवेयर एक बीच का विकल्प है?

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