# If Your P&L Lives in a Google Sheet, We Should Talk Source URL: https://blueprintdata.xyz/blog/pnl-lives-in-a-google-sheet Published: 2026-09-08 Author: Marco Porracin Site: Blueprintdata Tags: data platform, analytics engineering, Google Sheets, revenue, dbt, startups ## Summary A Google Sheet that makes the number close is a human process, not a source system. Here is how to tell when that shortcut has become the limit of your data platform. ## Article If your company's real P&L lives in a Google Sheet, we should probably talk. Not because this setup is absurd. For an early-stage company, it is often the right first step. The application already stores transactions. Finance still needs manual revenues, special-user lists, influencer payouts, daily KPI targets, and marketing spend adjustments. A spreadsheet is easy to share. A form is easy to fill. In an afternoon, someone can make the number close without introducing a warehouse, a modeling layer, or another system to operate. That is a good trade when the company is small and the close is still a conversation between a few people. The problem is that the temporary shortcut rarely stays temporary. More people start depending on the number. Product wants revenue by cohort. Operations wants today's target against yesterday's actuals. Marketing wants spend next to conversion. Dashboards only reconcile when someone updates the form. The sheet quietly becomes the company's source of truth for money. It was never designed to be one. A Spreadsheet Solves the Wrong Accounting Problem A Google Sheet is a good place for a human process. It is a poor place for a source system. The application database has transactions. Finance has the sheet that "makes the number close." Those are different jobs. One records what the product did. The other applies judgment, exceptions, and adjustments that never made it into the application. The sheet usually exists because the product cannot yet express the business: - Some revenue is booked offline or after the fact. - Some users are excluded from reported totals. - Some payouts are negotiated, not calculated. - Some daily targets are set by a person, not a model. - Some marketing spend arrives as a form reply. Those exceptions are real. A dashboard that ignores them is wrong. A dashboard that depends on a file with no contract is fragile. The sheet is not a source system. It is a human process wearing a CSV. The First Cracks Usually Appear at Close Dashboards are often where teams notice the problem, but the dashboard is not the problem. When revenue is invented in a sheet and displayed from a warehouse, the two only agree if a person updated the form before the pipeline ran. If the job started at 7:00 and the form was submitted at 7:12, the warehouse is "wrong" until tomorrow. Finance knows the number. The dashboard does not. Then two people edit categories. One treats a refund as contra-revenue. The other treats it as an adjustment. Both are looking at the same tab. Neither has a review step. The number still closes, just not to a definition anyone can point to. "Special users" live only in a tab. Product cannot join them. Analytics cannot test them. If someone deletes a row, the exclusion disappears. If someone edits a payout, yesterday's report cannot be reproduced. Google Sheets version history helps a person recover a file. It does not give you a typed, queryable, tested record of what the business believed on a given day. Marketing spend as a form reply has the same shape. It is convenient until someone asks why last Tuesday's CAC moved. The usual answer: a cell changed, a reply arrived late, or two campaigns were merged in a comment. This is not a Google Sheets failure. It is a missing definition of revenue. What the Sheet Cannot Give You Application systems record events. The sheet records a judgment about those events. If revenue is a column someone typed, the company cannot explain how it was produced. If revenue is a join and a definition, it can. Charges in the app, payouts in a processor, refunds in a support tool, and a short list of exceptions finance reviews each week can all be ingested. The exceptions can stay human. The definition should not live in a cell. Each tab is locally reasonable: accounts to exclude, manual invoices, spend that never landed in an ad platform. Together they become the unofficial revenue model. The sheet cannot tell you who changed a category, when a special user was added, or whether yesterday's close used the same rules as today's. It cannot enforce a grain. It cannot fail a test when a total no longer ties to the source. It cannot be reviewed in a pull request. Spreadsheets are also a weak integration layer. Teams export a tab, upload it to the warehouse, and hope the column names did not change. When they do, the pipeline still runs. The number just silently shifts. A warehouse gives the team a place to ingest operational sources, model shared definitions, keep a documented input for genuine judgment, and point BI at marts instead of a live sheet. This is the same stage as another common shortcut: connecting Metabase to a read replica (/blog/metabase-connected-to-read-replica). The replica copies the application. The sheet invents the number the application never stored. Same stage. Different limit. How to Know You Have Outgrown the Shortcut You should start planning the transition when several of these are true: - The warehouse and the sheet disagree because the pipeline ran before today's form. - Two people can edit the same revenue category without a review. - "Special users," exclusions, or payouts live only in a tab. - Deletes and edits in the sheet have no history the rest of the stack can use. - Marketing spend, targets, or adjustments arrive as a form reply. - Dashboards only reconcile after someone remembers to update a cell. One of these can be manageable. Several are evidence that revenue needs a definition, not another tab. The Migration Can Be Small The alternative does not need to be a finance-system replacement. For many growing companies, the first useful version is straightforward: - Ingest the operational sources that already exist: application transactions, processors, ads platforms, and any other system that already records money or spend. - Model revenue in dbt as a join and a definition, not as a column copied from a sheet. - Treat any remaining sheet as a documented, versioned input with a contract: expected columns, grain, owner, and refresh rule. It is an input, not the system of record. - Point BI at the resulting marts, not at the live spreadsheet. - Validate the new results against the current close, then migrate incrementally. Sheets can stay for genuine human judgment. A reviewer still needs a place to mark an exception, set a target, or record a one-off adjustment. That input should be small, owned, and logged. It should not be where revenue is invented. Cloud warehouses such as BigQuery and Snowflake can start small. Open tools such as Meltano and dbt keep the implementation visible and portable. The scope can begin with transactions, one payments source, and the handful of exceptions finance already reviews. A useful foundation can often be delivered in a few weeks to a couple of months. A Good First Step, Not a Final Architecture Keeping the real P&L in a Google Sheet is not a mistake. The mistake is waiting for the sheet and the warehouse to disagree before acknowledging that the company has outgrown it. If this setup sounds familiar, talk with Blueprintdata (/#contact). We can identify the smallest useful migration and build a cheap, scalable foundation your team can own.