Picture a steering committee meeting four months after a pilot started. The demonstration is good: the tool suggests general ledger codes for non-PO invoices and most of the suggestions look right. Then the questions start. How much time did it save? Nobody measured the old process. Can it go live? IT wants a security review because the vendor asked for write access. Has internal audit seen it? Not yet. The payables lead, meanwhile, has gone back to coding manually because running both ways was doubling her work. The decision is deferred to next quarter.
An AI proof of concept in finance can work and still go nowhere, because a demonstration and a decision are different deliverables. A pilot designed to reach production answers the questions the steering committee will ask before the work starts, not after.
Why finance AI pilots stall
The surveys show a wide gap between activity and result. A Gartner release in June 2026, based on finance leaders it surveyed in mid-2025, put the share of finance organizations that had implemented AI or planned to at 84%, against 7% reporting high or very high impact. McKinsey's 2026 State of AI research, which covers every function and not finance alone, had 44% of respondents saying AI is scaling across their enterprise. Hackett's 2026 key issues work, sample undisclosed, found 77% of organizations citing a lack of AI talent.
The reasons pilots stall in finance are usually more ordinary than talent or technology.
No baseline. If nobody measured the current process, any result is an opinion.
Criteria agreed afterwards. When success is defined after the pilot, it gets defined to fit what happened, and nobody on the committee trusts it.
Scope that grows. A pilot that starts with one entity's invoice coding and adds a second entity, then receipts, then a chatbot, never finishes anything.
Access negotiated late. A request for write access to the ERP in week six triggers a security and controls review that can outlast the pilot.
Nobody owns the control. The process owner thinks IT owns it, IT thinks finance does, and internal audit hears about it at the end.
No decision date. Without one, the pilot runs in parallel with the old process until people quietly stop using it.
Seven elements of an AI proof of concept that can reach production
| Element | What to decide before starting | Why it matters for production |
|---|---|---|
| One process | A single process in a single entity or business unit, with a clear start and end | Keeps the result measurable and the build small |
| Read-only data | The AI reads from the ERP or a copy; its outputs are suggestions a person acts on | Avoids a late security review and keeps the ERP as the book of record |
| Baseline | Volume, hours, error or rework rate and cycle time for the current process | Gives the decision a comparison, not an impression |
| Success criteria | The thresholds for go, extend and stop, written down and signed | Prevents criteria being fitted to the result |
| Control owner | A named finance person accountable for the control the AI touches | Gives internal audit and the auditors one person to deal with |
| Decision date | The day the committee decides, fixed at the start | Stops open-ended parallel running |
| Production path | Who would run it, in which environment, at what cost, with what support | Means a "go" decision can be acted on |
The last row is the easiest to leave blank. A pilot built on a vendor's demonstration environment, with data cleaned for the purpose, can perform well and still have no route into the real process.
Choosing the process and drawing the boundary
Pick from the top of a ranked list. A process with high volume, written rules, structured data and a person already reviewing exceptions gives the clearest result in a short time. The scoring method is in an earlier issue on ranking use cases.
Then draw the boundary tightly. Take a group that wants AI to suggest codes on non-PO invoices. A sensible pilot covers one entity, existing suppliers only, and one month of live volume, with new suppliers and intercompany invoices excluded. Each exclusion is written down so the result is not later criticized for what it never attempted.
Check what your ERP vendor already provides before building. SAP's accounts payable page for Joule, published in October 2026, names a payment exception and resolution agent and a bank account validation agent among others. Microsoft's account reconciliation documentation for Dynamics 365 Finance, updated 1 September 2026, describes an optional Copilot-powered agent that proposes the most likely action for each item. Both are vendor descriptions and say nothing about performance on your data. A pilot can test a vendor feature against a custom build on the same baseline, which can be the most useful comparison a CFO gets.
Setting the baseline and the success criteria
| Measure | Baseline method | Form of the success criterion |
|---|---|---|
| Hours per unit | Time logging for four weeks before live running, plus system volumes | Reduction against baseline on the same volume |
| Output accuracy | A person reviews a sample of AI outputs and records accept, correct or reject | Share accepted without change, above a stated level |
| Rework or exception rate | Count of items reworked or blocked in the baseline period | No increase, ideally a fall |
| Cycle time | Elapsed time from receipt to completion in the system | Reduction, or no worse |
| Control evidence | What the auditors would ask to see | Every suggestion and human decision logged and retrievable |
Write the thresholds as numbers before the pilot starts, and add a stop criterion: the level below which the pilot ends early. If the team cannot agree on the numbers, the scope is probably still too loose. Collecting the baseline is covered in the May issue on time audits.
Build the controls in from the first week
Keep it read-only. The AI reads data and proposes. A person posts, releases or changes anything. This is the simplest control and the one that most shortens the path to approval.
Log both sides. Record what the AI suggested and what the person decided, with the time and the reviewer. That log becomes the control evidence and the accuracy measure at once.
Agree the evidence with internal audit early. A short meeting in week one costs little. Finding out in week ten costs the decision date.
Limit the data. Give the tool the fields the process needs and nothing more. Access, logging and sign-off get fuller treatment in our August issue on guardrails.
Many finance functions are not ready for this yet. Of the 1,013 senior finance leaders KPMG surveyed in March 2026, 42% said their organizations were "fully assurance-ready" where finance processes use AI. In Deloitte's Q2 2026 CFO Signals survey of 200 North American CFOs, 19% said they have the greatest responsibility for AI governance. Whoever holds that responsibility in your organization should know about the pilot from the start.
A twelve-week shape
| Weeks | Work | Output |
|---|---|---|
| 1 to 2 | Scope, boundary, control owner, criteria; agree evidence with internal audit | Signed one-page pilot charter with the decision date |
| 1 to 4 | Baseline measurement on the current process | Baseline figures |
| 3 to 4 | Read-only data access, build or configure | Working tool on a test sample |
| 5 to 9 | Run on live volume in assistive mode; a person reviews every output | Logged suggestions and decisions |
| 10 to 11 | Measure against criteria; cost the production path | Results pack |
| 12 | Decision meeting | Go, extend once, or stop |
Baseline work starts on day one so it is finished before live running begins.
Running the decision meeting
There are three outcomes, and all three are acceptable.
Go. The criteria are met, the control owner is satisfied, and the production path is funded and assigned.
Extend once. A specific criterion was narrowly missed for a reason that can be fixed, such as a data field that was mapped wrongly. The extension has its own date and does not repeat.
Stop. The criteria were not met, or the production cost outweighs the gain. Record what was learned about the process and the data. A clean stop costs less than a pilot that drifts for another two quarters.
What a proof of concept will not tell you
Full-scale behavior is outside its reach. A pilot on one entity and existing suppliers leaves out the edge cases, the other entities and the months with unusual volume. Vendors also change their models, which can change results after go-live. Plan to keep measuring accuracy in production.
Nor will it tell you whether people will use it. A pilot team is usually willing and well supported. Adoption across the wider function is a separate piece of work, with its own training and its own owner.
Frequently asked questions
What is an AI proof of concept in finance?
It is a time-limited test of whether an AI-assisted version of one finance process performs better than the current one, on the company's own data, against a baseline and success criteria agreed in advance.
How long should a finance AI pilot run?
About ten to twelve weeks from scoping to decision is a workable shape for a single process. The decision date should be fixed on the first day, with at most one extension for a specific reason.
Why do AI pilots in finance fail to reach production?
Usually because there was no baseline, success was defined after the fact, nobody owned the control, write access triggered a late security review, or there was no date on which a decision had to be made.
What success criteria should a finance AI pilot have?
Numeric thresholds for hours per unit, output accuracy on a reviewed sample, rework or exception rate and cycle time, set before the pilot starts, plus a stop criterion and the control evidence the auditors will need.
Should an AI pilot have write access to the ERP?
No, not at the pilot stage. Read-only access with a person posting or releasing anything keeps the ERP as the book of record and avoids a security review that can outlast the pilot.
Should we test our ERP vendor's AI features or build our own?
Test what the vendor already offers first, and compare it with a custom build on the same baseline if the gap matters. Vendor descriptions of AI features are not evidence of how they perform on your data.
Where CFOLogic fits
We scope proofs of concept with CFOs one process at a time, agree the baseline and criteria up front, and build on the system already in place, whether SAP, Microsoft Dynamics or QuickBooks Online. The design is read-only by default, and a person approves every output that leaves the finance team. The engagement runs under CFO Success Partners. For the kind of exception layer a pilot might lead to, see our purchase-to-pay exception board, a demo built on fictional data.