AI Governance for Finance and Operations: Who Approves What, and What Gets Recorded

Executive summary

Most companies using AI in finance or operations have an AI policy. It lists approved tools, says what data may go where, and was signed by someone senior. Ask a different question and it goes quiet: if the AI proposed a change to a supplier payment last Tuesday and the change was wrong, whose name is on it?

AI governance for finance and operations is a standing routine. It says what the AI may touch, who approves each kind of action before it runs, what is recorded, and what changes after something goes wrong. A policy document can describe that routine. It cannot run it.

The hidden dependency is easy to state. Every action an AI proposes depends on a person who owns the result. When that person is unnamed, absent or approving forty items in forty minutes, the action still happens. Nobody answers for it.

There is a hidden cost too. An AI that proposes forty changes a week does not remove the work. It moves the work from preparing changes to checking them, and checking is the part nobody budgeted time for.

The method has five working parts: scope, approval rules set before the AI recommends anything, separation between whoever starts an action and whoever approves it, a record with provenance, and a review cadence with a rule for misses. It covers a payment run, a forecast adjustment, a reorder point and a customer promise date in the same way. An illustrative distributor shows each part with numbers, and two templates are ready to copy.

If you are still deciding where AI should act at all, start with what agentic AI is and the AI use case prioritization framework. The wider set of pages is in the AI trust and governance hub.

When to use this

Use this method when:

• An AI tool already drafts, recommends or changes something in finance or operations, even if a person clicks the final button.
• Your AI policy names tools and data rules but no approvers, thresholds or review dates.
• Approvals happen in the tool, in chat or by email, with no single place to see them later.
• Someone asked "who approved that?" about an AI-assisted change and the answer took more than five minutes to find.
• You are about to let AI propose actions in a second area and want one framework, not two.

The method assumes a working approval structure for people already exists. If spending authority and payment approvals are unclear for your staff, fix that first with the decision rights matrix template. AI governance borrows that structure. It cannot invent one.

Diagnostic questions

Answer these about the AI actions you already allow.

1. Can you list every kind of action the AI may propose, on one page, without opening the tool?
2. For each kind, is there a named approver (a person, not a team inbox)?
3. Were thresholds written before the AI started recommending, or adjusted later to fit what it already did?
4. Can the same person start an action and approve it?
5. For the last AI action that touched money or stock, can you show which records it used, what it proposed, who approved, what was done and what happened next?
6. What was last month's approve, reject and send-back split, and how long did approvals take?
7. When an AI action last proved wrong, what changed in the rules?

If you can answer 1 and 2 but not 5 to 7, you have a list of permissions and no routine. That is the common case.

One pattern behind it comes up often in mid-market finance teams, offered here as an illustrative composite rather than any one company: IT or legal owns the AI policy and writes it about tools and data, while the approvals happen inside the tool, owned by finance and operations. Each side assumes the other governs the decision. Nobody owns the gap between them, and the gap is where the money moves.

Framework: five working parts of AI governance

Every AI action passes through the same five parts, whatever it touches.

Scope

Write scope as verbs and objects: "may propose payment dates for approved suppliers within agreed terms." Write the exclusions just as plainly. Scope also covers what the AI reads. An AI that cannot see a dispute flag will propose a reminder to a customer in dispute. Start narrow. Widening scope later is a decision with a name and a date.

Approval rules

Thresholds written after go-live tend to be written around what the AI already does. Set them first, in dollars or units, with a named approver and a named backup per band. Small, reversible, in-scope actions with a clean history can later move to sampled review. A reminder on a $3,000 invoice is a candidate. A date change on a $90,000 supplier payment is not.

The approval request is itself a control, and usually the weakest one. If it shows the proposed change and an Approve button, the approver can confirm that the AI asked, not that it was right. When you compare AI tools, judge their governance by what the approval screen puts in front of the approver: reasoning, source records and the tool's history on that kind of action. A policy page and an activity log tell you much less.

Separation

The person who sets up a supplier does not approve that supplier's payments. Keep that rule when AI is involved, and count the AI and whoever prompted it as the starter. The AP process design guide covers the human version.

Record

"Approved by J. Patel, 09:14" tells you almost nothing. A useful entry records what the AI found, the source records with dates or versions, the reasoning shown, what was proposed, who approved and what they saw, what was done, and what happened afterward. The last field is the one most often missing and the one review depends on. Keep it append-only: corrections are new entries.

