Enterprise Adoption2 min read

AI Agents That Pay Invoices Need the Rules Clerks Already Follow

By , Senior AI ConsultantPublished

Finance already wrote the controls an AI agent needs, a login of its own, an approval limit, a ledger and a handoff, because it wrote them for clerks, and Twilio's supplier-call agents follow them.

Twilio's chief information officer wrote that an AI agent should not be allowed to move money until it has the same controls as the people it works beside, and Twilio already runs agents on supplier calls under those rules. The useful part is not Twilio. It is the observation that finance has been through this problem before.

The matching was never the hard part

Software has matched invoices to purchase orders and delivery receipts for years. What it did when the numbers did not agree was push the invoice to a clerk. Now vendors are selling agents that try to resolve the mismatch themselves, for example when a supplier's name is spelled a little differently from the one on file. That is a judgment call, and judgment calls are where a clerk's authority used to matter.

Picture a small distributor that gets 40 mismatched invoices a day. At five minutes each, that is over three hours of one person's day. An agent could clear the routine half of them, but only if someone decides what routine means: say, a difference under $50 on an invoice with a matching delivery receipt. Anything beyond that goes to a person. That limit is the same kind of limit a clerk already has.

Four things a clerk already has

Finance never trusted people on goodwill. Since the Sarbanes-Oxley Act of 2002, public companies in the United States have had to make sure no single person controls a payment from request to release. The same habits translate directly to an agent.

The first is a login of its own. If an agent borrows a manager's credentials, the log shows the manager approving a payment they never saw, and nobody can tell afterward which of the two did it. This is the same weakness we described in how an agent carries the keys of whoever set it up.

The second is a written list of actions. A clerk cannot release a payment above their limit, and an agent should have an explicit list of what it may do and nothing else.

The third is a record that nobody edits afterward, the agent included. Accountants never erase a ledger entry; they add a correcting one. An agent's trail of requests, decisions and payments should work the same way, because an auditor will ask for it, and so will your own team the first time a payment looks wrong.

The fourth is a handoff that does not start from zero. When a request falls outside the agent's list, the person who takes it should get the whole conversation, so they spend their time deciding, not asking the supplier to repeat themselves.

What this changes for a finance team

The question that decides whether a team can adopt an agent is no longer how clever the model is. It is whether the agent has a job description. A finance director weighing any agent for payables can ask four things: does it have its own login, what exact actions can it take, can it alter its own log, and what does the human receive when it hands over a case?

If the vendor answers all four, the team can start with a narrow limit and widen it as the log shows the agent behaving, the way a new hire's limit grows. If the vendor cannot, the agent is a clerk with the manager's password, and that is the situation finance spent decades learning to avoid.

Share this

STAY INFORMED

Get AI intelligence like this delivered to your inbox.

Free forever · Unsubscribe anytime


You May Also Find Valuable