I spend my days in the weeds of finance and FP&A by building the models and running deal scenarios across a portfolio of investments, and I’ve spent the last year automating that work with AI. I think the ‘think piece’ stories that talk about spreadsheets disappearing have it backwards. Tools like Claude in Excel make the spreadsheet itself several times faster to build and maintain. That makes the case for replacing it weaker, not stronger.

Here’s why.

The premise everyone gets wrong

The replacement narrative assumes Excel has only stuck around because nothing better existed. Now that AI native platforms can ingest your data and generate the output directly, why would anyone still build things cell by cell?

But the fact that better technology exists doesn’t mean your organization can use it today, and most finance teams are stuck in that gap.

For some workflows, an AI native platform is a perfectly reasonable end destination. But getting there means solving a much less exciting problem first: getting your underlying data into a state where a platform like that can function at all. That’s a data infrastructure problem, and those take years to solve, not product cycles.

Until that’s solved, the AI native platform doesn’t have clean rails to run on. The real question isn’t whether the new platform is smarter than Excel. It’s whether it can work with what you actually have. For a lot of us, the answer is “not yet.” Excel, with AI working inside it, can.

Customizability

Anyone who’s actually built financial models for a living knows this in their bones: every stakeholder wants the same underlying information, sliced a little differently. Investors want it framed one way, the lender another, internal IC a third. Sometimes even different investors and lenders want the same information shown slightly differently, through different lenses.

Excel’s real superpower is so basic it’s almost invisible - reshaping output for a new lens doesn’t mean rebuilding anything. Change a formula and adjust a filter, and the same underlying data tells a different, equally accurate story in minutes.

A software engineer (or even a finance professional like me) working with Claude today can build a genuinely good tailored reporting tool or a dashboard quickly. That part of the AI story is true.

But being able to build something quickly isn’t the same as being able to rely on it, and in finance, the gap between those two comes down to two things.

First, there’s no deployment cycle in Excel, and there is one for everything else. Even a custom tool that takes an afternoon to build still has to clear review, testing, and sign off before anyone downstream is allowed to depend on its numbers, and that’s appropriate given it’s feeding investment decisions or external reporting. In Excel, when a stakeholder asks for the same information sliced differently, you change a formula or rebuild a view in minutes and it’s usable immediately. When a deal is moving fast, minutes versus a multi-day review cycle is the difference that matters.

Second, the audit trail in Excel is native, and the trust in it is already established. Auditors and regulators have spent decades learning to trace a number back through formulas and cell references; that’s how they verify things. A custom coded tool can be just as accurate and just as well documented, but the institutional habit of trusting it the way you’d trust a traceable formula chain doesn’t exist yet. That kind of trust gets built up over time, through repetition, through every audit season where the trail held up. Excel already has that. Nothing else in finance does, at scale. Admittedly, this edge has a shelf life. As AI native tools mature and auditors build new habits, this gap will narrow.

What This Looks Like in Practice

I ran into a good example of this during a recent fundraise. We got a due diligence questionnaire (DDQ) asking for a long list of financial metrics, and we didn’t have more than half of them sitting ready made anywhere. What we did have was base level data, built out in Excel, across our whole portfolio. Using Claude in Excel, I built one sample model that applied the requested logic to a single example, then had it apply that exact same logic across the rest of the portfolio. The full set of metrics came out the other end, not because we found new data, but because the data we already had got reshaped into the form the question was actually asking for.

By hand, with the nested formulas and macros that would’ve required, that’s a four week job. With Claude in Excel doing the reshaping, it took a fraction of that.

It’s worth being precise about what actually made that possible. Excel didn’t get smarter. I had a tool that could apply a defined piece of logic across a large, already existing, already transparent dataset instantly, without setting up a pipeline or getting some new platform approved and onboarded. The data was sitting there in a flexible format the whole time. AI removed the friction of propagating logic across it by hand.

This shows up in smaller ways constantly too, like when you’re trying to win over a specific investor and need to show them terms tailored to their situation instead of generic fund level numbers. That used to be a slow, manual slog: pull that investor’s data, run scenario after scenario by hand, adjust assumptions, eventually land on something defensible. Now I can rework investor level data and run that scenario analysis fast enough to test more combinations of terms and assumptions than I used to be able to try in the time it took to build one. Same story as the DDQ. The data and the logic were already there. What changed was how fast I could reshape and rerun it.

Stage 1 vs. Stage 2

Most arguments for AI replacing Excel are really about what the ideal end state for financial data infrastructure looks like. They then quietly assume that whatever’s ideal in that end state is also the best tool for the data a company actually has right now. But those are two different problems. Here’s the framework I use.

Stage 2 is the AI native end state, where data is fully centralized and accessible to software that can reason over it directly, no spreadsheet layer required. It’s a genuinely good destination. I’m not skeptical of it as a goal. I’m skeptical of how close most organizations actually are to it.

Stage 1 is where most finance organizations actually live: data spread across systems that don’t talk to each other, historical records in formats that predate any current data strategy, the same metric defined slightly differently by different teams, a patchwork that took a decade to build and will take real money, time, and organizational will to unwind. Getting from Stage 1 to Stage 2 isn’t a software purchase. It’s a multi year transformation project, and most finance leaders I talk to know that, even if it’s not the version of the story you hear in vendor pitches.

Excel plus AI is what you reach for while you’re still in Stage 1, because it works on the data you have, in the format it’s already in, today. No migration, no six month integration project. You point the AI model (i.e. Claude) at the spreadsheet you’ve already got and it goes to work. For most companies, given where their data actually sits, it’s the only approach compatible with reality right now.

Where this leaves us

For most of finance, over the next several years, the dominant working model is going to be Excel plus AI, because it already matches the shape of the data we actually have and the trusted infrastructure we’ve already built around it. Full migration to AI native platforms is coming for parts of the industry. But it’s a second order shift, gated by a data maturity problem that no amount of model intelligence solves on its own.

However smart the model gets, it still has to sit on top of real data. Right now, for most of us, that’s still a spreadsheet, just one that finally moves at the speed the work actually requires.

It almost never comes down to the sale price on its own. It comes down to a few words they agreed to years earlier and never looked at again, the ones sitting in the term sheet under headings most people skim past. So here’s what those words mean, and why they decide who walks away with money.

Two kinds of shares

Start with who owns what. The cap table, short for capitalization table, is just the list of who owns a piece of the company and what kind of piece they hold. There are two main kinds, and the gap between them is the whole story.

Common stock is what founders and employees hold. Plain ownership, no special treatment when the company sells.

Preferred stock is what investors get for their money. It’s “preferred” because it carries rights that put investors ahead of common when it counts, and the moment it counts most is a sale. Each round (Series A, Series B, and on up) usually creates its own class of preferred with its own terms.

The waterfall: the line everyone stands in

When a company sells, the money doesn’t get divided by who owns what percentage. It gets paid out in a set order, written into the company’s charter. Picture a line where each person has to be paid in full before the next one sees a dollar. People call that order the waterfall.

