# Connect QuickBooks to Claude, ChatGPT and Cursor with governed access

> QuickBooks ends up behind a credential nobody can account for. Connect it once through Elaichi, then give each finance team a toolbox scoped to the records they actually own.

**TL;DR** Register your Intuit app, connect QuickBooks once under an accountable owner, then stamp per-team toolboxes so payables, support and leadership each get only what their work needs.

Ask a finance team who actually holds the keys to QuickBooks and the answer arrives slowly. The controller who set up the original connection left in March. A bookkeeping contractor has a login that nobody wrote down. Somewhere an export still runs every Monday, and the person who built it moved departments two reorganisations ago. None of this is carelessness. It is what happens when one ledger serves six teams over several years, and each of them solved access the fastest way available at the time.

Now those same teams want to ask an assistant about it. Which bills are unpaid past their due date. What this month's credit memos look like broken down by customer. Which bill payments cleared over ten thousand this quarter. Reasonable questions, all of them. Answer them by handing an agent the company file and you have manufactured one more credential nobody can find, except this one can write.

Elaichi takes the other route. QuickBooks gets connected once, on purpose, by someone accountable. That connection turns into a set of tools. The tools are packaged per team and narrowed per person, and the narrowing is worked out on every single call rather than trusted once at setup and forgotten.

## Six teams, one ledger

QuickBooks reads as a finance application until you write down everyone who needs something out of it. Then it reads as shared infrastructure.

Accounts payable lives in bills and bill payments. They want to know what is outstanding, what is scheduled, and which vendor a payment hangs off. Accounts receivable works the opposite direction: invoices going out, credit memos coming back, and what a customer owes once adjustments land. Controllership cares about the chart of accounts and the reports built on it, in a way nobody else does, because editing an account changes every report downstream.

Past the finance floor the reach widens. Customer support does not want the ledger at all. It wants to confirm a refund receipt exists for the person on the phone, and that the customer record is the right one. Payroll touches vendors and expense records. Leadership wants reports and account balances once a month and is generally least interested in how the figure was produced.

Six groups, four record types that carry most of the weight between them, bills and credit memos and refund receipts and accounts, and a legitimate claim in every case. The problem was never that support asks about a refund. The problem is that the only way to answer has historically been a login that can also post a journal entry. Each team has a different correct answer to what an agent should reach, and the ledger holds no opinion.

## Connecting QuickBooks

