Written by: Peaky
Date: June 15th, 2026
If you have read the launch essay or the drift category piece, you know the problem. The financial plan is a static document. Reality is not. Finance refreshes in batches. Operations changes continuously. The gap between them is where surprises live, and most CFOs find out about those surprises weeks after they would have liked to.
This post is about the part that comes next. What does it actually look like to catch drift before it hits the numbers?
The short answer is that Peaky watches the drivers behind your financial plan in real time, and surfaces what is changing the moment it changes. The longer answer is worth walking through, because the mechanism is what makes the promise believable.
A financial plan is built on drivers. Pipeline conversion rates, headcount counts, churn percentages, vendor spend categories, pricing tiers. Each driver has a source of truth somewhere in your operational stack. The CRM holds pipeline. The HR system holds headcount. Stripe holds revenue and churn. The accounting system holds vendor spend. Peaky connects directly to those sources, maps each driver to its source data, and continuously compares the assumption your plan is using against the latest actual data. When the gap between assumption and reality exceeds a threshold, Peaky generates a signal. The signal includes the gap, the impact on your plan, and a recommended adjustment.
That is the whole product in one paragraph. The rest of this post is how each piece actually works.
Most planning tools take weeks to set up. Peaky takes a day. We designed it that way on purpose, because the cost of setup is the reason most teams never adopt the tool they bought.
The three steps are simple. Connect your integrations. Build your model. Lock the master plan.
Sync takes about ten minutes. Connect your accounting platform, your CRM, your HR system, your billing platform. Peaky pulls the data automatically.
Model takes about an hour with agents doing the work in the background. You describe your business model in plain English. The agents propose a driver structure, the formulas behind it, and the initial assumptions. You review and adjust. Most teams have a usable forecast running by lunch.
Align is ongoing. You assign owners to each driver. The CRO owns pipeline. The COO owns hiring velocity. The CMO owns CAC. When a driver drifts, the right person sees it before the variance shows up in the board pack.
We built Peaky as a set of specialised agents rather than a single monolithic AI. The reason is practical. Different jobs need different kinds of intelligence, and using one heavy model for everything makes the product slow and expensive. Routing tasks to the right agent makes the system both faster and more accurate.
ARTHUR
Maps your ledgers. He reads your accounting export, understands the chart of accounts, and aligns it to the structure your model needs. This is the work that historically took finance teams weeks of spreadsheet stitching.
TOMMY
Builds and maintains the driver-based forecast. He sets up the formulas, refreshes the inputs continuously, and keeps the model accurate as reality changes.
ADA
Turns the model into the three statements: P&L, balance sheet, cash flow. She does this automatically every time the model updates.
POLLY
Watches for drift. She compares assumptions against actuals, forecasts against closed periods, and the structure of the books against what the model already knows. When something is off, she generates a signal.
MICHAEL
Runs collaborative budgeting. He lets each department head own their budget inside Peaky while keeping the master model consistent.
There are more agents shipping. The naming convention is deliberate. Each one is a colleague, not a tool. They do the work in the background so the finance team can focus on the parts of the job that actually move the business forward.
A signal is the unit of communication between Peaky and your team. When drift is detected, Polly generates one. The signal includes four things.
First, the gap. Growth assumption was 15%, actuals show 8%. Or: forecast said 380K, actuals delivered 290K. The specific number that is no longer where it should be.
Second, the context. What is the assumption based on. Which driver does it feed. When was the last time it was true. What has changed since.
Third, the impact. A table showing how this single drift propagates through the rest of the plan. Revenue impact. Margin impact. Runway impact. Often this is the part that converts a vague concern into a specific decision.
Fourth, a recommended adjustment. Peaky proposes what the driver should be set to, given the historical trend. You can accept, adjust, or ignore. The signal is not an instruction. It is a prompt for a decision the team is already qualified to make.
A common question we get is: how much work does this require from finance.
The honest answer is that the initial setup requires real work. You have to describe your business model. You have to confirm the driver structure. You have to set the initial assumptions. None of this is hard, but none of it is automatic either.
After setup, the work changes shape. You no longer rebuild the model every quarter. You no longer chase exports across multiple systems. You no longer manually reconcile last quarter's actuals against last quarter's forecast. Peaky does those things continuously. What you do is review signals as they come in, decide which ones change the plan, and steer accordingly.
Most teams describe this as the first time their finance work has felt like steering rather than recovering.
Peaky is not a replacement for your accounting platform. It is not a CRM. It is not a BI tool. It connects to all of these and sits on top.
Think of Peaky as the layer that turns operational signals into financial decisions. The data still lives in the systems where it was created. Peaky reads it, understands it in the context of your financial plan, and surfaces what matters.
For technical teams, Peaky also exposes a public API and an MCP server. The model can be queried, updated, or extended programmatically. The plan becomes infrastructure, not a deliverable.
Most teams have their first drift signal surfaced within a day of connecting their first integration. Sometimes within an hour.
The signals are not always dramatic. The first one might be a small assumption drift on a single hiring date. It might be a churn rate that has crept up by half a point. It might be a new ledger account that needs to be classified.
What changes is that the signal arrives now, not next month. The conversation about what to do happens before the cost compounds. The plan stays current. The team stays in front of the business instead of catching up to it.
That is what continuous financial planning looks like in practice. It is also what we mean when we say financial infrastructure for scaling without surprises.
If you want to see it on your own data, you can start a trial at peaky.ai.