The investors stand at the front. What they collect first is their liquidation preference, the promise that in a sale they get their money back before the common sees a cent. The base amount is usually what they paid per share when they invested, the original issue price, times the shares they hold.

Preference multiples and participation

Two terms set how big that first claim gets.

The preference multiple is how many times their money they take off the top. At 1x, they get their money back once before common gets anything. At 2x, they take twice their money first, which is far more aggressive and leaves far less behind them.

Then there’s participating versus non-participating, which is really about one bite or two. Non-participating means the investor chooses the better of two outcomes: either they take their liquidation preference, usually their money back first, or they convert into common and take their normal ownership share of the proceeds. It is one or the other, not both. Participating means the investor gets the preference first, and then also shares in whatever is left, as if they had converted to common. So they get downside protection and extra upside. If you’re a founder, you generally want non-participating preferred. Participating preferred can stack the deck against the common shareholders because the investor gets paid first and then still participates in the remaining value.

One more wrinkle, the pecking order among the investors themselves. Sometimes every preferred round ranks equally and they share at the same level. (Lawyers call that pari passu.) Sometimes the later rounds are senior, meaning they get paid ahead of the earlier ones. When there isn’t enough to go around, that order decides who collects.

Why common can end up with nothing

Now the part that surprises people. Add up every investor’s preference across all the rounds. That sum is the bar a sale has to clear before common gets anything. Sell above it, and common gets a piece of the extra. Sell below it, and the investors take everything there is, sometimes without even being made whole, and common gets zero.

Put numbers on it. Say investors have put $20 million in across a few rounds, all with a 1x preference. The company sells for $15 million. The investors take the full $15 million and are still $5 million short of whole. The founders and the whole employee option pool walk with nothing.

That’s how a sale can repay investors only partway and still leave the people who built the company empty-handed. The preferred come first. The cash runs out before it ever reaches the back of the line.

Why the big valuation doesn’t save you

Founders tend to assume a company once valued at a big number will pay out like one.

It won’t, not on its own.

Valuations come in two versions. Pre-money is what the company is judged to be worth before new money goes in. Post-money is that plus the new money. Both are just what someone was willing to pay for a small piece while things were heading up. Neither is the price the company sells for later, and neither changes the order of that line. You can have a sky-high old valuation and a low sale price sitting right next to each other, and only the sale price fills the waterfall.

You’ll also bump into fully diluted shares, the count you’d get if every option and warrant that could become a share did. It’s useful for working out ownership percentages. But in a sale, only the pieces worth cashing in get paid.

Options and warrants

Two more line items sit on almost every cap table.

An option is the right an employee has to buy shares later at a fixed price, the strike. A warrant is the same basic idea, usually held by an investor or a lender instead of an employee. Neither is a share. It’s a right to buy one.

When the sale price is high, holders exercise: they pay the strike and turn the right into shares worth more than they paid. When the price is low, the strike can sit above what a share is even worth, and there’s a name for that: out of the money, or underwater. Nobody pays more for something than it’s worth, so those options and warrants just lapse, worth nothing. In a small sale where common already gets zero, they’re dead on arrival.

How the sale is built matters too

The shape of the deal changes both who gets paid and how hard the tax hits. Three shapes come up most.

A share deal, or stock purchase, is the straightforward one: the buyer buys the shares directly from the shareholders. The owners are the sellers, they’re paid directly, and the buyer takes the whole company, problems included.

A merger combines two companies, and the owners of the one being bought get cash or the buyer’s stock for their shares. Again, the owners are paid fairly directly.

An asset deal is the different one. The buyer buys specific things the company owns, say the code and the customer contracts, and leaves the company itself behind. Buyers go this way when they want the good parts but not the liabilities, the lawsuits, or some subsidiary they have no use for. The catch for shareholders: the buyer pays the company, not them. To get anything, the company then has to wind down: shut itself down and hand out whatever’s left. And that hand-out runs back through the same waterfall.

Any of these usually counts as a deemed liquidation event in the charter, which is just the trigger that switches the liquidation preferences on. And here’s a detail that catches founders off guard: the preferred often control whether a sale can happen at all. Their sign-off is usually required, so the structure may not be the founder’s to choose.

The asset route carries a tax sting worth knowing about. It can get taxed twice, once at the company on any gain, and again at the shareholders when the company pays out what’s left. A company that’s piled up losses over the years carries them as net operating losses, which it can use to soak up much of that first layer. Even so, two layers is why an asset deal tends to be cleaner for the buyer and more expensive by the time the money reaches the seller.

When the buyer pays in its own stock

Sometimes the price isn’t all cash. Part of it, or all of it, can be the buyer’s own stock, which raises a question nobody enjoys asking: what’s that stock really worth?

If the buyer prices its shares off some old number, like its last funding round a couple of years back, that price is probably stale, especially if the business has grown since. Hand over stock at a price below what it’s truly worth, and a tax authority can treat it as a discount, with the gap counted as extra income to whoever got the shares. That’s a big reason companies pay for a 409A valuation, an outside appraisal of what the shares are worth, so the number they use holds up. The fix is dull but it works, and it’s the one I’d insist on: get a fresh valuation close to the deal instead of dusting off an old one.

Two more terms tend to hide in the fine print. Change of control provisions kick in when the company is sold, and can do things like speed up someone’s options or warrants. Anti-dilution provisions raise an investor’s share count if the company later sells shares cheaper than they paid. Either one can move the math, so read them before the sale, not after.

The safety nets

If all of this sounds bleak for founders and staff, two things usually take the edge off.

A management carve-out is a chunk of the proceeds the board sets aside for founders and key people regardless of what the waterfall says, so the ones who built the thing don’t leave with nothing in a deal that only repays investors. Retention equity is fresh stock or options the buyer grants to the people it wants to keep, separate from the purchase price. Both exist for one reason: left to itself, the default math can wipe the team out.

So what should you do

You don’t need a law degree. You need to know four things, and you need to know them before you take the money, not when a buyer shows up. Your preference multiple. Whether your preferred is participating. Whether later rounds outrank earlier ones. And what all those preferences add up to, because that total is the number a sale has to beat before you see a dime.

Then do the depressing exercise: model the sale where you go out for less than you raised, and look at where common lands. Run it before you sign a term sheet, and update it after every round. The chart is no fun. It’s also the only honest picture of what your equity is worth if things go south.

The terms you sign when you raise are the same ones that decide who gets paid when you sell. Most founders read them properly for the first time while the sale is already underway. Read them sooner.

Subscribe now

Basis is one company in a sudden and well-financed rebuild of the software that runs corporate finance. The plumbing of accounting, the ledgers and approval queues and reconciliation spreadsheets that almost no one outside the function ever sees, has become one of the most active corners of enterprise technology. The reason is scarcity.

Roughly 300,000 accountants have left the profession in the United States since 2020, by the estimate of the practice-management vendor IRIS, and about three-quarters of certified public accountants are near retirement age. Firms cannot hire fast enough to replace them. In Accounting Today’s annual survey of the field, recruiting and retention ranked as the top concern for large firms, and burnout was close behind. The shortage created a problem that headcount could no longer solve, and it arrived at the same moment that a new generation of software learned to do the work.

