AI-Native ERP Solves
the Wrong Problem.

In August 2026, Rillet raised a $100M Series C at a $1B valuation, led by ICONIQ with Sequoia, Andreessen Horowitz, Bain Capital Ventures, Battery and others alongside. The company describes its platform as an AI-native ERP built to rebuild the general ledger from scratch, and names NetSuite, SAP, Workday and Oracle Fusion as what it displaces. It is a serious product with more than 600 customers and revenue that has doubled twice in six months. This is not an argument that the company is wrong about its own business.

It is an argument that the category is the wrong shape for the buyer, and that the label attached to it has been doing a lot of quiet work.

Start with what changed in the models, because the category was named after that change and does not match it. Models did not get better at storing financial state. Storing state correctly and durably was solved decades ago, and it was never the constraint. What changed, over roughly the last twelve months, is that a model can now run a long sequence of steps across several systems, discover something in step forty that invalidates an assumption from step six, branch, reconcile and keep going without falling over. Long-horizon execution across software is the capability that arrived.

That capability describes the work that produces a journal entry. It does not describe the journal.

Every one of those steps happens outside the ledger, in the billing system, the CRM, the bank portal, the contract repository, the spend management tool and the workbook where someone ties it all together. The ledger receives the last step. Automating the last step is not the opportunity, because the last step was already automated.

SAP S/4HANA ships about a dozen core functional modules. Finance and Controlling, Sales and Distribution, Materials Management, Production Planning, Quality Management, Plant Maintenance, Project System, Human Capital Management, Supply Chain, Customer Relationship Management, Environment Health and Safety, and then industry-specific extensions on top of those. The general ledger is one component of one of them. NetSuite is complex for the same reason, and so is Oracle Fusion.

The products currently marketed as AI-native ERPs rebuild the ledger. That is what their own materials say, and it is a reasonable thing to build: the accounting core of most mid-market finance stacks genuinely is dated, and an agent-first close is a real improvement over manual journal entry. The problem is the word wrapped around it.

If your company runs on a ledger and not much else, a modern ledger is a sensible purchase and you should evaluate one. If you carry inventory, run projects, plan production, hold several legal entities, file statutory reports in more than one country or depend on procurement and warehouse logic that has been tuned for fifteen years, then what is on offer covers a slice of what you have and none of what makes replacing it hard. The modules you never think about are the ones that surface on the Monday after cutover.

Being precise about this matters at the point of purchase, because "we are replacing your ERP with AI" and "we are replacing your general ledger with AI" are proposals with different risk profiles, different scopes and different prices, and only one of them is being described accurately.

SAPinsider's April 2026 benchmark found 55% of organisations claiming an S/4HANA deployment and 34% fully transitioned, with somewhere between 20,000 and 25,000 legacy SAP ERP customers not yet licensed for the target platform at all. The 2027 maintenance deadline is cited by 39% of them as a reason to move, and AI announcements by 43%.

Holger Scheel of cbs Corporate Business Solutions told CIO that roughly half of large and midsize industrial companies have started the transformation and "very few have completely finished it", and that 2030 is the more realistic target for the rest. He puts the delay down to ERP systems that grew organically over twenty years, with correspondingly complex data structures. The standardisation work turns out to be much larger than the migration work anyone scoped.

Those are migrations from one vendor to the same vendor, with that vendor's tooling, its partner network, a global consulting industry organised around the task and a hard maintenance cutoff pushing everyone forward. They are still slipping by years. A move to a different vendor with a narrower functional footprint is not the easier version of that project.

Then weigh what the project buys. You inherit the durability, controls and implementation burden of the system with the highest displacement cost you own. And on the far side of it, your CRM, billing system, payroll provider, banks, spend management tool, contract repository and warehouse are all still running, still holding numbers finance has to reconcile against the new ledger, and the work of reconciling them has not moved an inch. You paid the largest bill available and the actual work was not in scope.

A journal entry states an amount, an account, a date and a currency. It does not state which of three source systems was trusted when they disagreed, what failed to tie and how the break was resolved, which policy election constrained the treatment, what precedent from last quarter applied, what the controller changed on review, or what evidence closed the exception. All of that happened. None of it is in the record.

That is not a design flaw. A ledger is meant to be a compact, auditable statement of position, and a hundred fields of provenance per line would ruin it at the job it exists to do. But it does mean the ledger is a poor place to look for the work, and a worse place to put an agent whose value depends on doing the work well.

