सब्सक्रिप्शन एक्सपोर्ट को MRR और ARR रिपोर्ट में कैसे बदलें (2026 गाइड)

एक subscription export आपको ये पंक्तियाँ देता है: customer, plan, amount, interval, status, start date। एक MRR रिपोर्ट को हर महीने केवल एक संख्या की आवश्यकता होती है। एक से दूसरे तक पहुँचने का काम अंकगणित जैसा लगता है और यह मुख्य रूप से परिभाषाओं का खेल है।

तैयार रिपोर्ट में हर आंकड़े को दो विकल्प तय करते हैं। कौन से subscriptions को active माना जाए, और क्या छूट (discounts) को amount में से घटाया जाए।

इनमें से किसी भी एक को गलत चुनने पर भी रिपोर्ट आंतरिक रूप से संतुलित रहेगी। बस यह फाइनेंस विभाग, billing dashboard और पिछले महीने के वर्जन से मेल नहीं खाएगी।

यह गाइड बताती है कि आपको सबसे पहले क्या तय करना चाहिए, इसके तीन मैन्युअल तरीके कौन से हैं, और प्रत्येक तरीका कहाँ काम करना बंद कर देता है।

शुरू करने से पहले आपको क्या चाहिए

आपको प्रति subscription एक पंक्ति (row) वाला export चाहिए, न कि प्रति invoice एक पंक्ति वाला। Invoices आपको बताते हैं कि क्या बिल किया गया था। Subscriptions आपको बताते हैं कि क्या आवर्ती (recur) है।

आपको हर पंक्ति में billing interval की आवश्यकता होगी। मासिक (monthly) और वार्षिक (annual) प्लान्स को तब तक नहीं जोड़ा जा सकता जब तक कि वार्षिक प्लान्स को सामान्य (normalise) न कर दिया जाए।

आपको status कॉलम की भी आवश्यकता होगी। Stripe का billing analytics दस्तावेज़ MRR को मासिक-सामान्यीकृत (monthly-normalised) राशियों के योग के रूप में परिभाषित करता है। यह केवल active और past_due status वाले subscriptions को ही गिनता है।

इस परिभाषा को वैसे ही अपनाना बेहतर है। यह प्रकाशित है, विशिष्ट है, और जब कोई पूछता है कि कोई संख्या क्यों बदल गई, तो यह आपको एक तर्कसंगत उत्तर देती है।

तीन निर्णय सबसे पहले लेने होते हैं।

कौन से statuses गिने जाते हैं। Active और past due दस्तावेज़ों में दिया गया डिफ़ॉल्ट विकल्प है। Canceled और unpaid को churn माना जाता है और वे बाहर हो जाते हैं।

क्या छूट (discounts) घटाई जाती हैं। Stripe इसे कॉन्फ़िगर करने योग्य बनाता है, जिसमें आवर्ती (recurring) और एक बार मिलने वाली (one-time) छूट के लिए अलग-अलग सेटिंग्स होती हैं। हमेशा के लिए मिलने वाली (Forever) छूट हमेशा काटी जाती है।

एक सब्सक्राइबर की गिनती कब से शुरू होती है। Stripe आपको पहली बिलिंग अवधि की शुरुआत या पहला भुगतान प्राप्त होने में से चुनने की अनुमति देता है। पहला विकल्प सबसे आम माना जाता है।

कोई भी फ़ॉर्मूला लिखने से पहले इन तीनों को शीट पर लिख लें। ये एक रिपोर्ट और एक बहस के बीच का अंतर तय करते हैं।

अंकगणित आसान हिस्सा क्यों है

सामान्यीकरण (Normalising) सरल है। Stripe का अपना उदाहरण $100 के मासिक प्लान पर 100 सब्सक्राइबर्स और $600 के वार्षिक प्लान पर 50 सब्सक्राइबर्स का उपयोग करता है। इससे (100 × 100) + (50 × (600 / 12)) = 12,500 मिलता है।

जटिलताएँ बहिष्करणों (exclusions) में हैं, और स्प्रेडशीट में इन्हें भूल जाना आसान है।

टैक्स बाहर हैं। Stripe टैक्स को MRR से बाहर रखता है। यदि आपके export में gross amounts शामिल हैं, तो आप हर महीने आंकड़े बढ़ा-चढ़ाकर दिखा रहे हैं।

ट्रायल बाहर हैं। ट्रायल अवधि वाले subscriptions को तब तक बाहर रखा जाता है जब तक कि वे कनवर्ट नहीं हो जाते।

