AI invoice approval is the use of an AI agent to decide, without a person, that a vendor invoice should be paid. The AI agents arriving in accounts payable in 2026 do this well on routine invoices inside the invoice approval workflow, and that is the problem. An agent that approves against vendor history and a risk score is approving against the two things a fraudster can study. The risk is not that the agent fails. It is that it works exactly as designed while someone has learned how it decides.Definition: Gaming the agent is committing fraud not by breaking an AI system, but by learning how it decides and staying inside its rules, so the control itself approves the wrong outcome.
I think there are more use cases for agents in workflows, including accounts payable. I run a company that builds them. This article is about where an agent’s authority should stop, and why the answer is the oldest idea in internal control, not a newer model.
Most of it. AI invoice approval software and the agents built into ERP systems such as Yardi Voyager, MRI, RealPage and Bottomline NexusPayables now handle the parts of the invoice approval process that used to be manual data entry: optical character recognition and data capture from incoming invoices, invoice coding to the right GL account and property, two-way and three-way matching against purchase orders and receipts, duplicate-invoice detection, AI-powered routing that learns which approver handles which vendor, and real-time visibility into invoice status and pending liabilities for cash flow forecasting. Every action is logged, so audit trails are better than they were when invoices sat in email. Processing time that took days now takes minutes, and finance teams absorb rising invoice volume without adding people. None of that is in dispute, and none of it is what this article is about. The question is the last step, the approval itself, and what happens when the agent that prepared the invoice is also the authority that pays it.
There are two ways an AI agent goes wrong, and they deserve different responses. The first is unintentional error: the agent misreads a quantity, misroutes an invoice, codes a repair to the wrong property. Error is visible, random and correctable. You find it in reconciliation, you fix the prompt or the training set, and the error rate drops. Most of the governance writing about AI agents is about this.
The second is intentional exploitation, and it is the subject of this article. Someone studies how the agent decides and shapes their inputs to clear it. Nothing is broken. The dashboard is clean, the log is complete, every criterion was met. The agent did its job; the job was wrong. The Association of Certified Fraud Examiners reports that occupational fraud runs a median of 12 months before detection and that schemes lasting more than five years cost a median of $1.1 million, against $40,000 for those caught within six months (ACFE, Occupational Fraud 2026). An approval control that can be gamed does not shorten that clock. It hides it.
Outsiders game an approval agent the same four ways they have always gamed an invoice approval process, except that the agent is more consistent than a person, which makes it easier to learn. Every invoice approval system, whether a multi-level approval chain of people or an agent, publishes its rules to anyone patient enough to watch what gets approved.
In real estate these four moves land on an environment already built for them: thousands of vendors, hundreds of legal entities, site-level approvals far from the owner who pays, and purchase orders that drift into discretionary buckets. The purchase order deserves its own section, because “it matched the PO” is the answer most people give to everything above.
Insiders do something outsiders cannot. They change the control itself.
An agent’s decisions come from its criteria, prompts, thresholds, tool permissions and data sources. Anyone who can edit those can make every subsequent decision look compliant against a rewritten rule. That is fraud through the control, not around it. The variance band widens by a few points. A vendor category is added to the routine list. A data source is swapped for one the insider maintains. The log records every decision faithfully, and every decision is wrong.
The version of this to watch for in 2026 is the agent that rewrites its own rules. Several approval agents now analyze invoice history and regenerate their approval criteria on a schedule, monthly in at least one case, so they “get smarter over time.” Read that as a controller: the agent is learning from the invoices it approved, including the ones that should not have been. An inflated rate approved in March is part of the baseline in April. A scheme that stays inside the band does not just evade the control; it trains it. The ACFE found that more than half of occupational fraud cases involved either a lack of internal controls or an override of existing ones (ACFE 2026). An agent that can change its own criteria has built the override in.
Because a PO match is only as strong as the PO, and in most real estate operations the PO is the weakest record in the chain. Three-way matching is a real control when the PO is specific, approved by someone other than the invoice approver, and closed when the work is done. In practice, four things happen to purchase orders that turn the match from a preventive control into a rubber stamp, and an approval agent that trusts the match inherits every one of them.
None of these involve a forged document, a fake vendor or a changed bank account. They are the reasons a matched, in-budget, routine-looking invoice still benefits from a person behind it. That does not mean PO-based approval is wrong. Approving matched invoices on the strength of the PO is reasonable when the PO itself carries the segregation: one person raises it, a different person approves it, and someone who did neither confirms that the invoice matches the PO’s scope and not only its vendor and balance. With that in place, an agent can do the matching and the person confirming the match is a quick, independent check rather than a full review. Without it, “approve anything that matches a PO under $X” hands the fraudster a rule to work inside.
Red flags: a PO referenced by more than one vendor; a PO replenished more than once a year; a PO whose remaining balance never reaches zero; invoices whose line descriptions do not match the PO scope; a large project PO accumulating small unrelated charges; the same person raising and approving against a PO. Controls: one PO per vendor and scope with a defined close date; blanket POs only for named recurring contracts with a stored rate and frequency; replenishment and amendment approved above the site by someone who does not approve the invoices; description-level matching, not only vendor and dollars; and a monthly PO-to-vendor and PO-replenishment report reviewed by the controller. An agent is the right tool to produce that report. It is the wrong tool to be the only thing reading it.
No. Two agents checking each other in the same environment, under the same administrative rights, are two checks, not two independent controls. Segregation of duties means no single person or system can initiate, approve, pay and record the same transaction. Splitting the approval between a coding agent and an approval agent inside one platform, administered by one team, does not create a second authority. It creates a second log.
The case for this is older than AI. The GAO’s Green Book (2025 revision, Principle 10) and COSO’s 2013 framework both treat segregation as a core control-activity design, and the Center for Audit Quality’s guide to internal control over financial reporting uses “separating approval and payment” as its worked example. What AI adds is a new way to fail the test while appearing to pass it.
There is also a newer reason, and it comes from the models themselves. Research on large language models as evaluators found that they recognize and prefer their own output; a reviewer model rates the producer model’s work higher when the two share a lineage (Panickssery, Bowman and Feng, 2024). Two agents on the same model family are not two opinions. They are one taste, consulted twice. Vendor pairings that market “dual agents” flagging exceptions are selling exactly this arrangement.
An audit trail does not fix it. An audit trail is a log, not a control. It tells you what the agent did after the money moved. Google DeepMind’s AI Control Roadmap, published days after my original article, reaches the same conclusion from the security side: internally deployed agents should be treated the way security treats insider threats, with independent monitoring and change control over what the agent is allowed to decide (Google DeepMind, 2026). In July 2026 a hidden comment in a code repository hijacked an AI code-review agent into acting on instructions its operators never wrote (Eftsure, 2026). The mechanism is not theoretical.
The standards draw a line that is useful here, and it is not the line most vendors draw.
Fixed-rule automation is accepted. A three-way match against a purchase order, a duplicate-invoice block, threshold-based routing: these are automated application controls, and PCAOB Auditing Standard 2201 lets an auditor rely on them without a person reviewing each transaction, and carry prior-year testing forward under a benchmarking strategy, provided the program is stable and IT general controls over program changes and access are effective (AS 2201, Appendix B, paragraphs B28 to B33). The condition is the whole point. The rule is fixed, testable, and nobody can change it without a logged, approved change. An agent that regenerates its own rules monthly fails the first word of that condition.
A probabilistic model exercising judgment is new territory, and the regulator has said where it stands:
Human involvement “remains essential” for reviewing generative-AI output, and supervision and review expectations have not changed. PCAOB staff, Spotlight on generative AI in audits and financial reporting, July 2024.
COSO’s Achieving Effective Internal Control Over Generative AI (February 2026) recommends a use-case-based approach to human oversight, with evidence that the oversight occurred, and Deloitte’s and KPMG’s summaries both read it that way (Deloitte Heads Up; KPMG Defining Issues, April 2026). RSM’s practical reading is the one to keep on the wall: if you cannot produce a log showing the human review actually happened, you will struggle to show the control exists (RSM, April 2026). No PCAOB standard, SEC rule or COSO guidance authorizes a probabilistic model to be the sole approver of a payment. None prohibits it in those words either. The guidance points in a direction, and the direction is a person with independent authority at the decision that moves money.
In preparation, almost everywhere: data capture, invoice coding, three-way matching against purchase orders, duplicate-invoice detection, exception handling and approval routing. At the authority points, as the analyst, not the signer. This is also where the cash-flow benefit lives, because the delay in most invoice approval workflows is the queue in front of the approver, not the approval itself; an agent that arrives with the comparison done shortens the queue without removing the control, and early payment discounts are won or lost in that queue.
|
An agent should |
A person with independent authority should |
|---|---|
|
Capture, code and allocate the invoice; propose GL, property, entity and CAM treatment |
Approve the invoice for payment |
|
Compare the invoice to vendor history, the contract and property, and the rest of the portfolio, and flag what does not fit |
Decide a flag is a false alarm and release the hold |
|
Match to the purchase order and report when a PO is being used as a bucket |
Release payment from the bank or ERP |
|
Route to the right approver by amount, entity and property |
Change vendor bank details, remit-to or payment method |
|
Draft the vendor callback script and log the outcome |
Make the callback |
|
Produce an audit trail of every proposal and every human decision |
Approve any change to the agent’s own rules, thresholds, prompts or permissions |
The temptation is to let the agent approve the small, matched invoices and keep people for the big ones. I would be careful with that, for the reasons in the purchase-order section above: a $400 recurring inspection from a known vendor against an open PO is exactly the invoice an evergreen PO produces. The version that holds up is a PO match confirmed by one person who neither raised the PO nor submitted the invoice, so the segregation lives in the PO process even when the invoice approval is light. The agent’s job is to have done every comparison before that person looks, so the confirmation takes seconds instead of minutes. That is where the efficiency is. It is not in removing the person.
Non-PO invoices, which are most of real estate’s recurring services, make this sharper: there is no purchase order to match, so the agent’s comparison against the contract, the property and the portfolio is the only preparation the approver gets. Real estate makes the authority points easy to name: the invoice approval, the payment release, the vendor master, the owner distribution instruction, and the agent’s configuration. Everything upstream of those, capture, coding, matching, comparison, routing, exception triage, is where agents should run without a person in the loop, because none of it moves money.
Change control over the agent’s configuration. It is the highest-trust action in the environment, and in most deployments it is held by the same administrator who manages the workflow, or by the agent itself.
Role-based access controls in the ERP system usually stop at the workflow: who can approve, who can release, who can edit vendors. The agent’s configuration sits outside that model in most deployments. Treat an edit to the agent’s criteria, prompts, thresholds, tools or data sources the way you treat an edit to a vendor’s bank account: logged as a change request, approved by someone other than the requester, versioned, and reviewed on a schedule by someone outside the team that runs the agent. If the agent proposes its own rule changes from invoice history, those proposals go through the same gate. A rule the agent wrote for itself last month is not a control. It is a hypothesis about what normal looks like, formed partly from whatever it was fooled into approving.
Require an independent human control wherever an action:
Everything else is fair game for automation, and should be automated. The list is short on purpose. Most of what an accounts payable team does is not on it.
A preventive control. It is designed to stop a loss before it happens by making sure no single person or system can initiate, approve, pay and record the same transaction, so that committing a fraud requires at least two actors. Detective controls such as audit trails, reconciliations and anomaly detection find what preventive controls missed. An AI approval agent that collapses preparation and approval into one actor removes a preventive control and leaves only the detective ones.
Not on its own. Three-way matching verifies that an invoice agrees with a purchase order and a receipt; it does not verify that the purchase order was appropriate, specific or still valid. Evergreen POs, invoices attached to the wrong PO, large project POs used as parking lots, and approvers who can amend their own POs all pass a match. It becomes a reasonable basis for a light approval when the PO carries segregation of duties: raised by one person, approved by another, and the match confirmed by someone who did neither. An agent can run the match; a person who did not initiate the PO or the invoice should confirm it fits.
Technically yes, and several platforms now ship agents that do. Whether it should depends on what kind of automation it is. A fixed, testable rule under effective change control is accepted by auditors under PCAOB AS 2201. A model that exercises judgment and adjusts its own criteria is not covered by any standard that authorizes it to approve alone, and COSO’s 2026 guidance and PCAOB staff commentary both point toward evidenced human oversight at the decision that moves money.
Prompt injection breaks the agent by feeding it instructions it was not supposed to follow; the July 2026 code-review hijack is an example. Gaming the agent does not break anything. The fraudster learns the agent’s rules and stays inside them, so the agent approves the wrong outcome while functioning correctly. Prompt injection is a security defect to patch. Gaming is a control-design problem to segregate.
No. Comprehensive audit trails are a log, not a control. They record what the agent did; they do not stop the agent from doing it, and they do not detect an invoice that was shaped to pass. The control is independent authority at the approval, and change control over the agent’s rules. The log is how you evidence both.
It reduces error risk and queue time. It does not reduce fraud risk, because vendor history is the baseline a fraudster studies and, in insider cases, the baseline the fraud has already contaminated. Detection needs comparison against the contract and property and against the rest of the portfolio, not only against the vendor’s own past, and the decision still needs a person.
Put change control on the agent’s configuration today: who can edit its criteria, how edits are approved, and whether it rewrites its own rules. Confirm the agent cannot release payment and cannot edit vendor data, and that finance leaders, not only the AP team, see its exception reports. Then pull a sample of its approvals from the last 90 days and compare each against the contract rate, the property’s status and the same vendor at your other properties. If you find nothing, you have a baseline. If you find something, you have the business case.
The statistics and cases above come from the sources listed below: the ACFE’s Occupational Fraud 2026, Department of Justice releases for each prosecuted case, the PCAOB’s standards and staff Spotlights, COSO’s 2026 guidance as summarized by Deloitte, KPMG and RSM, Google DeepMind’s AI Control Roadmap, Eftsure’s July 2026 analysis, and the self-preference research cited by name. No case involves a PredictAP customer, and no real estate company or software product is named. The “gaming the agent” framing and the eight-item checklist are a practitioner framework, not an audit standard, and nothing here is legal or audit advice.
On bias: I founded and run a company that sells AI invoice capture, coding and anomaly detection to real estate accounts payable teams. We built our product to prepare invoices for a person to approve, not to approve them, so this argument is also our design choice, and you should weigh it that way. The controls above need nothing from any vendor.
David Stifter is Founder and CEO of PredictAP, the AI invoice coding platform that 130+ real estate firms use to process 7 million invoices a year. Before founding PredictAP in 2020, he spent nearly two decades at Colony Capital (now DigitalBridge), where as Managing Director and functional CTO he ran Yardi and finance technology across a $60 billion-plus platform, 12,000 entities, and 500,000 invoices a year. Accountant by background, geek at heart.
Read the reference guide: Real Estate Invoice Fraud and Anomalies: A 2026 Best Practices Guide for Property Accounting Teams · See how PredictAP Invoice Integrity holds suspicious invoices before approval