The shape of the stack

Finance teams run on a layered set of tools that follows money through a company. At the base sits the general ledger, the system of record, still dominated by Intuit’s QuickBooks at the small end and by Oracle NetSuite and Sage Intacct in the middle market. Above it sit the specialized layers: accounts payable and spend, accounts receivable and billing, tax, the monthly close, audit and controls, treasury, and, for the firms that sell accounting as a service, practice management.

The now holds several hundred distinct accounting and finance tools, and a clear majority of them advertise some form of artificial intelligence. A few years ago that claim would have meant a chatbot bolted onto an old product. Today it increasingly means something that acts. A January report from Deloitte found that 63 percent of finance organizations had fully deployed AI in their operations, and that close to half of chief financial officers had folded AI agents into parts of the function such as forecasting and expense management.

Subscribe now

Ramp, the spend-management company, was valued at roughly $44 billion last month. BILL, which runs the payments rail beneath much of small-business accounts payable, says the share of transactions its AI agents now process end to end has climbed more than fivefold, at about 92 percent accuracy. The pattern repeats across every layer of the stack, from billing to the close.

Two bets on the future

The new entrants are making one of two bets:

The first bet is to replace the system of record itself. A cluster of startups, including Rillet, Campfire, Light, and DualEntry, is building what they call the AI-native enterprise resource planning system, a modern general ledger designed around automation rather than retrofitted with it. These companies argue that the incumbents cannot catch up, because automation is only as good as the data it can reach, and the old systems were built to store data with little action.

The second bet is more modest and, for now, more common. Rather than rip out the ledger, sit on top of it as an agent. This is the wager behind Basis, behind a quieter group of companies including Concourse, Lumera, Mesh, Zalos, and TenKey that aim their agents at the work that falls between existing systems.

Share

Lumera, founded by a former controller at OpenAI and Rippling who had also led corporate accounting at Square, has a phrase for the gap it is chasing. Companies have systems of record, the argument goes, but no system of work. The high-judgment processes that span several tools at once, an accrual that draws on usage data and a contract, a bank reconciliation that lives in a spreadsheet and a memorized set of rules, fit cleanly into no single product. That long tail is where finance teams still spend their nights, and it is the part that artificial intelligence is now able to reach.

Much of that work begins in an inbox. Invoices, payment questions and new-vendor requests arrive as email, and a person reads each one, decides what it is, and routes it. Several companies, including Ramp with its automated W-9 collection and a set of smaller startups, including Modai, Appzen, Auditoria, and TenKey have built agents that read the shared accounts-payable inbox, classify what they find, check it against the accounting system and draft a response for a human to approve.

The question of who signs off

The technology is real. The harder problem is trust, and the industry knows it.

An autonomous agent that posts journal entries is one bad automation away from a material misstatement, the kind of error that produces a public restatement and ends careers. Large language models fail in a specific and dangerous way for accounting. They can be confidently wrong, returning a clean, plausible answer that happens to be incorrect, which is worse than an obvious crash because no one thinks to check it.

The serious products have converged on the same answer. Basis logs every action its agents take with a timestamp, a source document, the rule applied and a confidence score, and it routes a task to a human whenever confidence falls below a set threshold. The newer agent companies talk less about replacing accountants than about audit trails, role-based access and human review at the points that matter. Governance seems to really really matter!

Share Accounting with AI

Not everyone is so cautious. Synthetic, a startup that raised $10 million this spring and is led by a co-founder of the bookkeeping service Bench, describes its goal plainly as removing human accountants entirely, producing real-time books for early-stage software companies at $49 a month. The bet there is that for a narrow enough customer, the long tail is short enough to automate away.

What happens to the people

For the firms that sell accounting, the change cuts two ways. Automation that lowers the cost of serving a client also threatens the business model built on billing hours, and it puts particular pressure on the offshore outsourcing that has long handled exactly the tasks the agents now perform. Private equity, which has spent the past few years buying up accounting firms, is paying for outcomes and scale, not for time, and AI agents change that math.

Inside the firms, the job is being redrawn rather than erased. The framing that recurs across the industry is the associate as supervisor. A first-year accountant who once spent sixty hours a week in spreadsheets instead reviews the work of a fleet of agents, applying judgment at the moments the software flags and signing the return the machine prepared. Capacity goes up without headcount, which is the entire point in a profession that cannot find enough people.

That leaves the question the technology has not answered. An agent can reconcile an account, draft a return and explain its reasoning. It cannot be held responsible. When the books are wrong, a person still signs them, and a person still answers for them to an auditor, a board or the I.R.S. The software has learned to do the work. The accountability stayed with the human, which may turn out to be the most durable thing in the entire stack.

What software is out there

(See Link) The Modern Accounting Stack: Breakdown of 500+ Accounting Software

To make the market easier to understand, TenKey put together a public map of the modern accounting AI stack. The resource breaks accounting and finance software into functional segments rather than treating “AI for accounting” as one broad category.

The map is meant to make the software landscape legible for accountants, operators and finance leaders deciding what to buy, what to watch and what still needs to be built.

It likely is incomplete….feel free to share if that’s the case and we will continue to update!

Subscribe now

Share

Leave a comment

AI entered most companies as a twenty dollar ChatGPT Plus charge on one employee’s corporate card. Then a Claude Pro charge from someone else. Then a team plan, a few GitHub Copilot seats for engineering, a Perplexity subscription a department head approved on their own. The technology arrived one line item at a time, and finance is only now treating it as a category worth governing.

AI behaves like a blend of software, labor, and infrastructure, and the disciplines that already apply to those categories apply here.

Find the AI you already bought

Audits are dull, and they are still the right place to start. Before approving anything new, account for what is already running.

AI waste tends to hide in three places:

• Standalone subscriptions, the ChatGPT, Claude, and Perplexity seats paid by card or pushed through expense reimbursements.

• AI built into software the company already owns and already pays for: Microsoft 365 Copilot riding on existing Office licenses, Gemini bundled into Google Workspace, plus the AI add-ons in Notion, Slack, and Salesforce that get switched on and almost never measured.

• Employee tooling that is free today or personally paid, the Cursor seat or the second ChatGPT account someone runs out of pocket until a manager eventually agrees to expense it.

The audit should also surface duplication. Three teams may each be paying for their own research layer, one on Perplexity, one on Glean, one routing the same questions through ChatGPT. Engineering may run Cursor while GitHub Copilot already comes bundled in the GitHub Enterprise seats the company pays for, so the same developer is covered twice.

One error is to treat every AI charge as innovation spend. Some of it is shadow IT with better branding. The opposite error is to treat all shadow AI as a problem to be stamped out. Some of those unofficial tools are doing real work.

This is why the audit has to be part financial and part ethnographic. Finance systems will tell you what is being paid for. They will not tell you what matters. For that you talk to the power users. Ask what they reach for every day, what they tried and abandoned, what they would fight to keep, and where slow approvals pushed them into workarounds. Employees can tell you which tools are toys and which aren’t

Pilots over demos

