AI Agents for Accounts Payable: Who Does the Agent Answer To?

An AI agent for accounts payable is software that reads supplier invoices, matches them against purchase orders and receipts, and releases payment without a person keying it in. Capture and matching are largely solved. What is not solved is authority: what the agent is allowed to pay, who signs off above the line, and what proof survives for the auditor. Until accounts payable controls exist that work when the agent is the one deciding, the agent prepares the payment run and a human still presses release.

If you are reading this because your AP automation already handles capture and three-way match, and someone above you has asked why a person is still approving every batch, you are in the right place. The answer is not that the agent cannot do the work. It is that nobody has written down, in a form an auditor accepts, what it is allowed to do.

The speed case for agents in AP was won a while ago. Faster than your team, cheaper than your team, never off sick at quarter end. None of that is why the payment run is still manual. Control is.

Key takeaways

• The work in AP was never the bottleneck for agents. Authority is: what the agent may pay, within what limits, with whose sign-off.
• Most AP controls assume a named human at the decision point. Approval matrices, maker-checker and vendor-master callbacks all quietly break when the actor is an agent.
• An agent reading the AP inbox is an ideal target for payment fraud. It is diligent, fast and never suspicious.
• KYI lets the finance head write payment rules in plain English, confirm them once as exact rules, and have every payment checked against them before release: yes, no, or route to a named approver.
• Every decision, including every refusal, comes with a signed receipt your auditor can verify without trusting your system's logs, or ours.

The work was never the hard part

Look at what AP automation already does well. OCR and extraction pull invoice data. Coding rules assign GL accounts. Three-way match compares invoice, purchase order and goods receipt. Exceptions route to a queue. Most mid-market finance teams have some version of this running.

Agents extend that pipeline one step further: from preparing the payment to releasing it. Technically, that step is small. The agent already knows the supplier, the amount, the due date and the match status. Releasing the payment is one more call.

Organisationally, that step is enormous, because it moves the agent from recommending to deciding. And every control your finance function relies on was designed around the assumption that a person makes that decision.

Accounts payable controls were built for people

Your accounts payable controls were not designed badly. They were designed for people. Put an agent in the decision seat and each one loses the assumption it rests on.

The last row is the one that surfaces at year end. Under Sarbanes-Oxley Section 404, or any internal control framework, the auditor tests whether a control was designed properly and whether it actually operated. "The agent was configured with limits" answers the first. It does not answer the second. The auditor wants to see the control working on real transactions, and a log written by the agent's own platform is testimony from the party being tested.

The accounts payable fraud an agent is most exposed to

Payment fraud against finance teams is not slowing down. The AFP's 2026 Payments Fraud and Control Survey found that 74% of organisations experienced business email compromise in 2025, up from 63% the year before. The FBI's Internet Crime Complaint Center reported almost $3.05 billion in business email compromise losses for 2025.

The classic attack is simple. An email arrives that looks like it comes from a real supplier: "We have changed banks. Please use the account details below for all future payments." Sometimes the domain is spoofed. Sometimes it is one letter off. Sometimes the supplier's own mailbox has been compromised and the email is genuine in every technical sense.

People catch some of these because something feels wrong. An agent has no such instinct. It is diligent, it reads every email, it acts quickly, and it does exactly what the most plausible instruction in front of it says. That is what makes it valuable in AP. It is also what makes it the ideal target.

The defence is not a smarter agent. It is a rule the agent cannot override: if a supplier's bank details change, no payment goes to the new account until a person confirms it. That rule has to sit outside the agent, because the agent is the thing being tricked.

How KYI fits into the payment run

KYI (Know Your Intent) is the layer that sits between the agent deciding to pay and the payment being released. It answers one question every time: is this payment inside what the finance team authorised?

It works in three steps.

Step 1: You brief it, you do not configure it

The finance head writes the payment rules the way they would brief a new controller on their first day. No forms, no settings screens, no rule builder.

Pay only suppliers on our approved list.

Anything above $10,000 on one invoice waits for Priya, our payments officer, to approve.

Never pay the same invoice twice.

Only pay invoices already approved in our accounting system.

If a supplier's bank details change, hold the payment until we confirm by phone.

Step 2: KYI reads it back, you lock it

KYI turns that note into exact rules and shows them back for confirmation.

The finance head confirms the structured rules, not the original sentence, and that confirmation is what gets signed and versioned. A model may help translate plain English into rules. It never makes the payment decision. Once the rules are locked, every yes or no is produced by those rules exactly, the same way every time, and no instruction arriving in an email or a prompt can talk its way around them.

