A financial model built internally is not the same as a model that is ready for investor scrutiny. The gap is almost never the spreadsheet formulas. It is assumption integrity, cross-statement coherence, reconciliation against actuals, and the ability to hold its shape when a VC analyst starts pulling threads on Day 1 of diligence. Founders who open a data room with an unvalidated in-house model spend the first two weeks of diligence defending the spreadsheet rather than selling the company. This article covers the structured validation process: what to check, in what order, what India-specific issues surface at the worst moment, and what investors actually do with the model before they ask the founder a single question.
What does “financial model validation” mean in the context of a data room?
Financial model validation, in this specific context, is the structured process of verifying that a completed in-house model is internally consistent, grounded in defensible assumptions, reconciled against actuals and statutory returns, coherent with the pitch deck narrative, and capable of withstanding the first-pass methodology a VC or PE analyst runs in week one of financial diligence. It is not the same as building a model from scratch. It is also not the same as the financial due diligence that investors run after the data room opens. Validation is what the founder does before the room opens, to find and fix every material error before the other side finds it for them.
Why an in-house model will not survive diligence as-is
Most in-house models are built under time pressure, usually by a founder and a finance executive working together across multiple updates without a formal quality-control step. They are built to answer internal planning questions, not to withstand external forensic scrutiny. By the time a data room opens, those models carry months of accumulated assumption drift, silent inconsistencies, and structural workarounds that are invisible to the people who built them and immediately visible to an analyst reviewing cold.
Four structural failure points recur across almost every unvalidated in-house model.
Hardcoded inputs inside calculation blocks. When numbers are embedded in formula rows rather than isolated on a dedicated assumptions tab, the model becomes opaque. An analyst who finds a hardcoded growth rate at row 47 of the revenue schedule cannot tell whether it is intentional or an error. That uncertainty is enough to flag the model as unreliable.
Assumption drift across updates. Models updated repeatedly over months accumulate inconsistencies: a pricing assumption updated in the revenue tab that was never carried through to the COGS build; a headcount ramp that diverged from the hiring plan after a mid-year org restructure; a churn rate that was revised in the dashboard but not in the underlying cohort logic. These are not fraudulent. They are the natural result of iterating without a reconciliation discipline.
The multi-version problem. Founders routinely maintain three or more versions of the model simultaneously: one for internal planning, one shared with an existing investor, one included in a pitch deck. Each version has drifted from the others. When a data room opens, it is often unclear which version is canonical. Investors who encounter a model dated eight months earlier, or one that contradicts figures in the deck, begin diligence with a credibility question already open.
The India-specific reconciliation gap. Indian startup models carry regulatory complexity that creates specific reconciliation obligations the model must address. A delta of more than 10% between book revenue and GST-declared turnover is a yellow flag in diligence. A delta above 20% typically triggers a separate workstream. These are discoverable in under an hour by an investor’s chartered accountant with access to the data room, which is why the reconciliation must be prepared before the room opens, not after the question arrives.
What investors actually do with your model in week one of diligence
Validation done right mirrors the methodology the other side will use. A VC analyst reviewing a data room financial model in the first week typically runs eight checks before asking the founder anything.
Three-statement balance check. If ending cash on the cash flow statement does not equal cash on the balance sheet, the model fails its first test. This takes under two minutes to verify and is always the first check.
Sensitivity and linkage test. The analyst will change one input (usually revenue growth rate or churn) and watch whether outputs update consistently across all sheets. A pricing change in Month 3 that does not flow through to gross margin, OPEX, cash, and runway means the model is not properly linked. Broken linkage is treated as a structural error, not a minor omission.
Pitch deck coherence check. The model is cross-referenced against the pitch deck before any detailed review begins. If the deck states 3x ARR growth over two years but the model projects 2x, or if the deck’s gross margin figure does not match the model’s, the inconsistency is flagged immediately. Analysts routinely find that founders updated the deck after the model or vice versa without aligning both.
Actuals-versus-historicals reconstruction. If the model includes historical columns, the analyst will reconstruct actuals from the MIS reports, bank statements, and audited accounts in the data room and compare them line by line. Revenue figures, gross margin, and headcount costs that diverge by more than a rounding difference between the model’s historical section and the audited P&L raise a question about which version of the numbers is correct. The pattern described by multiple investor-side practitioners is consistent: they rebuild the trailing 12-month numbers from source data before they trust the projections.
Benchmark comparison. Implied unit economics (gross margin, burn multiple, CAC payback period) are derived from the model’s own numbers and compared against sector norms. For an Indian SaaS company at Series A, a gross margin above 78% implied by the model but 61% in the audited accounts immediately triggers a request for reconciliation. The investor is not trying to catch the founder lying. They are trying to understand which number reflects the real business and why the two differ.
Revenue recognition coherence. For SaaS and subscription businesses, the analyst will check whether revenue in the model is booked on cash receipt basis or accrual basis, and whether that treatment matches the Ind AS 115 treatment in the audited accounts. A model that shows revenue equal to cash receipts for a business that bills annually upfront (which should carry a deferred revenue balance) signals that the model was not built with Ind AS 115 mechanics in mind. Investors with India experience check this routinely.
Working capital mechanics. A model showing revenue and cash receipts moving in lockstep for a business with 45-day payment cycles is missing working capital. Analysts calculate the implied days sales outstanding (DSO) from the model’s revenue and cash figures and compare it to the payment terms stated elsewhere in the data room. If the DSO implied by the model is zero but the sales contracts show 30-day terms, the model’s cash timing is wrong.
FEMA and cap table compliance check (for rounds involving foreign investors). Where FDI is involved, the analyst will verify that the share issuance price in the cap table model complies with the pricing guidelines under Rule 21 of the Foreign Exchange Management (Non-Debt Instruments) Rules, 2019 (the NDI Rules). The price must not be less than the fair value determined by a registered valuer. A cap table model that shows a price below the RBI’s prescribed floor risks creating a FEMA violation that can block the allotment or require post-close rectification.
The eight-step validation process
Run these steps in order. Each is a gate: a material failure at any step should be fixed before proceeding to the next.
Step 1: Version audit and model consolidation
Before validating anything in the model, identify which version is the master. List every version of the model that exists: on the founder’s local drive, in shared Google Drive folders, sent to existing investors, referenced in the pitch deck. Compare version dates and the core outputs (Year 1 revenue, gross margin, and runway endpoint) across every version.
If there is more than one version, consolidate to a single master before any other validation work begins. A model that changes between the due diligence request and the data room upload, even innocuously, is a credibility problem. Fix this first.
Step 2: Assumption isolation and documentation
Every input must live on a single, clearly labelled assumptions tab. Run an audit of every calculation sheet: find every cell containing a number rather than a formula referencing the assumptions tab. List each one. Determine whether it is intentional (rare) or a drift error (almost always). Fix the errors and move every legitimate input to the assumptions page.
Each assumption on that tab must carry four pieces of information: what it measures, its value, its unit (monthly versus annual, percentage versus absolute), and its source (historical average, industry benchmark, management estimate). An assumption documented as “monthly new customer growth: 3%, based on trailing six-month cohort data, February to July 2026” is auditable. An assumption documented as “growth: 3%” is not.
Assumptions that are management estimates rather than data-derived must be explicitly flagged as such. Investors do not penalise founders for estimates. They penalise founders for presenting estimates as data.
Step 3: Model-to-pitch-deck coherence check
Place the pitch deck and the model side by side. Reconcile every number referenced in the deck against the model. Focus on:
- ARR or revenue projection (Year 1, Year 2, Year 3)
- Gross margin
- Burn rate and runway
- Market size and implied market share at exit
The pitch deck was likely updated at different times than the model. Wherever the two diverge, decide which is correct and align both before the data room opens. Investors will find every discrepancy. The question is whether it is found with an explanation ready or without one.
Step 4: Actuals-to-model historical reconciliation
If the model includes historical columns, reconcile them against the actual MIS reports and audited accounts. Three line items matter most: revenue, gross margin, and net cash.
Pull the last 12 months of MIS data (which at an investor-grade startup should already be available; if it is not, the MIS discipline problem is more urgent than the model validation problem). Compare month by month against the model’s historical section. Flag any month where revenue or gross margin diverges by more than 5%. Trace the discrepancy to its source: timing, classification, or a genuine error in the model’s historical build.
This reconciliation is not optional for the data room. The Treelife financial due diligence checklist notes that investors cross-verify model figures against MIS reports and audited accounts as a standard procedure. A clean reconciliation note in the data room eliminates the question before it is asked.
Step 5: Cross-statement reconciliation
Three mechanical checks are mandatory and must pass for every period in the model, not just annually.
Cash tie-out. Ending cash on the cash flow statement must equal cash on the balance sheet for every month or quarter in the model. Build a check row in a dedicated checks tab that flags any period where the two differ.
Balance sheet balance. Total assets must equal total liabilities plus equity for every period. A check formula of (Assets) minus (Liabilities plus Equity) must equal zero across every column. Any non-zero result has a structural error that must be traced.
Working capital flow. Accounts receivable, accounts payable, deferred revenue, and inventory movements must flow correctly from the P&L into the cash flow statement. A business billing ₹50 lakhs in Month 3 but collecting it in Month 4 must show an accounts receivable build in Month 3 and a receipt in Month 4 on the cash flow. If the model shows cash equalling revenue in every month regardless of payment terms, working capital has been assumed away.
Step 6: India-specific regulatory reconciliation
This step has no direct equivalent in global financial model validation guides. It addresses the regulatory complexity specific to Indian startup models.
GST-revenue reconciliation. Book revenue in the model must be reconcilable to GST-declared turnover in GSTR-1 and GSTR-3B. Prepare a formal reconciliation note documenting every difference: export revenue exempt from GST, advance receipts treated on cash basis for GST but accrual for book purposes, credit note timing, or multi-state supply classification differences. This note must be included in the data room alongside the financial model, not prepared in response to the investor’s question. The Treelife financial due diligence checklist confirms that an investor’s CA treats an unexplained GST-revenue delta as a revenue recognition risk that can result in an escrow arrangement or valuation reduction.
TDS receivables on the balance sheet. For businesses with domestic professional or technical services revenue, TDS at 10% is deducted at source under Section 194J of the Income Tax Act 1961. The TDS credit builds up as an asset (recoverable via Form 26AS and eventual ITR filing). If your business has ₹30 lakhs or more in unrecovered TDS credit, its absence from the balance sheet is a material omission. Add it, reconcile it against Form 26AS, and document the recovery timeline.
ESOP expense under Ind AS 102. Employee Stock Option Plans create an accounting charge from the date of grant under Ind AS 102 (Share-Based Payments). Most in-house models carry no ESOP expense at all. The ESOP cost must appear in OPEX from the grant date of each tranche, calculated using the Black-Scholes model at fair value on grant date, amortised over the vesting period. Its absence understates the cost base and inflates EBITDA. An investor-side CA who knows to look for it, and they do, will ask for the adjustment. Add it before the question is asked.
Ind AS 115 revenue recognition (SaaS and subscription businesses). For companies billing annually upfront, revenue must be recognised over the subscription period under Ind AS 115 (Revenue from Contracts with Customers), not at the point of cash receipt. The model must carry a deferred revenue balance on the balance sheet and show monthly revenue recognition from that balance. A model that books ₹12 lakhs of cash received in Month 1 as ₹12 lakhs of revenue in Month 1, when that annual subscription should be recognised at ₹1 lakh per month, has a revenue recognition error. This is not a projection issue. It is an accounting error that contradicts the audited financials and the company’s stated Ind AS compliance. If you need the mechanics, the Treelife Ind AS 115 guide for SaaS businesses covers recognition, contract liabilities, and disclosure requirements.
FEMA pricing compliance for inbound FDI. If the current or planned round involves foreign investors (including NRI investors and foreign venture capital investors), the share issuance price in the model’s cap table section must comply with Rule 21 of the Foreign Exchange Management (Non-Debt Instruments) Rules, 2019. The price to a non-resident cannot be less than the fair market value determined by a SEBI-registered Category I Merchant Banker or a Chartered Accountant using any internationally accepted pricing methodology. A cap table model that shows a share price below the registered valuation report’s concluded value creates a FEMA compliance risk. Verify the cap table price against the most recent valuation report. If they diverge, the model is wrong.
Provident Fund and ESIC on headcount costs. Every headcount assumption must use fully loaded costs including the employer PF contribution (12% of basic, subject to ceiling under the Employees’ Provident Funds and Miscellaneous Provisions Act 1952) and Employee State Insurance where applicable. Models that use gross salary without employer statutory contributions understate headcount costs by 15-20%. This is one of the most common errors in founder-built Indian models.
| India-specific item | Location in model | Consequence if missing or wrong |
|---|---|---|
| GST-revenue delta | Revenue tab + reconciliation note in data room | Revenue recognition risk, potential escrow or valuation cut |
| TDS receivables | Balance sheet | Asset understated, balance sheet does not reconcile to 26AS |
| ESOP expense (Ind AS 102) | OPEX, from grant date | EBITDA overstated, immediate investor query |
| Deferred revenue (Ind AS 115) | Balance sheet + revenue schedule | Revenue overstated in early periods, audited accounts do not match |
| FEMA pricing compliance | Cap table model | FEMA violation risk blocking allotment |
| PF/ESIC on payroll | Headcount/OPEX schedule | Headcount costs understated by 15-20% |
Step 7: Benchmark pre-emption
Investors compare the implied unit economics in your model against sector benchmarks before raising questions. Run this comparison yourself first so you know where the gaps will appear.
For an Indian SaaS company at Series A, the benchmarks investors typically apply are: gross margin in the 65-75% range for software-only revenue (lower for mixed software and services), burn multiple below 1.5 for efficient capital deployment, CAC payback under 18 months for SMB-focused businesses and under 24 months for enterprise, and NRR above 110% for expansion-led growth. These are not fixed thresholds; they are conversation anchors. If your model implies a 58% gross margin, you need a clear explanation of why (higher services revenue, India-specific delivery cost structure, intentional decision to invest in CS capacity ahead of revenue) rather than discovering the gap when the analyst asks.
Run the following six calculations on your own model before sharing it:
- Gross margin percentage for each of the three modelled years
- Burn multiple (net cash burned divided by net new ARR or revenue added in the same period)
- Implied CAC (sales and marketing spend divided by new customers acquired)
- CAC payback period (implied CAC divided by gross margin per customer per month)
- Rule of 40 (revenue growth percentage plus EBITDA margin percentage, for mature SaaS businesses)
- Headcount efficiency (revenue per full-time equivalent at each annual period end)
If any output is a significant outlier against sector norms, either the model is wrong or there is a legitimate business reason for the deviation. Prepare the explanation before the investor asks.
Step 8: Scenario mechanism and presentation audit
Scenario mechanism test. Switch the model from base case to downside. Verify that every output (revenue, gross margin, OPEX, cash, runway, and every KPI) updates consistently. If any output stays static when the scenario changes, the mechanism is broken. Investors test this in the first session.
The downside scenario must also include a cost response: which hires get delayed, which discretionary spend is cut, and how that changes runway. A downside scenario that reduces revenue but holds costs at base case levels is not a stress-test. It is a pessimistic revenue projection with no management response built in. Investors read the cost response as evidence that the founder has thought through what they would actually do.
Navigation audit. The model must be usable by someone who has never seen it before. Check for:
A README or model guide tab explaining scope, time period, currency, version date, and where inputs live. Without it, an investor’s analyst will spend the first hour orienting themselves rather than reviewing the model.
A checks tab confirming all three-statement reconciliations pass (visually green when clean, red when a check fails). This tab tells the investor that the validation has been done and documented.
Consistent sign conventions (all outflows negative or all outflows in brackets, one convention only). Consistent date format (DD/MM/YYYY for Indian entities). Consistent currency (₹ in lakhs or crores, not a mix of both in different tabs).
Version date visible on the cover sheet or the model guide tab. If the model is updated during diligence, the version date must change and the data room index must be updated accordingly.
What validation typically finds
Based on model review engagements run at Treelife before data room openings, the most common material findings fall into six categories.
The multi-version model. Three or more versions exist, with different revenue and margin outputs. The data room is uploaded with an outdated version. Investors find the discrepancy against the pitch deck in the first session.
Missing working capital. For businesses with B2B contracts and 30-60 day payment cycles, cash timing in the model is wrong. The model shows cash arriving the same month as revenue. The bank account shows a different pattern entirely. The discrepancy is material when DSO is 45 days or longer.
ESOP expense absent. The model carries no ESOP expense despite active grants. The audited accounts (or the next audit) will show the charge under Ind AS 102. The model understates OPEX and overstates EBITDA. Investors with India experience check for this specifically.
Pitch deck and model misalignment. The deck states 2.5x revenue growth in Year 1. The model shows 1.9x. The founder updated the deck narrative after the model was built. The investor finds the discrepancy without warning, which is a worse situation than the founder flagging it proactively.
Circular references. Introduced accidentally when modelling interest income on cash balances or debt repayment schedules. Circular references must be identified and resolved before sharing, as they cause calculation errors in Excel that produce different results on different machines depending on iteration settings.
Assumption-driven valuation, not business-driven. The model’s projections appear to have been calibrated to support a target pre-money valuation rather than built from the business’s actual drivers. Revenue growth ramps to whatever multiple produces the target, not to what the headcount, sales capacity, and market assumptions would actually support. Investors recognise this pattern and it damages credibility across the entire model, not just the valuation section.
How long does validation take?
The timeline depends on the model’s starting state.
| Model state | Typical validation timeline | Principal blocking issue |
|---|---|---|
| Single master version, assumptions isolated, three statements linked, checks tab present | 3-5 business days | Documentation, India-specific regulatory reconciliation notes |
| Working model, scattered assumptions, no checks tab, one consistent version | 8-12 business days | Assumption consolidation, linkage fixes, reconciliation notes |
| Functional revenue model, no full three-statement link, no working capital mechanics | 12-18 business days | Balance sheet build, cash tie-out, deferred revenue mechanics |
| Multiple versions, no master model, historical section inconsistent with MIS | 20+ business days | Model consolidation before validation can begin |
The reliable rule: start validation at least four weeks before the planned data room opening date. Founders who begin the day the data room is being indexed will not finish before investor diligence opens. The consequence is not a delay. It is defending the model while investors are already in it.
Common mistakes that cost founders time and negotiating leverage
Sharing a draft with investors before validation. Once the model is in an investor’s hands, any errors found belong to the diligence record. A model shared as a draft is treated as final. Recovering from “that version had some issues” after a sophisticated analyst has already mapped them is nearly impossible.
Treating the model as a standalone document. It will be cross-referenced against the audited accounts, MIS reports, GST returns, bank statements, and the cap table. Every inconsistency between the model and any other data room document is a diligence question. Validation must include a cross-document consistency check, not only an internal model review.
Calibrating projections backward from a valuation target. If the revenue assumptions were chosen to support a pre-money valuation rather than built from the business’s actual operating drivers, a sophisticated investor will find it. The pattern is recognisable: growth rates that happen to produce exactly the multiples required, with no operational logic connecting the assumptions to the projections. This destroys credibility across the entire model.
Ignoring the ESOP pool mechanics in the CCPS-to-equity conversion. For companies with Compulsorily Convertible Preference Shares outstanding, the cap table model must show both the pre-conversion ownership structure and the fully diluted post-conversion view including ESOP pool. Founders often model only the fully diluted view. This obscures the liquidation preference waterfall, which matters in any M&A or secondary sale scenario and which investors will model independently.
Skipping the downside cost response. A downside revenue scenario without a corresponding cost adjustment is not a stress-test. It tells the investor that the founder has not thought through what they would actually do if growth underperforms. The downside must show the cost levers that get pulled (specific hiring delays, specific discretionary cuts) and the revised runway that results.
Not reconciling before the room opens. The GST-revenue reconciliation, TDS asset balance, and ESOP charge are the three items most likely to generate formal investor queries within the first week of diligence. Preparing them before the data room opens eliminates those questions. Preparing them in response to the questions costs 5-10 business days of diligence time and signals reactive rather than proactive financial management.
In the model validation engagements we have run at Treelife
The pattern is clear. The models that create the least diligence friction share three characteristics: the revenue logic is built from a small number of genuine operating drivers that the founder can explain from memory, the three statements reconcile cleanly without exception, and the assumptions page is honest about which numbers are data-derived and which are management estimates.
The models that create the most friction are not the ones with wrong projections. Investors expect projections to be uncertain. The models that stall diligence are the ones where an analyst cannot determine which numbers are real, which are estimates, and which are errors. That ambiguity is what validation removes.
One pattern specific to India: the gap between book revenue and GST-declared turnover is the first thing a knowledgeable investor’s CA looks for, not the last. We have seen data room processes stall for 10-12 business days while a reconciliation note was prepared that should have been in the room at opening. That delay is not a technical problem. It is a negotiating leverage problem. Every additional week of diligence is a week in which the investor has more time to find issues and apply conditions to the term sheet.
The investment in validation (typically four to six weeks of structured preparation) pays back directly in a shorter diligence timeline, fewer investor queries, and a negotiating position where the conversation stays on strategy rather than descending into spreadsheet forensics.
FAQs
Q: What is the difference between financial model validation and financial due diligence?
A: Validation is what you run before the data room opens, on your own model, to find and fix errors before investors see them. Financial due diligence is what investors run after the data room opens, to verify your claims. Validation is founder-controlled and proactive. Due diligence is investor-controlled and reactive. Running a thorough validation directly reduces the findings that surface in diligence.
Q: Can we do validation internally, or does it require external review?
A: The structural checks (reconciliations, assumption isolation, scenario testing) can be run internally. The checks that benefit most from external review are assumption defensibility (familiarity with the model creates blind spots), India-specific regulatory reconciliation (GST bridge, TDS asset, ESOP calculation), and benchmark comparison. A founder who built the model is the least reliable person to identify where its logic is unclear to an outsider, not because of dishonesty but because they already know the assumptions behind every number.
Q: How do we handle a gap between our book revenue and GST-declared turnover?
A: The gap must be explained in a formal reconciliation note attached to the data room, not buried or ignored. Common legitimate explanations include export revenue exempt from GST, advance receipt timing (cash-basis GST versus accrual-basis book revenue), credit note adjustments, and multi-state supply classification differences. The note should quantify each category and cite the relevant provision. If the gap cannot be fully explained, that is a problem to resolve before the data room opens, not a question to answer during diligence.
Q: How should the model treat ESOP expenses?
A: Under Ind AS 102 (Share-Based Payments), the fair value of options at grant date is recognised as an expense over the vesting period, with a corresponding credit to a share-based payment reserve. The fair value is typically calculated using the Black-Scholes model. The model must include this charge in OPEX from the grant date of each tranche. Many investor-side analysts add it back for EBITDA normalisation purposes, but it must appear in the model, not be excluded silently, so the investor can make that normalisation explicitly rather than discovering the omission.
Q: Does FEMA pricing apply if we are raising from an NRI investor?
A: Yes. NRI investment on a non-repatriation basis falls under the NDI Rules 2019. On a repatriation basis, it constitutes FDI and is subject to Rule 21 pricing guidelines. In either case, the price cannot be below the fair value determined by a registered valuer. The cap table model must reflect a price at or above the most recent registered valuation. If the model shows a price below that level, the allotment risks being in breach of FEMA, which requires post-close rectification and RBI reporting.
Q: What happens if the investor finds a model error after the data room has opened?
A: Update the model immediately, version-date it, replace it in the data room, and proactively notify the investor with a clear explanation of what changed and why. A founder who says “we identified and corrected an error in the deferred revenue mechanics, here is the updated version with a change log” is demonstrating operational discipline. A founder who waits for the investor to raise the issue is creating a trust problem that is difficult to recover from in negotiation.
Q: Should the model include the current fundraising round in its projections?
A: Yes, with two distinct views: one assuming the round closes (showing use of proceeds and the resulting growth plan), and one showing runway without the raise. The no-raise scenario is not pessimism. It shows investors whether the business can survive a failed or delayed close. A business that requires the current round to remain operational is a different risk profile from one that has 6-9 months of buffer without it. Investors read the no-raise scenario carefully.
Q: What is the burn multiple and does it need to appear in the model?
A: Burn multiple is net cash burned divided by net new ARR added in the same period. For a SaaS company, a burn multiple below 1.5 is generally considered efficient at Series A. The model should surface this as a KPI in the dashboard, calculated from the model’s own outputs, so investors read the Treelife-calculated version rather than deriving their own with potentially different inputs. Leaving investors to calculate a metric from scratch creates risk that they use a different numerator or denominator than intended.
Q: How far back should historical data in the model go?
A: At minimum, 12 months of monthly actuals reconciled against the most recent MIS and management accounts. For a Series A raise, investors typically want 18 months of actuals to assess growth trajectory and identify anomalies. The historical section must be locked against accidental formula overwrite and clearly distinguished from the projection section by colour coding or tab separation.
Q: What does a “checks tab” look like in practice?
A: A dedicated sheet with named check rows, each of which returns a zero or a “PASS” when the reconciliation holds and a non-zero number or “FAIL” when it does not. Typical checks: balance sheet balances (assets minus liabilities minus equity = 0), cash tie-out (balance sheet cash minus cash flow ending cash = 0), three-statement link integrity (P&L net income equal to cash flow start point), and scenario switch (base case revenue not equal to downside revenue when scenario toggle is set to downside). The tab should be easy to read at a glance. An investor or their analyst who opens it should be able to confirm within 30 seconds that all reconciliations are clean.
Q: Is Ind AS 115 applicable to all Indian startups, or only certain companies?
A: Ind AS 115 applies to companies that are required to follow Indian Accounting Standards (Ind AS), which includes all listed companies and all unlisted companies with net worth of ₹250 crore or more. Most early-stage startups are therefore not formally required to apply Ind AS 115 and may follow AS 9 under IGAAP instead. However, investors with institutional backgrounds (particularly those investing from an AIF or following global fund standards) will apply Ind AS 115 logic when evaluating the model’s revenue recognition treatment, regardless of whether the company is formally required to follow it. The practical validation recommendation is to apply the Ind AS 115 treatment in the model (and document the choice) regardless of formal applicability. It produces a more conservative and defensible revenue figure and avoids diligence questions about timing.
Q: How does angel tax abolition affect the financial model?
A: Section 56(2)(viib) of the Income Tax Act was abolished from 01 April 2024 (AY 2025-26 onwards) by the Finance Act 2024. Share issuances after that date are no longer subject to angel tax, and the financial model does not need to carry a provision or risk disclosure for it on new rounds. Any pending assessments for prior years (AY 2023-24 or AY 2024-25) remain and must be separately addressed. FEMA pricing compliance for foreign investors continues independently of the angel tax abolition.
Q: What is a “use of proceeds” section and where does it live in the model?
A: A breakdown of how the capital raised will be deployed, by category and approximate timing: product and engineering headcount, go-to-market and growth spend, general and administrative, working capital buffer, and contingency (typically 10-15% of the raise). It should sit on the cap table or fundraising tab and connect to the operating assumptions, so investors can read the use of proceeds and trace each category to specific hiring plans, marketing assumptions, or cost line items in the OPEX build. A use of proceeds section that lists categories without connecting to the model’s underlying assumptions is decoration, not analysis.