Seema Amble made the general version of this argument at Andreessen Horowitz in September 2026, writing that "the contract is not the legal matter, the ticket is not the customer's resolution, and the opportunity is not the sale." Her conclusion is that incumbents holding the record get stronger as agents get more capable, because the data and actions they control become more valuable, and that the durable opening is for whoever becomes best at doing the job across systems rather than owning any one record.

The companies building in this category understand that. Rillet does not describe a passive book of record. It describes agents performing accounting work, native integrations pulling operational data in, accounting policy and controls applied alongside that work, and an audit trail over what the agents did. Almost all of that describes the layer around the ledger rather than the ledger itself. What is left open is whether owning that layer requires replacing the system of record underneath it.

For anyone holding a budget, that resolves into a short instruction. Keep the record. Buy the work.

BetterCloud's 2026 State of SaaS report puts the average company at 118 SaaS applications, up 11% on the 106 recorded a year earlier, which reverses two years of consolidation. Companies with 1,500 to 4,999 employees went from 116 applications to 164 in a single year. Each of those holds some state that finance eventually has to reconcile, and the count is rising rather than falling.

The clearest evidence that the work sits outside the ledger is what finance teams reach for when they need to get something done. Odoxa surveyed 303 CFOs at UK private companies with 250 or more employees on behalf of Sixthfin in May 2026. Two thirds use Excel for account analysis and reconciliation. 57% use spreadsheets for accruals, 54% for manual journal entries, 53% to run the close calendar. More than a third say they do not have high confidence in the reliability of their own figures, and 97% say the monthly close affects workload across the team.

Every one of those companies has a general ledger, and most of them have a good one. The spreadsheets are not there because the ledger is bad at being a ledger. They are there because getting to a defensible number spans systems the ledger does not reach, and the workbook is the only place that work has ever been allowed to happen.

Replace the ledger and the workbooks stay exactly where they are. That is the test to apply to any proposal in this category: after the migration, does the Tuesday of close week look different? If the reconciliation still runs in Excel across six systems, you bought a nicer ledger.

Suppose you take the other route. The ledger stays, the CRM stays, the billing platform stays, and a capable agent goes above all of them. Published APIs, MCP servers and modern integration tooling make that access cheaper every quarter, so the agent can read every number the analyst could read and nobody spent three years on a migration to get there.

That is the better architecture. It is not yet a working one.

Reaching the data is a different thing from understanding it. The agent inherits all the information the analyst had and none of the judgment the analyst applied to it, and the space between those two is where answers go wrong. An agent with read access to six systems and no instruction about which of them is authoritative for a given figure will still return a number, confidently, in the format you asked for. Adding a seventh connector does not change that.

Both routes arrive at the same unsolved problem. The migration just charges more to get there.

What does not get cheaper with better connectors is that each of those systems carries its own definition of the same word, and the definitions are all defensible.

Revenue in the billing system is what was invoiced. Revenue in the CRM is what was booked. Revenue in the close is what was earned in the period after the deferral rules run. A customer is a logo in the CRM, an account in billing, a workspace in the product and a legal entity in the ledger that may hold several of each. An active user is a login in one system and a paid seat in another. None of these is wrong. Each was defined by a competent person for a purpose that still holds today.

An experienced analyst navigates all of it silently. They know the sales figure excludes intercompany, that the finance figure applies the deferral, that the two customer counts differ by four percent for a reason someone settled in 2021. That knowledge was never written anywhere a machine can read, because until now it never had to be. It sat in the room with the person doing the work.

Take the person out of the loop and the missing definition stops being an inconvenience and becomes the output. An agent asked to reconcile across five systems has no way to discover which definition applies where. It will choose one, it will be confident, and the answer will look exactly like a correct answer. A wrong number that looks wrong gets caught in review. A wrong number that looks right gets presented to the board.

This is exactly why the replace-the-ledger pitch is appealing, and exactly why it fails. The disagreement lives between the ledger and everything upstream of it, which a ledger migration leaves untouched. And you are not going to end up with one system anyway: the SaaS count per company is going up. Whichever route you take, somebody still has to decide what the words mean.

It is not a lookup. Before anything can answer it, somebody has to have settled all of the following.

• Is revenue here what was invoiced, what sales booked, or what was recognised under accounting policy?
• Which transaction types are excluded, and on what basis?
• How are credits, refunds and cancellations treated?
• Which legal entities count as Germany, and what happens to a German customer billed from another entity?
• Which date assigns an amount to the quarter: invoice, posting, service or payment?
• If an amount covers several periods, is it prorated or does it fall into a single period?
• Which exchange rate applies, from which day, and at which step of the calculation?
• If two systems hold different values, which one has authority?
• Does sales get the same answer as finance, or is each entitled to a different legitimate view?