A demo shows you the tool at its best, in conditions the vendor controls. A slick walkthrough of a support agent like Sierra or Decagon clearing tickets, or of GitHub Copilot scaffolding a feature, proves the tool works in the vendor’s hands. It does not prove the tool works on your data, your edge cases, and your team. A pilot does, and that is the only thing you are buying. The pilot is also where the build versus buy question gets answered, because running something for thirty days tells you how much of it you could have assembled from a foundation model and a weekend.

A serious pilot runs at least thirty days. It starts from a baseline, because savings claims are meaningless without one. How long does the task take today. What does it cost. What quality is acceptable. What error rate can you tolerate. What human review does the work require before it ships.

With that baseline in place, the pilot should measure four things:

• Usage - Does your team continue to use it

• Productivity - Does it save your team time

• Quality - Is it improving quickly

• Cost- What are you paying for intelligence

  Leave a comment

Do not buy yesterday’s intelligence

Ordinary software improves on a predictable curve. You buy a version, it gets patches, it gets better slowly. AI does not behave that way. The underlying model can change, the pricing can change, the leading vendor can change, and your own use case can change, sometimes inside a single contract term.

A tool that looked excellent at purchase can become redundant because a foundation model absorbed its core feature. Standalone AI copywriters like Jasper and Copy.ai built businesses on a capability that GPT-class models now do natively for the price of a chat subscription. Grammarly spent years as the default writing checker, watched general assistants close most of the quality gap for free, and responded by acquiring Coda and the Superhuman email client and rebranding the entire company around a broader bet. A workflow that seemed too risky last year can become viable once better controls ship. What you are buying keeps changing under you, so the cadence of your review should match the cadence of the change.

Agentic systems move the buying decision from “can it answer” to “can it act.” A tool that drafts a reply for a human to send is one kind of purchase. Superhuman Go pulling your calendar to schedule a meeting, Salesforce Agentforce working a support case end to end, a Cursor agent committing code, or a Ramp agent approving an expense is another kind entirely.

The disciplines are already familiar

Finance does not need perfect technical fluency before it can govern AI. Waiting for that fluency is how the spending got ahead of the policy in the first place. The core disciplines transfer directly. Know what you spend. Require an owner for every tool. Test before you scale. Define the return you expect and check whether you got it. Cap the downside. Avoid lock-in that removes your ability to switch. Review on a schedule. Kill what does not work.

Historically, most accounting teams didn’t have the resourcing to even consider building their own solutions. At best, they’d have a really solid excel wizard. But now, they have tools like Claude, Codex, and Lovable and accountants are really empowered. Building has become such a hot topic item for accounting teams that modern accounting software companies are offering $5,000 to crown the best Finance Engineer (Numeric’s Finance Engineer Cup).

Before AI, building software was slow and expensive because someone had to translate business requirements into a repeatable flow, then write the code to make that flow run the same way every time. Now, you can describe what you want in English and get the computer to do useful work: draft the workflow, write the script, classify the email, extract the invoice detail, or generate the first version of an internal tool.

So the build-versus-buy question has changed, but it has not disappeared. AI has made the first version of a workflow much cheaper to build. But accounting makes production expensive: the work still needs controls, evidence, review paths, exception handling, auditability, and someone accountable when it breaks.

The right question is no longer just, “Can we build this ourselves?” Increasingly, the answer is yes. The better question is: “Are we prepared to own this workflow once the team depends on it?”

Start by classifying the workflow

To answer this question, first separate prototype difficulty from production ownership.

When thinking about automating a business process, you have to understand what type of system you are likely going to end up building. You can frame this by grading your workflow across two dimensions: the ambiguity of the process and the amount of control & assurance required.

By “process ambiguity”, I mean how much judgment the workflow requires (e.g., is the outcome of this up for interpretation). Ask:

• Is the work mostly rules-based, where the same input should produce the same output (aka low-ambiguity)?

• Does it involve messy language, incomplete context, exceptions, judgment calls, and information spread across different systems (aka high ambiguity)?

By “control & assurance burden”, I mean the accounting risk created by the workflow. In other words, what would we need to trust, review, and be able to defend the results of this process once the business depends on it? Ask:

• Does it touch cash, payments, payroll, tax, revenue, journal entries, approvals, or vendor master data?

• Can a reviewer verify the output quickly, or would they need to redo the work to verify?

• Does the workflow need evidence, audit trail, preparer/reviewer signoff, or approval history?

• Does it cross systems, users, clients, or external parties?

• If it fails, is the result a minor cleanup task, a close delay, a misstated number, a payment error, or a fraud risk?

With AI, the frontier for what can be built internally has shifted significantly. We can visualize it along these dimensions:

As we can see from the diagram, AI has made handling messy inputs, drafting, classification, and investigation easier to automate. But control and assurance requirements haven’t changed, so the problem shifts from what we can build to what we really want to own. You need review paths, deterministic checks, audit trails, permissions, exception handling, and someone accountable when the workflow fails.

In other words: AI lowers the cost of handling ambiguity, but it does not lower the need for accountability. The farther right a workflow sits, the more it starts to look like production-grade software, whether you buy it, configure it inside an existing platform, or build it yourself with controls.

Who depends on this?

The chart helps classify the workflow, but there is one more practical question: how “production ready” does this need to be?

The same AI workflow can be safe in one context and risky in another. A prompt that helps one accountant clean up a CSV is very different from a shared workflow that routes AP approvals, updates vendor records, or produces client-facing commentary. We can think of 4 levels of maturity levels:

• Personal helper: CSV cleanup, email drafts, contract summaries. Build freely, with human review.

• Team workflow: AP triage queue, close checklist, recurring report prep. Build only with ownership, documentation, logs, and exception handling.

• Client-facing deliverable: Variance commentary, CFO memo, board package support. Requires evidence links, review, signoff, and retention.

• System-of-record workflow: Vendor master changes, payments, journal entries, approvals. Usually buy, or build only with product-grade controls.

Here is how we think common accounting workflows map across ambiguity, assurance burden, and production responsibility:

• Rename invoice files by vendor/date
  Ambiguity: Low
  Control burden: Low
  Production maturity level: Personal helper, or team workflow if shared
  Required control: Naming convention, spot check, and preservation of original files

• Clean up a CSV export for your own analysis
  Ambiguity: Low
  Control burden: Low
  Production maturity level: Personal helper
  Required control: Human review before use and preservation of source data

• Draft a vendor email response
  Ambiguity: High
  Control burden: Medium, because it affects vendor communication
  Production maturity level: Personal helper or team workflow
  Required control: Human reviews and sends the final response; no autonomous commitments

• Triage AP inbox messages
  Ambiguity: High
  Control burden: Medium to high, because of missed invoices, routing errors, and approval delays
  Production maturity level: Team workflow
  Required control: Queue, logs, assigned reviewer, and exception path

• Check approval thresholds
  Ambiguity: Low
  Control burden: High, because it affects approval policy and spend control
  Production maturity level: Team workflow or system-of-record adjacent
  Required control: Deterministic rule, locked threshold source, audit trail, and no LLM discretion