फ्री प्लान्स बाहर हैं। शून्य-कीमत वाले प्लान पर मौजूद सब्सक्राइबर कुछ भी योगदान नहीं देता है, इसलिए उन्हें active सब्सक्राइबर के रूप में भी नहीं गिना जाता है।

उपयोग-आधारित (Usage-based) रेवेन्यू बाहर है। यह वह बात है जो लोगों को हैरान करती है। Metered प्रोडक्ट्स को MRR से पूरी तरह बाहर रखा गया है, इसलिए आंशिक रूप से उपयोग-आधारित बिलिंग वाले व्यवसाय का MRR स्वाभाविक रूप से वास्तविक रेवेन्यू से कम दिखाई देगा।

इसके बाद कूपन का मामला आता है, जो प्रलेखित (documented) है और वास्तव में अप्रत्याशित है। यदि किसी सब्सक्राइबर का MRR शून्य हो जाता है, तो उस सब्सक्राइबर को उस अवधि के लिए churned माना जाता है।

एक 100% छूट वाला कूपन ठीक यही करता है। बाद में कूपन हटा दें और सब्सक्राइबर फिर से active हो जाता है, जो reactivation के रूप में दिखाई देता है।

सो एक प्रमोशन बिना किसी ग्राहक के छोड़े भी आपकी रिपोर्ट में churn पैदा कर सकता है।

इसे मैन्युअल रूप से कैसे करें

विकल्प 1: interval को सामान्य (normalise) करें, फिर महीने के अनुसार योग करें

एक मासिक राशि (monthly amount) कॉलम जोड़ें। वार्षिक राशियों को बारह से विभाजित करें, साप्ताहिक को लगभग 4.33 से गुणा करें, और मासिक को वैसे ही छोड़ दें।

फिर status पर फ़िल्टर लगाकर SUMIFS के साथ महीने के अनुसार कुल योग निकालें। उन महीने के अंत की तारीखों को बनाने के लिए EOMONTH का उपयोग करें जिनकी आप रिपोर्ट कर रहे हैं।

MRR की रिपोर्ट महीने के अंत की तारीख के अनुसार करें, न कि आज की तारीख के अनुसार। Stripe की डाउनलोड करने योग्य रिपोर्ट स्पष्ट रूप से महीने के अंत में प्रत्येक सब्सक्राइबर का MRR होती है, और उस परंपरा का पालन करने से बाद में मिलान (reconciliation) करने में आसानी होती है।

यहाँ सबसे बड़ी सीमा इतिहास (history) की है। यह आपको चालू महीने का स्पष्ट आंकड़ा तो देता है, लेकिन यह नहीं बताता कि इसमें बदलाव क्यों हुआ।

विकल्प 2: movement कॉलम बनाएं

यही चीज़ रिपोर्ट को उपयोगी बनाती है। बदलाव को new, reactivation, expansion, contraction और churn में विभाजित करें।

Stripe की विकास (growth) परिभाषा शुरुआती आंकड़ा प्लस new, reactivation और expansion, माइनस contraction और churn है, जिसे बाद में विनिमय दरों (exchange rates) के लिए समायोजित किया जाता है। इसका व्यावहारिक उदाहरण ठीक इन्हीं घटकों के माध्यम से $1,000 को $1,045 में बदलता है।

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

बहु-मुद्रा (Multi-currency) का एक दूसरा परिणाम भी जानने योग्य है। Stripe का कहना है कि जब subscription रेवेन्यू को कई मुद्राओं में संभाला जाता है, तो प्रोडक्ट या कीमत के आधार पर फ़िल्टर करना और ग्रुप बनाना अनुपलब्ध होता है।

इस तरीके की सीमा इसका रखरखाव (maintenance) है। Movement कॉलम के लिए पिछली अवधि के स्नैपशॉट की आवश्यकता होती है, इसलिए आप हमेशा के लिए पिछले महीने की एक दूसरी कॉपी रख रहे होते हैं।

विकल्प 3: इसके बजाय बिलिंग सिस्टम से movements लें

अधिकांश बिलिंग प्लेटफ़ॉर्म आपके लिए movements को export कर देंगे। Stripe तीन CSVs प्रकाशित करता है: प्रति माह प्रति सब्सक्राइबर MRR, एक subscription metrics summary, और प्रत्येक ग्राहक के MRR movement का लॉग।

वह तीसरी फ़ाइल ही है जिसे माँगा जाना चाहिए। यह विकल्प 2 के सबसे कठिन हिस्से को हटा देती है।