None of those is exotic. Every one of them was decided by somebody at some point, and most were never written down. The last two are the ones companies discover late. Sales can legitimately need bookings while finance needs recognised revenue, and the answer is not to average them into a figure neither will defend. It is to keep both, record which question each one answers, and know how they reconcile.

A glossary or a data catalogue can hold all of that, and holding it beats not holding it. But a document and an executing system are two different things. Change the query next month without changing the glossary and the two drift apart quietly: the documentation still reads correctly while the system returns a different number, and nothing in the process notices.

So for an agent, meaning has to be executable. The alternative to a migration costs far less and is considerably less pleasant, because it is not a purchase. It is a decision. Somebody has to say what your company means by revenue, by customer, by active, by an expense, and where each legitimate variant applies. Then that has to live somewhere an agent can read and somewhere it cannot quietly rot: executed as code the query engine runs, versioned, owned by you, with a named person who signs off when it changes.

Two properties follow from doing it that way. Answers become reproducible, because meaning gets resolved once at indexing time rather than re-guessed inside a model on every query, so the same question against the same data returns the same number today and next quarter. And the layer survives your model choice, which almost nothing else in your AI stack does. If the only place your business logic exists is a model provider's context window or memory service, your institutional knowledge is rented, and switching vendors becomes an amnesia event rather than a procurement decision.

One of our customers is a spend management platform. Its own customers are finance teams, and everything it holds, meaning expenses, budgets, approvals and invoices, is upstream of their ledgers. Before any of it becomes a journal entry, a chain of judgments has already been applied: which expense types and statuses count, which cost centre, which period, which exchange rate from which day, how to treat an amount that spans several months. That chain is the work. The entry is what is left of it after the work is done.

None of those rules existed in writing.

We connected read-only to their MongoDB and generated the structural layer automatically, because their tables carried no descriptions. They named the first five reports they wanted and wrote a short brief for each. The output had large gaps against what they expected, and the gaps were the useful part: a brief describes what you want, not the rules underneath it. So they sent us the queries behind their existing reports, we reverse-engineered the logic out of them into a written reference, and then spent a week with their team on what the queries could not explain by themselves.

Two things came out of that week.

The first was a rule that had never been decided at all. How should a performance period be assigned when an amount spans several months? Nobody had ever specified it, and their own system had been applying it differently from one report to the next.

The second was less comfortable. Two legacy reports, built three years apart by different engineers, returned different numbers for the same figure, one of them carrying a hardcoded condition with no explanation attached. Neither engineer had been careless. Nobody had ever decided which reading was right, so both shipped.

Once the logic existed as definitions rather than as code buried inside individual queries, five things changed.

• A new report went from a couple of weeks to a couple of hours. It no longer needs an engineer or a deployment, which also means a reporting change can no longer break the product.
• Reports stopped being able to disagree. They all read the same definitions now. Tidying the code would not have achieved this: large MongoDB queries cannot be decomposed into shared pieces, so a code-level fix leaves every report holding its own private copy of the rules.
• Aggregation across entities arrived as a property rather than a project. Their customers can hold several companies, and the old reporting showed one at a time, so people exported each and added them up by hand. Combining across entities falls out of having defined the logic once.
• Trust got built by comparison instead of assertion. The feature pilot customers valued most was not in the original plan: dashboard templates showing the familiar numbers next to the new ones. Finance teams verify before they delegate, so give them something to check the new numbers against.
• They decided to hold one definition of each figure. Discovering that some legacy numbers had been wrong turned into a decision to retire their own reporting page rather than maintain two systems that could contradict each other in front of the same customer.

Nothing in that programme needed a new ledger. Their accounting systems were fine and stayed where they were. What was missing was a written, executable statement of what their own numbers meant, and until it existed, nothing built on top could be trusted, whether the thing on top was a report, an agent or a person.

Systems of record are not going away, and in an agentic setup most of them get more valuable, because they remain the authoritative place where state and actions are held. What changes is what has to exist across them. An AI system doing work a company will act on has to reach information wherever it lives, understand how the concepts in those systems relate to one another, and produce results somebody can explain afterwards. At LazyFox we treat those as three separate problems.

