SaaS ব্যবসায় Recurring Revenue কেন গুরুত্বপূর্ণ

একটি সফটওয়্যার ব্যবসা ভালো বিক্রি করেও সমস্যায় পড়তে পারে। এ মাসে কয়েকটি বড় চুক্তি হলো, আয়ও ভালো। কিন্তু পরের মাসে নতুন বিক্রি না এলে কী হবে? কর্মীদের বেতন, সার্ভার, সাপোর্ট, পণ্য উন্নয়ন—খরচগুলো তো থেমে থাকবে না।

এককালীন সফটওয়্যার বিক্রির দুর্বল জায়গা এখানেই। প্রতিবার আয় করতে নতুন বিক্রি দরকার। SaaS ব্যবসায় recurring revenue এই চাপ কিছুটা কমায়, কারণ সক্রিয় গ্রাহকের সাবস্ক্রিপশন থেকে পরের মাসেও আয় আসার একটি ভিত্তি থাকে।

তবে subscription model-কে লাভের শর্টকাট ভাবলে ভুল হবে। গ্রাহক কয়েক মাসের মধ্যে চলে গেলে, ছোট প্ল্যানে নেমে গেলে কিংবা পণ্যটির নিয়মিত প্রয়োজন না থাকলে সুন্দর দেখতে Monthly ও Annual pricing page খুব বেশি কাজে আসে না। Recurring revenue SaaS ব্যবসায় তখনই অর্থবহ, যখন গ্রাহক নিয়মিত এমন কিছু পাচ্ছেন, যার জন্য তাঁরা নিয়মিত অর্থ দিতেও রাজি।

Recurring revenue-কে শুধু “মাসিক পেমেন্ট” ভাবলে ভুল হবে

ধরা যাক, একটি কোম্পানি হিসাবরক্ষণ সফটওয়্যারের লাইসেন্স ২০,০০০ টাকায় বিক্রি করল। ওই বিক্রি থেকে ২০,০০০ টাকা এসেছে। কিন্তু একই গ্রাহক পরের মাসে আবার টাকা দেবেন—এমন কিছু ওই লেনদেনে নেই। এবার একই সফটওয়্যার মাসে ১,৫০০ টাকার সাবস্ক্রিপশনে দেওয়া হলো। গ্রাহক যত দিন সাবস্ক্রিপশন চালিয়ে যাবেন, তত দিন সেই গ্রাহক recurring revenue-এর অংশ হয়ে থাকবেন।

পার্থক্যটি শুধু “২০,০০০ টাকা একবার” বনাম “১,৫০০ টাকা প্রতি মাসে” নয়। এককালীন বিক্রিতে ব্যবসাকে পরবর্তী revenue-এর জন্য আবার বিক্রি করতে হয়। Subscription business-এ পুরোনো গ্রাহকদের একটি অংশ পরের মাসের revenue base তৈরি করে দেন। এরপর নতুন গ্রাহক, upgrade বা বাড়তি ব্যবহার সেই base-এর সঙ্গে যোগ হতে পারে।

আবার উল্টো ঘটনাও ঘটে। কেউ subscription বাতিল করেন, কেউ কম দামের plan নেন, কারও payment collection সমস্যায় পড়ে। তাই recurring revenue ভবিষ্যতের নিশ্চিত নগদ অর্থ নয়। এই জায়গাটি SaaS-এর financial dashboard বুঝতে বিশেষ গুরুত্বপূর্ণ। একটি subscription payment ব্যর্থ হলেই সব ক্ষেত্রে সঙ্গে সঙ্গে MRR শূন্য হয়ে যায় না। উদাহরণ হিসেবে Stripe-এ past_due subscription নির্দিষ্ট অবস্থায় MRR-এর মধ্যে থাকতে পারে; canceled বা unpaid subscription আর থাকে না।

অর্থাৎ dashboard-এর সংখ্যা দেখার আগে সেই platform সংখ্যাটি কীভাবে হিসাব করছে, তা জানা দরকার।

আরও পড়ুন: SaaS কীভাবে আয় করে: Subscription Business Model-এর সহজ ব্যাখ্যা

কেন এই মডেলে পরিকল্পনা কিছুটা সহজ হয়

৮০ জন গ্রাহক একটি সফটওয়্যারের জন্য প্রতি মাসে ১,৫০০ টাকা করে দিচ্ছেন।

