Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can a Shared Services Center Automate Accounts Payable With AI Agents Safely?
No, not while payables pages render the vendor's bank details, tax identifiers and several entities' ledger data to the model. Replace those values with consistent tokens before the model reads the screen, then let each entity's own approver release the payment.
A shared services center exists to run one process for several legal entities, and accounts payable is usually the first process it takes. The center's clerks work in one ERP, but each entity keeps its own ledger, its own supplier records and its own authority matrix, so an invoice that arrives for one company is matched, blocked and released under that company's rules. An agent that reads those pages inherits all of it: the payee list, the bank account on the vendor record, the tax identifier that may belong to a sole proprietor, and the payment form where a check or an electronic transfer is set up. The multiplication is what changes the answer. A single company's agent reads one vendor's banking; a center's agent reads the same supplier's banking as it is recorded for every entity the center serves, and the page does not label which entity's account it is showing.
The record this page works through is a multi-entity AP run: one supplier, three entities, one payables page. Nothing in the question turns on the model's intelligence. It turns on what the screen renders before the model reads it, who signs for the entity whose money moves, and what the center can show afterwards. The pages reviewed are the vendors' own payables help, a supplier registration guide, university guidance and the research record on what models do with what they read.
Key findings
- For a shared services center to run payables on agents, the page would have to show consistent tokens such as VEND_014 and ACCT_014 before the model reads it, with the real account released only at the payment that entity approved (What Is Render-Layer Tokenization?).
- It would also require an approver named for each entity, working from that entity's own authority matrix, and a record of what the model received on every screen the run opened (What Is Least Exposure?).
- None of the payables pages reviewed describes a substitution before a model reads the screen; the Oracle page that sets the match level lists where each option defaults and says nothing about what the screen shows (Oracle, Matching, 2026).
- NetSuite's Pay Single Vendor form asks the user to "select the payee you want to pay" and carries "For Electronic Bank Payment" on the same page, so the destination and the rail are chosen where the agent works (Oracle NetSuite, 2026).
- SAP blocks a variance invoice automatically, and "You must release a blocked invoice in a separate step before it can be cleared for payment" (SAP, 2026).
- A supplier registration guide states that "Bank account information must be included" and that electronic payment "must be selected if bank account is included", so the destination is captured at onboarding, before an invoice exists (Suntory Global Spirits, 2025).
What does the model read when it opens a payables page?
The payment screen is a form, and the form is where the run ends. NetSuite's help for Pay Single Vendor lists the fields the page renders, the A/P account, the payee, the account, the balance, the currency and the posting period, and it "never mentions purchase orders, receipts or matching anywhere on the page", so the match that justified the payment happened on a screen the form does not describe (Oracle NetSuite, 2026).
The match lives on the earlier screens, and they are just as literal. SAP's invoice verification compares the invoice, the purchase order and the goods receipt through the GR/IR clearing account, applies tolerance keys for quantity (DQ, DW) and price (KW, PP, PS), and blocks a variance invoice: "the invoice is then automatically blocked for payment", and "The invoice block applies to all items in an invoice", so a single line with a variance can hold the payment until a person releases it (SAP, 2026).
So the run opens four screens: the invoice, the vendor record, the match result and the payment form. The model reads the account number on the vendor record because the page renders it beside the payee the agent needs, and the same record carries the tax identifier the entity files under (What Can an AI Agent See When It Logs Into Your Accounts Payable System?). An agent that resolves a hold on one invoice therefore holds the destination on every supplier record it opened on the way (Can AI Work NetSuite Payables Without Bank Details?).
Why does a multi-entity ledger multiply the vendor data on screen?
A single company sets a supplier up once and pays it from one ledger. A center pays the same supplier from several, and each ledger carries the banking that entity pays to. Oracle's supplier master carries what a payables agent must not hold: tax identifiers, bank accounts, remittance addresses and, in shared-services estates, the same supplier's banking across several ledgers (Can AI Work Oracle Payables Without Bank Details?).
The registration guide shows how much arrives at onboarding. "Bank account information must be included" and "Electronic payment must be selected if bank account is included", and an EIN filer selects Organization, while Individual "will only be selected for suppliers using a government issued identification number" (Suntory Global Spirits, 2025). Those fields are captured once and reused for every entity that buys from that supplier.
| What the record holds | Why the run needs it | What should reach the model |
|---|---|---|
| Bank account and routing number | To pay this entity's invoice | A token such as ACCT_014 |
| Tax identifier (EIN, SSN or SIN) | To report and withhold | A token, or nothing |
| Remittance address | To send the remittance advice | A token, or nothing |
| Payee name and invoice number | To match and post | The real values |
The table is the multiplication in one place: one supplier, several entities, and a bank account for each. A model that opens the supplier record to check a remittance address reads every account on it, including the ones belonging to entities whose invoices it is not working, and nothing on the page marks which account belongs to which entity.
What do the vendors themselves say?
The pages reviewed place their controls on the decision rather than on the read, and the difference matters more in a center than in a single company.
| Page reviewed | What it documents | What a buyer should verify |
|---|---|---|
| NetSuite Pay Single Vendor | The payee field ("select the payee you want to pay"), the electronic payment box, and a form reference that never mentions matching (Oracle NetSuite, 2026). | Whether the page shows only the payee for the entity being paid |
| SAP invoice verification | Tolerance keys, the automatic block, and the separate release step (SAP, 2026). | Who holds the release, and what the release screen renders |
| Oracle Payables matching | Match approval level and hold-unmatched, set in setup windows per supplier or order shipment (Oracle, Matching, 2026). | Which setting applies to each entity's ledger |
| Oracle Siebel settlement | OFAC screening and a limit check that "creates an Inbox item for the supervisor's approval" (Oracle, Settlement, 2026). | Whether the approval names the destination |
Oracle's setup page lists where each option defaults and says a value "can always override" the default, but it does not say what happens to an invoice once it is held (Oracle, Matching, 2026). SAP's tolerances are set "as per the company code" (SAP, 2026), so the rule that blocks an invoice belongs to one entity and not to the group. A match level, a hold and a payment limit are all rules about whether money may move; none of them is a rule about what the screen shows the reader who opens the record.
Nor is the gap confined to the ERP pages. Of 15 AI agents and 86 AI security products reviewed, none describes replacing the customer data an agent reads on a screen with tokens it can work with, and the ERP products described here were not among them (Do AI Agents Ask Before Making a Payment?).
Who approves a payment when one center pays for several entities?
The approval belongs to the entity whose account is debited, even when the center's staff press the button. Two documented patterns make that concrete.
Siebel's settlement page shows a limit chain in operation. On Submit Payment the system screens the payee, and "If the payee or vendor payee is in the OFAC database, Siebel Insurance suspends the payment" (Oracle, Settlement, 2026). A short limit "creates an Inbox item for the supervisor's approval", and a supervisor whose own limit is short escalates again. The pattern is a written authority matrix with escalation, which is the shape a center needs for each entity it serves.
Harvard's guidance puts the same rule in general terms: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University, 2026). A payment is all four. The temptation is to let one approval cover the estate, and the expense queue shows why that fails: in the Concur guide, a submitted report is reimbursed only once it is "approved by Accounts Payable" (Humboldt State University, 2021), so for travel costs the center is the approver, while a supplier invoice leaves an entity's bank account and needs the entity's own signer.
The question that decides it is whose limit was checked. An agent can prepare, match and propose; the release needs a person with a limit on that entity's ledger, and the record needs both names.
How should a center test one entity's run before the estate scales?
Pick one entity, one supplier with a bank change pending, and one agent run, then read four things.
First, the page. Name the fields the agent's role renders on the vendor record and the payment form: payee, A/P account, bank account, routing number, tax identifier, remittance address. If the bank account is on a page the agent opens, it is in the run.
Second, the transcript. Search it for the account digits and the routing number. A model that read the value can repeat it in a summary, a note or a file it writes, which is the risk the contextual-privacy study measured when GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases (Mireshghallah et al., 2024).
Third, the approval. Ask whose limit was checked and which entity's ledger the release posted against. If the answer is the center's own signer for an entity's invoice, the matrix is not the entity's.
Fourth, the record. MIT Sloan's analysis is that organizations "need to make monitoring a permanent operational expense" (MIT Sloan, 2026). A run whose transcript nobody keeps cannot answer the first three questions after the fact.
Then repeat the four checks on a second entity and compare the tokens. If ACCT_014 means one supplier's account in the first run and another's in the second, the substitution is not consistent and the agent's notes are ambiguous. A hijacked agent that holds only tokens has nothing to send (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
What does a governed environment change?
A governed environment is a control class that acts where the screen is drawn, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on VEND_014 and ACCT_014, and the real values resolve only at an approved destination, at the moment of an approved action. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. A named person confirms which fields are tokenized and approves each consequential action, and the run writes a record of every screen as tokens, every action and every approval, exported to the organization's own monitoring.
For a multi-entity center, three properties matter more than the mechanism.
The policy is set per entity. The same supplier can render as VEND_014 for one entity and VEND_015 for another, or resolve to one token where the center wants the supplier recognized across ledgers, and the choice is written down rather than left to a model's memory of the last page.
The approval follows the money. The person who releases the payment holds a limit on the entity whose account is debited, and the record shows which limit was checked.
The record survives the run. Every screen in its tokenized form, every action and every approval with a name exports to the center's monitoring, so the question a controller asks six months later (what did the agent see when it changed this payee) has an answer that is not a transcript.
None of this changes the match, the tolerance or the release rules the ERP already enforces. It changes what the agent reads on the way to them.
What the record shows
The control that decides the answer sits before the model reads the page: what the agent receives on the vendor record and the payment form, which person releases the payment for each entity, and what record survives the run. The pages reviewed put their controls on the match, the block and the release, and those are configured per company code, per supplier or per approval limit, so a center already knows how to hold a payment. What the estate does not hold is the screen. The same supplier's banking renders to whoever opens the record, clerk or agent, and in a center it renders for every entity at once. A controller can test this on one entity in an afternoon: open a supplier with a bank change pending, run the agent's match, and search its transcript for the account digits before anyone approves the payment.
Methodology and limitations
This page rests on five vendor documents from NetSuite, SAP, Oracle and Suntory Global Spirits, a university expense guide, university AI guidance, one industry analysis and one research preprint, plus existing RedactSure research. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for this page, and "not described in the pages reviewed" means only that the recorded facts for those pages do not state it. The products are described from their public documentation, vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a multi-entity AP run, not an organization.
Determinations about whether a payables control meets a contractual, tax or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can a shared services center automate accounts payable with AI agents safely?
No, not while the payables pages render the vendor's bank details and tax identifiers to the model. The pages reviewed put their control at the match, the block and the release, but the vendor record the agent opens carries the destination as it was captured at onboarding. Replace those values with consistent tokens before the model reads the screen and the center can automate the match and the proposal; the release still waits on a person with a limit on that entity's ledger.
Does an approval setting make an agent's payment safe?
No. An approval governs the release, not the read. NetSuite's Pay Single Vendor page is a form reference with a payee field and an electronic payment box (Oracle NetSuite, 2026), and the block that holds a variance invoice decides whether money moves, not what the agent read to prepare it (SAP, 2026). Neither changes the account number the agent read to prepare the payment, which is the value an injection or a careless summary exposes.
What does the model receive from a vendor record it opens?
Everything the page renders for the role it signed in with: the payee, the bank account and routing number, the tax identifier, the remittance address and the open bills. Oracle's supplier master carries tax identifiers, bank accounts, remittance addresses and, in shared-services estates, the same supplier's banking across several ledgers, as Can AI Work Oracle Payables Without Bank Details? sets out. Nothing on that page tells the model which entity an account belongs to unless the screen says so, and the record was built for a clerk who already knew.
Can one approval matrix cover several entities at once?
Not if the approval is to mean anything. A limit belongs to a person on a ledger, and the Siebel pattern shows the chain: a short limit "creates an Inbox item for the supervisor's approval", and a supervisor whose own limit is short escalates again (Oracle, Settlement, 2026). One matrix across entities would let a signer release money from an account they hold no authority over. Write the matrix per entity, name the approver, and let the center's staff operate it.
Does tokenizing the vendor record break the three-way match?
Not when the tokens are consistent for the run. The match compares amounts, quantities and references, and a token such as VEND_014 preserves the identity the comparison needs while the account digits stay out of the model. As Does Masking Data on Screen Break Browser Agents? records, replacing identifiers with consistent pseudonyms and restoring them afterwards reduced semantic utility errors by a factor of five against baseline techniques. What breaks a match is inconsistent substitution, where the same supplier renders two ways in one run.
What record should the center keep of an agent's payables work?
One that answers three questions for every payment: what the model received on each screen, which person approved the release, and which entity's ledger the payment posted against. Harvard's guidance is to "Treat prompts, outputs, logs, and retained context as organizational data", and to keep the ability to stop the system when it behaves unexpectedly (Harvard University, 2026). Export that record to the center's own monitoring, not the vendor's, so an entity's auditor can read it without asking the center to reconstruct the run.
How RedactSure Keeps a Multi-Entity AP Run Off the Model's Screen
A center's vendor pages render one supplier's banking for every entity it serves, so an agent that resolves a hold reads accounts it has no reason to hold. In one study, GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the vendor record renders the account, routing number and tax identifier beside the payee, and the payment form shows where the money leaves. Inside, the page renders VEND_014 and ACCT_014, the real account resolves only to the payment the entity's approver released, and the record lists each screen and approval.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A run a center cannot reconstruct is a run it cannot sign off. Bring one entity's vendor record and see, with test values, what the model reads and who releases the payment. Book a demo