Agents that do the work. A ledger that doesn't take their word for it.

What makes an ERP AI-native rather than AI-enabled

Every ERP vendor now has an AI announcement. Most of them describe the same thing: an assistant panel bolted onto an interface designed in 2009, able to summarise a report or draft an email. That is a useful feature and it is not what this word should mean.

The distinction that matters is who initiates the work. In an AI-enabled system a person still opens the screen, still starts the task, and the model helps them finish it faster. In an AI-native system the work starts without a person: a bill arrives, an agent picks it up, and a human appears only at the point where judgement or authority is genuinely required.

That inversion has architectural consequences you cannot retrofit. The system needs a permission model that describes what software is allowed to do, not just what people are. It needs an audit trail that records reasoning and confidence alongside the resulting entry. It needs a policy engine sitting between intention and execution. And it needs the whole business in one data model, because an agent reasoning about a vendor bill needs the contract, the purchase order, the budget, and the payment history without asking three systems for permission first.

Three ways AI goes wrong in finance

We are more interested in these than in the demo, because they are what a controller will ask about in the second meeting.

It is confidently wrong

A model that codes a bill to the wrong account with high confidence is worse than one that declines to guess, because nobody reviews it. Our answer is a confidence threshold that routes uncertain work to a person, and an evaluation harness that specifically measures confidently-wrong rate rather than just accuracy. A change that improves overall accuracy while increasing confident errors does not ship.

It cannot explain itself later

Six months on, an auditor asks why a transaction was coded a particular way. If the answer is a model output nobody can reconstruct, you have a control problem. Every agent action records the model and version, the context supplied, the source records read, a reasoning summary, the confidence, the policy applied, and the approver — and that record is exportable.

It quietly widens its own authority

The failure people fear most is an agent doing something nobody authorised. This is why authority is enforced as middleware rather than described in a prompt. An agent cannot talk its way past the policy engine, because the policy engine is not listening to the agent — it evaluates the proposed action against rules your controller wrote, in code, deterministically.

What we will not let AI do

• Write to the general ledger directly. Every posting goes through a deterministic engine that enforces balance, period control, and permissions. There is no path around it.
• Release funds. Payment execution requires a named human approver at any amount and any confidence. This is not configurable downward.
• Close a period. Agents prepare the close, chase the owners, and tie the subledgers. A person signs.
• Change its own permissions. Authority levels are set by an administrator in the policy surface, and changes are logged like any other privileged action.
• Send to customers unsupervised. Dunning notices and campaigns are drafted and queued. A person releases them.

How the agents get good at your business

On connection the agents read your posted history to learn how your team codes, which vendors map to which accounts, and what your approval patterns look like. From there every correction is a labelled example specific to you — which is why the accuracy chart above starts low and climbs rather than arriving at ninety percent on day one.

A vendor claiming high accuracy in week one is claiming to know a chart of accounts it has never seen. We would rather be visibly cautious for a fortnight and earn the number on your data, in the open, with the measurement method published.