# Set up Bill.com MCP access for ChatGPT, reads only

> Set up Bill.com MCP access for ChatGPT so accounts payable can read bills, and never approve one, pay one, or edit vendor bank details.

**TL;DR** To connect Bill.com to ChatGPT for accounts payable, put the account behind Elaichi's one MCP endpoint, give the AP role block rules on the approval, payment and vendor-record tools, and hold the ChatGPT grant to a toolbox of read tools. Elaichi records each call that runs with the person, the connector, the connection and the ChatGPT client, so the audit log shows who asked what. A call a restriction refuses never reaches execution, so the restriction rows, not the tool-call rows, are what prove the block.

## The ask behind the ask

An AP clerk wants to stop opening four tabs to answer one question: which bills are due Friday, and which still sit with an approver. That is a reading job. It is the job people mean when they ask for Bill.com MCP access for ChatGPT. The risk is everything next to it. The same account that lists bills can usually approve one and schedule a payment. It can often edit the bank details on a vendor record too.

So the rollout is two decisions, not one. Which tools the AP role may reach, and how you show a reviewer later that the other ones were never reachable. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. MCP is how the tools get to ChatGPT. Elaichi is where the two decisions live.

## Does Bill.com show up in Elaichi's catalog?

Check [the connector catalog](/connectors/) before you plan anything else. Elaichi authors and runs most of the 650+ connectors in it. The rest are native MCP connectors. There the vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. The list moves with every connector sync, so the catalog page is the answer, not a blog post. Each connector has its own page, for example [Acumatica](/connectors/acumatica/).

If the app you need is not in the system catalog, an organization can add it itself. An Org Owner or Org Admin can create a custom connector from a JSON config. They can also add a remote MCP server, one that speaks MCP over Streamable HTTP at a public hostname, as the organization's own connector. Both need the connector:create permission and the custom connectors feature, which the Gold plan includes. Among the built-in roles, only Org Owner and Org Admin hold connector:create. Ask your Bill.com account team whether they publish a remote MCP server you can point at. If they do, it comes under the same roles, restrictions and audit log as everything else in the catalog.

One warning on that route. Elaichi checks a custom connector's config for shape, not for where it points. A restriction binds a connector's own identity rather than the host it calls. A block on one connector does not stop a second connector built against the same API. That is why connector:create is the one permission Elaichi flags as high trust.

## How do you set up Bill.com MCP access for ChatGPT?

Five steps, in this order, because the restrictions should exist before anyone's client does.

1. **Connect the account once, deliberately.** Every call through a connection runs on the account that connection was made with, whoever is calling. A connection shared with the AP team acts in the app as its owner. If each clerk should carry their own permissions in Bill.com, each clerk connects their own account.
2. **Read the tool list and write the names down.** In the console, a connector's tool list shows every tool, with flags for what is restricted for you. An AI client can read the same list with the connector and connection list-tools operations. You cannot write a block rule for a tool you have not named.
3. **Write the restrictions on the AP role.** Details below.
4. **Build a toolbox of the read tools.** A toolbox is a named list of tool entries, each pinned to one connection. This is what you give the grant at consent time.
5. **Each person adds Elaichi in ChatGPT and approves their own grant.** The endpoint is the same string for every organization and every client: `https://api.elaichi.ai/mcp`. The step-by-step is in [the ChatGPT setup walkthrough](/blog/connect-elaichi-to-chatgpt/).

On the ChatGPT side, Elaichi arrives as one custom MCP app, not one app per connected product. On ChatGPT Business, only admins and owners can enable developer mode and deploy a custom MCP app. They create it from Workspace settings > Apps > Create. The form takes the endpoint and an authentication mechanism; then Scan Tools, the authorization prompt, and Create. Only admins and owners publish it, from Workspace settings > Apps > Drafts > Publish ([OpenAI's developer mode and MCP apps page](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), checked October 2026). Admins on Business, Enterprise and Edu can also turn an app on or off for the whole workspace ([OpenAI's admin controls page](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-for-plugins-and-apps), checked October 2026).

