Read-only should be the default on every client file you hold, and it should stay that way until a specific task justifies changing it. Caribooks is built so that this is also the path of least resistance: every connection starts read-only, write access is turned on one company at a time by the account holder, and a short list of actions stays gated even after that.
What the permission model actually does
Three separate controls. Keep them distinct in your head, because they fail in different ways.
Every connection starts read-only. Authorizing QuickBooks does not grant writes. A freshly connected company can be read in full, reports and records and searches, and cannot be changed by anything you or the assistant type.
Write access is per company, set by the account holder in the Caribooks portal. It is not a global switch, and the assistant cannot flip it. On a read-only connection the write tools fail outright. This matters more than it sounds: the assistant is not being asked politely to stay out of the books, it does not have the capability.
Sending, voiding and deleting each need an explicit confirmation in the conversation, every time. Emailing a document to a customer, voiding an invoice, deleting a record: each one requires you to confirm that specific action, even on a company you have set to full access.
Why read-only is the defensible default for a practice
The risk worth managing is not a rogue assistant. It is the ordinary one: the wrong company file, the wrong period, an instruction that was clear to you and ambiguous to the model.
On a read-only connection every one of those failures produces a wrong answer, which you catch because it does not match what you expected. On a full-access connection some of them produce a posted transaction, which you catch later, or not at all, and then have to reverse and explain to the client.
The costs are not symmetric. A bad report costs you a re-run. A bad entry in a client's ledger costs a correction, a conversation, and a small dent in the thing you actually sell, which is that the books are right.
The second argument is coverage. Most of what a practice wants out of an assistant is reading: 35 reports, including balance sheet, trial balance, general ledger, aged receivables and payables with detail, transaction lists by customer or vendor, budget vs actuals, tax summary. None of that needs write access. If you never enable writes on a single client file, you still get almost all of the value.
Granting write access without giving up the control
When you do enable it, keep it narrow and deliberate:
- Enable it on one company, for a task you can name, that you were going to do by hand anyway.
- Pick work whose result is visible and cheap to correct. Drafting invoices from a source document is a good first candidate. A first pass at categorizing a batch of expenses is a good second.
- Check the result in QuickBooks the same day, not next month.
- Set the company back to read-only when the task is done.
Because the level attaches to the company, a practice can run nine client files read-only while working in the tenth. That is the shape most bookkeeping practices should be in most of the time. The guides index has the workflow for running that many files at once.
One limit to know before you design a policy around this: the access level belongs to the company connection, not to the person asking. Anyone working in the assistant on that account operates at whatever level the company is set to. If you need different staff to have different rights on the same client file, this permission model does not express that.
Documenting the choice for a client
Write it down once, in plain language, in the engagement file, and send the client a copy. Something close to this:
- What is connected. QuickBooks Online company X, connected to Caribooks, a hosted connector that relays between QuickBooks and an AI assistant.
- What it stores. No accounting data. It keeps the account email, company names, and the QuickBooks access tokens, encrypted and hosted in Canada. The token is Intuit's access key, not a password, and can be revoked at any time.
- The access level and the date it was set. Read-only, effective this date. If it changes, add a line, do not rewrite the old one.
- Who can change it. Named person, from the Caribooks portal.
- What always requires a confirmation. Sending a document, voiding, deleting.
- How to end it. Revoke from QuickBooks, or disconnect the company.
Keep it factual and keep it dated. It is a record of a control you chose, not a consent form, and it is not a substitute for whatever your own practice standards require. The security page has the underlying detail if a client's IT contact asks.
Where this is the wrong choice
If your client files are QuickBooks Desktop, none of this applies. Desktop does not expose the API this depends on, so it is not supported and cannot be.
If your practice policy is that no third party holds an OAuth token to a client file, read-only does not change that answer. The token exists either way. The honest response is not to connect, and to say so to the client.
And if the only thing you want from an assistant is a profit and loss and the ability to send an invoice, Intuit's own connector inside Claude is free with a QuickBooks subscription. It does not cover the balance sheet, aged receivables, the general ledger, journal entries, vendors or bills, and it is not available to Canadian QuickBooks companies, but where it fits it is the cheaper answer. The comparison lays out which one covers what.