• Detect duplicate invoices
  Ambiguity: Medium
  Control burden: High, because of overpayment risk
  Production maturity level: Team workflow or system-of-record adjacent
  Required control: Matching logic, exception review, and evidence retained before payment decision

• Extract invoice details
  Ambiguity: Medium to high
  Control burden: High, because of posting accuracy and payment accuracy
  Production maturity level: System-of-record adjacent
  Required control: Field validation, confidence thresholds, source document link, and human review for exceptions

• Handle vendor bank-detail changes
  Ambiguity: High
  Control burden: Very high, because of fraud risk, cash loss, and vendor master data
  Production maturity level: System-of-record workflow
  Required control: Out-of-band verification, dual approval, restricted permissions, audit trail, and no autonomous update

• Draft month-end variance commentary with evidence links
  Ambiguity: High
  Control burden: High to very high, because it involves client-facing judgment and reporting support
  Production maturity level: Client-facing deliverable
  Required control: Evidence links to trusted data, preparer/reviewer signoff, version retention, and human final approval

Take approval thresholds. There is very little ambiguity. If the threshold is $10,000, the system should not improvise. But assurance is high because approvals affect financial controls. That belongs far to the right and low on the ambiguity axis. You probably want deterministic software.

Vendor email drafting is different. The ambiguity is high because the language is messy and context matters. But the assurance requirement is lower if a human reviews the draft before sending. That can be a good place for an LLM-assisted workflow.

Vendor bank-detail changes are different again. The ambiguity is high because the request may show up in a messy email thread, but the assurance requirement is also extremely high because the downside is serious with the risk of potential fraud and monetary loss. That is where “just use an agent” is the wrong answer. You might use an LLM to identify the request, but the actual workflow needs hard controls, escalation, audit trail, and human approval.

The hardest automation is where ambiguity and assurance are both high. That is where a lot of real accounting workflow lives. Accounts Payable is a good stress test for this build-versus-buy question. At first glance, an AP inbox looks like a language problem: messy emails, invoice attachments, vendor questions, approval nudges, and exceptions. That makes it tempting to just use an agent. But in production, AP is also a control problem. It touches vendor records, payment timing, duplicate invoices, approvals, audit trails, and fraud risk.

That is why the hardest quadrant is not solved by prompting alone. You need an LLM where interpretation matters (reading emails, classifying requests, extracting context) and deterministic rails where the workflow needs to be reliable, reviewable, and auditable.

Should we build it ourselves?

Once you know where the workflow sits on ambiguity, assurance burden, and production maturity, ask a few practical questions:

• Is the workflow narrow and specific to our firm?
  Building is more attractive if the answer is yes.
  Buying, configuring, or building with stronger controls is more attractive if this is a common accounting workflow.

• Is the output easy to verify?
  Building is more attractive if a reviewer can check the output quickly.
  Buying, configuring, or building with stronger controls is more attractive if the reviewer has to redo the work to verify it.

• Does it touch financial records, cash, payroll, tax, approvals, or vendor master data?
  Building is more attractive if it does not.
  Buying, configuring, or building with stronger controls is more attractive if it does.

• Who depends on it?
  Building is more attractive if it is mostly used by one person.
  Buying, configuring, or building with stronger controls is more attractive if a team, clients, or the system of record depends on it.

• What happens if it fails?
  Building is more attractive if the failure creates minor cleanup work.
  Buying, configuring, or building with stronger controls is more attractive if the failure could cause a close delay, bad data, payment error, fraud risk, or client-facing issue.

• Does it need integrations, permissions, audit trail, or support?
  Building is more attractive if those needs are minimal.
  Buying, configuring, or building with stronger controls is more attractive if those are required for the workflow to be trusted.

• Do we have a clear owner?
  Building is more attractive if someone durable owns the workflow, understands it, and can maintain it.
  Buying, configuring, or building with stronger controls is more attractive if ownership is unclear or concentrated with one person.

As a rule of thumb: build when the workflow is narrow, reversible, easy to verify, and clearly owned. Buy or govern heavily when the workflow is shared, common, high-volume, tied to financial records, or expensive to get wrong.

Some other dimension to consider:

Maintenance cost & operational risk: Is your team well positioned to own this over time? Is the knowledge of the system siloed with one person or spread across the team? Who owns it and responds when it fails and how frequently will they need to make tweaks and changes over time?

If one person creates a useful workflow on their laptop, that may be fine for a personal process. The moment a workflow moves from personal helper to team process, client deliverable, or system-of-record workflow, the ownership burden changes. It now needs documentation, permissions, monitoring, review paths, and a clear fallback when it fails.

For bookkeeping and fractional CFO firms, this burden compounds across clients. A workflow that works for one client may need to handle different ERPs, approval policies, vendor habits, close calendars, document storage rules, and client-specific exceptions. The build-versus-buy question is not just, “Can we automate this once?” It is, “Can we safely maintain this across every client who will depend on it?”

Runtime cost: How frequently does this run and how expensive is this to actually run?

If you are using an agent to fetch your latest emails every time a workflow runs, you may be paying the model to do something deterministic over and over again. It is much more efficient to write the code once: fetch the emails, structure the context, and then let the agent reason over the result.

That is a small example, but I think it points at the larger architecture question. You generally want deterministic code wherever the process can be made deterministic, and LLMs where judgment, language, and ambiguity actually matter.

This matters even if today’s tools make usage feel cheap. Flat-rate plans and generous limits can hide the real marginal cost of a workflow. If a process is going to become part of how the business runs, you should estimate it against actual usage: how many times it runs, how many tokens it burns, which models it needs, what tools it calls, and what happens as volume grows. This matters because usage patterns and model pricing can change. A workflow that feels cheap in a small pilot may look different once it runs across every client, every invoice, or every close cycle.

Market availability: Is this workflow actually unique, or is it something vendors are already building into their products?

This is easy to overlook because AI makes the internal build feel newly possible. But the same tools that make it easier for your team to build also make it easier for vendors to ship more workflow automation into the products you already use. Before you take on the cost of owning a workflow internally, it is worth asking whether your ERP, close platform, AP tool, payroll provider, or reporting tool already has this on the roadmap.

If the workflow is specific to how your company operates, building may still make sense. But if it is a common accounting process, you are probably not the only team asking for it. In that case, the better question is whether you want to maintain your own version, or wait for a vendor to package the workflow with permissions, audit trails, support, and integrations already attached.

So where does that land us for build-vs-buy?

It’s obvious to us that teams should absolutely build more than they used to. If a workflow is narrow, low-risk, easy to verify, and mostly used by one person, build the thing. Write the prompt. Add the script. Use the agent. A lot of useful internal automation will live there, and that is good.

You can also use internal builds to learn. Sometimes the fastest way to understand what you want from a product is to prototype the workflow yourself first. Even if you eventually buy software, you will be a much sharper buyer because you have felt where the process gets weird.

Buying starts to make more sense when the workflow is common, high-volume, shared across a team, tied to financial records, and expensive to get wrong. That is especially true when the workflow needs integrations, permissions, audit history, monitoring, exception handling, and support. The product value is that the workflow has been made durable: observable, auditable, controllable, and maintainable across a team.