Change the rules and you get a new version. Every decision records which version it was checked against, so "what were the rules on 14 March?" always has an answer.

Step 3: Every payment asks first

Before the agent releases a payment, it checks with KYI. There are three possible answers:

• Allow. The payment is inside the rules. It goes out through your normal payment rails.
• Ask a human. The payment needs a named approver. It waits for them.
• Deny. The payment breaks a rule. It does not go out, and the agent is told which rule failed.

Every answer comes with a signed receipt.

And if KYI does not answer at all, nothing goes out. No answer means no payment: the batch waits until KYI responds or a person releases it manually. KYI is built for high availability, so this is rare, but when it happens the payment run fails safe rather than paying unchecked.

If you have used positive pay, the shape will feel familiar. Positive pay has the bank check each presented cheque against the list you issued before it clears. KYI checks each agent payment against the rules you signed before it is released.

One payment run, traced

Here is a single payment run under the five rules above. Five invoices, five decisions.

The last one is the one that matters. The agent did exactly what it was built to do: it read the email, believed it, and tried to pay. KYI did not. The receipt for that refusal looks like this:

decision:  deny
rule:      bank_change
passed:    supplier, amount, invoice
version:   3
receipt:   0x2b91…4e08

Note what it records. Not just "denied", but which rule failed, which rules passed, and which version of your rules was in force. Your payments officer sees why it stopped. Your auditor sees the control working on a live transaction.

Controls you can ask for

The five rules above are a starting point. Every finance team runs AP slightly differently, so KYI is shaped around your process with our team rather than forcing your process into ours. Controls finance teams ask for include:

• Approvals by threshold. Above your line, a named approver decides. Different lines for different entities, suppliers or currencies.
• Matched against your records. Pay only what is approved in your ERP or matched to a purchase order and goods receipt.
• Duplicate payment prevention. The same invoice never gets paid twice, including re-sent copies with a reformatted invoice number.
• Bank detail change holds. New or changed accounts wait for a callback, or a cooling-off period, before any money moves.
• Budgets that hold. Monthly ceilings per supplier, per cost centre or per department. Enforced before release, not reported after.
• Payment windows. Payments go out only on your scheduled payment days or within set hours.

If the control exists in your AP policy manual today, the question to ask is simple: can it be written as a sentence? If it can, it can be a rule.

What your auditor sees

This is where agent-run payments either pass the audit or create a finding.

An approval record shows a payment happened. It does not show that anything checked it. The record that proves a control was operating is the refusal: the agent tried to pay, the check said no, and here is the evidence. Most systems return a refusal and throw the record away. KYI records refusals through exactly the same path as approvals: same format, same signature, same retrieval.

That gives your auditor three things they normally have to reconstruct from screenshots and interviews:

1. The authority. The signed, versioned rules the finance team approved, as they stood on any given date.
2. The decisions. Every payment the agent attempted, with the verdict and the rule that produced it.
3. The independence. Each receipt is signed by a party with no stake in whether the payment went out, and can be verified without access to your systems or ours.

The third point is the one that changes the conversation. A log your AP platform wrote about itself is testimony. A receipt that can be checked by someone who trusts neither of you is evidence. We wrote more about why that distinction now decides enterprise reviews in The AI Agent Security Questionnaire.

Where Abstraxn fits

Abstraxn builds KYI. The detail finance teams ask about first is what it touches, so here it is plainly.

Abstraxn never holds your money, never holds your keys, and never sits in your payment path. Payments still go out through your bank, your ERP and your existing payment rails. KYI sits beside them and answers one question before release: is this payment allowed? Your systems act on the answer.

That constraint is deliberate. A party with no stake in whether a payment succeeds is the only kind of party whose record of that payment means something to an auditor two years later.

What your team actually integrates. Your engineering or AP platform team adds one check before payment release. The agent asks, KYI answers allow, deny or ask a human, and returns a signed receipt. Rules are set by the finance team in plain English and confirmed once. The technical detail lives in the KYI Framework documentation.

What it does not replace. KYI is not an AP automation platform. It does not capture invoices, code them or match them. It is the authority layer that lets whatever you already use for that hand the final step to an agent, without the payment run becoming the least controlled part of your finance function.

Frequently asked questions

Related reading

• Know Your Intent (KYI): Agents Have an Identity Layer. They Have No Intent Layer.
• The AI Agent Security Questionnaire: 12 Questions Enterprise Buyers Ask, and What a Passing Answer Looks Like
• AI Agent Spending Limits: How to Build a Mandate That Can't Be Overspent
• Agentic Commerce Compliance: Why the Boring Layer Is the One That Unlocks the Money
• Who Is Liable When an AI Agent Is Right?