कैप टेबल स्प्रेडशीट की गलतियाँ: असल में क्या गड़बड़ होती है (और Excel पर भरोसा करना कब बंद करें)

कैप टेबल स्प्रेडशीट की सबसे आम गलती है ऑप्शन पूल को दो बार गिनना — एक बार आरक्षित शेयरों के रूप में, और ग्रांट जारी होने पर फिर से जारी किए गए शेयरों के रूप में — जिससे डाइल्यूशन कुछ प्रतिशत अंकों तक बढ़ा-चढ़ाकर दिखता है, और किसी को पता तक नहीं चलता। दूसरी सबसे आम गलती इससे भी सरल है: कई लोग अपना-अपना "नवीनतम" संस्करण रखते हैं, इसलिए कोई भी विश्वास के साथ यह नहीं कह सकता कि असल में कौन-सी फ़ाइल सही है। ये दोनों गलतियाँ तब तक अदृश्य रहती हैं जब तक आपकी कंपनी से बाहर का कोई व्यक्ति हिसाब जाँच न ले — और ठीक यही वह क्षण होता है जब ये आपको सबसे महँगी पड़ती हैं।

अगर आप यह इसलिए पढ़ रहे हैं क्योंकि आपने कैप टेबल स्प्रेडशीट की गलतियाँ खोजी थीं, तो आपको शायद पहले से ही संदेह है कि आपकी शीट में कोई गलती है। यह अंतर्ज्ञान आम तौर पर सही होता है। यहाँ बताया गया है कि ये गलतियाँ असल में कैसी दिखती हैं, अगर आप अमेरिका के बाहर कंपनी बना रहे हैं तो ये और बुरी क्यों होती हैं, और वह ईमानदार सीमा क्या है जिसके बाद एक स्प्रेडशीट पर्याप्त नहीं रह जाती।

वे गलतियाँ जो असल में बार-बार होती हैं

सामान्य सूचियाँ आपको दस गलतियाँ गिना देंगी। व्यवहार में, लगभग हर टूटी हुई कैप टेबल चार गलतियों तक ही जाती है।

ऑप्शन पूल की दोहरी गिनती। आप 10% का पूल बनाते हैं और उसे एक पंक्ति में आरक्षित शेयरों के रूप में दर्ज करते हैं। फिर आप अपने पहले कर्मचारी को ऑप्शन देते हैं और जारी किए गए शेयरों के लिए दूसरी पंक्ति जोड़ देते हैं — पर उन्हें आरक्षित वाली पंक्ति से हटाए बिना। अब वही इक्विटी दो बार गिनी जा रही है, कुल बकाया शेयर बढ़े हुए दिखते हैं, और फ़ाइल का हर स्वामित्व प्रतिशत चुपचाप गलत हो जाता है। कैप टेबल के विश्लेषण में यह सबसे अधिक उद्धृत की जाने वाली स्प्रेडशीट गलती है, और इसका कारण साफ़ है: यह कोई एरर नहीं दिखाती, बस चुपचाप डाइल्यूशन को कुछ प्रतिशत अंकों तक बढ़ा देती है। कुछ प्रतिशत अंकों को कोई तब तक नहीं पकड़ता जब तक टर्म शीट मेज़ पर न आ जाए और आँकड़ों को कड़ी जाँच में टिकना न पड़े।

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

संस्करणों की भरमार। Cap-Table-v3-FINAL.xlsx, Cap-Table-v3-FINAL-actually-final.xlsx, और एक प्रति जिसे आपके सह-संस्थापक ने बिना वाई-फाई वाले हवाई जहाज़ में संपादित किया और फिर हाथ से मिला दिया। स्प्रेडशीट में डिज़ाइन के हिसाब से ही सत्य का कोई एकल स्रोत नहीं होता — हर सेव एक फ़ॉर्क है, कमिट नहीं। जिस क्षण एक से अधिक व्यक्ति को राइट एक्सेस की ज़रूरत होती है, आपने एक ऐसी विसंगति के लिए हालात बना दिए हैं जो सबसे बुरे संभव समय पर सामने आती है: ड्यू डिलिजेंस के बीच में, जब किसी निवेशक का सहयोगी आपके डेटा रूम से अपना अलग संस्करण बनाता है और वह आपके संस्करण से मेल नहीं खाता।