হিসাবটি সহজ:

৮০ × ১,৫০০ = ১,২০,০০০ টাকা

যদি পরের মাসেও একই গ্রাহকরা একই plan-এ থাকেন, তাহলে ব্যবসাটির ১,২০,০০০ টাকার recurring revenue base রয়েছে। এটি কোনো revenue guarantee নয়। কিন্তু একজন প্রতিষ্ঠাতার জন্য পার্থক্যটি বড়। নতুন মাস শুরু হওয়ার সময় পুরো revenue target শূন্য থেকে তৈরি করতে হচ্ছে না।

এই base দেখে অন্তত কিছু প্রশ্নের উত্তর দেওয়া সহজ হয়। বর্তমান subscription revenue দিয়ে hosting ও support cost-এর কতটা সামলানো যাচ্ছে? নতুন কর্মী নেওয়ার আগে কতটা recurring income আছে? Marketing spend বাড়ালে কয়েক মাস টিকে থাকার মতো cash আছে কি? তবে এখানে একটি সাধারণ ভুল এড়াতে হবে।

MRR মানেই ব্যাংকে থাকা টাকা নয়।

একজন গ্রাহক পুরো বছরের subscription fee আগেই দিতে পারেন। আবার invoice তৈরি হলেও টাকা তখনো পাওয়া নাও যেতে পারে। Accounting revenue recognition-ও আলাদা নিয়মে হতে পারে। এই কারণেই MRR-কে business metric হিসেবে দেখা উচিত, accounting revenue বা cash balance হিসেবে নয়।

MRR আসলে কোন সংখ্যাটি দেখায়?

MRR অর্থ Monthly Recurring Revenue। সহজ ভাষায়, সক্রিয় subscription-গুলোর recurring value-কে মাসিক হিসাবে স্বাভাবিক করে যে অঙ্ক পাওয়া যায়, সেটিই MRR।

একজন গ্রাহক বছরে ১২,০০০ টাকা দিচ্ছেন।

তাঁর subscription-এর মাসিক value:

১২,০০০ ÷ ১২ = ১,০০০ টাকা

অর্থাৎ MRR-এ ওই subscription-এর অবদান ১,০০০ টাকা। এখানে হিসাব সহজ মনে হলেও বাস্তব billing data-তে জটিলতা আসে। Trial, coupon, tax, setup fee, usage charge কিংবা credit adjustment কীভাবে গণনা হবে, তা platform অনুযায়ী এক নাও হতে পারে।

Stripe তার MRR calculation-এ trial, free plan, tax ও metered product বাদ রাখে। Chargebee-তে আবার configuration অনুযায়ী কিছু component-এর treatment বদলানো যায়। তাই একটি ছোট SaaS কোম্পানির জন্যও নিজের MRR policy লিখে রাখা কাজে দেয়। কোন revenue recurring, কোনটি one-time এবং কোন adjustment MRR-এ যাবে—দলের সবাই যেন একই সংজ্ঞা ব্যবহার করেন। তা না হলে marketing dashboard-এ একটি MRR, finance spreadsheet-এ আরেকটি MRR এবং founder update-এ তৃতীয় সংখ্যা দেখা অস্বাভাবিক নয়।

ARR নিয়ে একটু সাবধান হওয়া দরকার

ARR বলতে SaaS জগতে সাধারণত Annual Recurring Revenue বোঝানো হয়। আবার কিছু analytics platform একই সংক্ষিপ্ত রূপকে Annual Run Rate বা Annualized Run Rate অর্থেও ব্যবহার করে। তাই ARR নিয়ে আলোচনা করার সময় প্রতিষ্ঠানের সংজ্ঞা পরিষ্কার থাকা ভালো।

ChartMogul-এর Annual Run Rate হিসাবের পদ্ধতিতে:

ARR = MRR × ১২

MRR যদি ১,২০,০০০ টাকা হয়, তাহলে annualized ARR দাঁড়ায়:

১৪,৪০,০০০ টাকা

