What the Bill.com MCP server does today
BILL published its account MCP server as a beta, open to every eligible BILL organization. You add it to Claude as a custom connector or to ChatGPT as an MCP app, sign in to BILL through OAuth, pick one organization, and then ask questions in plain English: which bills are due in the next two weeks, how much you owe a vendor, where a payment is in delivery, which customers are past due, or how card spend breaks down by budget. BILL's documentation lists the production URL as https://gateway.prod.bill.com/ai-mcp-server/v1 and a sandbox twin on gateway.stage.bill.com.
The important line in that documentation is this one: "Everything here is read-only for now. Creating, editing, approving, and paying are not yet available." Every call runs as the signed-in user and sees only what that user's BILL role can see. It supports US-based organizations only, one organization per connection, and not partner organizations or the Accountant Console. Claude and ChatGPT are the two clients BILL says it has validated end to end; any other MCP client has to be approved by BILL's developer program first.
Two other things share the name, and buyers mix them up. BILL also runs a documentation MCP server at developer.bill.com/mcp, which helps a coding assistant search the API docs and touches no account data. And there are third-party BILL MCP servers that do write. StackOne's hosted connector lists 62 actions, including Create Payment, and several community servers wrap the BILL API with credentials kept in a local .env file. So "BILL plus an AI agent" today means read-only through BILL's own server, or full write access through someone else's server sitting on the v3 API. For the write path, the controls live in the API, which is what we measured.
We read all 325 operations in the BILL v3 API
BILL publishes an index of its developer documentation at developer.bill.com/llms.txt, and every API reference page embeds the OpenAPI 3.0.1 definition for its operation. On 14 October 2026 we downloaded all 327 reference pages that index lists, parsed the 326 that carry a definition, and walked every request body down to its leaf fields. The result is 325 distinct operations, of which 210 write data (143 POST, 38 PATCH, 15 DELETE and 14 PUT) and together accept 1,639 input fields.
Then we asked two questions of each write operation. First, does BILL require an MFA-trusted API session to call it? BILL marks those operations explicitly in the reference text, and the search found 17. Second, does the operation set or change a limit, a budget or an approval? We searched field names for limit, budget, approval, cap, threshold and similar words and read every hit by hand.
The answer is more interesting than the other vendors we have measured. Zapier MCP carried no agent cap at all across 1,921 fields, and Microsoft Graph had no money near an agent. BILL is different. It models spending limits in detail: budget limits, recurring limits, a maximum transaction size, per-member limits, a vendor auto-pay maximum and amount-based bill approval policies. The problem is not missing controls. It is who can change them.
BILL guards the payment with MFA and leaves the limits open
BILL clearly thought about the payment step. All three payment-creation operations, Create a payment, Create a bulk payment (up to 50 bills per request) and Create a mass payment (up to 2,000 bills per request), require an MFA-trusted session. So do creating a vendor, updating a vendor, creating a recurring bill and adding a bank account. Those are exactly the moves a fraudster would make, and BILL puts a phone-based check in front of each.
Now look at the operations that decide how much may be paid. In the AP and AR API, Create a bill approval policy, Update a bill approval policy, Delete a bill approval policy and Approve or deny a bill require no MFA-trusted session. In Spend & Expense, Create a budget, Update a budget, Delete a budget, both budget-member limit operations, Create a vendor card and Update a vendor card carry no MFA requirement either. That is 11 control operations and 0 behind the MFA gate.
MFA-trusted is also less of a gate for an automated caller than it sounds. When a user validates an MFA challenge with remember-me set, BILL issues a rememberMeId that the API reference says "expires in 30 days." A script or agent that logs in with that ID gets an MFA-trusted session on every login for a month without anyone touching a phone. Sessions do expire after 35 minutes of inactivity, which is a sensible control, but an agent that keeps working never goes inactive.
Spend & Expense limits are real, and an admin token can rewrite them
BILL Spend & Expense, the former Divvy product, gives you some of the best card controls in the market. A budget carries a limit for the current period, a recurringLimit for future periods, and a maxTxSize that BILL describes plainly: "Any single transaction for an amount greater than maxTxSize will be declined." Each budget member can have a personal limit, and a vendor card can be issued with its own limit tied to one vendor. If you only need to cap a card, this works.
The catch is the credential. BILL's documentation states that only ADMIN users can generate Spend & Expense API tokens, and that in production the API user must hold the ADMIN role. So any agent or integration calling the Spend & Expense API is holding an administrator's token. That same token can call Update a budget to raise the limit, set limitlessOverspend to true (BILL's field for "enabling spend amounts over the budget limit", blocked only on daily and weekly budgets), create a fresh vendor card with any limit, and fetch the card number, CVV and expiry through the card's PAN token endpoint. The limits exist. The agent holding the token is allowed to move them.
That is fine when a human admin runs a reviewed integration. It is a different risk when the caller is a language model following instructions that can arrive in an email, a vendor invoice or a web page. Prompt injection does not need to break BILL. It only needs the agent to call an operation its token already permits.
What BILL controls well, credited honestly
BILL is a serious payments platform and several of its controls are genuinely good for agents:
- Amount-based bill approval policies. A rule such as BILL_AMOUNT greater than or equal to 1,000 with two named approvers means a 1,500 dollar bill cannot be paid until both approve. Custom approval policies are on the Corporate (89 dollars per user per month) and Enterprise plans; Essentials and Team get standard policies.
- No overpayment. The payment amount field states that you cannot overpay a bill, so an agent paying against a bill is bounded by that bill.
- Vendor auto-pay maximum. Vendors carry an
autoPay.maxAmount, and changing a vendor requires an MFA-trusted session. - MFA on payments, vendors and bank accounts, the three classic fraud paths.
- Rate limits. 20,000 AP and AR requests per developer key per hour, 3 concurrent requests per organization, and 60 Spend & Expense calls per token per minute. They slow a runaway loop, though they bound requests, not dollars.
- Dual control on the Enterprise plan, and a read-only official MCP server, which is the right default for a first release.
If your agent only ever pays approved bills that a human entered, BILL's own approval policies cover a lot. The gap opens when the agent creates the bill, manages the card, or holds a role that can approve or rewrite the policy.
What changes when an agent can write to BILL
Picture the realistic setup: an AP agent connected through a third-party MCP server or a small custom integration, reading invoices from an inbox, creating bills, and paying them. Every step uses an operation BILL documents. The agent can create a bill, and if the bill falls below your approval threshold it needs no approver. It can pay up to 2,000 bills in one mass payment request. It can choose the payment method, and that choice alone moves fees: ACH costs 0.59 dollars on BILL's price list, while Instant Payment costs 1 percent with a 9.99 dollar minimum and a 100 dollar maximum per payment.
Nothing in that chain asks whether this agent has already spent its month's budget, whether the vendor is one this agent may pay, or whether today's total across all bills is still sane. BILL's approval policies look at one bill at a time. Spend & Expense budgets look at one budget. Neither sees what the same agent did through another tool, another card or another system, such as a SaaS subscription, an ad account or an API it pays per call. For a fuller picture of agents that pay vendors, see our page on AI bill pay agents.
What a controller adds before an AI agent touches BILL
The controls finance teams ask for sit outside the tool the agent operates, so the agent cannot rewrite them:
- A per-agent budget, daily and monthly, cumulative across every payment and every system the agent touches, not per bill.
- A per-transaction cap that the agent's own credential cannot raise.
- Vendor and payment-method rules, for example ACH and virtual card only, no Instant Payment, and only vendors already on an approved list.
- An approval threshold by amount routed to a named person in Slack or email, where the approver is never the agent's own BILL user.
- A separate, non-admin identity for the agent, so it never holds a Spend & Expense admin token.
- An audit trail that records which agent asked to pay which vendor how much, and who approved it.
How AgentsPay works alongside BILL
Keep BILL as your system for bills, vendors and payment rails. AgentsPay sits in front of the moment money leaves. Each agent that can pay gets its own AgentsPay identity with a hard per-agent budget and per-transaction cap, vendor and category rules, and approval routing by amount to a person in Slack or email. The agent asks AgentsPay before it calls Create a payment, and continues only on an approval. Policy changes happen in AgentsPay's dashboard by a human, never through the agent's own credential.
For spend that never becomes a BILL bill, such as software, ads or API usage, AgentsPay issues a scoped virtual card per agent with its own limit. Every request, approval and decline lands in one audit log, so the controller can answer "what did the agents spend this month" across BILL and everything else. If you are comparing other finance tools that expose MCP, our measurements of the QuickBooks and NetSuite MCP servers and of payment MCP servers from Stripe, PayPal and Square use the same method. Pricing for BILL API access itself is broken down in Bill.com API pricing.