Somebody Has Shipped an "Agentic CFO". Read the Product Scope as a Map of What the Market Thinks Your Job Decomposes Into.
Somebody Has Shipped an "Agentic CFO". Read the Product Scope as a Map of What the Market Thinks Your Job Decomposes Into.
Not a review. A sorting exercise you can run on any of these products, and one worth running on your own function.
On 10 September a US startup relaunched itself around an AI agent it describes as a chief financial officer for founders and owner-operators. It connects to a company's financial systems, maintains a live model of the business, and — this is the part that distinguishes it from a chatbot — monitors continuously and raises things unprompted rather than waiting to be asked.
I am not going to review it. I have not used it, it is built for US venture-backed startups rather than Australian care providers, and by the time this argument matters the specific company may not exist. Product reviews age badly and this blog is not the place for them.
What is genuinely useful is the feature list itself, treated as evidence. A team that has been building in this space since 2020 had to decide what to build and what to leave out. That scope is one of the more honest signals available of which parts of a finance function the market currently believes can be automated — arguably more honest than a vendor's claims about the future or a consultancy's forecast, because a shipped product is a set of bets somebody had to fund.
So here is the exercise. It takes about forty minutes and you can run it on any product in this category, including the one your accounting platform will announce next quarter.
The test: two columns, one hard question
Write out every capability the product claims, in its own words, one per line. Then sort each line into one of two columns.
Column A — this is genuinely a procedure. The steps are the same every time. Given the same inputs, a competent person would produce the same output. The rules are written down somewhere, or could be.
Column B — this requires a judgement the product cannot see the inputs for. Not "a judgement," note. A judgement whose inputs are not in any system the product connects to.
That qualifier is the whole test, and it is where most analysis of this topic goes wrong. The question is never whether a task is hard, or whether it feels like it requires expertise. The question is whether the information needed to do it correctly exists in the data the tool can reach.
|
Column A
Same inputs, same output, rules writable. This is where automation is arriving now, and where it will keep arriving whether you plan for it or not.
|
Column B
The deciding input lives in a conversation, a funding agreement, a relationship, or a determination — not in the ledger. Better models alone do not close this; getting the information into a system the tool can reach might.
|
Running it on the typical scope
Products in this category converge on much the same capability set. Sorted:
Clearly Column A. Pulling and normalising data from accounting, banking and payroll systems. Keeping a model refreshed as new transactions land. Recomputing a runway or a cash position when an input changes. Producing a variance list against budget. Assembling a recurring report to a fixed template. Flagging that a figure has moved beyond a threshold somebody set.
That list is not trivial work. It is most of what junior and intermediate finance people spend their week on, and in a small organisation it is a large share of what the finance function visibly produces. Nobody should feel comforted by the fact that it is "only" procedure.
Clearly Column B. Whether a flagged variance matters. Which of two plausible explanations is the real one. Whether a funding stream will renew. Whether the right response to a tight runway is to cut, to delay, or to go and ask. What your board will actually accept in a paper. Whether a number looks wrong because the business changed or because someone coded a journal badly.
Look at what those have in common. Every one of them depends on information that, in most organisations today, has never been entered into a system: what the funder said on a call, how the last board conversation went, which manager is reliable about accruals, whether the contract that ends in March is really ending.
The uncomfortable middle
You will find several lines that refuse to sort, and they are the informative ones.
Forecasting is the clearest. Rolling a model forward mechanically is Column A. Deciding what the forecast should assume is Column B. Products in this space tend to market the whole thing as one capability. My own view is that current models handle accounting and reporting reasonably well but still struggle with forecasting — precisely because the forecast's assumptions are the Column B half.
Anomaly detection splits the same way. Finding the outlier is Column A. Knowing that this particular outlier is the third month in a row a specific service has underclaimed, and that the cause is a rostering change nobody told finance about, is Column B.
The pattern is that a task which looks like one thing is usually two: a mechanical step, and a framing decision that determines whether the mechanical step produces anything useful. Automation takes the first half cleanly. The marketing describes both halves. The gap between those two facts is where disappointed implementations come from.
Why Column B is bigger in our sectors than in the products' home market
This is the part that does not transfer, and it is the reason a scope designed for a US software startup should not be read as a description of your job.
An NDIS provider's revenue depends on plan types, claim timing, participant plan renewals, and price limits set by a body that does not consult your ledger. An NFP's position depends on grant conditions, acquittal timing and restricted-fund rules that live in agreements, not in the accounting system. An aged care provider's cost base moves on determinations from an industrial tribunal. A childcare operator's fee revenue is bounded by a cap set in policy.
None of that is in the data. Which means for a provider in these sectors, the proportion of the finance role that a tool connected to your ledger, bank and payroll can actually own is smaller than for a software business with three revenue lines and no funders. That is not a reason to dismiss the tools. It is a reason to be precise about which column you are buying.
What to do with your two columns
Column A is your automation shortlist, in priority order by hours. Not by how impressive the task sounds — by how many hours a week your team spends on it. The most automatable work is usually the least interesting to talk about, which is why it survives so long.
Column B is your job description. If your finance function's output is mostly Column A, that is a strategic finding and it is worth knowing now rather than in three years. It is also the honest answer to the board member who asks whether AI will replace the finance team: it will take Column A, and whether that matters depends entirely on how much Column B your function currently does.
The middle column is your specification. Those are the places where you want a tool to do the mechanical half and hand you the framing decision, and where a product that claims to do both should be treated with more scepticism than one that admits the split.
The exercise costs you an afternoon and it does not require buying anything. Do it on the next product announcement that lands in your inbox — there will be one within a month — and you will get more out of the announcement than the vendor intended.
Which column is most of your finance function in?
It is an uncomfortable question and a useful one, and it is easier to answer with someone who has seen a lot of finance functions. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — including working out which parts of the work should be automated and which should not.
Talk to PFL →
Comments
Post a Comment