On a ChatGPT Pro account, checked 15 October 2026, the path runs through the Plugins button, then Add, then Add custom MCP server. The form asks for a name, the server URL and an authentication choice. An "I understand and want to continue" checkbox must be ticked before Create as a plugin goes live. OpenAI's docs say the ChatGPT desktop app, the Codex CLI and the IDE extension share one MCP configuration for the same Codex host. That is on [OpenAI's MCP docs](https://learn.chatgpt.com/docs/extend/mcp), checked October 2026.

When the person approves Elaichi's own consent screen, tick "Run your connected tools". Then choose "Only the ones I pick" and name the AP toolbox. That choice is re-checked on every call. If the toolbox is later deleted or unshared, the grant reaches less, never everything.

## Which restrictions stop the money moving?

Three rules, on the role that AP holds. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A team's rules are written on the role its members hold.

**One: block the approval and payment tools.** Name every tool on that connector that approves a bill, schedules or sends a payment, or records one. A block rule matches by tool name or by the stored operation, so renaming a tool later cannot slip it past the block. Blocks also follow lineage: a block on a connector covers every fork that declares descent from it.

**Two: block the vendor-record writes.** Paying the right amount to the wrong account is the failure that costs the most. It also looks the most normal in a log. If the connector has tools that create or update a vendor, or change remittance details, they belong in the same rule. Sometimes an argument must never move rather than never be written. [Locking the argument on a toolbox entry](/blog/frozen-parameters-wire-transfer-receiver/) is the other tool for that job.

**Three, optional: hold the role to reads with an allow rule.** An allow rule naming only the read tools admits those and nothing else on that layer. Here is the trade-off, and it catches people out. An allow rule turns on the allowlist for its whole layer just by existing. Once the AP role carries any allow rule, every connector and tool its allow rules do not name is blocked for that role. That holds across all connectors, not only the one you wrote the rule about. So the role also needs whole-connector allow rules for every other app it uses. Blocks alone are gentler to start with, and leave any tool you did not name reachable. The difference is set out in [why blocks match tool names but allows match operations](/blog/block-matches-name-allow-matches-operation/).

A member's own personal rules sit on top of their role's. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Changes to roles, team membership, restrictions and access grants reach every surface within about two minutes. Revoking a share or disconnecting an account takes effect on the caller's next call.

## The audit query that proves it

Open the audit log, filter the category to Assistant, set the actor to the AP clerk, and set a start time at the rollout date. Connected-tool calls sit in the Assistant category, because their action is `assistant.toolbox_tool`. Filtering to MCP shows client grants, not tool calls. That one mistake is why an access review sometimes comes back empty.

Each row records the acting user, the toolbox the call went through, and the tool's advertised and catalog names. It also records the connector, the connection the call actually reached and the tool's classification. The rest of the row covers how approval was given, the surface, the ChatGPT client's id and the outcome. The detail panel writes it as a sentence, opening with where the call ran, for example "Using ChatGPT, ...". A "What it did" line reads Read data, Changed data or Deleted data. For a read, the Approval line reads "Didn't need approval because it only read data". Export the filtered view as CSV for the reviewer. An export longer than 10,000 entries stops rather than saving a partial file.

Now the honest limit. A call a restriction refuses never reaches execution, so it writes no row at all. The audit log proves what ran. What proves the block is a second query: the restriction changes, recorded as `restriction.created`, `restriction.updated` and `restriction.deleted`. Add a search from the clerk's own client. A restricted tool comes back named and flagged restricted, with no schema and no way to call it. Pair the two and the evidence stands on its own. There is more on [the fields a reviewer actually asks for](/blog/what-an-ai-audit-log-must-capture/).

Every member can read their own activity in the audit log. The organization-wide view needs the audit:view permission, which Org Owner, Org Admin and the free, read-only Auditor role hold. A compliance reviewer can therefore be added without taking a billable seat.

## What ChatGPT's own settings cannot do here

To any MCP client, Elaichi is one server named Elaichi. Its tool list holds Elaichi's own operations plus `search_tools` and `execute_tool`, with `run_code` where Code Mode is on. Beyond those, connected tools are never listed one by one, however few there are. So a client control that picks or gates individual MCP tool names can only act on those as wholes. It cannot tell a bill-payment tool from a calendar tool, because both arrive through the same name.

None of the tools that run connected tools is marked read-only, either. A client setting that lets read-only tools run unprompted will still prompt on every connected-app call, reads included. It does not make the connected app read-only. ChatGPT has its own approval step as well. Before a supported action runs it may show an approval card. Whether it does depends on the app permission setting and the action's context ([OpenAI's app permissions page](https://help.openai.com/en/articles/20001495-managing-app-permissions-in-chatgpt), checked October 2026). Hold the app to reads in Elaichi, with the picked-toolbox choice at consent and the block rules above. Over MCP there is no per-call approval from Elaichi: the grant a person approved is the approval. That is covered in [the layers of human approval](/blog/human-approval-for-ai-agent-actions/).

## When this is more than you need

If one person does AP, reads only, and already has an export that answers the Friday question, you do not need any of this. The same goes for a two-person finance team on a single shared login, where nobody is asking for a per-person trail. Elaichi earns its place when several people, several apps and a reviewer are involved at once. That threshold is worth being honest about before you buy anything: see [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/).

For the wider model behind the three rules above, start at [the governance pillar](/blog/mcp-governance/). For the same shape applied to a different finance system, read [the Buildium read-only playbook](/blog/finance-team-chatgpt-buildium-read-only/). Check what is live today on [the connector catalog](/connectors/).

## FAQ

### Is Bill.com in Elaichi's connector catalog?

Check elaichi.ai/connectors/ for the current list, because the catalog changes with every connector sync. Elaichi authors and runs most of the connectors in it. The rest are native MCP connectors: the vendor runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. If an app is not in the system catalog, an Org Owner or Org Admin on the Gold plan can add it as the organization's own custom connector. That is done from a JSON config, or by pointing Elaichi at a remote MCP server reachable over public HTTPS.

### How do I stop an AI assistant from approving or paying a bill?

Write a block rule on the role the accounts payable team holds. Name every tool on that connector that approves a bill, schedules or sends a payment, or edits a vendor's remittance details. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A block rule matches by tool name or by the operation the tool performs, so renaming the tool later does not get it past the block. A block on a connector also covers every fork that declares descent from it.

### Will the audit log show an AI tool call that a restriction blocked?

No. A call a restriction refuses is stopped before any executor runs, so it writes no audit row. The audit log records what ran, not what was prevented. To evidence the block, use two other records. The first is the restriction changes themselves, written as restriction.created, restriction.updated and restriction.deleted. The second is the person's own tool search, where a restricted tool comes back named and flagged restricted, with no schema and no way to call it.

### Can ChatGPT be set to read-only for one connected app?

Not from ChatGPT's own settings, when the app is Elaichi. Elaichi appears to a client as one MCP server, and its connected tools are never listed individually. A per-tool client control therefore cannot tell one connected app from another. None of the tools that run connected tools is marked read-only either. Hold a client to reads on Elaichi's side instead: at consent, tick "Run your connected tools" and choose "Only the ones I pick", naming a toolbox that contains only read tools. Then block the write and delete tools with a restriction on the role.

### How long does a restriction change take to apply?

Within about two minutes. Role, team-membership, restriction and access-grant changes are cached per organization, so a change reaches the MCP endpoint, the console and the REST API on that schedule. Some changes are faster. Revoking an MCP client's grant, removing or suspending a member, revoking a share and disconnecting an account all take effect on the next call, because Elaichi re-reads the grant, the shares and the connections on every request.

## Read next

- [Connect Ashby to ChatGPT for recruiters](/blog/connect-ashby-to-chatgpt-for-recruiters/) — Connect Ashby to ChatGPT for recruiters with two restriction rules that hold the role to reads, plus the audit query that proves nothing was changed.
- [Slack MCP access for ChatGPT: a safe company rollout](/blog/connect-slack-to-chatgpt-for-the-whole-company-safely/) — Two restrictions, one guard you do not configure, and one audit query: Slack MCP access for ChatGPT, rolled out company-wide.
- [Connect Linear to Claude for our product team](/blog/connect-linear-to-claude-for-our-product-team/) — To connect Linear to Claude for our product team, govern Linear's own MCP server: per-person sign-in, a block rule, review for new tools.