AI governance for ERP

The four pillars

Everything here is a page, not a promise.

Each of these is documented in full because a finance team cannot evaluate a control it is only told about.

Why AI never writes the ledger

Read →

Five levels, four permanent exclusions.

Act inside rules your controller wrote.6 of 12 actions permitted

Answer a question from your dataread onlyL0

Run a report or reconciliationread onlyL0

Draft a vendor billheld for reviewL1

Draft a journal entryheld for reviewL1

Send an invoice reminderinside dunning policyL2

Post a coded bill under thresholdmatched PO, within toleranceL2

Post a bill over thresholdneeds named approverL3

Schedule a payment runproposal only, never releaseL3

Release fundshuman only, any amountnever

Close an accounting periodhuman onlynever

Reopen a closed periodhuman only, loggednever

Change its own permissionsadministrator onlynever

Why we publish the constraints rather than the capabilities

A capability list is a sales document. It grows over time, it is never wrong for long, and it commits you to nothing. A constraint list is the opposite: it is a public statement about what the product will refuse to do, which a competitor can quote back at us and a customer can hold us to.

We think that asymmetry is the whole point. Every serious objection to AI inside an accounting system is a question about limits, not features. Can it move money without a person. Can it close a period. Can it widen its own permissions. Can I prove what it did, a year later, to somebody who is paid to be sceptical. A features page answers none of those.

Anyone can add a capability. Publishing a limit is a commitment you have to keep.

What incumbents will do instead

SAP, Oracle, Microsoft, Sage, and Odoo will all ship credible AI features, and some of them will be better than ours in specific places. What is harder to retrofit is the architecture underneath: a permission model that describes what software may do rather than what people may do, an audit schema that records reasoning and confidence beside the resulting entry, and a policy engine positioned between intention and execution.

Those are not features you add in a release. They are decisions about where the execution path runs, and a system designed around human-initiated screens has to be substantially rebuilt to accommodate them. That is the actual thesis behind being AI-native rather than AI-enabled, and it is the reason the governance pages exist before most of the agent pages do.

How to evaluate any vendor on this

Four questions, useful against us as much as anyone else. Ask where the permission check happens — if the answer is the system prompt, that is an instruction rather than a control. Ask what a single audit record contains, and whether it includes the model version and the policy evaluated. Ask what happens to accuracy when a model is updated, and whether there is a gate or a changelog. And ask for the list of things the agents may never do, in writing.

If a vendor cannot answer the fourth question, it is usually because the answer is nothing.

Where to go next

If you are evaluating, start with authority levels — it is the page a controller will care about most. If you are already comfortable with the model and want to see the evidence it produces, go to the audit trail.

Questions

What comes up in diligence.

Is any of this required for SOC 2?

SOC 2 assesses your control environment, and automated activity inside a financial system is squarely in scope. The authority matrix and the audit export are what most auditors want to see. Note that SOC 2 says nothing about whether the ledger is correct, which is a separate assurance we address through the shadow ledger and a third-party engine review.

Who at our company administers this?

Typically the controller owns policy definitions and an administrator owns authority levels, which keeps the person defining rules separate from the person granting scope. Some customers require two administrators to approve any increase.

What happens during an incident?

Authority can be dropped globally in one action, which puts every agent back to draft without losing in-flight work. Incidents affecting agent behaviour are reported to affected customers rather than absorbed into a release note.

Can we run agents in one entity and not another?

Yes. Levels are set per agent, per workflow, and per entity, which is the common pattern for groups that want automation in operating companies and manual review at the holding level.

What the agents may do, and how you know what they did

Everything here is a page, not a promise.

Authority levels 0–4

Permission model

The AI audit trail

Policy builder

Human-in-the-loop

Why AI never writes the ledger

Accuracy & evaluation

Data privacy & model use

Five levels, four permanent exclusions.

Why we publish the constraints rather than the capabilities

What incumbents will do instead

How to evaluate any vendor on this

What comes up in diligence.

Evaluate the controls, not the demo.