কাগজে সংখ্যাটি সুন্দর দেখালেও এটিকে আগামী ১২ মাসের নিশ্চিত আয় ভাবা যাবে না। আজ যে ৮০ জন গ্রাহক আছেন, তাঁদের কেউ চলে যেতে পারেন। কেউ upgrade করতে পারেন। নতুন গ্রাহক আসতে পারেন। Pricing-ও বদলাতে পারে। ARR মূলত বর্তমান recurring business-এর আকারকে বার্ষিক দৃষ্টিতে দেখার একটি উপায়।

মাস শেষে MRR বেড়েছে—তবু সমস্যা থাকতে পারে

SaaS dashboard-এর সবচেয়ে বিভ্রান্তিকর দৃশ্যগুলোর একটি হলো: revenue বাড়ছে, কিন্তু ব্যবসার ভেতরের একটি সমস্যা একই সঙ্গে বড় হচ্ছে। মাসের শুরুতে MRR ছিল ৫ লাখ টাকা। মাস শেষে হয়েছে ৫ লাখ ২০ হাজার। দেখে মনে হচ্ছে, সব ঠিক পথে আছে।

এবার ভেতরের হিসাব দেখা যাক:

• নতুন গ্রাহকের MRR এসেছে ৭০ হাজার টাকা
• পুরোনো গ্রাহকের upgrade থেকে এসেছে ২০ হাজার
• downgrade-এ কমেছে ১০ হাজার
• subscription বাতিল হওয়ায় কমেছে ৬০ হাজার

শেষ পর্যন্ত বৃদ্ধি ২০ হাজার টাকা। কিন্তু এই ব্যবসাটি এক মাসেই পুরোনো subscription থেকে ৬০ হাজার টাকার MRR হারিয়েছে। নতুন sales সেই ক্ষতি ঢেকে দিয়েছে বলে সমস্যাটি মোট সংখ্যায় ধরা পড়ছে না।

এ কারণেই শুধু total MRR দেখলে SaaS-এর স্বাস্থ্য বোঝা যায় না। New MRR বলে নতুন subscription কত revenue আনছে। Expansion MRR দেখায় বর্তমান গ্রাহক থেকে বাড়তি revenue। Contraction MRR-এ downgrade-এর ক্ষতি দেখা যায়। Churn MRR দেখায় পুরোপুরি হারিয়ে যাওয়া recurring revenue। এই সংখ্যাগুলো পাশাপাশি রাখলেই revenue growth-এর মান সম্পর্কে পরিষ্কার ধারণা পাওয়া যায়।

গ্রাহক থাকা আর revenue ধরে রাখা এক বিষয় নয়

একজন customer পুরোপুরি subscription বাতিল করলেন—এটি churn। কিন্তু আরেকজন ১০,০০০ টাকার plan থেকে ৬,০০০ টাকার plan-এ চলে গেলেন। তিনি এখনো customer, অথচ ব্যবসা প্রতি মাসে ৪,০০০ টাকা কম পাচ্ছে। এই দ্বিতীয় ঘটনাটি customer count-এ ধরা পড়বে না। Revenue analysis-এ ধরা পড়বে contraction হিসেবে।

সুতরাং “আমাদের customer churn কম”—এই একটি সংখ্যা দিয়ে retention ভালো প্রমাণ করা যায় না। গ্রাহক থেকে কত recurring revenue ধরে রাখা যাচ্ছে, সেটিও দেখতে হয়।

এখানেই revenue retention-এর মূল্য।

কেন একজন গ্রাহক plan ছোট করছেন, কেন আরেকজন renew করছেন না, কোন feature ব্যবহার বন্ধ হয়ে যাচ্ছে—এসব প্রশ্ন product team-এরও। Subscription business-এ retention শুধু finance team-এর metric নয়।

নতুন গ্রাহক ছাড়াও SaaS বাড়তে পারে

SaaS growth নিয়ে আলোচনা প্রায়ই customer acquisition ঘিরে হয়। আরও traffic, আরও lead, আরও signup। কিন্তু বিদ্যমান গ্রাহকের মধ্যেও growth থাকতে পারে। একটি কোম্পানি শুরুতে ৫টি user seat কিনল। কয়েক মাস পর তাদের দল বড় হলো এবং ১৫টি seat নিল। অথবা basic plan আর প্রয়োজন মেটাচ্ছে না বলে higher plan-এ গেল।