छूटी हुई या देर से दर्ज की गई ग्रांट्स। किसी शुरुआती कर्मचारी के ऑप्शन ज़बानी वादे में दिए जाते हैं, Slack संदेश में तय होते हैं, और स्प्रेडशीट में तब तक नहीं पहुँचते जब तक छह महीने बाद किसी को याद न आ जाए — आम तौर पर तब, जब वह व्यक्ति अपने वेस्टिंग शेड्यूल के बारे में पूछता है, या कंपनी छोड़ता है और फ़ॉरफ़िचर की गणना करनी पड़ती है। छूटी हुई ग्रांट्स सिर्फ़ कैप टेबल को विकृत नहीं करतीं; वे एक कानूनी खाई पैदा करती हैं, क्योंकि असल में क्या पेशकश की गई थी, इसका कोई समकालीन रिकॉर्ड ही नहीं होता।

अमेरिका के बाहर ये और बुरी क्यों हो जाती हैं

खोजने पर आपको मिलने वाला हर कैप टेबल स्प्रेडशीट टेम्पलेट एक ही धारणा पर बना होता है: एक Delaware C-corp, एक मानक अमेरिकी ESOP के तहत एक ऑप्शन पूल, और किसी एक अधिकार-क्षेत्र के नियम कि एक प्रस्ताव कैसा दिखना चाहिए। यह धारणा टिकती नहीं अगर आप Riyadh, Lagos, Nairobi या Jakarta में निगमित हैं।

ऊपर की चार गलतियों के ऊपर दो संरचनात्मक समस्याएँ जुड़ जाती हैं:

दोहरी-इकाई संरचनाएँ तालिका को दो हिस्सों में बाँट देती हैं। अमेरिका के बाहर के बहुत से संस्थापक आखिरकार किसी राउंड के लिए Delaware C-corp या Singapore होल्डिंग कंपनी में फ़्लिप कर लेते हैं, जबकि जिस इकाई को वे असल में चलाते हैं वह स्थानीय ही रहती है। अब एक कैप टेबल नहीं खिसक रही — बल्कि दो हैं, दो मुद्राओं में, दो सेट नियमों के तहत, और एक सामान्य टेम्पलेट के पास इन्हें आपस में मिलाकर रखने का कोई तंत्र नहीं है। स्थानीय इकाई की तालिका में एक गलती सिर्फ़ स्थानीय स्वामित्व को गलत नहीं दिखाती; यह उस प्रो-राटा गणित को भी गलत दिखाती है जिस पर होल्डको राउंड की असल कीमत तय होती है।

अधिकार-क्षेत्र-विशिष्ट आवश्यकताओं के लिए कोई सेल नहीं होती। सऊदी अरब में आम-सभा (जनरल असेंबली) के प्रस्ताव और मतदान के समय के असल स्वामित्व से जुड़े, शेयरधारिता-भारित मतदान रिकॉर्ड ज़रूरी हैं — एक कानूनी आवश्यकता जिसे अमेरिका में बने ज़्यादातर कैप टेबल टूल बिल्कुल भी मॉडल नहीं करते, स्प्रेडशीट की तो बात ही छोड़िए। अगर आपके स्वामित्व प्रतिशत किसी दो बार गिने गए ऑप्शन पूल के कारण गलत हैं, तो उन प्रतिशतों के आधार पर पारित हर प्रस्ताव उस गलती को विरासत में पा लेता है। अब यह सिर्फ़ एक गलत आँकड़ा नहीं रह जाता; यह एक शासन-रिकॉर्ड है जो टिकेगा नहीं।

