QuickBooks Online is the single source of truth for actuals in about 85% of the multi-location operators we work with. The integration between your books and your FP&A layer is, correspondingly, the most important plumbing in your stack. If it drifts, every downstream number — BvA, branch benchmarking, CFO Copilot recommendations — drifts with it.
This is the operator’s guide to how the Aziell QuickBooks integration works: what it pulls, how often, how it handles the class-vs-location split, and what to do when the numbers look off. It is long on detail on purpose. This is the layer worth getting right.
What the integration pulls
On the first sync, Aziell requests a 24-month historical window of the following objects:
- Chart of accounts (with hierarchy)
- Class list and location list
- All posted journal entries
- Invoice headers and line items
- Bill headers and line items
- Payroll summaries (at the GL level, not detail)
- Bank and credit card transactions
- Trial balance at month-end for each of the 24 months
Aziell does not request or receive: customer PII beyond name, vendor banking details, 1099 data, or anything from the QuickBooks Time product. The scope is deliberately narrow. We read what we need to rebuild your financial statements and stop there.
Sync cadence
After the initial 24-month pull, Aziell listens for QuickBooks webhook events and pulls incrementally as transactions post. In practice this means most transactions are visible in Aziell within 2 to 5 minutes of being posted in QuickBooks. A full reconciliation sweep runs nightly at 2:00 AM in the holdco timezone to catch any webhook misses and verify trial balance parity.
Operators sometimes expect real-time to mean “ sub-second.” It is close, but not that. The QuickBooks webhook infrastructure has a small variable delay. For FP&A purposes, 2 to 5 minutes is not different from real-time. For cash-management purposes that need faster latency, plug the bank feed directly into Aziell’s cash layer rather than relying on the QuickBooks bank sync as an intermediary.
Class vs. Location: the single most important decision
QuickBooks Online has two dimensional fields that multi-unit operators use in different ways: Class and Location. Aziell can consume either, but they produce materially different downstream behavior, and it is worth picking deliberately.
Location dimension
Intuit’s intended use. Native multi-location features (location-based sales receipts, location-aware bank rules). If your business is pure multi-location with one P&L per physical site, use Location. Aziell maps one QBO Location to one branch, one-to-one.
Class dimension
Intuit’s more flexible dimension. Classes can represent anything — service line, revenue stream, customer segment. Many multi-unit operators use Class for service lines within a location (dental vs. ortho vs. implants at the same practice) while using Location for the location itself.
Our recommendation
Use both. Location for physical branches (required if you want a clean branch tree), Class for service lines within branches (optional but highly valuable for service-mix analysis). If you are only using Class today to mean “location,” migrate. Aziell has a guided migration tool that rewrites historical journal entries with the new dimension; the process takes about 40 minutes on a typical book.
The benchmarking value of clean branch-level data is described in detail in branch-level P&L benchmarking — in short, if your branches are not separable in the ledger, they cannot be compared against each other, and you lose the highest-ROI FP&A exercise available to a multi-location operator.
How Aziell handles the chart of accounts
On first connect, Aziell imports every account and auto-classifies it into one of four roles: revenue, COGS, labor, or overhead. The classifier uses account name, account type, and parent-child relationships. Accuracy on multi-location service businesses is typically 90%+ on first pass.
The accounts that most often need manual reclassification:
- Contractor-labor accounts named as “Subcontractors” — the classifier defaults them to overhead; they should usually be labor.
- Supplies accounts used for both COGS materials and office supplies — split or reclassify.
- Credit-card rewards that post with a credit sign — reclassify as contra-expense, not revenue.
- Intercompany accounts across holdco entities — tag as eliminations to prevent double-counting at consolidation.
Fixing these four categories takes about ten minutes. It is the most consequential ten minutes of the setup, as described in the getting-started guide.
What to do when the numbers look off
The most common cause of a visible discrepancy between Aziell and QuickBooks is not a sync failure — it is a transaction posted in QuickBooks without a class or location tag. Those transactions show up in the company-level P&L but do not allocate to a branch, so the branch sum does not equal the company total.
Aziell surfaces these as a “Unallocated” branch in every view. Click in, and you see the individual journal lines that lack dimension tags, with a deep link back to each transaction in QuickBooks. Fix the tag in QuickBooks, wait for the next incremental sync, and the line moves to its correct branch automatically.
Other common discrepancies and fixes:
- Manual journal entries with the wrong class. Re-post with corrected class; Aziell picks up the amendment.
- Deleted transactions in QuickBooks that still show in Aziell. Trigger a manual resync from the Integrations panel; deletions flow through within five minutes.
- Accrual vs. cash basis mismatch. Aziell respects your QuickBooks company preference. If you need a cash-basis view of an accrual-basis book, set the toggle per report in Aziell; the GL stays untouched.
Multi-entity and holdco structures
If your group runs multiple QuickBooks companies (one per legal entity, for example), Aziell supports a holdco structure that aggregates across them. Each QuickBooks company connects as its own integration; Aziell consolidates at the holdco level with intercompany eliminations driven by the account tags described above.
This is the structure most PE-backed and fund-backed multi-location operators end up running. The setup takes roughly ten additional minutes per entity beyond the first. The only caveat is that the chart of accounts should align across entities; mismatched COAs produce messy consolidation views. Aziell has a COA-alignment helper in the holdco onboarding flow.
Security, scope, and audit
Aziell uses Intuit’s OAuth 2.0 scope with read-only permissions. No write scope is ever requested. Every API call is logged, and every journal line that enters Aziell retains its QuickBooks transaction ID for lineage. If an auditor asks you where a number came from, you can click the number in Aziell and land on the original QuickBooks transaction.
The integration can be revoked at any time from the QuickBooks admin panel. On revocation, Aziell retains your historical data in your tenant unless you also delete the Aziell workspace; no data is shared across tenants under any condition.
What to read next
If you have QuickBooks wired up and the COA cleaned, the logical next read is the driver-based budgeting framework, which builds the plan on top of the live actuals. If you are still weighing whether to connect at all, the hidden cost of spreadsheet budgeting frames the ROI.
The Aziell Product Desk publishes how-to content that documents how the platform actually behaves — setup paths, integration scope, dimension modeling, Copilot ergonomics. Posts under this byline are written by Aziell's product and engineering team based on what operators experience when they onboard. Every post is verified against the current build before publishing.
See the math run on your own books.
Connect QuickBooks, map your branches, and let the CFO Copilot surface your first recommendation set overnight.