Ask a finance leader about their organisation's AI programme and you will usually hear about a pilot. Ask what happened to it and the answer is quieter. The model worked. The demo landed. And then it stopped, somewhere short of the systems that actually run the business.

The demo is the easy half

Extracting fields from an invoice is close to a solved problem. A capable model will read a supplier name, an invoice number, a date and a total from most documents you put in front of it. That is the part that demonstrates well in a boardroom, and it is the part that vendors optimise for.

The difficulty starts immediately afterwards. A number that has been read is not a number that has been accepted. Before anything can post, it has to survive the purchase order it claims to match, the receipt that may or may not exist yet, the tolerance rules the organisation has agreed, the tax treatment for that jurisdiction, the cost centre it should be coded to, and the approval hierarchy that governs who is allowed to say yes at that value.

Where pilots actually die

In our experience the failure is rarely intelligence. It is integration, and it takes a few recognisable forms.

  • The last mile has no owner. The pilot proves extraction, then hands a spreadsheet to a team that still keys the result into the ERP. Nothing has been automated, the work has been moved.
  • Exceptions were never designed. A process that handles the clean cases and escalates everything else has not removed effort, it has relocated it into a queue that nobody staffed.
  • The model does not know your rules. A general model knows what an invoice is. It does not know that this supplier bills in a particular format, that this plant tolerates a certain variance, or that this approval threshold changed last quarter.
  • Nobody can audit it. Finance cannot accept an outcome it cannot explain to an auditor. If the reasoning behind a posting is not recorded, the control environment rejects it regardless of accuracy.

What changes when the agent sits inside the system

An agent that runs inside the ERP is working with the live purchase order, the live goods receipt and the live master data, not a copy of them. It can read the tolerance configuration rather than have it re-described. It can write back through the same interfaces a human clerk would use, which means the audit trail, the authorisation checks and the segregation of duties that already exist continue to apply.

That last point matters more than it first appears. A great deal of the governance work an organisation has done over twenty years is encoded in its ERP configuration. An automation layer that sits outside the system has to re-implement that governance, badly. One that sits inside it inherits it.

A more honest way to scope a pilot

If you are about to start, consider scoping the pilot around a posting rather than an extraction. Pick one document type, one entity and one approval path, and define success as a transaction that reaches the ledger without a human retyping it. It is a harder target and a far more useful one, because it forces every unglamorous question, master data quality, exception ownership, audit evidence, into the open in week one rather than month nine.

Twenty years of enterprise delivery teaches an uncomfortable lesson. The interesting part of the problem is almost never the part that demonstrates well.