So the build-versus-buy question has changed, but it has not gone away. AI makes the first version much easier to build, but it does not automatically make the workflow cheap to own. AP is a perfect example: you can prototype invoice triage or vendor email drafting quickly, but owning the full workflow means handling queues, approvals, vendor verification, exception paths, evidence, audit history, and visibility across the team.

That is the layer TenKey is focused on: helping accounting teams automate the operational work of Accounts Payable while preserving the controls, visibility, and exception handling they need to trust the process.

These present challenges because the inputs arrive as a mess, and sorting them out means working across several systems at once. One invoice email might need to be checked against the bill in BILL and the payment record in QuickBooks. No single system holds the whole picture, so today the person doing the work is the integration layer: reading the context, checking the systems, and escalating anything risky.

That translation work is most of the job, and it is the part software has never been able to touch. It is what we are building TenKey to do: a vendor-neutral layer that sits at the AP inbox, reads the mess, checks it against the systems a team already runs, and turns it into clean, governed action, with a person in the loop for anything risky.

Why MCP Suddenly Matters

The first wave of AI in finance was mostly talk: summarize a contract, explain a variance. The answers were good, and they were still just answers. The next wave has to operate inside the systems where the work happens, without breaking anything.

That is why the Model Context Protocol, or MCP, has started showing up in finance conversations that have nothing to do with engineering. MCP is an open standard, introduced by Anthropic in late 2024, for connecting AI systems to outside tools and data. OpenAI, Microsoft, and others support it too.

The major finance vendors are racing to make their systems reachable this way. Ramp initially shipped a connector that lets AI assistants like Claude and ChatGPT analyze spend, review bills, and complete expenses, with each user’s permissions carried over. This week Ramp went further and launched Stack, an AI operating system for accounting firms that runs the monthly close end to end, every step reviewable and auditable. Intuit has shipped an early-preview QuickBooks server for developers. NetSuite has launched an AI Connector Service on MCP, and Microsoft is adding a version to Dynamics 365.

Each of these agents starts from inside one system. Ramp reasons over Ramp, Brex over Brex. The incumbents are reaching outward now, and Stack is the clearest example, but they still begin from the center of their own platform. The work that creates the most drag does not sit in any one system. It spans several at once, and it usually starts upstream of all of them, in the inbox.

MCP has a limit, too. It is plumbing, and plumbing does not make a workflow safe. Finance teams still need the controls that make automation trustworthy: role-based access, approval gates, audit logs, source evidence, and rules about what it can do. Every serious vendor is adding these, so controls are becoming the price of entry rather than the thing that sets a product apart. What separates one agent from another is judgment: how to read a vendor’s intent, when an action is safe, what evidence it needs, and what has to go to a person. That judgment does not come from the connector.

What Practitioners Are Already Saying

The practitioner market is converging on the same point.

Gaapsavvy recently hosted a finance AI session with Adam Dix from Anthropic’s finance team. More than 1,300 people attended, most of them in-house finance and accounting practitioners, and their questions were revealing. They cared less about whether a model could write a memo and more about where AI-built workflows should live, how finance data should be governed, and how a non-deterministic tool can be audited or recreated later. The real question in accounting has moved past whether the model can do the task. It is whether the workflow can be trusted and verified.

The demand mapped to real finance work: reconciliations, accruals, variance analysis, close, AP, AR, cash, and audit support. Practitioners want AI that operates inside the systems and controls where the work already happens. The best of it will not come from a model vendor or a single ERP working from the outside; it has to absorb the judgment of the people who actually close the books and answer the auditors.

MCP can help with the integrations and give agents access to systems. It cannot decide where evidence belongs, how approvals should work, what an auditor needs to recreate, or when a human has to stay in the loop. The protocol gives agents reach. Practitioner knowledge gives them judgment. Governance makes the result usable. Accounting AI needs all three.

Why This Matters for Fractional CFO Firms

For fractional CFO and outsourced accounting firms, the reason to care is leverage. These firms rarely lose margin because their partners cannot think strategically. They lose it because staff drown in client inboxes, spreadsheets, bill systems, and vendor threads. Every new client brings another finance stack, another set of vendor behaviors, and another place for small errors to become client-visible.

One super-agent spanning every client is dangerous and sloppy. The real opportunity is a repeatable operating model: one workspace per client, client-scoped access to email and accounting systems, read-only to start, human approval for every external reply and every write, and a visible record of what the agent found, drafted, escalated, or cleared.

If a firm can take on more client AP volume without hiring in proportion to client count, the unit economics change. The metric that matters is clients per staff member with no drop in service quality.

Why This Matters for Lean Finance Teams

For a controller or finance lead at a company of 50 to 500 people, the calculus is different. The goal is narrower: keep accounts payable from falling apart while the team stays small.

These companies often already own modern tools: QuickBooks, Ramp or Brex, maybe Tipalti or BILL. Vendors do not live tidily inside any of them. They email, follow up, ask whether they were paid, send the same document twice, and escalate when something is late.

The stack is modern. The front door is still email.

A connected agent belongs there first, as a controlled AP clerk that watches the inbox, checks the systems, and keeps people focused on judgment. The test is simple: can it tell you what AP-relevant work arrived today, what it did with each item, what is blocked, and what needs approval?

Where This Goes

The next stage in accounting will be agentic workflows that move across systems while preserving control. The ledger stays in the system of record, and the agent becomes the translation and coordination layer around it.

This is why the connector race is a tailwind rather than a threat for an independent layer. The more systems become agent-accessible, the easier they are to coordinate across. The incumbents will reach across systems too, and some are already saying so, but each does it from the center of its own platform, with its own product as the destination.

Ramp Stack is the sharpest version of this, and the contrast is the whole point. Stack starts at the close. It works downstream, on structured records that have already made it into the system: reconciliations, journal entries, recurring schedules. That is the back half of the process. The front half is the inbox, where the invoice shows up with no PO and the past-due notice lands with no context. None of that is a clean record yet. Someone has to read it, check it across systems, and turn it into something a close engine can use. A close is only as good as the inputs that reach it, and the inputs start in the inbox.

MCP matters, but it does not finish the job. The future of accounting AI is a governed agent layer that turns unstructured finance work into controlled system action. For fractional firms, that means delivering more service with the same team. For lean finance teams, it means using AI to take back control of the AP inbox so the accounting team can get back to doing accounting.

That gap is where TenKey sits: upstream of the close, and upstream of any single platform. Stack and the platform agents reason over the records inside their own walls. TenKey reasons over the mess before it becomes a record, checking it across BILL, QuickBooks, Brex, and Tipalti as equals.

What level of Financial Transformation is your team on?

Despite every technology thus far, Accounting by nature has been stuck in the historical performance of the business.

Financial Transformation will not occur suddenly or eliminate finance teams in one fell swoop, as many technology predictions suggest. More likely, the transformation will happen gradually. First through productivity gains, then operational leverage, and eventually through financial systems that behave less like databases and more like active participants in the business.

