पाठशाला Pathshala · संचालन Sanchālan, Operations · Lesson 16 · Build

The first data warehouse and the single source of truth

Three teams report three revenue numbers because three systems count three different things. A warehouse, a semantic layer that defines each metric once and a named owner for every number end the argument.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Empty metal storage racks in rows across a large industrial warehouse. — Photograph: Adrien Olichon · Pexels

In the board meeting the head of sales says revenue was ₹27 lakh in September. The product lead’s dashboard says ₹15.5 lakh. Finance, a week later, says ₹15.9 lakh. Nobody is lying and nobody made an error. Three systems counted three different things and called each of them revenue.

This lesson explains why the numbers diverge, when a company needs its first data warehouse, the smallest stack that works, the semantic layer that defines each metric once, the ownership that keeps it honest, and a monthly tie-out to the ledger. It assumes the company already [closes its books monthly](/library/monthly-close-and-mis-report).

Why three teams report three numbers

Each team reads the system it works in, and each system answers a different question. The CRM records contracts signed, so sales reports bookings: the value of a deal on the day it closes, whether it starts next month or runs for three years. The billing system records subscriptions that are live, so product and growth teams report monthly recurring revenue. The ledger records revenue as the service is delivered, net of GST, refunds and credit notes, so finance reports recognised revenue. The bank records money that arrived. Andreessen Horowitz’s 16 Startup Metrics warns against the commonest confusion: bookings are the value of a contract, revenue is recognised when the service is provided or ratably over the life of the subscription.

Beneath the definitions sit smaller differences that cause just as many arguments. One system includes GST and another does not. One counts a plan on the day it is created, another on the day it starts. One converts dollar invoices at the invoice date, another at the payment date. A failed card payment is still a live subscription in one system and a cancelled one in another. A refund issued this month for last month’s invoice lands in different months in different places. None of these is a mistake. Together they ensure that any two dashboards built independently will disagree.

Click through the four teams. The sales number is the largest because it counts a ₹24 lakh annual contract that has not started. The product number leaves out a one-time implementation fee. The finance number takes off a credit note for August. The cash number is short because some September invoices are still unpaid. Each is useful. The trouble begins only when all four are called revenue.

When a company needs its first warehouse

The warehouse is not a scale problem; it is a trust problem, and it arrives earlier than founders expect. The signals: the same metric is quoted with two values in a meeting more than once a month; the [weekly metrics page](/library/weekly-metrics-review-one-page-one-hour) takes someone half a day to assemble by copying from five tools; analysts or founders are running queries against the production database; or a priced round is coming and investors will ask for cohorts and revenue by customer for every month since launch. Any two of these and the company should build the warehouse this quarter. A company of thirty people with four or five source systems is not too small.

The smallest stack that works

Andreessen Horowitz’s survey of modern data infrastructure describes a blueprint for business intelligence built on data replication, a cloud data warehouse and SQL-based modelling, and calls the replication-plus-transformation combination nearly ubiquitous. For a first warehouse that means four layers. Ingestion: managed connectors or small scheduled scripts that copy the CRM, the billing system, the payment gateway, the ledger, the product database and the support desk into the warehouse daily. Storage: a cloud warehouse; BigQuery, for example, does not charge for the first 1 TiB of queries or the first 10 GiB of storage each month, which covers many companies’ first year. Transformation: SQL models, kept in version control and reviewed like code, that turn raw tables into clean ones: customers, subscriptions, invoices, payments. Presentation: one BI tool that every team uses.

Model five tables first and nothing else until they are trusted: customers, subscriptions, invoices, payments and the one product event that defines an active customer. Keep the raw copies exactly as they arrived and build every clean table from them in code, so that any number can be traced back to the source row that produced it. Write tests alongside the models: every customer has one identifier across systems, no invoice is counted twice, totals by month match the source system’s own report. When a test fails, the dashboard waits. A small warehouse that is right is worth more than a large one that is usually right, because the first time a board member finds an error the company is back to arguing about whose number to believe.

Two cautions. Copy only the personal data the analysis needs and mask the rest; the [DPDP Act lesson](/library/dpdp-act-what-it-requires-of-your-product) sets out what the law expects of data a company holds. And resist the urge to build a platform: the first warehouse should be one engineer’s or analyst’s project for a month, not a team’s for a year.

The semantic layer: one definition, every dashboard

A warehouse with clean tables still produces three revenue numbers if each dashboard computes revenue its own way. The semantic layer is the fix. The a16z survey defines the metrics layer as a system providing a standard set of definitions on top of the data warehouse. In dbt’s Semantic Layer documentation the argument is put directly: moving metric definitions out of the BI layer and into the modelling layer lets data teams feel confident that different business units are working from the same metric definitions, and when a definition changes it is refreshed everywhere it is used.

Rows of wooden card catalogue drawers in a library. — A catalogue gives every book one entry and one place. A semantic layer does the same for every metric. Photograph: Vadim Koza · Pexels

In practice, write each metric once, in code, with its plain-language definition beside it: bookings, monthly recurring revenue, recognised revenue, cash collected, active customer, churned customer, net revenue retention. Every dashboard, spreadsheet export and investor report reads from those definitions and computes nothing of its own. The company still has four numbers for September. It now has four names for them, one definition each, and one agreed answer to the question “what was revenue?”: recognised revenue, as finance reports it.

A single source of truth is not one number. It is one definition for each number, and one person who answers for it.

Ownership: who answers for each number

Tools do not end arguments; owners do. Give every metric in the semantic layer a metric owner, the leader who answers for its value and approves any change to its definition: finance for revenue and cash, sales for bookings and pipeline, product for activation and retention. Give every source system a data owner who answers for the quality of what it sends: if the CRM has deals without close dates, sales fixes them, not the analyst. Keep a definitions page that anyone in the company can read and a change log with dated entries. And make one rule absolute: once the books close, recognised revenue in the warehouse must equal revenue in the ledger, line for line, with any difference explained in writing.

A worked first warehouse

An illustrative Hyderabad software company of forty people has the September problem every month. In October its one data analyst connects the CRM, the billing system, the gateway, the accounting software and a read replica of the product database to a cloud warehouse. In November she writes SQL models for customers, subscriptions, invoices and payments, and defines seven metrics in the semantic layer with the finance lead, the sales lead and the head of product in one meeting. In December every dashboard is rebuilt to read those definitions, and the old ones are switched off on a published date. The first tie-out finds a ₹1.8 lakh gap between warehouse and ledger revenue for November: credit notes raised in the accounting software that never reached the billing system. The fix is a process change, not a query. By the January board meeting the deck has one revenue number, with bookings and cash shown beside it under their own names.

The monthly tie-out

On the day after the books close, the analyst runs the tie-out and sends a short note to the finance lead. Recognised revenue in the warehouse against revenue in the ledger, by line and by customer, with every difference above a set floor explained. Cash collected against the bank statement. Customer counts against the billing system. Any definition changed this month, with the reason and the restated history. If the tie-out is clean for three months running, the warehouse has earned the right to be called the source of truth. If it is not, it has not, whatever the dashboards look like.

The companies and figures in this lesson are illustrative. Product names and free allowances are stated as checked on 11 October 2026 and change; nothing here is an endorsement of a vendor.