The best QuickBooks Online integration is the one for your job.

Almost every comparison article skips this, and it is the part that determines whether an integration will hold up. Five facts to have in your head before you evaluate anything.

• Authorization is OAuth 2.0, per company. You are redirected to Intuit’s own consent screen, and the app receives tokens rather than your password. A well-built integration never sees a QuickBooks credential at all. Each connected company carries a realm identifier, and the tokens are bound to it.
• Refresh tokens expire from disuse. A refresh token that goes unused for long enough stops working, which is why an integration you connected for a seasonal client and forgot will one day tell your staff to reconnect. Ask a vendor how they handle expiry, and whether you hear about it before your client does.
• The API is throttled per company. Intuit publishes the current request, concurrency and batch limits, and they are more generous than most firms assume. The practical implication is that throughput problems in a sane integration are almost never the API. They are the human review step.
• Scopes are coarse in the protocol and should be fine in the product. Intuit’s accounting scope is broad. If a vendor stops there, any authorized client can do anything the scope allows. What you want is a product that narrows further on its own: per-company allow-lists, read-only roles, and per-call checks.
• Sync direction is a design choice with consequences. One-way into QuickBooks is safe and lossy. Two-way is powerful and is how duplicate records happen. Ask which one you are buying, and what the conflict rule is when both sides changed.

Intuit publishes a QuickBooks Online MCP server, and it is a genuinely good piece of work. It exposes QuickBooks entities and reports as callable tools so an AI assistant can read and write real ledger data through a standard interface, it supports flags that disable write, update and delete, and it is free.

Two properties define what it is for. It runs as a local process on one machine, and it authenticates against one company realm at a time. For a developer or a single business wiring one company to an AI assistant, that is exactly the right shape, and you should use it.

For an accounting firm it is the wrong shape, and not because of any deficiency in the software. A firm with forty clients going that route registers and maintains its own Intuit application, holds forty sets of refresh tokens, runs the process somewhere its staff can reach, and then builds the parts that are not in scope for a local developer tool: which staff member may reach which client, an enforced read-only role, an approval step before a posting lands, revocation that takes effect in seconds, and an audit log a partner can read during a dispute. That is a platform, not a configuration, and building it is a year of somebody’s life.

That gap is exactly what Numbers Game is. Same protocol, same idea, built as a hosted multi-tenant service where a firm is a tenant, a client file is a scoped resource, and a staff member is a role.

• What scopes does it request, and what does it use? A gap between the two is not automatically bad, but a vendor who cannot describe it has not thought about it.
• Which direction does data flow, and what is the conflict rule? Ask specifically what happens when the same record changed on both sides since the last sync.
• What happens on disconnect? Does the data it created stay in QuickBooks, does it stop syncing quietly, does anything get cleaned up. Disconnection behaviour is where integrations surprise people.
• How does it detect duplicates? This is the single most common way an integration damages a set of books, and the honest vendors will describe the rule rather than assert the outcome.
• Does it store your ledger data, and for how long? Do not accept “we never store your financial data” without asking about the exceptions. Every product has some.
• Can you revoke, and how fast does it take effect? There is a real difference between revocation on a cache timescale and revocation whenever the current token happens to expire.
• What can it not do? Ask for the list of structural incapabilities. A vendor without one has not drawn the boundary anywhere.
• Who finds out first when it breaks? Token expiry, a failed sync, a refused write. If the answer is your client, that is the answer.

These are the three we see most often when a firm brings us a set of books that stopped tying out. None of them is caused by a bad product. All three are caused by connecting a good product without deciding what it was allowed to do.