এই বাড়তি recurring revenue Expansion MRR হিসেবে দেখা যায়। এটি একটি গুরুত্বপূর্ণ পার্থক্য। ব্যবসা বাড়ানোর জন্য প্রতিটি বাড়তি টাকা নতুন customer থেকেই আনতে হবে—এমন নয়।

তবে এখানেও পণ্যের বাস্তবতা দেখতে হবে। Upgrade অর্থবহ তখনই, যখন বেশি মূল্য দেওয়ার বিপরীতে গ্রাহক বাড়তি সুবিধা পাচ্ছেন। কৃত্রিমভাবে প্রয়োজনীয় feature আটকে রেখে সবাইকে higher plan-এ ঠেলে দেওয়াকে শক্তিশালী retention strategy ধরে নেওয়ার কারণ নেই।

Investor শুধু ARR দেখবেন না

একটি SaaS কোম্পানির ARR দ্রুত বাড়ছে—এটি অবশ্যই গুরুত্বপূর্ণ তথ্য। কিন্তু ভালো বিনিয়োগের সিদ্ধান্ত নেওয়ার জন্য এটুকু যথেষ্ট নয়। একই ARR-এর দুইটি কোম্পানির আর্থিক অবস্থা সম্পূর্ণ আলাদা হতে পারে।

একটির customer acquisition cost খুব বেশি। অন্যটির churn বেশি। আবার কোনো কোম্পানির revenue কয়েকজন বড় customer-এর ওপর অতিরিক্ত নির্ভরশীল হতে পারে। এ কারণে recurring revenue-এর পাশাপাশি সাধারণত cash flow, gross margin, CAC, retention, churn এবং customer concentration-এর মতো বিষয়ও দেখা হয়।

Bessemer Venture Partners-এর cloud business metrics কাঠামোতেও recurring revenue-এর সঙ্গে CAC payback, CLTV, churn ও cash flow-এর মতো মেট্রিক রাখা হয়েছে। ARR ব্যবসাটি কত বড় হচ্ছে তার একটি ছবি দেয়। ছবির বাইরে ব্যবসাটি লাভজনক, দক্ষ বা ঝুঁকিমুক্ত কি না—সেটি আলাদাভাবে বিচার করতে হয়।

Subscription সবার জন্য ভালো model নয়

এখানেই recurring revenue নিয়ে সবচেয়ে প্রচলিত ভুল ধারণাটি আসে। Subscription model আকর্ষণীয় বলেই প্রতিটি software product-কে subscription বানাতে হবে—এমন নয়।

গ্রাহক যদি একটি software বছরে একবারও ব্যবহার না করেন, সেখানে প্রতি মাসে fee নেওয়ার যুক্তি দুর্বল হতে পারে। একইভাবে চলমান hosting, update, processing, support বা অন্য কোনো recurring value না থাকলে গ্রাহক কেন বারবার অর্থ দেবেন, সেই প্রশ্ন থাকবে।

Pricing ঠিক করার আগে তাই “মাসে কত নেব?” দিয়ে শুরু না করে আরেকটি প্রশ্ন করা ভালো:

গ্রাহক প্রতি মাসে আসলে কী পাচ্ছেন?

উত্তরটি পরিষ্কার হলে পরের প্রশ্নগুলো আসে। Pricing account অনুযায়ী হবে, seat অনুযায়ী, usage অনুযায়ী, নাকি fixed tier-এ? Monthly plan দরকার, নাকি annual commitment বেশি মানানসই? কোনো ক্ষেত্রে hybrid pricing কি বেশি স্বাভাবিক? Fixed monthly fee SaaS-এর একটি model, একমাত্র model নয়।

ছোট SaaS ব্যবসায় কোথা থেকে শুরু করা যায়

প্রথম দিনেই ছয়টি pricing tier, আটটি add-on এবং জটিল usage calculator বানানোর দরকার নেই। বরং recurring value কোথায়, সেটি আগে বোঝা দরকার।

গ্রাহক কেন product ব্যবহার চালিয়ে যাচ্ছেন—সেই কারণটি pricing-এর সঙ্গে মিলতে হবে। একটি team collaboration tool-এ user seat যৌক্তিক হতে পারে। অন্য ধরনের product-এ usage বেশি অর্থবহ হতে পারে। আবার কিছু service-এ monthly subscription-এর সঙ্গে one-time implementation fee রাখাই স্বাভাবিক।