Start with a prerequisite that not every connector has. QuickBooks expects your organisation to register its own OAuth application with Intuit before anyone can connect an account. That registration belongs to whoever holds `connector:manage`, and Intuit documents the developer account and app creation steps [in its own getting started guide](https://developer.intuit.com/app/developer/qbo/docs/get-started/start-developing-your-app#set-up-your-developer-account). Until it exists, a connection attempt has nothing to hand off to.

With that done the flow is short. Open Connections, choose Add connection, pick QuickBooks, set Share with if you already know the audience, and press Connect. Intuit's authorisation window opens, you pick the company and approve, and you finish on Connection added.

The brevity hides the decision that matters. This connector is OAuth, so one identifiable human approves it, and what that person approves draws the outer edge of the connection for the rest of its life. Whoever clicks Connect sets the ceiling. Approve while signed in as the outgoing controller and their reach becomes the connection's reach. Approve against the wrong company and every tool call afterwards lands in the wrong books.

So treat the click as the governance step it is. Pick an owner who will still be here next quarter, and confirm the company on the authorisation screen before approving.

Then distribute the result with Share with, which takes a member, a team, or everyone, at View, Use, or Edit. View lets a person see the connection without running anything through it. Edit means they can change its settings and its sharing. Use is the setting that does the real work here: an accounts payable clerk can run bill tools against this connection without opening it, editing it, transferring it, or even finding it in a list. They borrow the owner's grant on terms you set, recomputed every time it resolves, so it ends when the owner's access ends.

## What anyone should be able to see, sorted by what a mistake costs

QuickBooks arrives with 132 tools. Rank them by blast radius rather than by module, because that is what you get asked about after an incident.

The lowest tier reads. `list_all_quickbooks_bills` and `get_single_quickbooks_bill_by_id`, `list_all_quickbooks_credit_memos` and `get_single_quickbooks_credit_memo_by_id`, `list_all_quickbooks_refund_receipts`, `list_all_quickbooks_accounts` and `get_single_quickbooks_account_by_id`, `list_all_quickbooks_reports`. A wrong call here shows someone a figure they had no business seeing. That is a real failure, it is bounded by whatever the connection can reach, and nothing in the books moved. It is also where the three questions people actually bring get answered, in full, without a single write.

The middle tier creates records. `create_a_quickbooks_bill`, `update_a_quickbooks_bill_by_id`, `create_a_quickbooks_bill_payment`, `create_a_quickbooks_credit_memo`, `create_a_quickbooks_vendor`, `create_a_quickbooks_customer`, `create_a_quickbooks_item`. Mistakes here are visible and a human can unwind them, but they are in the ledger, and they were made by a model on somebody's behalf. `create_a_quickbooks_account` sits awkwardly among its siblings and deserves a stricter bucket: a new line in the chart of accounts is a structural change, not a transaction.

The top tier removes things. `delete_a_quickbooks_recurring_transaction_by_id`, `delete_a_quickbooks_sales_receipt_by_id`, `delete_a_quickbooks_credit_card_payment_by_id`, `delete_a_quickbooks_time_activity_by_id`. None of them belongs in a toolbox somebody reaches conversationally. The recurring transaction is the nastiest of the four, because deleting one produces no immediate symptom. The symptom is a bill that fails to appear next month.

The workable default: reads available broadly, writes only to the team that owns that record type, deletes nowhere until somebody can describe the workflow that needs them and who reviews it. Per-tool controls make this less blunt than it sounds. An entry can be switched off with the enabled toggle instead of being removed, and its description can be overridden so the model is told in plain language what the tool touches and when it should decline.

## A toolbox for each team

A template is the reusable half: tool entries with their overrides and no connections attached. A toolbox is the bound half, and it is what an MCP client actually talks to. You stamp a template to produce a toolbox, attaching connections to its entries as you go. An entry left unbound shows as needs connection, a signal rather than an error.

Build templates along the lines the teams already work on. Payables holds `list_all_quickbooks_bills`, `get_single_quickbooks_bill_by_id`, `list_all_quickbooks_vendors` and `create_a_quickbooks_bill_payment`. Receivables holds `list_all_quickbooks_invoices`, `get_single_quickbooks_invoice_by_id`, `list_all_quickbooks_credit_memos` and `create_a_quickbooks_credit_memo`. Support refunds is deliberately thin: `list_all_quickbooks_refund_receipts`, `get_single_quickbooks_refund_receipt_by_id`, `list_all_quickbooks_customers`, nothing that writes. Group reporting carries `list_all_quickbooks_reports`, `list_all_quickbooks_profit_and_loss`, `list_all_quickbooks_balance_sheet` and `list_all_quickbooks_cashflow_statement`. Payroll gets `list_all_quickbooks_vendors`, `list_all_quickbooks_purchases` and `list_all_quickbooks_time_activity`. Controller is the broad one and should be the smallest audience.

Inside an entry you can set default values and freeze parameters. Frozen parameters are the sharper instrument, because a frozen value is removed from the schema the model is shown and then merged over whatever arguments arrive at execution. The model cannot see it and cannot negotiate it. Ordinary defaults yield to a caller's arguments; frozen values override them. Use that wherever a tool takes a parameter that decides scope.

Two properties to plan around. Entry lists cap at 200, so one template could hold the whole catalogue, which is not a reason to build one. And stamping copies: editing a template afterwards leaves every toolbox already stamped from it exactly as it was. Change a template, then re-stamp and swap deliberately.

## Governing it from the leaving date backwards

Design this the way a controller's resignation will test it, because that event finds every shortcut.

Remove a member and it takes effect on the very next request. Revoke a share, or disconnect an account, and the same holds. Role and restriction changes are the ones to be careful about: they read a snapshot that can lag by around a minute, two in the worst case. So if somebody must be out of the ledger this second, remove the member or pull the share rather than demoting their role.

Ownership is the part people forget. If the departing controller owns the QuickBooks connection, everyone using it at Use level leans on a grant that dies with them. Transfer the connection to somebody staying before the last day, rather than finding out when the payables toolbox stops resolving.

For the notice period, restrictions do the narrowing. They are allow-lists or block-lists over connectors and individual tools, aimed at a role or at one named member. There is no organisation-wide version. A member-level rule replaces whatever their role's rule said instead of merging into it, so read the role's rule before you write the personal one. An allow rule that names nothing denies everything, which is the bluntest and most useful notice-period setting available. Rules are checked at connect time, when tools are listed, when one is called, and again on the outbound request. They match against the catalogue's original tool name, so renaming an entry cannot slip past them.

Afterwards the audit log is the record. It is append-only by construction, nothing in the product edits or deletes a row, and it covers tool calls, memberships, roles, teams, connections and transfers, toolboxes, shares, restrictions, SSO and SCIM changes, and sign-ins. It records the id of the QuickBooks record a call created or changed, which is what reconciliation needs. It does not record arguments or results, because a tool call's payload is your customers' financial data. Rows are eventually consistent, so give a recent action a moment before concluding it is missing. The Auditor role, for whoever reviews this monthly, is one of the free ones.

## One endpoint for the whole organisation

There is a single endpoint for your organisation, copied out of the Connect your AI client dialog. Every client gets the same string, and setup is manual in each one. What differs is not the address but the person: when someone signs in, what their agent can reach is resolved against their own access, not against the connection's. Two people pointed at the same endpoint see different tools and get different answers.

On first connection a client asks for consent scopes: Read, Create and change, Delete, and Run tools. Only Read is on by default, and for most QuickBooks audiences that is the correct resting state. Turn on Create and change for the team that owns the record type and leave Delete alone.

One thing to plan for. Past 30 advertised tools, counting the platform's own operations alongside your connected ones, individual names are replaced by `search_tools` and `execute_tool`. With 132 QuickBooks tools you cross that line immediately. That search ranks lexically rather than semantically, so name and describe entries using the words your people type: bill, credit memo, refund receipt, vendor.

## Connect QuickBooks to Claude

Copy the endpoint from the Connect your AI client dialog. In Claude, open Settings, go to Connectors, and choose Add custom connector, then paste the endpoint. On Team and Enterprise plans only an Owner can add a custom connector, so if you are rolling this out to a finance team, get the Owner to add it once rather than asking each person to try and fail.

Sign in when prompted. The consent step asks for Read, Create and change, Delete, and Run tools, with only Read enabled. Leave it there for a reporting or support audience. Grant Create and change to the payables and receivables groups who will actually be creating bill payments or credit memos.

## Connect QuickBooks to ChatGPT

ChatGPT's custom connector support is on Business, Enterprise and Edu plans, and it works in the web client only, so a controller who lives in the desktop app should know that before starting.

Open Settings, then Apps, and switch developer mode on. Choose Create, paste the organisation endpoint, and run Scan tools. Because QuickBooks pushes the advertised count past 30, the scan resolves to `search_tools` and `execute_tool` rather than a long list, which is expected and not a failed setup.

Sign in, then set consent scopes. Read alone covers the reporting and lookup questions. Add Create and change only where someone's job involves writing to the ledger.

## Connect QuickBooks to Cursor

Cursor reads MCP servers from JSON, so this one is per machine rather than per organisation. Add an entry under `mcpServers` in `~/.cursor/mcp.json` to make it available everywhere on that laptop, or in a repository's `.cursor/mcp.json` to scope it to one project. A finance analyst who works across two machines does both, twice.

Restart Cursor, sign in, and set consent scopes as you would elsewhere: Read on, everything else off until there is a reason. Per-machine configuration is worth noting in your offboarding checklist, because the file stays on the laptop after the account stops resolving. The endpoint in it is harmless once the person is removed, since access is resolved per person on every request.

## Day two

Connections break. An Intuit grant is revoked, credentials rotate, someone tidies up an app in the Intuit developer portal. The symptom is tools failing for everybody sharing that connection at once, and the fix is Reconnect, which repairs the existing connection rather than making you rebuild the shares and toolboxes hanging off it.

Offboarding has a fixed order worth writing down. Transfer any connections the leaver owns. Remove the member, which bites on the next request. Then check whether any role or restriction change you made alongside it has caught up, remembering that those read a slightly stale snapshot.

Access requests are the pressure valve. When somebody hits a tool they cannot run, the request goes to whoever can actually grant it and gets resolved in the open, which beats a direct message that ends in a shared password, and it leaves a row behind.

For routing, notifications go to Slack or email, and the audit log forwards to Datadog. Pick one channel for the finance team to watch and send the rest to Datadog, where a monthly review of who ran what against the ledger becomes a query.

## FAQ

### Do I need my own Intuit developer app before I can connect QuickBooks?

Yes. QuickBooks requires your organisation to register its own OAuth application with Intuit before any connection can be made, and that registration is done by someone holding connector:manage. Intuit documents the developer account and app setup steps in its getting started guide. Once the application exists, Add connection hands off to Intuit's authorisation window in the normal way.

### Can customer support look up a refund receipt without getting access to the whole ledger?

Yes, and this is the main reason to use toolboxes. Build a support template holding only list_all_quickbooks_refund_receipts, get_single_quickbooks_refund_receipt_by_id and list_all_quickbooks_customers, stamp it against the QuickBooks connection, and share that toolbox with the support team. Share the underlying connection at Use rather than View or Edit, so support can run those tools without opening, editing or even seeing the connection itself.

### If I change someone's role, how quickly does it apply to their agent?

Not instantly. Role and restriction changes are evaluated against a snapshot that can be about a minute behind, two at worst. Removing a member, revoking a share or disconnecting an account is different: those take effect on the very next request. If someone has to be out of QuickBooks immediately, remove them or pull the share rather than relying on a role downgrade.

### Why does my client show search_tools instead of the QuickBooks tool names?

Once more than 30 tools are advertised, counting the platform's own operations alongside your connected ones, individual names are replaced by search_tools and execute_tool. QuickBooks carries 132 tools, so you cross that threshold as soon as you bind it. The behaviour is expected. Because that search ranks lexically rather than semantically, name and describe your entries with the words people actually type, such as bill, credit memo or vendor.

See the [QuickBooks connector](https://elaichi.ai/connectors/detail/quickbooks/).