Data is the access problem: can the system read the relevant information across the stack you already run, without a migration as the first step. Meaning is the interpretation problem: does customer, revenue, active or expense resolve to the right definition when five systems encode the concept differently. Trust is the production problem: can the company see where an answer came from, which definition applied, what the person asking was allowed to see, and why the result held at that moment.

The component that reconciles all three is what we call the Enterprise Intelligence Layer. It runs across the systems a company already has and serves their meaning to whichever application or agent is asking. LazyFox is broader than that layer. We are building an Enterprise AI Adoption Platform around one problem: getting AI from pilot into production without asking the company to rebuild its technology estate first. It connects read-only to the existing stack, and no migration is the entry price.

That is also the test to put to the new finance platforms. Whether an AI-native ledger can beat a fifteen-year-old ledger is not in dispute; it can, and for a company whose accounting core needs replacing anyway there is real appeal in having the ledger and the automation built together from day one. Whether the new capability has to arrive attached to a ledger replacement is a separate question, and for an enterprise with years of controls, integrations and business logic embedded in SAP or Oracle, the two do not have the same answer.

None of that context belongs naturally to Salesforce, to SAP, to the bank, to the billing platform or to whoever supplies the model. It is the accumulated result of how your company decided to operate, and it is the one part of the stack you cannot buy back after giving it away.

• Keep the systems of record and buy the work. Automate the steps that happen between the systems you already run. An orchestration and definition layer across them does the job a multi-year migration was supposed to do, without the migration.
• Baseline the disagreement first. Take your five most disputed figures, ask every system that holds them the same question on the same day, and write down how many different answers come back. That number is your starting point and it is usually the entire business case.
• Decide rather than merge. Where two definitions are both legitimate, keep both, name where each applies, and reconcile them explicitly. Merging them into a single number produces a figure nobody in the room will defend.
• Settle time, currency and scope on the record. Which date assigns an amount to a period, whether an amount spanning months is prorated or falls into a single period, which rate from which day applied at which step, and who may see which slice when one person legitimately spans several entities. These produce more silent disagreement than anything else on this list.
• Put the definitions in versioned code you own. A document describing what a metric means starts dying the moment somebody edits a query, because nothing forces the two to agree. If the definition is what the engine executes, it cannot drift without something breaking.
• Name an owner. Not a full-time job. A named person who signs off when a definition changes. Every deployment that works has one, and every one that stalls does not.
• Test any vendor with one question. Your company defines a given word two legitimate ways. Show me where that decision is recorded, how the system knows which reading applies to this query, and what happens to every existing report when someone changes it.

None of this expires when the models change. A definition of revenue that finance, sales and delivery have agreed on is still correct whether it is read by a model shipping today or one shipping in three years. Most of the rest of your AI stack is rented on terms that change every few months.

• Models did not get better at storing state. They got better at running long sequences of steps across several systems and recovering when an early assumption breaks. That describes the work that produces a journal entry, not the journal.
• Most of what is marketed as an AI-native ERP is a general ledger. SAP S/4HANA ships about a dozen core modules covering procurement, production, projects, supply chain, HR and more. The ledger is one component of one of them.
• The migration is the most expensive item in the proposal, and it does not solve the automation problem. Only 34% of surveyed organisations have fully transitioned to S/4HANA, with 20,000 to 25,000 legacy customers not yet licensed, and that is SAP customers moving to SAP with a deadline pushing them. After cutover your CRM, billing, payroll, banks and spend tools are still there, still holding numbers finance has to reconcile.
• The ledger records the conclusion, not the reasoning. Which source was trusted, what did not tie, which policy constrained the treatment, what the reviewer changed: all of it happened, none of it is in the entry.
• The work is visibly outside the ledger already. 67% of UK companies with 250 or more staff reconcile in Excel and more than a third do not fully trust their own figures. Every one of them owns a ledger.
• What blocks cross-system automation is meaning rather than connectivity. Billing, CRM and the close each hold a defensible and different definition of revenue. An analyst navigates that silently. An agent cannot, because nobody wrote the rule down. Collapsing your systems does not fix it either: the disagreement was never inside the ledger, and the average company runs 118 SaaS applications and rising.
• Nine decisions sit behind a question as ordinary as revenue for Germany last quarter, from which date assigns an amount to the quarter to which system wins when two disagree. Most companies have never recorded any of them anywhere an agent can read.
• In production this looked like a report going from weeks to hours, reports that can no longer disagree, aggregation across entities appearing as a side effect, and a performance-period rule nobody had ever decided finally getting decided.