Pricing যত জটিল হবে, নতুন ব্যবসার জন্য কোন অংশ কাজ করছে তা বোঝাও তত কঠিন হতে পারে। আর একটি বিষয় শুরুতেই ঠিক করা ভালো: MRR কীভাবে গণনা করা হবে। Trial, discount, tax, setup fee, metered usage—এসব নিয়ে পরে তর্ক করার চেয়ে শুরুতেই একটি সংজ্ঞা লিখে রাখা সহজ।

Churn-এর ক্ষেত্রেও শুধু “subscription canceled” লিখে থেমে গেলে তথ্যের অর্ধেক হারিয়ে যায়। সম্ভব হলে cancellation-এর কারণ আলাদা করে রাখা দরকার—দাম, পণ্যের ঘাটতি, ব্যবহার কমে যাওয়া, payment সমস্যা নাকি অন্য কিছু।

বাংলাদেশ থেকে SaaS চালালে billing আগে যাচাই করুন

Recurring revenue model কাগজে ঠিক করলেই billing infrastructure নিজে থেকে তৈরি হয়ে যায় না। Payment provider-এর availability, supported currency, recurring billing, tax tool এবং payment method দেশভেদে বদলায়। বাংলাদেশের কোনো SaaS যদি বিদেশি গ্রাহকের কাছ থেকে recurring payment নিতে চায়, pricing launch করার আগেই নির্বাচিত provider-এর বর্তমান documentation পরীক্ষা করা দরকার।

ভারত বা অন্য বাজারেও একই নিয়ম প্রযোজ্য—country support ধরে নেওয়া ঠিক নয়। এই অংশটি পরে দেখার বিষয় নয়। কারণ গ্রাহককে কোন currency-তে charge করা যাবে, recurring collection কীভাবে হবে কিংবা provider account আদৌ পাওয়া যাবে কি না—এসব pricing বাস্তবায়নেই প্রভাব ফেলে।

কখন hybrid model বেশি যুক্তিসঙ্গত

অনেক SaaS-এর revenue পুরোপুরি recurring হওয়ার প্রয়োজন নেই। ধরা যাক, enterprise customer-এর জন্য প্রথমে data migration, custom integration ও training করতে হচ্ছে। এগুলো একবারের কাজ। সেই খরচকে জোর করে মাসিক subscription-এর মধ্যে লুকিয়ে রাখার প্রয়োজন নেই।

একটি সহজ কাঠামো হতে পারে:

এককালীন setup fee + মাসিক software subscription

এতে implementation-এর মূল্য আলাদা থাকে এবং চলমান software service-এর recurring value-ও পরিষ্কার থাকে। তবে reporting-এর সময় setup fee-কে MRR-এ যোগ করা উচিত নয়। Chargebee-এর standard MRR calculation-এ setup fee recurring revenue-এর অংশ হিসেবে ধরা হয় না।

প্রতি মাসে কোন সংখ্যাগুলো দেখা দরকার

শুরুর পর্যায়ের SaaS-এ বিশাল dashboard বানানোর চেয়ে কয়েকটি metric ধারাবাহিকভাবে দেখা বেশি উপকারী।

MRR দেখাবে বর্তমান recurring base। New MRR জানাবে নতুন customer কত যোগ করছেন। Expansion MRR দেখাবে পুরোনো customer থেকে revenue কত বাড়ছে। Contraction ও Churn MRR বলবে কোথায় revenue বেরিয়ে যাচ্ছে।

এর সঙ্গে customer churn এবং revenue retention রাখলে ছবিটি আরও পরিষ্কার হয়। ARR বার্ষিক আকার বুঝতে সাহায্য করবে, তবে প্রতিষ্ঠানের ভেতরে ARR-এর সংজ্ঞা যেন এক থাকে। সংখ্যার তালিকা বড় করার চেয়ে একই metric প্রতি মাসে একই নিয়মে হিসাব করা বেশি গুরুত্বপূর্ণ।

Pricing বদলানোর আগে একটি জিনিস নিশ্চিত করুন

Recurring revenue SaaS ব্যবসাকে তুলনামূলকভাবে দৃশ্যমান একটি revenue base দিতে পারে। কিন্তু সেই সুবিধা subscription button থেকে আসে না; আসে চলমান customer value থেকে।

