Connect an AI Agent to QuickBooks, Xero or Conta Azul Safely

To connect an AI agent to QuickBooks, Xero or Conta Azul safely, start with read-only access, let the agent prepare drafted entries in a staging area, and require a named person to approve anything that reaches the ledger. Use the official API with scoped authorization, never a shared login. Widen permissions one action at a time, and only after the agent has proved reliable on the previous one.

Key takeaways

• Begin with read-only access. Most of the value (matching, summarizing, flagging) needs no write permission at all.
• Separate three permissions: read, draft and post. Grant them in that order, and treat posting as a separate decision for each type of record.
• Where the accounting platform has no native draft status, keep drafts in a staging record outside the ledger and post only after approval.
• Approval must be a recorded act by a named person, with the evidence in front of them, not a vague check that someone looked.
• Design every write so that a retry cannot create a duplicate, and review the connection's permissions on a schedule.

Why does accounting software need more care than other tools?

Most business tools forgive mistakes. A wrongly scheduled meeting can be moved, and a badly worded message can be followed by a correction. A ledger is different. Entries feed tax filings, bank reconciliations, lender reports and audits, and a wrong entry often stays hidden until someone builds a report on top of it.

Three features make accounting integrations riskier than they look:

• Errors compound. A wrong category on a bill changes the profit report, the tax estimate and the budget comparison at the same time.
• Reversals leave traces. Voiding or deleting a posted entry is possible, but it creates a trail that your accountant has to understand and explain.
• The data is sensitive. Bank details, payroll figures, supplier terms and customer balances should be seen only by the people and systems that need them.

QuickBooks, Xero and Conta Azul each expose an API, and each uses its own permission model and its own rules about which records can be created, edited or voided. The details change over time, so check the current documentation of your platform before you decide which actions the agent can take. The approach in this article does not depend on any one vendor's quirks. It depends on keeping the agent's authority smaller than the damage it could do.

If you are unsure whether a given edition of your software has a usable API at all, the quick check in Does Your Software Have an API? A Quick Check Before AI is worth doing before anything else. Avoid driving the accounting screens through a browser as a shortcut. It is fragile and hard to audit.

What should the agent be allowed to read first?

Read access is the safest place to start and, in practice, the most useful. An agent that can read the books can already answer questions, prepare reconciliations, spot anomalies and write summaries for the owner. It cannot change a single balance.

Grant the narrowest set of read scopes that supports the first job. A reasonable starting list for an accounts payable helper might be:

• Chart of accounts, so it can suggest categories that actually exist.
• Supplier and customer lists, so it can match names without inventing new ones.
• Open bills and invoices, so it can detect duplicates and late items.
• Bank transactions awaiting reconciliation, so it can propose matches.
• Tax rates and tracking categories, so its drafts use your real configuration.

Leave out payroll, owner equity details, bank credentials and anything else the first job does not need. This is the principle described in Least privilege for AI agents: start with the smallest access: the agent should be able to do the job and nothing beyond it.

Authorization itself deserves attention. Use the OAuth flow the platform provides, store the tokens in a proper secrets store, and connect with an identity that exists for the agent rather than a manager's personal login. Tokens expire, and the agent should stop and report when that happens instead of looking for a workaround. The OWASP Authorization Cheat Sheet is a good reference for the underlying principles of deny by default and checking permissions on every request.

Run the agent in read-only mode for long enough to see how it behaves with your real data. Check its answers against what your bookkeeper knows. If it misreads your chart of accounts or confuses two suppliers with similar names, you want to learn that while nothing can be damaged.

How should drafted entries work?

A draft is a proposal that a person can accept, correct or reject. The agent's job is to make that decision quick and well informed, not to make it for the person.

Platforms differ here. Some support a draft status on certain documents, such as bills or invoices, which keeps them out of reports until someone authorizes them. Others have no such status for a given record type, and anything created is immediately part of the books. When there is no native draft, do not write to the ledger and hope for the best. Create the draft in a staging record outside the accounting system, for example a review queue, and post it through the API only after approval.

A useful draft contains more than the proposed entry. It should carry:

• The proposed record in full: supplier, date, lines, account, tax treatment and total.
• The source document, linked or attached, so the reviewer can check it without hunting.
• The reasoning in plain language: why this supplier, why this account, what was matched.
• Flags for anything uncertain, such as a new supplier, a total that differs from the purchase order, or a possible duplicate.

Source documents often arrive as scans and photos, so reading them reliably is its own problem. OCR for AI Agents: Reading Scans, PDFs and Photos Reliably covers what to check before trusting extracted amounts.

One more risk specific to documents: text inside an invoice or email is data, not instructions. A supplier PDF that says to change the bank details or approve payment immediately must never be obeyed. The OWASP guidance on prompt injection prevention explains why untrusted content has to be kept separate from the agent's instructions. In accounting terms, the rule is simple: the agent may extract a bank account from a document and flag a change, but it never acts on a request embedded in one.