यदि आप किसी मीट्रिक परिभाषा को बदलते हैं, तो देरी की उम्मीद रखें। Stripe का कहना है कि कॉन्फ़िगरेशन परिवर्तनों को दिखने में 24 से 48 घंटे लगते हैं।

साझा सीमा। तीनों रास्ते MRR पर आकर रुक जाते हैं। इसे ARR, ARPU, churn और retention में बदलने का मतलब है उसी तालिका के ऊपर निर्णयों की एक और परत जोड़ना।

मैन्युअल तरीका कहाँ धीमा हो जाता है

पहले महीने में एक दोपहर का समय लगता है। चौथे महीने में अधिक समय लगता है, और इसलिए नहीं कि डेटा कठिन हो गया है।

तब तक वर्कबुक में active की दो परिभाषाएँ, एक हाथ से सुधारा गया exchange कॉलम, और एक ऐसा movement टैब होता है जिसे कोई छूना नहीं चाहता।

व्युत्पन्न मीट्रिक (Derived metrics) समस्या को बढ़ा देते हैं। ARPU कुल MRR को active सब्सक्राइबर्स से विभाजित करने पर मिलता है। Lifetime value (LTV) ARPU को churn rate से विभाजित करने पर मिलती है।

Churn का अपना एक जाल है। Stripe का हर (denominator) तीस दिन पहले सक्रिय सब्सक्राइबर्स प्लस उस अवधि में जोड़े गए नए सब्सक्राइबर्स हैं, जिससे 100 / (1000 + 100) = 9.1% मिलता है। एक स्प्रेडशीट जो केवल शुरुआती संख्या (opening count) से विभाजित करती है, वह अधिक संख्या रिपोर्ट करती है।

Retention भी अप्रत्याशित रूप से व्यवहार करता है। Revenue retention 100% से अधिक हो सकता है, क्योंकि एक समूह (cohort) के भीतर expansion, churn से अधिक हो जाता है।

इसमें से कुछ भी कठिन नहीं है। यह केवल पांच ऐसे निर्णय हैं जिन्हें हर महीने समान रूप से लिया जाना चाहिए, चाहे रिपोर्ट कोई भी बना रहा हो।

Powerdrill Bloom के साथ रिपोर्ट कैसे बनाएं

चरण 1: अपना subscription export अपलोड करें

subscription CSV, या subscription और movement फ़ाइलों को एक साथ अपलोड करें। Powerdrill Bloom आने पर कॉलमों का विश्लेषण (profile) करता है, जिससे कोई भी कुल योग निकालने से पहले छूटे हुए intervals, खाली amounts और डुप्लिकेट subscription IDs सामने आ जाते हैं।

चरण 2: प्राकृतिक भाषा (natural language) में परिभाषाएँ बताएं

नियमों को बनाने के बजाय उनका वर्णन करें। बताएं कि कौन से statuses गिने जाते हैं, क्या amounts छूट के बाद की (net of discounts) हैं, और आप किस महीने के अंत की रिपोर्ट कर रहे हैं।

फिर उसी समय जांच के लिए कहें। पूछें कि किन पंक्तियों में ऐसा interval है जिसकी आपको उम्मीद नहीं थी, और छूट के बाद कौन से subscriptions शून्य पर हैं। फिर पूछें कि क्या मासिक योग billing summary से मेल खाते हैं।

चरण 3: चार्ट, रिपोर्ट या डेक एक्सपोर्ट करें

मासिक ट्रेंड, घटक (component) के अनुसार एक movement तालिका, या आंकड़ों और परिभाषाओं के साथ बोर्ड-रेडी स्लाइड प्राप्त करें।

यह हर महीने इसे फिर से बनाने से बेहतर क्यों है

	मैन्युअल तरीका	Powerdrill Bloom
वार्षिक प्लान्स को सामान्य (normalise) करना	प्रति फ़ाइल फ़ॉर्मूला कॉलम	अपलोड करें और नियम बताएं
Movement का विवरण (breakdown)	बनाए रखने के लिए पिछले महीने का स्नैपशॉट	घटकों (components) के लिए पूछें
ट्रायल और metered लाइनों को बाहर रखना	प्रत्येक चक्र में मैन्युअल फ़िल्टर	बहिष्करण (exclusions) बताएं
Billing summary से मिलान करना	मैन्युअल जांच	पूछें कि क्या कुल योग मेल खाते हैं

बीच की पंक्तियों में ही दिन बीत जाते हैं। किसी कॉलम का योग करना काम नहीं है; महीनों तक पांच परिभाषाओं को स्थिर रखना असली काम है।

आम गलतियाँ