পণ্যটি যদি নিয়মিত সমস্যা সমাধান করে, গ্রাহক যদি ব্যবহার চালিয়ে যান এবং pricing সেই ব্যবহারের সঙ্গে মানানসই হয়, তখন subscription model যুক্তিসঙ্গত হতে পারে। আর পণ্যটি মূলত একবারের কাজের জন্য হলে, শুধু recurring revenue পাওয়ার আশায় monthly fee বসানো উল্টো retention সমস্যা তৈরি করতে পারে।

যে ব্যবসা এখন এককালীন software sale-এর ওপর নির্ভর করছে, তার জন্য সবচেয়ে বাস্তব পদক্ষেপ হলো এক রাতে পুরো pricing বদলে ফেলা নয়। আগে দেখা দরকার কোন service বা feature সত্যিই নিয়মিত value দিচ্ছে। তারপর সীমিতভাবে subscription বা hybrid model চালিয়ে MRR, churn ও expansion পর্যবেক্ষণ করা যায়। তখন বোঝা যাবে ব্যবসাটি সত্যিকারের recurring revenue তৈরি করছে, নাকি এককালীন মূল্যকে শুধু কয়েকটি মাসিক payment-এ ভাগ করেছে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Recurring revenue আর MRR কি একই বিষয়?

এক নয়। Recurring revenue হলো পুনরাবৃত্তভাবে আসা আয়ের সামগ্রিক ধারণা। MRR বা Monthly Recurring Revenue সেই recurring revenue-কে মাসিক ভিত্তিতে স্বাভাবিকীকরণ করে দেখায়। ফলে বার্ষিক subscription থেকেও মাসিক MRR হিসাব করা যায়।

বার্ষিক subscription নিলেও কি সেটি recurring revenue?

হ্যাঁ। Recurring revenue মানেই প্রতি মাসে payment নিতে হবে—এমন নয়। গ্রাহক বছরে একবার অর্থ দিলেও চুক্তিটি যদি নিয়মিত নবায়নযোগ্য subscription হয়, তাহলে সেটি recurring revenue model-এর অংশ হতে পারে। MRR হিসাবের সময় বার্ষিক subscription-এর মূল্য সাধারণত মাসিক মানে রূপান্তর করা হয়।

SaaS ব্যবসায় কত ঘন ঘন MRR ও churn দেখা উচিত?

শুরুর পর্যায়ের SaaS ব্যবসার জন্য মাসভিত্তিক MRR, New MRR, Expansion MRR, Contraction MRR এবং Churn MRR নিয়মিত দেখা একটি বাস্তবসম্মত পদ্ধতি। দ্রুত পরিবর্তনশীল ব্যবসায় dashboard আরও ঘন ঘন দেখা যেতে পারে, তবে trend বোঝার জন্য একই নিয়মে ধারাবাহিক হিসাব রাখা বেশি গুরুত্বপূর্ণ।

Payment ব্যর্থ হলে কি সঙ্গে সঙ্গে MRR কমে যায়?

সব ক্ষেত্রে নয়। এটি ব্যবহৃত billing platform এবং subscription status-এর ওপর নির্ভর করে। কোনো platform past_due subscription কিছু সময় MRR-এর মধ্যে রাখতে পারে, আবার canceled বা unpaid subscription বাদ দিতে পারে। তাই নিজের billing system-এর MRR calculation rule জানা জরুরি।

সব SaaS ব্যবসার কি subscription model ব্যবহার করা উচিত?

না। যেসব সফটওয়্যার নিয়মিত ব্যবহার করা হয় এবং hosting, update, support, processing বা অন্য কোনো চলমান সুবিধা দেয়, সেখানে subscription বেশি মানানসই হতে পারে। কিন্তু মূল value যদি একবারের কাজেই শেষ হয়ে যায়, তাহলে এককালীন payment বা hybrid model অনেক ক্ষেত্রে বেশি যৌক্তিক।

MRR বাড়লেই কি SaaS ব্যবসা ভালো অবস্থায় আছে?

অবশ্যই নয়। নতুন customer acquisition থেকে MRR বাড়লেও একই সময়ে পুরোনো গ্রাহকের churn বা downgrade বেড়ে যেতে পারে। তাই মোট MRR-এর পাশাপাশি retention, churn, expansion, gross margin, CAC এবং cash flow-ও দেখা দরকার।