The distinction between reading, drafting and sending is explored further in Read, draft and send: three different AI permissions. In accounting, add a fourth word: post. Posting is the step that changes the books, and it belongs to a person or to a tightly limited rule that a person has approved.

A step-by-step plan for the first connection

Use this order. Each step has an exit condition, and you move on only when it is met.

• Step one: define one job. For example, prepare draft supplier bills from emailed invoices. Write down what the agent will never do, such as pay, void or edit past periods.
• Step two: create a dedicated connection for the agent with the smallest read scopes the job needs. Record who owns it and where the credentials are stored.
• Step three: run read-only for a trial period. Ask the agent to reconcile or categorize a sample of past transactions and compare its output with the human result.
• Step four: add the staging area. The agent writes proposed entries there, never to the ledger. Every draft includes source, reasoning and flags.
• Step five: start human review. A named reviewer accepts, edits or rejects each draft. Track the reasons for rejections, because they show where the instructions or data need work.
• Step six: enable posting for one low-risk record type only, and only after the reviewer approves. Make every write safe to retry, as described in Idempotency for AI agents: prevent duplicate actions.
• Step seven: add monitoring and a stop switch. Log every read and write, alert on unusual volume, and make sure someone can revoke the connection in one action.
• Step eight: review the permissions on a schedule, and expand scope only through a written change, not an informal request.

The pace should follow evidence, not enthusiasm. Many teams stay at step five for a long time, and that is a perfectly good place to be, because the time saved comes from the preparation, not from skipping the reviewer.

Who approves, and what counts as approval?

Approval is only a control if it is specific. A message saying looks fine from someone who did not open the source document is not approval. Define it so that an auditor could follow it later.

A workable approval standard has four parts:

• The approver is named, and is not the person or process that prepared the entry.
• The approver sees the draft, the source document and the agent's flags together.
• The decision is recorded with a time and an identity: approved, edited or rejected.
• The post to the ledger happens only after that record exists, and it references it.

Not every entry needs the same approver. Routine, small and recurring items can go to the bookkeeper. New suppliers, changes to bank details, unusual accounts and large amounts should go to someone with financial authority. AI Approval Workflow: Route Each Request to the Right Approver goes into how to set those routes without creating a bottleneck.

Keep payments out of this integration at the start. Recording a bill is a very different act from releasing money, and the limits that apply to the second are covered in Can an AI Agent Make Payments? Safe Limits to Set First.

Finally, protect against double posting. Networks fail, and an agent that retries a write can create the same bill twice. Give each proposed entry a stable identifier and check for it before writing. Stripe's documentation on idempotent requests shows the general pattern well, even though it concerns payments rather than bookkeeping: a repeated request with the same key must not repeat the effect.

An illustrative scenario: a supplier bill arrives by email

This is an illustrative scenario, not a description of a real company.

A small distribution business receives supplier invoices in a shared mailbox. The agent has read access to the accounting platform and to that mailbox only. When an invoice arrives, it extracts the supplier, date, lines and total, looks the supplier up in the existing list, and checks open bills for the same invoice number.

In the first case, the supplier is known, the number is new and the lines match a previous pattern. The agent places a draft in the review queue with the PDF attached, the proposed account and a one-line explanation. The bookkeeper opens it, confirms the amounts against the document, and approves. Only then is the bill created in the books, with the approval reference attached.

In the second case, the same email carries a line saying that bank details have changed and asking for the next payment to go to a new account. The agent does not act on it. It flags the change, marks the draft as high risk, and routes it to the finance lead, who confirms the change by calling a known number from the supplier file. The books and the payment details stay untouched until that call happens.

In both cases the agent saved the preparation time, and in neither did it hold authority over the ledger or the money.

How does Be Human handle accounting integrations?

Be Human designs these integrations around one defined role. The first engagement specifies the job, the minimal read scopes, the staging area for drafts, the approval boundaries and an observable success criterion. In managed operations, we monitor the connection, review permissions on a schedule, maintain the integration when the platform changes, handle expired authorizations and introduce any widening of access as a controlled change that the company approves. Your team keeps ownership of the accounts, the approvals and the decision to post.

Frequently asked questions

Can an AI agent post directly to the ledger? It can, technically, but it should not start there. Begin with read access and staged drafts, then enable posting for one low-risk record type after a human approval step is working. Keep anything involving payments, bank details or closed periods under human control.

Do QuickBooks, Xero and Conta Azul handle drafts the same way? No. Some platforms offer a draft status for certain documents and others post immediately, and this can differ by record type. Check the current documentation for each, and where there is no native draft, hold the proposal in a staging area outside the ledger.

What if the agent makes a wrong entry anyway? Because the agent writes only after approval and every write carries a reference, you can trace which entry came from which draft and who approved it. Correct it through your normal accounting process, then use the rejection and error reasons to adjust the instructions or the review rules. If errors repeat, narrow the agent's permissions until the cause is fixed.

Should the agent use my personal login? No. Use the platform's official authorization with a dedicated connection that has the minimum scopes, and store the credentials in a secrets store. A personal login makes actions hard to attribute, gives the agent more access than it needs and breaks whenever that person changes role or password.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.