Review cadence

Pick a day each month, a sample size per action type and a reviewer who is not the usual approver. Then write the rule for misses: when an approved action proves wrong, the review decides whether scope, a threshold or an approver changes, and records the answer, including "no change" with a reason.

The sentence to take back to your team: a policy says what the AI may do; governance says who answers when it does it.

Step-by-step process

1. Inventory current AI actions, including tools someone set up without asking. Owner: CFO with the operations lead. Output: one-page list of action types.
2. Write scope per action type: verbs, objects, records read, exclusions. Owner: each process owner.
3. Set thresholds and named approvers, borrowed from existing decision rights, with backups. Owner: CFO.
4. Check separation. In a small team, require a second approver above a lower threshold. Owner: controller.
5. Define the record entry (see Templates). If the tool cannot store it, keep a shared register. Owner: controller.
6. Brief approvers. A request shows reasoning, source records and the AI's history for that action type. An approver who cannot judge it sends it back. Owner: CFO.
7. Set the review day, reviewer and samples. Owner: CFO.
8. Run the first review, score approval quality and record what changes. Owner: reviewer.

The review belongs in the monthly business meeting described in the operating review system.

Worked example: a distributor allowing three kinds of AI action

Illustrative. The company, figures and thresholds are invented to show the method. They are not benchmarks.

The setup

A mid-market industrial distributor lets AI propose three kinds of action. Volumes are for a four-week month.

Check: 100 + 24 + 36 = 160 a month, or 40 a week over four weeks. Base samples: 4 + 3 + 3 = 10.

One payment change as the record shows it: the AI found a supplier offering 2% for payment within 10 days on a $40,000 invoice, checked the cash forecast and proposed paying on day 9. The controller approved (under $50,000, within terms). The record shows the payment made and $800 taken (2% of $40,000). Every field is filled, including what happened.

The composite: forty approvals a week, none rejected

This is a composite, illustrative pattern. It describes no single company.

For three months the approvers approve 100% of the 40 proposals a week, each in under a minute. Nothing is rejected or sent back. Leadership reads the 100% as proof the AI is good.

Then the controller, newly assigned as reviewer, pulls the month's base sample of 10 and checks each against the source records. Three have a problem:

• Two reorder-point changes used a demand window containing a one-time project order. One item went from 400 to 700 units at $18 a unit, the other from 250 to 450 units at $30. That is 300 × $18 = $5,400 plus 200 × $30 = $6,000, so $11,400 of stock bought for demand that will not return. Both changes were well above 20% (75% and 80%), so both went to the operations manager, who approved each in under a minute. The higher band added a name. It did not add a check.
• One reminder went to a customer disputing a $22,000 invoice. The dispute sat in the CRM, which the AI could not read, and at under $25,000 the email stayed with the credit controller, who did not check.

Three of ten is 30%. Ten is too few to call the true rate 30%; applied to 160 proposals it would suggest about 48 flawed approvals a month (160 × 0.3), and the real figure could sit well either side. What the sample does prove is that the rate is above zero, and that the 100% approval rate was measuring speed.

Every one of those approvals was recorded: approver, time, proposal. The record was complete, and nothing in it was responsible for what happened next. Nobody compared the new reorder points with what the items sold the following month. Nobody asked why the dispute flag never reached the approver. A log of signatures cannot tell you whether anyone read what they signed.

People propose wrong things too. What made these three expensive was that each one flowed past a named approver who was not positioned to catch it, while the approval rate said all was well. Most AI governance reviews the AI. Here the AI did what it was set up to do with the records it was given. The approvals were what failed.

What changed after the review

Four decisions were recorded. Reorder proposals must now show the demand window and flag any single order above 10% of its volume (approved by the operations manager). The AI may read dispute status from the CRM, and any open dispute sends the reminder to the controller regardless of amount (approved by the CFO). Approval quality joined the monthly review, and a month with zero rejections now prompts a conversation. The two reorder points were reset as new entries referencing the originals.

The cost of doing this properly is small. Forty sub-minute approvals took under 40 minutes a week. At 20 higher-band items a month, a three-minute read on each is one hour, and a one-hour monthly sample makes two hours a month, against $11,400 of excess stock from two approvals.

