Security and controls: it never touches money.
The single question every controller asks before an AI agent gets near accounts payable is whether it can move money. The answer here is no, and it is not a policy or a permission you could accidentally loosen. There is no payment path in the code to begin with. Everything below is how that boundary holds, and what sits around it.
No payment authority, enforced in code
Most "AI in AP" pitches talk about autonomy and then quietly leave the door open to payment execution as a future feature. This build does the opposite: payment is not a switch that is turned off, it is a capability that was never built.
Walk through the four stages described on How it works and you will notice the pipeline ends at coding and routing. Capture reads the invoice. The 3-way match checks it against the PO and receipt. Coding assigns a GL code from your chart of accounts. Routing hands the coded invoice into the approval workflow you already run. At no point does the agent hold, initiate, schedule, or confirm a payment. There is no ACH file it can generate, no wire instruction it can submit, no vendor payment API it is wired into.
This matters because the usual way software vendors describe a payment boundary is as a setting: a toggle marked "auto-pay," defaulted to off, that a busy admin could flip on six months in without realizing what it changes. That is not what is happening here. The agent's tool set, the functions it is allowed to call, simply does not include one that talks to a bank, a card network, or a payment rail. Adding that capability would mean writing new code and shipping a new build, not checking a box in a settings screen.
The practical effect is that the worst-case failure mode most finance teams worry about with AI agents, an autonomous system quietly authorizing a fraudulent or mistaken payment, is not something this system can do even if every other control failed. A prompt injection hidden in a scanned invoice, a manipulated PDF, a compromised vendor record, none of it matters for payment risk specifically, because there is no function call on the other end that would move funds. The blast radius of a worst-case AI mistake here is a bad GL code sitting in a queue for a human to catch, not a wire transfer that already left the building.
That is also why this page is written the way it is. I am not asking you to trust a policy document or a promise about how the model was prompted. The boundary is structural. You, or anyone you hire to review the code at handover, can confirm it by reading the source: there is no payment-execution module to audit because there is no payment-execution module.
Payment stays exactly where your auditors already look
Removing the agent from payment is only half the point. The other half is that nothing new gets introduced to replace it.
Coded, matched invoices flow into the approval chain you already run inside QuickBooks Online, Xero, or NetSuite, the same system your controller, your approvers, and your external auditors already use and already trust. The agent does not stand up a parallel approval mechanism, a separate sign-off screen, or a new place where money-adjacent decisions get made. It hands work to the process that already exists, pre-populated and ready for the same human who would have approved it anyway.
For a finance team operating under SOX or a comparable internal-controls framework, this is the detail that matters most. Segregation of duties, the principle that the person or system entering a transaction cannot be the same one authorizing payment, is not something this build has to invent a story around. The agent never sits in the authorizer role, structurally, so the separation your control framework already requires between data entry and payment approval is preserved by default rather than papered over with a new policy.
It also means there is no new system for your auditors to learn. The evidence trail an auditor would want during a walkthroughs, who approved what and when, still lives in your accounting system's own approval log, exactly where it lives today. What the agent adds is a second, independent trail alongside it, covered in detail further down this page, that shows how each invoice arrived at the approver's desk in the first place.
The controls that catch fraud before a human even has to look
A clean 3-way match is not the same thing as a safe invoice. Some of the most convincing invoice fraud matches perfectly on paper. These are the checks that run regardless of whether the numbers line up.
Approval thresholds. You set dollar thresholds, and anything above them routes to a human for sign-off no matter how clean the match is. A confident match on a $180,000 invoice does not get treated the same as a confident match on an $800 one. The thresholds are yours to set and yours to change; the agent does not have discretion to override them.
Duplicate detection. Re-submitted invoices, whether an honest double-send from a vendor's system or a deliberate resubmission scam, are one of the more common ways money leaks out of AP. The agent fingerprints incoming invoices on vendor, invoice number, amount, and date pattern, and holds anything that looks like a repeat for review rather than assuming the second one is a correction.
New-vendor holds. A vendor the agent has never seen in your history is treated as elevated risk, full stop, even if the invoice matches a valid PO and the receipt lines up. New-vendor fraud, where a fabricated supplier is inserted into the pipeline once, paid once, and never seen again, depends on that first invoice sailing through unnoticed. Here it does not.
Changed-bank-detail holds. This is the single guardrail I would not ship a build without. Business email compromise and vendor-impersonation fraud almost always show up as a legitimate-looking invoice from a known vendor, with one quiet change: new banking details. The agent flags any change to a vendor's payment details on the vendor master and holds the associated invoice, regardless of match confidence, until a human confirms the change through a channel that is not the email the change arrived on.
Minimum-necessary access, isolated per vendor and per tenant
The agent's credentials are scoped to exactly what the pipeline needs and nothing else: read access to the invoice inbox and document sources, read access to purchase orders, receipts, and the vendor master, read access to your chart of accounts and historical coding, and write access limited to coded invoice records inside your accounting system's existing approval workflow. There is no scope for payment initiation, no scope for altering approval rules, and no scope for touching bank or payment-method records beyond flagging that they changed. The full list of sources it reads and systems it writes to is on the Integrations page.
Each build runs against your own accounts: your own accounting-system connection, your own document-processing account, your own database holding vendor history and coding context. Nothing is pooled into a shared multi-tenant service that also processes another company's invoices. For accounting and BPO firms running this pattern across multiple clients, each client's data, vendor history, and coding context is isolated in its own instance; nothing a model learns coding one client's invoices leaks into how it codes another's.
Every action, logged and impossible to quietly edit
A control that cannot be evidenced is not really a control, it is a policy statement. This is the evidence layer.
Every stage of the pipeline writes to an append-only log. Capture logs the raw extraction, the confidence score on every field, and the link back to the region of the source document that value came from, the same grounding described on How it works. The 3-way match logs its verdict and the reasoning behind it: which PO and receipt it matched against, what tolerance it checked, and why it did or did not clear. Coding logs the GL code assigned and whether it was proposed for confirmation or applied directly. And every human action inside the exception queue, an approval, an edit, an escalation, a rejection, is logged against the person who took it and the time they took it.
The word that matters here is immutable. Entries are appended, never overwritten. If a human corrects a coding decision, the log keeps both the agent's original proposal and the human's correction, with a timestamp on each, rather than replacing one with the other. That is a deliberate design choice: an auditor reconstructing what happened to a specific invoice six months later should be able to see the full sequence, not just the final state.
This is the same audit-and-evaluation lane that generates the touchless-rate numbers covered on The proof. It is not a separate compliance feature bolted on for this page; it is the record the eval harness reads to score extraction accuracy and match precision, and it is the record a SOX walkthrough or an internal-audit sample would pull from. One trail, two uses.
Your data stays on infrastructure you control
This is not a shared SaaS product where your invoices sit in a multi-tenant database alongside other companies' financial data. The build runs on your own infrastructure and your own accounts: your own cloud or API account with the document-processing provider, your own account with the model provider used for extraction and match reasoning, and your own Postgres database, with pgvector, holding vendor history and coding context. Nothing routes through infrastructure I own on your behalf, and nothing about your invoices, your vendor list, or your coding history is retained anywhere outside your own environment once the build is handed over.
That has a direct security consequence: there is no cross-customer data-commingling risk to reason about, because there is no shared database for it to commingle in. Whatever access controls, network policies, encryption standards, and retention rules you already apply to your cloud accounts apply here too, because this runs inside those accounts, not next to them.
This is a build shaped to your controls, not a certified product
I would rather lose the deal than overstate this, so here is the plain version.
There is no SOC 2 report, no ISO 27001 or ISO 42001 certificate, and no compliance badge attached to this offering, and I am not going to imply otherwise with a logo on a page. Those certifications describe a vendor's own standing product, run on a vendor's own infrastructure, assessed once and sold to every customer as-is. That is not what this is. This is a bespoke build, written for your accounts, your approval chain, and your control framework, and handed to you as code you own outright. There is no shared product behind it for a certification to describe.
What that means in practice is more useful than a badge, not less. The security posture of the finished system is a direct reflection of your own environment: your cloud account's existing compliance program, your accounting system's existing access controls, your existing segregation-of-duties policy, all of it inherited rather than replaced. If your organization is under SOX, the build is designed during discovery to fit the segregation-of-duties boundaries your policy already defines, not to introduce a new boundary you now have to reconcile against the old one. If your cloud provider already carries a certification you rely on, the build runs inside that same account and inherits it, because nothing about the data leaves for a separate, uncertified environment.
If you want an independent third party to review the code, the data flows, or the control boundaries described on this page before you rely on them in production, you are free to commission that review yourself; the code is yours at handover, and I have no interest in being the only party who has looked at it. What I will not do is sell you a certification, a claim of "bank-grade security," or a compliance program that does not exist. The honest version of this page is a system with one hard boundary enforced in code, a small set of guardrails aimed specifically at the fraud patterns that matter in AP, minimum-necessary access, and a trail that lets you or an auditor check all of the above yourselves.
The controls hold. Next, see where the build actually plugs in.
Security is the constraint the whole system is built around. Integrations covers the practical side: exactly which sources it reads, which one accounting system it writes back to, and what you need to have ready before week one.