Most organizations are already moving through this transition, whether formally or not. Over the past few months, we have spoken to several hundred accounting teams and the pattern is becoming increasingly recognizable to us at TenKey.

Like most, AI may be a thought partner for your team. If it is, you are standing on the tip of an iceberg with so much more automation possible below!

Subscribe now

Level 1: AI as a Thought Partner

The first stage is already widespread across finance organizations, though many companies still treat it informally.

Controllers use ChatGPT to organize accounting memos. FP&A teams summarize earnings transcripts with Claude. Audit professionals test technical positions through Gemini before meetings. The workflow itself remains human-led, but the speed of knowledge work changes materially.

The important shift at this stage is compression of hours. Work that previously required several hours of research and drafting can often be completed in thirty minutes. The accountant still exercises judgment. The starting point simply improves.

Share Accounting with AI

Level 2: AI as an Assistant

The second stage begins when AI moves from research into execution. This is where the economics of finance operations start changing more visibly. The accounting team has started to trust AI at this point, but still limits it to specific actions within the broader accounting workflows.

Many accounting departments still depend on labor-intensive coordination processes: collecting support, following up on approvals, updating reconciliations, preparing close packages and managing recurring review cycles across fragmented systems. AI assistants increasingly absorb portions of that work.

"The monthly close is less of an accounting problem than a coordination problem."

That observation, from a controller at a mid-market software company, increasingly reflects reality across the profession. The bottleneck inside many finance organizations is no longer technical capability. It is operational friction. AI assistants reduce that friction first.

Subscribe now

Level 3: AI as Teammates

At the third stage, AI systems begin operating continuously inside workflows rather than responding only when prompted. This is where the conversation shifts from productivity software to operational infrastructure.

Instead of helping individuals complete tasks, AI systems begin monitoring transactions, coordinating across systems and surfacing exceptions automatically.

This is also the stage where organizational structure begins changing. Historically, finance scale required headcount scale. More entities meant more accountants. More transactions meant more coordination layers. More reporting complexity meant larger close teams.

AI changes that relationship because because fewer people are needed to manage repetitive operational movement between systems.

The leverage compounds quietly at first, then suddenly becomes difficult to ignore.

Level 4: AI as Intelligent Ledgers

The evolution of the ledger itself. The ledger begins moving from passive recordkeeping toward active financial intelligence.

The broader implication is difficult to overstate. For most of modern corporate history, finance teams have operated reactively. Data collection came first. Analysis followed later.

It raises the importance of experienced finance professionals who understand controls, materiality, incentives and risk.

Regardless of how sophisticated the software becomes, companies will still need someone responsible for deciding whether the numbers reflect economic reality.

Leave a comment

For years, general ledger operations were constrained by the same problems. Headcount requests were denied while close timelines stayed the same. New products were launched without accounting visibility. Teams spent hours creating, posting, and reviewing journal entries inside systems that never felt built for accountants in the first place. You would read through thousand-page Big 4 manuals searching for one example that clarified a GAAP position, only to turn around and draft a twenty-page memo for internal alignment.

Much of the work became repetitive operational maintenance when it should have been focused on financial analysis, business partnership, and decision-making. The underlying systems rarely improved enough to change the experience. Excel hit its limits years ago. Outsourcing reduced costs in some areas but rarely reduced operational complexity.

Subscribe now

What is striking about this moment is not just the speed of AI. It is how quickly ordinary accounting workflows begin to feel different once AI is introduced into them. Processes that previously required multiple systems, multiple follow-ups, multiple hours, and incredible expertise, can suddenly move with far less friction. Internal knowledge becomes easier to surface. Review preparation becomes faster. Recurring processes become more consistent. Teams regain time that used to disappear into administrative work.

The accounting teams seeing the biggest improvements right now are not necessarily the largest teams or the most technical teams. They are the teams willing to test new workflows early.

Their culture allows room to experiment. They explore new applications, pilot software during close cycles, and look closely at where operational bottlenecks exist inside the business.

That mindset matters more than most people realize.

Because unlike prior waves of accounting software, this generation of tools is accessible almost immediately. You do not need to overhaul your ERP. You do not need a technical implementation team before getting started. Most teams can identify one recurring pain point during month-end close and begin testing improvements around it within days.

Accounting will always rely on judgment, trust, and consistency. AI does not replace those qualities. It strengthens the teams already operating with them.

So here is a simple challenge after your next month-end close: spend time exploring one modern accounting AI product before the next close begins.

• Run a pilot.

• Test one workflow.

• 03See where friction disappears.

Maybe it is a better way to interact with NetSuite. Maybe it is a better way to manage accounting email workflows. Maybe it is a faster way to draft technical accounting memos. You may not recognize every company yet, but there are dozens of teams building products specifically designed to improve the daily lives of accountants. Trust me, TenKey is one of them.

The firms that develop the habit of experimenting now are going to move much faster than the firms waiting for the industry to force the change on them.

Leave a comment

This is a translation problem.

Every accounting system is built to operate on structured, standardized inputs. Fields must be filled. Categories must be selected. Dates, amounts, and counterparties must be clear and consistent. Even where GAAP requirements apply, the accountant is primarily cleansing the data monthly for real time management reporting. Communication happens in natural language, meaning essential information is implied rather than stated, and not in the rigid schema that existing systems require.

Bridging this gap has always been the job.

An accountant reads an input (email, bank transaction, internal ledger, etc), interprets its meaning, determines whether it represents a valid obligation/right, identifies what information is missing, and decides how it should be recorded. What appears in the system as an objective fact is the result of a series of judgments that took place outside of it. The system does not perform this work. It merely reflects its outcome.

This is most visible in accounts payable, where the distance between incoming information and system-ready data is particularly wide. The shared inbox, rather than any other system in the process, is the operational center of gravity. It is where invoices arrive, where vendors ask questions, where discrepancies surface, and where context is gleaned. It is also where the limits of existing systems are most apparent.

The AP inbox is unstructured, continuous, and conversational; the ERP is none of those things.

For decades, software has been able to store and process financial data with increasing efficiency, but it has not been able to meaningfully participate in this intermediate layer. It could not interpret ambiguity, resolve incomplete information, or engage in the back-and-forth required to clarify it. Every time the software lacked required context (which is often), the automation broke and the accountant had to step in and do it by hand.

TenKey translating unstructured AP inputs into structured, system-ready data

What is changing now is that software can operate within the space that was previously reserved for human judgement. Agent harnesses now (within 2026!), are making it possible for systems to read unstructured inputs, infer intent, identify gaps, and take action to resolve them. A system can now recognize that an email contains an invoice, determine whether key information is present, check it against existing records, and, when necessary, follow up to request what is missing.

This is a fundamentally different capability. It is not the automation of a predefined sequence of steps. It is the ability to translate.

Once that layer is addressed, the rest of the system begins to function as intended. Downstream processes become more reliable because they are no longer compensating for incomplete or inconsistent inputs. Errors decrease not because controls have tightened, but because ambiguity has been resolved earlier in the process. The role of the accountant shifts accordingly. Accountants spend less time interpreting raw inputs and more time reviewing outcomes and applying judgment where it is truly needed.

