Most firms vet software carefully and vet the people who wire it together hardly at all. Yet an integration built by a contractor can often see more of your clients' data than any single app you subscribe to, because its whole job is to move that data between them. The questions below are the ones worth asking before the first connection is made.
1. Whose account does it run under?
Every connection to Xero, QuickBooks, a mailbox or a shared drive is authorised by some login. It should be one your firm owns. If a builder connects your ledger using their own account, the connection belongs to them, and it leaves when they do.
The same applies to the automation platform itself. Ask whether the n8n or Make workspace will be in your firm's name, billed to your firm, with your staff as owners.
2. What permissions does it ask for, and why?
Xero and QuickBooks both use OAuth: when an app connects, it asks for specific access and someone at your firm approves it. Ask for a reason, line by line, for each permission requested. An integration that only reads invoices has no business asking to write journals.
A careful builder will start with read-only access and add write access later, for the specific steps that need it, once you've seen them work.
3. Where do the credentials live?
API keys, tokens and passwords should sit in the automation platform's credential store or a proper secrets manager. They shouldn't be in a spreadsheet, a shared document, an email thread, or pasted directly into a workflow step where anyone who can view the workflow can read them.
4. What data does it keep, and for how long?
This is the question most often missed. Automation platforms log each run, and by default that log can include the data the run handled. A document-intake workflow might therefore hold a copy of every client receipt in its run history, long after the receipt is safely in the ledger.
Both n8n and Make have settings that limit what's stored from each run and for how long. Ask what they'll be set to, and ask what else keeps copies: temporary storage, email inboxes, spreadsheets used as staging areas.
5. What happens when it fails?
Every automation fails eventually. A password changes, an API goes down for an hour, a client sends a file in a format nobody expected. The real risk isn't failure; it's silent failure, where nothing happens and nobody notices until a client asks why their bills weren't posted.
Ask who gets alerted, how quickly, and what the client experiences in the meantime. There should be a concrete answer, not "we'll keep an eye on it".
6. How do we switch it off?
There should be a short, written answer. For a typical build it's something like: deactivate the workflow in the platform, disconnect the app from inside Xero or QuickBooks, and check the runbook for anything that was mid-flight. If nobody can tell you how to stop it, you don't control it.
7. What happens if we stop working together?
You should own the workflows, any code, and the documentation, and they should keep running under your accounts without the builder. Ask for handover to be written into the scope with the rest of the work, rather than promised for later.
The regulatory backdrop
None of this is legal advice, and the rules differ by country, but in each of the markets below the firm remains answerable for what its providers do with client data.
- United Kingdom. Under UK GDPR, a firm that has someone else process client personal data on its behalf needs a written contract with that processor setting out what they may do with it.
- United States. The FTC Safeguards Rule covers tax preparers and many accounting firms, and expects them to select and oversee service providers that handle customer information. The IRS publishes guidance for tax professionals on the same subject.
- Canada. Under PIPEDA, an organisation stays accountable for personal information it transfers to a third party for processing, and is expected to protect it by contract.
In practice, the seven answers above are most of what you'd need to show that oversight exists.
Our answers
Every AVROQ build ships with a runbook that answers these seven questions for that specific build: the accounts it runs under, the permissions it holds and why, where credentials are stored, what's retained, who's alerted on failure, how to switch it off, and what you own. If a question here isn't answered in writing, it isn't finished.