Startup runway غلط نہ گنیں، revenue نہیں cash وصولی اصل فرق ہے
Startup runway کا بنیادی حساب یہ ہے: موجودہ قابلِ استعمال cash ÷ اوسط ماہانہ net burn = باقی runway کے مہینے۔ Gross burn تمام cash outflows ہے، جبکہ net burn نکالنے کے لیے ان outflows میں سے اسی مدت میں حقیقتاً وصول ہونے والا operating cash منہا کیا جاتا ہے۔
Invoice جاری ہونا، sale book ہونا یا customer کا ادائیگی کا وعدہ cash وصولی نہیں ہے۔ اس لیے historical runway کو P&L revenue سے نہیں بلکہ bank اور cash-flow data سے نکالیں؛ delayed receivables کو cash سمجھنے سے burn کم اور باقی مہینے حقیقت سے زیادہ نظر آئیں گے۔
Gross burn، net burn اور runway الگ رکھیں
Gross burn ایک ماہ میں نکلنے والی کاروباری cash کا مجموعہ ہے، مثلاً salaries، rent، marketing، cloud services، contractor payments، taxes اور equipment کی ادائیگیاں۔ Alehar کی cash-based تعریفیں gross burn کو کل ماہانہ cash outflow، net burn کو cash outflow منہا cash inflow، اور runway کو cash balance منقسم net burn قرار دیتی ہیں۔
Net burn = operating cash paid − operating cash collected۔ اگر ایک startup نے 30 لاکھ روپے ادا کیے اور customers سے 12 لاکھ وصول کیے تو gross burn 30 لاکھ اور net burn 18 لاکھ روپے ہے۔ Pre-revenue startup میں collection صفر ہو تو دونوں برابر ہوں گے؛ وصولیاں اخراج سے زیادہ ہوں تو net burn منفی ہوگا اور مستقل محدود runway دکھانے والی سادہ division موزوں نہیں رہے گی۔
Current cash میں صرف وہ رقم رکھیں جس پر کاروبار ابھی تصرف کرسکتا ہے۔ Undrawn loan، نامکمل funding commitment، overdue invoice اور restricted deposit اس balance کا حصہ نہیں۔ ITU پر موجود Lean Startup مواد بھی runway کو bank میں باقی cash منقسم ماہانہ net drain بیان کرتا ہے اور 10 لاکھ ڈالر cash کے مقابل ایک لاکھ ڈالر ماہانہ burn سے 10 ماہ نکالتا ہے۔
تین ماہ کی PKR worksheet یوں بنائیں
کسی ایک غیر معمولی مہینے کو مستقل رفتار بنانے کے بجائے اس worksheet میں تین مکمل مہینوں کا rolling average استعمال کریں۔ ہر مہینے کے لیے opening cash، operating cash collected، cash paid، financing inflows اور closing cash کی الگ columns رکھیں؛ annual prepayments اور one-off payments کو cash paid کے اندر شناخت کے لیے الگ نشان لگائیں۔ Funding cash balance بڑھاتی ہے، مگر اسے customer collection بنا کر operating net burn کم نہ کریں۔
یہ ایک فرضی پاکستانی startup کی قابلِ نقل مثال ہے۔ اگست کے آخر میں اس کا قابلِ استعمال cash 1 کروڑ 12 لاکھ روپے ہے:
- جون: cash paid 24 لاکھ، cash collected 9 لاکھ، net burn 15 لاکھ روپے۔
- جولائی: cash paid 38 لاکھ، cash collected 5 لاکھ، net burn 33 لاکھ روپے۔
- اگست: cash paid 26 لاکھ، cash collected 18 لاکھ، net burn 8 لاکھ روپے۔
تین ماہ کا cash paid 88 لاکھ ہے، اس لیے اوسط gross burn تقریباً 29.33 لاکھ روپے ماہانہ ہے۔ Cash collected مجموعی طور پر 32 لاکھ، یعنی اوسطاً 10.67 لاکھ ماہانہ ہے۔ Net burn کا مجموعہ 56 لاکھ اور اوسط 18.67 لاکھ بنتا ہے؛ چنانچہ 112 لاکھ ÷ 18.67 لاکھ سے historical headline runway تقریباً 6 ماہ نکلتی ہے۔
ہر نئے ماہ کے اختتام پر سب سے پرانا مہینہ نکال کر تازہ مہینہ شامل کریں۔ پھر opening cash + تمام cash inflows − تمام cash outflows = closing cash سے reconciliation کریں۔ فرق باقی ہو تو bank account، tax payment، financing receipt، owner transfer یا fee کے چھوٹ جانے کی جانچ کریں۔
Booked revenue کو cash سمجھنے سے حساب کیوں بگڑتا ہے
فرض کریں جولائی میں 15 لاکھ روپے کی invoices book ہوئیں، مگر bank میں صرف 5 لاکھ آئے۔ پوری booked رقم منہا کرنے سے net burn 23 لاکھ دکھائی دے گا، جبکہ cash-based عدد 38 لاکھ − 5 لاکھ = 33 لاکھ ہے۔ باقی 10 لاکھ accounts receivable ہے، دستیاب cash نہیں۔
SEC کی financial-statements وضاحت کے مطابق income statement کمائی گئی revenue دکھاتا ہے، جبکہ cash-flow statement حقیقی cash inflows اور outflows دکھا کر net income کو operating cash سے reconcile کرتا ہے۔ اسی فرق کی وجہ سے receivable کو historical collection نہ بنائیں؛ forecast میں اسے اسی متوقع مہینے میں رکھیں جس میں رقم آنے کا امکان ہے، اور downside case میں تاخیر یا جزوی عدم وصولی الگ دکھائیں۔
Advance customer payment الٹ صورت ہے: پوری رقم وصول ہونے کے مہینے میں cash inflow ہے، خواہ accounting revenue بعد کے مہینوں میں پہچانی جائے۔ مگر اسے آئندہ ہر ماہ recurring collection سمجھنا بھی غلط ہوگا۔ Bank arrival اور revenue recognition کو الگ رکھنے سے historical burn اور future forecast ایک دوسرے میں نہیں ملتے۔
Annual prepayments اور one-off costs کو دو بار نہ گنیں
فرض کریں جولائی کے 38 لاکھ outflow میں 9 لاکھ کی سالانہ software prepayment اور 6 لاکھ کے laptops شامل تھے۔ Historical cash movement میں پورے 15 لاکھ جولائی ہی میں رہیں گے؛ انہیں accounting expense کی طرح کئی مہینوں پر پھیلانے سے جولائی کا bank drain تبدیل نہیں ہوتا۔
Forward cash forecast میں ان ادائیگیوں کو ہر ماہ دہرانا بھی درست نہیں۔ 88 لاکھ کے تین ماہ کے outflows سے یہ 15 لاکھ نکالنے پر قریبی مہینوں کا baseline outflow 73 لاکھ ÷ 3، یعنی تقریباً 24.33 لاکھ روپے ماہانہ بنتا ہے۔ اگلی 9 لاکھ کی annual renewal forecast horizon میں ہو تو پوری رقم اس کی due date والے مہینے میں شامل کریں؛ laptop replacement بھی صرف واضح منصوبے کی تاریخ پر ڈالیں۔
Dashboard پر تین الگ قطاریں رکھیں: actual three-month burn، exceptional payments کے بغیر baseline، اور تاریخ وار آنے والی بڑی payments۔ پہلی بتاتی ہے cash کے ساتھ کیا ہوا، دوسری معمول کی موجودہ رفتار دکھاتی ہے، اور تیسری واضح کرتی ہے کہ balance کس مہینے اچانک گرسکتا ہے۔
Downside runway میں وصولی اور funding delay آزمائیں
Headline runway پچھلے اوسط cash pattern کے برقرار رہنے کا مفروضہ ہے۔ پاکستانی startup کے downside case میں delayed collections، foreign-currency software یا cloud bills کی PKR ادائیگی، tax dues اور planned hiring کو الگ assumptions بنائیں۔ Exchange rate کا بے بنیاد عدد لگانے کے بجائے vendor کی معلوم PKR invoice یا صاف لکھا ہوا scenario استعمال کریں۔
فرضی مثال میں baseline outflow 24.33 لاکھ روپے ہے۔ اگر downside collection 8 لاکھ ماہانہ اور currency-linked ادائیگیوں کا اضافی scenario 3 لاکھ ماہانہ ہو تو net burn 24.33 + 3 − 8 = 19.33 لاکھ روپے ہوگا۔ 112 لاکھ ÷ 19.33 لاکھ سے downside runway تقریباً 5.8 ماہ نکلتی ہے۔
اگر متوقع funding تین ماہ دیر سے بند ہو تو اسے وصولی سے پہلے cash balance میں شامل نہ کریں۔ تین downside مہینوں میں تقریباً 58 لاکھ روپے خرچ ہونے کے بعد cash قریب 54 لاکھ رہ جائے گا، جو اسی رفتار پر تقریباً 2.8 مزید مہینوں کے برابر ہے۔ یوں چھ ماہ کی headline runway کے باوجود collection اور fundraising delay عملی مہلت کو واضح طور پر کم کردیتے ہیں۔
ہر ماہ historical rolling runway، future base case اور downside runway دوبارہ نکالیں۔ فیصلہ کرتے وقت سب سے چھوٹے معقول عدد کے ساتھ اس کی assumptions بھی لکھیں، تاکہ معلوم رہے تبدیلی recurring اخراج، delayed collection، annual payment یا funding delay میں سے کس وجہ سے آئی ہے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