Model check
Your model's inputs, against verified numbers.
We test each key input in your model against verified bank data, tax data where the market provides it, and registry filings, and against peers from their filings. Each assumption comes back marked, with its rows.
Funds and family offices
The deal model runs on management's numbers. The committee meets Thursday and someone will ask where 38% growth comes from.
Private credit lenders
Repayment depends on a revenue plan. You want its inputs tested before sanction, and not at the first covenant test, when the loan conditions are first measured.
Founders and CFOs
You want your plan checked against your own verified data before an investor's associate does it, one cell at a time.
A line-by-line test of revenue, growth, margins, working-capital days, debt and burn. Each input sits beside the verified figure and a peer range, with a status. The assumption register goes to the deal team. The sensitivity table goes to the committee.
Model assumes revenue growth of 38% next year. Verified turnover for the last five months is up 14% year on year, and receivable days have moved from 52 to 71.
Illustrative finding. Not a real company.
What lands on your desk
Assumption register
Each input, the verified figure, the peer range and a status, in Excel. The associate's working document.
Base-year check
Model history against bank data, tax data and filed accounts, monthly where data allows.
Sensitivity table
Your outputs recalculated on verified inputs, using your own formulas. The page the committee asks for.
Scope note
Inputs we could not test, and why. Market entry and pricing power live here.
How the work runs
Receive the model
Excel with live formulas. We list every hard-coded input, every value typed over a formula, and every figure that feeds a projection. A pasted number inside a formula range is the commonest find.
Verify base year
History tied to bank data (with consent), tax-return data where available, and filed accounts. If the base year is wrong, every projection built on it is wrong by construction.
Rebuild unit economics
Margin, payback and burn from verified cash. Headcount against public employment records where they exist. Working-capital days from the books and tax data, compared with what the model assumes. A model that holds receivable days flat while the ledger shows them stretching is a familiar sight.
Set peer ranges
Growth, margin and working-capital ranges from comparable companies' filed financials. Peers and filing years are named, so you can disagree with the choice.
Mark each input
Supported, outside the verified range, or not testable, with source rows. A named analyst reviews every mark.
Input trace
Each revenue, cost, debt and tax input traced to a source, or marked unsupported.
Formula integrity
Hard-coded numbers in formula ranges, broken links, circular references, sign errors, inconsistent units.
Statements tie
Balance sheet balances, cash ties to the cash flow, and the debt schedule ties to charges and borrowings.
Tax treatment
The model's tax treatment set against the published rules of the market, as a flag for your adviser. Not tax advice.
History check
Working capital, margin and growth assumptions against the company's own filed history.
Peer check
The same assumptions against filed history of comparable companies, where the market publishes it.
Sensitivity
Three inputs flexed, with the effect on the key outputs.
Error log
Every issue with cell references, size of effect and a suggested fix.
Extension by agreement: full downside and covenant stress testing. Usually 5 Business Days.
Send the model and pay.
Formula scan, link scan and a check of history against source.
Inputs traced to source. Assumptions tested against history and peers.
Sensitivity run. A second reviewer reads the log.
Error log and sensitivity page delivered.
Usually (our estimate)
Usually 5 days of manual review by an associate, mostly spent finding the hard-codes.
Kubr
2 to 5 Business Days from a complete data set.
Typical times are targets we are still testing in the pilot. The 2 to 5 day window is the commitment. Terms in Disclosures.
What the cases taught us
Unit-economics failure appears in many of the 483 cases, and unverified operating metrics in many of them. Models built on those inputs inherit the error.
Burn and unit-economics checks feature in many cases. Every model gets that test.
We do not build or own the model, and we do not judge whether the assumptions are wise. We test whether they are supported.
Counts come from our first review of the public cases in the casebook on this site. We mapped each case, on hindsight, to the checks that could have surfaced it. It is our reading, not a finding about any company. Many cases describe allegations that are contested. See the cases
ChecksWhat we check, in plain words
| Check | What it means | An illustration (invented) | It can mislead when |
|---|---|---|---|
| Bank credits vs books | We compare the money that actually moved through the bank with the sales and costs in the books, month by month. | The books show ₹4 crore of sales in a quarter. Bank credits from customers add up to ₹2.5 crore. | AA only sees the accounts the company links, so an undisclosed account stays invisible. Cash-heavy businesses and timing differences create false flags. |
| Counterparty tax / GST | We look up the main customers and suppliers in the tax system and see whether they are active, filing, and report the same trades. | A customer the company calls its largest has not filed a return in a year. | Needs taxpayer consent or GSP access. A registered, filing shell still passes this check, which is why C3 and C4 run beside it. |
| Unit economics & burn | We rebuild margin per sale, customer acquisition cost, payback and cash burn from verified numbers, not from the deck. | The deck shows a profitable order. Rebuilt from invoices, each order loses money. | Cost allocation is a judgement call. Kubr shows its assumptions and lets the user change them. |
| Operating-metric verification | We test claimed headcount, stores, vehicles, units and users against independent traces. | The company claims 800 staff. Provident fund filings show 140. | Contract staff do not appear in EPFO. Vahan access needs licensed APIs. Some businesses have no physical trace. |
| Drawing power vs books | We compare the stock and receivables statements the company gave its bank with its own books. | The bank was told stock was ₹20 crore. The books say ₹12 crore. | CARO is annual, so the signal comes late. It covers only borrowers above the ₹5 crore limit. |
What it will not tell you
- We put no value or target price on the company. Discount rates and exit multiples are marked out of scope.
- New markets, pricing power and competitor response cannot be tested from records. We mark them not testable.
- Bank and tax tie-outs need the company's consent. Without it we test against filed accounts only, and say so.
- Accounts we are not given access to are out of view. Each one is listed as a gap.
Not in this service: build or own the model, or judge its assumptions.
What it can do
- Tie the model's historical years to bank credits, filed accounts and, where the market provides it, tax-return turnover.
- Compare projected growth with the verified run-rate and with peer growth from filed financials.
- Check claimed headcount against public employment records where they exist, and operating metrics against independent records.
- Log formula breaks, hard-coded overrides, circular references, unit mismatches and inputs that contradict each other, with cell references.
Why it differs from the usual way
Usually
The model is reviewed on history management supplied.Kubr
We pull history from bank, tax and registry data first, where the market provides them, and then read the model.Usually
Benchmarks are chosen by the reviewer and often unsourced.Kubr
Peer ranges come from named companies' filed financials, with the filing year.Usually
Findings arrive as comments in the margin of the model.Kubr
Each input gets a status and source rows. The model reruns on verified inputs.Records we examine
| Record | What we take from it |
|---|---|
| Bank data, with consent (the RBI Account Aggregator framework) | |
| Tax-return data, where the market provides it (with consent) | |
| Company registry filings (MCA21) | |
| Public employment records, where they exist | |
| Auditor's report disclosures in filed accounts | |
| Your model |
Some records need the company's consent. The report says which were pulled from source and which the company supplied.
In India
- What we pull here
- The company's model checked for arithmetic, and its history checked against GST returns, bank data and AOC-4 accounts.
- What is thinner here
- We test the model against records. We do not build or approve forecasts.
What it costs
Pick the size of the deal or exposure. The fee is fixed before work starts.
₹75,000
Above the top band the fee is quoted individually. Indicative base, in local currency, before tax. All services and what moves the fee
Shape the scope
Time horizon
Entities
Speed
The fee shown for your deal size is an indicative base. A longer look-back, more entities or a faster turn moves it. The quote fixes the number before work starts.
Questions
Will you tell us what the company is worth?
No. We test the inputs and rerun your model on verified numbers. The price and the decision stay with you.
What if the company won't consent?
The bank and tax tie-outs cannot run. We test against filed accounts and peers, and the assumption register records the refusal.
Do you change our model?
We work on a copy. Your formulas stay intact. We add a verified-inputs sheet and a register beside them.
Do you check the formulas?
Yes. Hard-codes in formula ranges, broken links, circular references, mixed units and a balance sheet that does not balance are logged with cell references. We log them and do not rebuild the model.
Often paired with
Start with one company.
We reply within one business day with scope, price and a date. Indicative prices in INR, before GST at 18%. Scope and price are fixed in the engagement letter.