यही वह खाई है जिसे वैश्विक संस्थापकों के लिए बना एक Carta विकल्प पाटने वाला है — सिर्फ़ सस्ती कैप टेबल गणना नहीं, बल्कि एक ऐसी संरचना जो आपके अधिकार-क्षेत्र को बाद में जोड़ने के बजाय शुरू से ही मान कर चलती है।

बदलने की असली सीमा

अधिकांश सलाह कहती है "जब आप स्प्रेडशीट के लिए बहुत बड़े हो जाएँ तब बदलें", जो इतनी अस्पष्ट है कि बेकार है — संस्थापक हर तिमाही "बहुत बड़े" की परिभाषा नए सिरे से गढ़ते हैं ताकि Excel फ़ॉर्मूलों का एक और दौर उचित ठहरा सकें।

सीमा आकार नहीं है। यह तीन घटनाओं में से एक है, और इनमें से कोई भी अकेली काफ़ी है:

1. आपका पहला बाहरी निवेशक। जिस क्षण आपके अलावा कोई व्यक्ति स्वतंत्र रूप से आपके स्वामित्व का मॉडल बनाने वाला होता है, आपकी स्प्रेडशीट को किसी अजनबी द्वारा दोबारा बनाए जाने में टिकना पड़ता है। अगर वह नहीं टिक सकती, तो यह भविष्य की समस्या नहीं है — यह अभी की ड्यू डिलिजेंस समस्या है।
2. आपकी पहली ESOP ग्रांट। जिस पल इक्विटी संस्थापकों से निकलकर किसी कर्मचारी के पास जाती है, आपको एक ऐसी प्रणाली चाहिए जो वेस्टिंग, क्लिफ़ और फ़ॉरफ़िचर को ट्रैक करे — बिना किसी इंसान के सही तारीख पर कोई सेल अपडेट करना याद रखे। एक वेस्टिंग अपडेट चूकिए और आपने असल स्वामित्व या तो ज़्यादा जारी कर दिया या कम।
3. वह क्षण जब दो लोगों को फ़ाइल संपादित करनी पड़ती है। एक संपादक वाली कैप टेबल गलत हो सकती है, फिर भी संगत रहती है। दो संपादकों और किसी लॉकिंग तंत्र के बिना वाली कैप टेबल में आखिरकार दो सच होंगे।

अगर इन तीनों में से कुछ भी अभी तक नहीं हुआ है, तो एक साफ़-सुथरी स्प्रेडशीट वाकई ठीक है — यह पहले ही दिन Excel छोड़ देने की वकालत नहीं है। अगर इनमें से कोई भी हो चुका है, तो स्प्रेडशीट अब लागत बचाने वाला विकल्प नहीं रह जाती। यह एक ऐसी देनदारी है जिसका बिल टलकर आता है।

इंतज़ार करने की असल कीमत

"जब तैयार हों तब माइग्रेट करें" का ईमानदार संस्करण यह है कि माइग्रेट करने की लागत हर उस महीने के साथ बढ़ती है जब आप इंतज़ार करते हैं, और यह धीरे-धीरे नहीं बढ़ती।

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

असल में इसे क्या ठीक करता है

समाधान कोई बेहतर स्प्रेडशीट टेम्पलेट नहीं है। समाधान है उस चीज़ को हटाना जो स्प्रेडशीट को शुरू से ही अविश्वसनीय बनाती है: हर सेव पिछली स्थिति को चुपचाप अधिलेखित (ओवरराइट) कर देता है, इस बात का कोई रिकॉर्ड रखे बिना कि क्या बदला और क्यों।

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

यही वह अनुशासन है जिसकी आपकी ESOP ग्रांट्स को तब ज़रूरत होती है जब आप हर एक के लिए वकील का इस्तेमाल करना बंद कर देते हैं — एक दोहराने योग्य, अधिकार-क्षेत्र के प्रति सजग प्रक्रिया जो इस बात पर निर्भर नहीं करती कि किसी को सही सेल अपडेट करना याद रहे।

