The FP&A reporting workflow is fragmenting.

Still the most common setup, especially at companies with over 100 employees. Production data in a cloud data warehouse (Snowflake, BigQuery etc.) and someone writes SQL to pull what is needed. Results land in Google Sheets or Excel, get modeled and formatted, then turned into a report. That report might be a Google Slides deck, a PowerPoint, or increasingly just a well-structured document.

Flexibility is the big strength here. Every component is swappable. But that is also the downside: more steps, more software, more potential bottlenecks. And if your report ends up in Google Slides, you will hit a wall with the native charting pretty quickly. No waterfall charts, no mekko, limited formatting control. Chartbuddy can help there.

A common variation swaps manual SQL for Alteryx or a similar ETL tool. Same structure, but data extraction is scheduled rather than manual. Makes sense for fixed reporting cadences, though the tradeoff is cost and rigidity.

This is the one we have the strongest opinion on.

BI dashboards became the default handoff between data teams and finance teams for a good reason: finance teams could not pull their own data. SQL was a specialised skill. You needed someone technical to write queries, maintain data models, and put a visualization layer on top so finance could interact with the output.

That assumption is eroding fast. LLMs write SQL. Natural language interfaces let finance professionals query warehouses directly. Every quarter, the skill gap that justified the dashboarding layer gets a little smaller.

And the dashboard creates a real problem for reporting. Power BI charts look like Power BI charts: fonts sized for a browser, colors that clash with your deck, legends that do not fit. Looker has the same issue. Someone screenshots the dashboard, pastes it into a report, spends time per chart making it presentable. Or rebuilds from scratch.

Look, BI tools are excellent for monitoring and ad-hoc exploration. As a mandatory pass-through in the reporting pipeline though? In practice it often creates extra work: the export, the formatting etc. We believe this pattern's best days are behind it. Finance teams that can query their own data are starting to skip it, and their workflows are faster for it.

Teams on Pigment, Anaplan, or Adaptive follow a different starting point. The planning tool handles budgets, forecasts, scenarios, headcount. It is the system of record for forward-looking financials.

These tools do not float in isolation from the warehouse either. Pigment connects directly to Snowflake or BigQuery. You can SQL inside Pigment to pull in actuals, then model on top of them. The warehouse is still there, just abstracted away.

It is a powerful setup. Consolidates a lot of what would otherwise require separate tools and separate people into one platform. Fewer software licenses, fewer profiles involved, tighter feedback loops between planning and actuals.

The frustrating part is the last mile. The analysis is done. The outcomes are clear. The charts exist inside the platform. And then you spend a disproportionate amount of time getting those charts into a report format, because they just do not export cleanly. You are rebuilding work that has already been done, in a different tool.

Chartbuddy can help when the report is in Google Slides. Though honestly, for internal reporting and decision-making, the dashboards inside these planning tools are often presentation-ready enough on their own. The export problem really bites when you need external-facing output: board decks, investor updates, that kind of thing.

Less a workflow, more a behaviour pattern. Describe what you need in plain English to an LLM. "Monthly ARR by segment, stacked bar, last 8 quarters." It writes a Python script that queries your warehouse and renders a chart. Paste the output wherever.

We love this one. Especially for smaller teams and fast decision-making. Speed advantage is real and the barrier to entry is basically zero.

Repeatability is the weakness though. Outputs are non-deterministic, chart styling varies across runs, there is no version control. Fine when it is a one-off. But the moment you find yourself doing the same analysis a second or third time, it is a sign to migrate it into one of the more robust workflows above. Use the quick & dirty to explore. Use something else to report.

What makes this interesting beyond the ad-hoc use case: it is training finance professionals to interact with data directly. People who would never have opened a SQL editor are pulling data through natural language. That shift is reshaping every other workflow on this list. It already is.

Not a separate workflow. Just a different destination for the same data.

Take the quantitative output from any of the flows above (a scheduled SQL output, an export from Pigment, an ad-hoc query) and combine it with qualitative context from Notion, Google Docs, meeting notes etc. Feed both into an LLM. Get back a concise, structured document for decision-making.

There is a version of the future where this replaces the slide deck entirely. Jeff Bezos banned PowerPoint at Amazon years ago in favor of written memos, and that approach is spreading. A well-structured document with embedded data points forces clearer thinking than 40 slides ever will. And with LLMs handling the drafting, the time from "data is ready" to "report is ready" is collapsing.

We are genuinely not sure yet how far this goes. But we would not bet against it. That would not be good for Chartbuddy, but you win some, you lose some.