The tools nobody sells

Finance software is good at the common ground: statements, consolidation, budgets, bank feeds, invoices, a cash forecast. It is rarely good at what makes one business different from the next. A commodity trader values its cargoes afloat in its own way. A fund manager follows liquidity across vehicles that no standard chart of accounts describes. A services firm wants next quarter's cash to follow its CRM pipeline, not last year's averages.

These needs are too specific for a vendor's roadmap and too small for an IT project, so they end up in spreadsheets. In the AFP's 2025 FP&A benchmarking survey, 96% of respondents said they use spreadsheets for planning [1]. The spreadsheet itself is rarely the problem. The copy of the data inside it is: exported, pasted, and out of date by the next close.

Writing the code is now the easy part

Assistants write software every day. When Anthropic first measured how Claude is used, 37.2% of the conversations it studied were computer and mathematical tasks, mostly software engineering [2]. Describe a report in a paragraph and an assistant will write the page.

What it will not write is the ground the page stands on. The same AFP survey shows where finance teams struggle: 61% of respondents named unreliable data as a challenge, and 60% said inaccessible data held them back [1]. A finance tool needs four things that no assistant brings with it:

Without them, a tool written by an assistant is a script on one person's laptop, or one more dashboard that nobody quite trusts.

What the Builder pass is

K-φ has three workspaces on one engine: FP&A, CASH and BUILD. FP&A and CASH are ours. BUILD is the one your team shapes: its menu and every page behind it.

The Builder pass is how you hand BUILD to an assistant. A builder on your account copies it in one click; it is a link. Paste it into Claude, Codex or Gemini CLI, and say what you need.

When the assistant opens the link, it gets a brief: the workspace it is building, the K-φ API it may call and with which rights, the design kit that makes every page look like the rest of K-φ, and the rules it has to follow. K-φ keeps the code and deploys it, so there is no repository, cloud account or token for anyone on your side to manage. A few minutes later the page is in BUILD, next to FP&A and CASH. The next change is one more message in the same chat.

Headless Stories, episode 2. A Builder pass, pasted into Claude.

Part of the platform, not a dashboard on the side

Two rules make the difference.

The first: figures come from the engine. A BUILD page shows what K-φ has computed (statements, bank positions, forecasts, covenant ratios), and the brief tells the assistant never to recompute a figure K-φ already gives. A number reads the same in FP&A, in CASH and in BUILD.

The second: a BUILD can write back. With an admin's approval, it may add its own lines to the cash forecast. Our first example does exactly that: it reads the Salesforce pipeline and writes the cash it expects from it into the forecast. Those lines appear in the Cash worksheet and in the forecast, tagged with the name of the BUILD that wrote them. A person can delete them but not edit them, and if the right is withdrawn they leave every forecast at once.

Every BUILD also starts with a Dashboard made from a catalogue of widgets: bank balances, cash low point, covenant panel, budget against actual, invoices due by week and more. Each card flips over to show the table behind it.

What a pass can do, and what it cannot

A pass is a credential, so it is narrow and short-lived by design.

And before any release of K-φ, automated tests try to reach one account's data with another account's credentials, function by function. A single success stops the release.

Why it matters

For a finance team, the tool that is specific to your business no longer needs a project. You describe it, you see it the same day inside the platform where your numbers already tie, and you keep refining it in the conversation that built it.

For whoever answers for controls, the questions that matter have answers: who built it, what it can read, what it wrote, and how to undo it.

And build versus buy stops being a choice between the two. Buy the common ground in one platform (statements, consolidation, bank feeds, invoices, the cash forecast), and build the part that makes your business different on top of it, on the same data and under the same rules.

The Salesforce pipeline is one example among many. A trader could put its cargo positions next to its bank balances and its facility. A fund manager could follow cash across vehicles with its own definition of what is available. A group could test its covenants the way each lender wrote them. Each of these mixes data K-φ already holds with inputs and logic that only that business has. That mix is what the Builder pass is for.