किसी कैप टेबल स्प्रेडशीट की गलती को बाद में ठीक करना एक सफ़ाई परियोजना है। शुरू से ही स्प्रेडशीट की गलतियाँ न होना एक संरचनात्मक विकल्प है, जो एक बार लिया जाता है, और लगातार फल देता रहता है।

Govy कैप टेबल को एक इवेंट-सोर्स्ड लेजर पर चलाता है, जो Delaware के डिफ़ॉल्ट से बाहर के संस्थापकों के लिए बना है — आम-सभा शासन, अधिकार-क्षेत्र के प्रति सजग ESOP अनुबंध, और एक ऐसी कैप टेबल जिसे चुपचाप अधिलेखित नहीं किया जा सकता। देखें कि यह कैसे काम करता है, govy.tech पर।

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

कैप टेबल स्प्रेडशीट में सबसे आम गलती क्या है? ऑप्शन पूल को दो बार गिनना — एक बार आरक्षित शेयरों के रूप में और ग्रांट जारी होने पर फिर से जारी किए गए शेयरों के रूप में। यह एक अकेली फ़ॉर्मूला गलती है, पर यह डाइल्यूशन को कई प्रतिशत अंकों तक बढ़ा देती है, और किसी को तब तक पता नहीं चलता जब तक किसी निवेशक का सहयोगी स्वतंत्र रूप से तालिका दोबारा न बना ले और आँकड़े मेल न खाएँ।

किसी स्टार्टअप को स्प्रेडशीट कैप टेबल कब छोड़ देनी चाहिए? कैलेंडर के हिसाब से नहीं — किसी घटना के हिसाब से। ट्रिगर है आपका पहला बाहरी निवेशक, आपकी पहली ESOP ग्रांट, या वह क्षण जब दो लोगों को एक ही फ़ाइल संपादित करनी हो। इन तीनों में से कोई भी एक स्प्रेडशीट को "ठीक है" से "सक्रिय रूप से ख़तरनाक" में बदल देता है, चाहे आप कंपनी को कितने ही महीनों से चला रहे हों।

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

क्या कैप टेबल स्प्रेडशीट एक ऑडिट ट्रेल मानी जाती है? नहीं। स्प्रेडशीट एक वर्तमान स्थिति संग्रहीत करती है, न कि वह इतिहास कि वह वहाँ तक कैसे पहुँची — हर संपादन पिछले को अधिलेखित कर देता है, और Excel का अपना संस्करण-इतिहास इस बात का ग्राह्य प्रमाण नहीं है कि किसने क्या और क्यों बदला। एक ऑडिट ट्रेल के लिए ज़रूरी है कि हर बदलाव एक अलग, टाइमस्टैम्प वाली, उत्तरदायी घटना के रूप में दर्ज हो, जो सेलों के ग्रिड से बिल्कुल अलग तरह की प्रणाली है।

क्या अमेरिका के बाहर के अधिकार-क्षेत्र कैप टेबल की गलतियों को और बुरा बना देते हैं? हाँ, क्योंकि अधिकांश स्प्रेडशीट टेम्पलेट और यहाँ तक कि अधिकांश कैप टेबल टूल एक अकेली Delaware C-corp के इर्द-गिर्द, अमेरिकी-मानक ऑप्शन पूल के साथ बने होते हैं। Riyadh, Lagos या Jakarta में कोई संस्थापक अक्सर एक दोहरी-इकाई संरचना, अधिकार-क्षेत्र-विशिष्ट ESOP उपकरण, या आम-सभा प्रस्ताव ट्रैक कर रहा होता है, जिनके लिए किसी सामान्य टेम्पलेट में कोई कॉलम ही नहीं होता — इसलिए वही दोहरी-गिनती वाली गलती एक ऐसी संरचनात्मक गलती के साथ मिलकर बढ़ जाती है जिसकी टेम्पलेट ने कभी उम्मीद ही नहीं की थी।