We started TenKey to turn systems of record into systems of doing.

We started TenKey to build the translation layer for accounting teams. What has emerged over the past few months (OpenClaw and Cowork) has only reinforced how inevitable this shift is. AI is moving from something that assists work to something that actually does it, operating across systems with context, memory, and agency.

While OpenAI and Anthropic are building the underlying primitives for this future, the real opportunity now is to apply that capability to the parts of the economy that have never had it. We believe accounting is one of them, and that the agentic translation layer it has long relied on, burning the midnight oil, will finally be built into the system itself.

Where the Term Is Coming From

A few months ago, I was talking with a partner at PwC I used to work for. We had gotten mixed reactions regarding focusing on Accounts Payable, some thought it was solved, and others said “You have to start with Accounts Receivable.” We asked for his thoughts and were bracing for him to tell us AP was a waste of time, “Revenue is king,” and to start with Accounts Receivable.

He took it in a different direction almost immediately. His point was that right now, the specific workflow matters less than how you position the outcome. In his words:

If you can credibly say your product drives Financial Transformation and reduces the amount of manual work in finance, it will sell. It does not really matter if you start in AP, AR, or somewhere else in the stack.

At first, I was like okay, maybe, but that sounds like a total buzzword. Most of us don’t wake up thinking about “financial transformation.” We think about getting the numbers right, closing on time, and not having to explain the same variance three months in a row. But the more accounting teams we work with, the more I think he was describing something very real.

What the Work Actually Looks Like

If you spend time inside an accounting team, the problem is not hard to find. It’s not that we don’t have tools. It’s that the work itself is stitched together across systems that don’t line up cleanly.

Very little time is spent on straightforward execution. The majority of the effort goes into figuring out why things don’t match. You’re pulling data from the ERP, comparing it to something in billing, checking cash somewhere else, and trying to reconcile all of it into a version of the truth that you’re comfortable signing your name to.

A lot of that work is invisible if you haven’t done it. It shows up as small things. Following up with another team to understand a number. Building a quick model to isolate a discrepancy. Re-running a report because something feels off. It adds up quickly.

Finance teams spend around 60 percent of their time on data gathering and reconciliation. The work is less about processing and more about connecting.

The Cost of Operating This Way

The way this work is structured creates a built-in delay. Something happens in the business, and then finance works backward to understand it. The close becomes the point where everything gets pulled together.

If you’ve been through enough closes, you know how that feels. There’s always a moment where you’re confident in the numbers, but it comes after a lot of effort, and usually later than anyone would like.

That delay carries into everything else. Forecasts are built on numbers that are already a step behind. Decisions get made with partial context, especially in fast-moving parts of the business.

Companies with more timely financial visibility tend to perform better, particularly on margins and forecasting accuracy. That lines up with intuition. If you understand what’s happening earlier, you have more options.

What Financial Transformation Actually Means

This is where the phrase starts to make more sense to me.

If you strip it down, financial transformation is about reducing the amount of work required to understand what actually happened in the business. Not just speeding up tasks, but reducing the need for someone to manually connect everything.

A lot of what gets labeled as transformation today doesn’t really do that. It makes individual steps better, faster invoice processing, cleaner approvals, nicer dashboards. But the underlying structure stays the same.

The more interesting changes are the ones that start to take that responsibility away from people and put it into the system.

Where the Shift Is Actually Happening

Variance analysis is a good example because everyone has done it. You run a report, see something that doesn’t make sense, and then you start digging. You look at transactions, compare periods, maybe talk to someone in another team, and eventually you figure out what drove the change.

That process is not complicated, but it is time-consuming and it depends heavily on knowing where to look.

Instead of building the explanation from scratch, you’re validating and refining it.

You see the same pattern in reconciliations and forecasting. Issues get identified earlier, closer to when they happen. Forecasts update based on actual activity instead of being rebuilt on a schedule. The common thread is less manual coordination.

Why the Headcount Conversation Comes Up

The PwC partner framed this in terms of headcount, which is how a lot of executives think about it. There is some truth there. If you remove enough manual work, you can support the same business with fewer people. But I don’t think that’s the most interesting way to look at it.

What actually changes is how time is spent. When you’re not constantly pulling data and reconciling differences, you have more capacity to focus on what the numbers mean. That’s where finance can actually add value.

It also makes the function easier to scale. As the business grows and complexity increases, you don’t have to add people at the same rate just to keep up with the mechanics.

How I Think About Approaching It

If I were approaching this inside a company, I wouldn’t start with a tool. I would start with a workflow that everyone knows is painful.

Accounts Payable is an obvious one. Bank reconciliations is another. Close for sure. Pick something where you consistently see people chasing information and trying to reconcile differences. Map out what actually happens, where data is coming from, where things break down, and where people have to manually figure things out.

Not just automating a step, but reducing the need for someone to coordinate across the entire process.

That framing usually leads to better decisions about what to build or buy, because it’s grounded in how the work actually happens.

What Changes When It Works

When you get this right, the impact is pretty noticeable. Close becomes less chaotic because fewer issues pile up at the end. Forecasts feel more connected to what’s actually happening in the business. Conversations shift away from debating numbers and toward understanding them. Finance starts to feel less like a reporting function and more like part of how the company operates day to day.

Why the Term Will Stick

I still think the phrase financial transformation is a bit overused, and it will probably get stretched to cover a lot of things that don’t fully deserve it. But the underlying shift is real.

The way we’ve historically done this work, with people acting as the connective layer between systems, does not scale well with the complexity of modern businesses. Something has to change. The market has already decided this is important. Products that can show they reduce manual work and help finance operate more efficiently will continue to gain traction.

Subscribe now

Every functioning accounting team today runs an operational system. Every number needs to tie, every entry needs a reason, and every process needs to hold up under scrutiny.

AI can now participate in that system. It can suggest classifications, surface anomalies, and accelerate parts of the close.

The CPA still carries the responsibility.

Why this is worth paying attention to

A lot of AI discussion in finance focuses on capability. What it can do.

In practice, the real constraints are

• Can you trust the output enough to rely on it?

• Can you explain it when someone asks?

• Can it handle the exceptions, not just the standard cases?

• Does it fit inside existing controls, or work against them?

As the CPA adopts AI, they must maintain certainty of accuracy of financial reporting and mitigation of risk. This has always been the job of the accountant, and it will serve critical as AI adoption proliferates.

What you’ll get from this

The focus here is straightforward: take real accounting work and look at it through the lens of AI, without overcomplicating it.

Expect:

• Breakdowns of specific workflows and where AI helps (or doesn’t)

• Practical tradeoffs between speed, accuracy, and control

• Observations from working through edge cases

• A clearer view of how the accounting role is evolving

The point

This isn’t about turning accountants into engineers or pretending AI solves everything.

It’s about understanding how a tool that generates answers fits into a profession that requires certainty.

If you can navigate that well, you gain leverage. Faster close and less stressful year-ends audits.

If you care about keeping your work accurate, defensible, and relevant as the tools change, this will be useful.