subscriptions के बजाय invoices का योग करना। Invoices में एक बार के शुल्क (one-off charges) और यथानुपात (prorations) शामिल होते हैं। आवर्ती रेवेन्यू (Recurring revenue) subscription की एक विशेषता है, बिल की नहीं।

amount में टैक्स छोड़ देना। टैक्स हर महीने आंकड़े बढ़ाता है और कभी भी शुद्ध (net) नहीं होता है। सामान्य करने से पहले इसे हटा दें।

ट्रायल को रेवेन्यू के रूप में गिनना। ट्रायल में अभी तक कोई आवर्ती राशि (recurring amount) नहीं होती है। इसे शामिल करने का मतलब अगले महीने की ग्रोथ को पहले ही उधार लेना है।

बिना बताए ARR को MRR का बारह गुना मानना। यह एक सामान्यीकृत वार्षिक आंकड़ा (normalised annual figure) है, न कि एकत्र किया गया कैश। इसे इस तरह लेबल करें कि कोई इसे bookings न समझे।

कूपन-टू-churn प्रभाव को अनदेखा करना। पूरी छूट मिलने पर सब्सक्राइबर शून्य पर आ जाता है, जिसे churn माना जाता है। बाद में स्पष्टीकरण देने के बजाय उन पंक्तियों को फ़्लैग करें।

churn को शुरुआती संख्या (opening count) से विभाजित करना। प्रलेखित हर (denominator) में उस अवधि के दौरान जोड़े गए सब्सक्राइबर्स शामिल होते हैं। दोनों संस्करण समान डेटा पर अलग-अलग दरें उत्पन्न करते हैं।

हर महीने नए सिरे से निर्माण करना। परिभाषाएँ नहीं बदलतीं; केवल export बदलता है। नियमों को वही रखें और फ़ाइल को बदलें, ठीक वैसे ही जैसे एक budget versus actual report में किया जाता है।

निष्कर्ष

status सूची को ठीक करें, छूट पर निर्णय लें, interval को सामान्य करें, और महीने के अंत के अनुसार रिपोर्ट करें। ये चार चीजें एक ऐसी MRR रिपोर्ट तैयार करती हैं जो फाइनेंस विभाग के किसी भी सवाल का सामना कर सकती है।

महंगा हिस्सा योग (sum) नहीं है। यह है कि जब export का आकार बदलता है, तब भी हर महीने पांच परिभाषाओं को स्थिर रहना पड़ता है।

यदि आपका महीना इसी काम में समाप्त होता है, तो अपने subscription export पर Powerdrill Bloom आज़माएं। अपने स्वयं के डेटा से KPI लक्ष्य निर्धारित करने के लिए हमारी गाइड भी देखें। SaaS metrics ट्रैकिंग के लिए AI टूल्स का संग्रह और AI वित्तीय विश्लेषण (financial analysis) पेज इसके टूलिंग पक्ष को कवर करते हैं।

अक्सर पूछे जाने वाले प्रश्न

एक subscription export से MRR निकालने का फ़ॉर्मूला क्या है?

प्रत्येक subscription को मासिक राशि में सामान्य (normalise) करें, फिर योग्य status वाले subscriptions का योग करें। Stripe का उदाहरण है (100 × $100) + (50 × ($600 / 12)) = $12,500।

मैं MRR को ARR में कैसे बदलूँ?

मासिक आंकड़े को बारह से गुणा करें। इसे एकत्र किए गए कैश के बजाय एक सामान्यीकृत वार्षिक रन रेट (normalised annual run rate) के रूप में लेबल करें, क्योंकि वार्षिक प्लान्स का बिल पहले ही ले लिया जाता है।

क्या उपयोग-आधारित (usage-based) रेवेन्यू को शामिल किया जाना चाहिए?

Stripe metered प्रोडक्ट्स को MRR से बाहर रखता है। यदि आपके रेवेन्यू का एक महत्वपूर्ण हिस्सा उपयोग-आधारित है, तो इसे शामिल करने के बजाय एक अलग लाइन के रूप में रिपोर्ट करें।

कौन से subscription statuses को active माना जाता है?

दस्तावेज़ों में दिया गया डिफ़ॉल्ट विकल्प active और past_due है। Canceled और unpaid subscriptions को churn माना जाता है और वे कुल योग से बाहर हो जाते हैं।

मेरी churn दर billing dashboard से भिन्न क्यों है?

अक्सर ऐसा हर (denominator) के कारण होता है। प्रलेखित गणना तीस दिन पहले सक्रिय सब्सक्राइबर्स प्लस उस अवधि के दौरान जोड़े गए नए सब्सक्राइबर्स से विभाजित करती है।