Templates

One-page AI governance policy

If a section cannot be filled in, the policy is not ready.

Record entry layout

Metrics and KPIs for AI governance

A 100% approval rate can mean the AI is excellent or that nobody is reading. The record alone cannot tell you which. A sample can.

Common mistakes

Treating the signed policy as the governance. A policy drafted in a workshop and handed over is where most AI governance stops. The first miss is where it should start. If nobody can say what changed after yours, run the first review this month.

Naming a team as approver. "Finance approves" means nobody does. Name a person and a backup.

Letting the prompter approve. Whoever asked the AI for the proposal is its co-author.

Recording the signature and not the outcome. Without "what happened," the review has nothing to compare against.

Reading a high approval rate as success. Sub-minute approvals on large items mean the request is not built to be judged.

Reviewing everything, then nothing. Full review in month one usually lapses by month three. A fixed sample on a fixed day lasts.

AI prompt assistance

AI can draft and check the governance documents. It should not set thresholds or name approvers. Do not paste confidential data into a tool your company has not approved.

1. Convert an existing policy.

Here is our AI policy and our decision rights for finance and operations. Rewrite it into ten sections: purpose, scope, approval rules, separation, what approvers see, the record, review cadence, after a miss, changing the policy, owner and date. Where our documents give no named person, threshold or date, write [MISSING]. Do not invent one.

Check: the CFO or process owner fills every [MISSING] before anyone signs.

2. Find gaps in a month of records.

Here is last month's AI action record export with these fields: [list]. By action type, compute approve, reject and send-back rates, median time to approve, and the share of entries with the outcome filled. List entries where starter and approver are the same person. Show every calculation.

Check: recompute one action type by hand and confirm the separation list against the source.

3. Draft the review note.

Using only the sampled entries and findings below, draft a monthly review note: what was sampled, what was found, and for each miss a proposed decision on scope, threshold or approver. Mark each "proposed" and leave the approver blank.

Check: the policy owner edits and approves each decision by name before it is recorded.

Implementation guide

In the first month, expect to find an AI action nobody approved. In the third, make at least one recorded decision, even if it is "no change, because."

Governance: the CFO owns the policy and the review. Each approver owns the decisions in their band. The reviewer owns the sample and findings. Who approves which action is covered in decision rights for AI actions, and how misses feed a standing risk list in the AI risk register and review cadence.

Downloadable assets

The policy template, record entry layout and metrics table above are designed to be copied into a document or spreadsheet. No calculator exists for this topic; a shared spreadsheet with one row per record entry is enough for the first three months.

Related resources

• AI trust and governance hub: every page on trusting and governing AI that acts.
• Decision rights for AI actions: who approves which AI action, and when authority can widen.
• AI risk register and review cadence: turning misses into a standing risk list with owners.
• How to trust an AI finding: what to check before acting on what an AI reports.
• Decision rights matrix template: the human approval structure AI governance borrows.
• AP process design: separation and approval in the payment cycle.
• Operating review system: the meeting where the monthly sample review belongs.

Frequently asked questions

What is AI governance for finance and operations?

It is the standing routine that decides what AI may propose, who approves each kind of action before it runs, what is recorded, and what changes after a miss. A policy document describes it. Named approvers, a record and a monthly review make it real.

Who should approve AI actions?

A named person whose existing authority covers the action, with a named backup. If a controller approves supplier payments under $50,000, the controller approves AI-proposed changes to those payments. Whoever prompted the AI should not approve.

What should an AI approval workflow record?

What the AI found, which records it used, its reasoning, what it proposed, who approved and what they saw, what was done, and what happened afterward. The outcome is the field most often missing. Without it, a review can confirm someone signed but not whether the decision was right.

Is a 100% approval rate a good sign?

Not by itself. It can mean the AI is reliable or that approval has become a formality. Check time to approve, sample approved actions against the source records, and treat a long run with no rejections or send-backs as a reason to look closer.

Does AI accountability change who is responsible?

No. The person who approves an AI-proposed action answers for the decision, as a manager answers for a request they sign. Governance makes sure that person exists, can see enough to judge, and is named on the record.

How this works in a System of Performance

An AI policy names what is allowed, and a log records who clicked. Neither checks whether an approval was a judgment or a reflex. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. To see where your own approvals stand first, bring it to us as a launch partner.