A controller running an agentic ERP at the parent and QuickBooks Online at a subsidiary has the same question every quarter: can the agents touch the subsidiary ledger directly, or does something sit in between. The honest answer is that QuickBooks Online is a system of record with its own object model, its own throttling behaviour, and its own idea of what a journal entry is. An agent that posts straight into it without staging will eventually produce something the auditors cannot explain.
This piece walks through the concrete architecture: how the QuickBooks Online REST API is actually shaped, what its rate limits mean for a parent system doing continuous reconciliation, how agents should stage postings against a deterministic ledger before writing to QuickBooks, and how daily proof is produced across both sides.
The QuickBooks Object Model Is Not Your Ledger
QuickBooks Online exposes a REST API organised around named entities: Invoice, Bill, Payment, JournalEntry, Customer, Vendor, Account, Item, and a few dozen more. Reads use a SQL-like query syntax. Writes are full-object replacements, not partial updates. There is no PATCH. The quirks that matter for a parent ERP are structural, not cosmetic.
Customer and Vendor are separate objects with separate IDs, so a counterparty that is both buys and sells to you exists as two unrelated records that must be matched on something other than QuickBooks IDs. Name-list entities like Customer, Vendor, Item and Account cannot be deleted through the API, only deactivated by setting Active to false. Minor versions shape the response schema: as of August 2025, Intuit deprecated minor versions 1 through 74, and any request specifying a lower value is now treated as minor version 75. Pinning the minor version in every call is the only way to keep schema drift from leaking into the agent's reasoning.
None of this is a reason to avoid the API. It is a reason not to treat QuickBooks as the authoritative ledger when a parent system is already serving that role. The ownership decision comes first: for every object type (customers, items, chart segments, open bills, posted journals) one system owns writes and the other receives them. The agent respects that boundary.
Throttling, Tokens and the Operational Envelope
QuickBooks Online publishes hard limits that any sustained integration will hit. Production enforces 500 requests per minute per realm ID and 10 per second per realm and app, with batch endpoints throttled separately at 40 per minute per realm and app. A 429 response asks the caller to wait 60 seconds before retrying, and any request taking longer than 120 seconds times out.
OAuth adds its own clock. QuickBooks Online access tokens expire after 3,600 seconds, and refresh tokens are valid for 100 days with a rolling expiry extended on every use. A parent ERP running agents against a sleepy subsidiary ledger has to touch the refresh token at least every 100 days or re-consent the whole connection. That is a scheduled job, not an afterthought.
The commercial envelope changed as well. Intuit's App Partner Program, effective July 28, 2025, split API calls into free unlimited Core (write) operations and metered CorePlus (read) operations, with the free Builder tier capped at 500,000 CorePlus reads per month before further requests are blocked. For an agent that polls, that cap is the design constraint. Reads must be budgeted; writes are cheap.
Staging Postings Against a Deterministic Ledger
The architectural rule that keeps auditors on side is simple: the agent never writes directly to a ledger it also reasons over. In the erp.io model, agents operate against a deterministic double-entry ledger they cannot mutate. They produce proposed postings, which a rules engine validates (balanced, in-period, within approval threshold, mapped to real GL accounts) and then commits. The commit is what writes to QuickBooks, not the agent.
The pipeline for a vendor bill looks like this: extract the invoice fields, code them against the chart of accounts and class/location segments, check the proposed Bill object against policy (approval threshold, duplicate invoice number, vendor on an active list), post to the staging ledger, then write to QuickBooks via a Bill or BillPayment call with the parent system's internal transaction ID stamped in a reference field. Idempotent posting means the same internal ID always resolves to the same QuickBooks record. If the write fails midway, the retry does not produce a duplicate: the agent queries by the external ID first and only creates when nothing matches.
That reference field is what makes reconciliation possible. QuickBooks supports a PrivateNote and a DocNumber on most transaction objects; one of them carries the parent system's hash. Without it, a failed write followed by a successful retry is indistinguishable from a human entering the same bill twice. With it, every QuickBooks row has a parent-side counterpart or an explainable reason for not having one. The structural separation between the agent's reasoning surface and the ledger it posts to is what the control relies on.
Change Data Capture, Webhooks and Daily Proof
Reconciliation needs to see what changed on both sides since the last run. QuickBooks offers two mechanisms, and both have sharp edges. The CDC endpoint pulls objects modified since a timestamp, but it only tracks changes within the last 30 days and returns at most 1,000 objects per response, and it excludes entities such as JournalCode, TaxAgency, TimeActivity, TaxCode and TaxRate. A sync that falls more than 30 days behind cannot use CDC to catch up and must fall back to full-entity queries.
Webhooks fill the real-time gap by sending change notifications when records are created or updated. Intuit's documented practice requires endpoints to respond within 3 seconds with an HTTP 200 and to be served over HTTPS with a properly chained certificate. The payload is a reference, not the full object: the parent system still has to call back to QuickBooks for the data. And the payload itself is changing. Intuit extended the migration deadline to July 31, 2026, after which apps that do not update will no longer process notifications, which can delay changes customers see in QuickBooks Online.
Daily proof is built on this plumbing. Every night the parent agent pulls the day's CDC delta from QuickBooks, resolves each row to a staged posting via the external ID, and produces a reconciliation report: matched, matched-with-variance, unmatched-in-QBO, unmatched-in-parent. Variances route to the Controller agent; unmatched rows block the next day's close until a human disposes of them. The report is the artifact, not an email. Close speed is largely a function of how fast that variance queue clears.
Chart of Accounts Mapping Is the Integration Surface
Every reconciliation failure eventually points back to a mapping. QuickBooks Online uses a flat Account entity with AccountType and AccountSubType; the parent ERP almost certainly uses a multi-segment chart. A subsidiary QuickBooks file may have 180 accounts; the parent chart has a different granularity, different natural account codes, and segments for entity, department and location. A one-to-one copy will not work, and treating the chart as a copy job is where most integrations quietly fail.
The mapping lives in the parent system as a versioned table: subsidiary account ID, parent natural account, segment overrides, effective date range. The agent uses it on every write, not on migration day only. When the subsidiary adds an account in QuickBooks, the webhook fires, the mapping table flags it as unmapped, and the Controller agent either proposes a mapping or holds postings against that account until a human approves one.
Items, classes and locations work the same way. The ownership rule says the parent system defines them and the subsidiary receives them; the agent writes to QuickBooks when the parent list changes. Reads from QuickBooks are advisory, used to detect drift, never to overwrite the parent list silently.
What the Controller Should Require Before Go-Live
Three artefacts settle whether the integration is production-ready. First, a written sync map by object type naming the owning system, the direction, the conflict rule, and the external-ID field used for idempotency. Second, a reconciliation report run for at least two closed weeks before cutover, with variance counts tracked daily. Third, a rollback condition: a defined threshold of unmatched rows or failed writes that triggers a pause of agent writes to QuickBooks, not a frantic Slack thread. These are the same disciplines that belong in any agentic ERP platform, and they are what let the Controller sign off on a subsidiary ledger they did not personally touch.
The integration is not the point. The ledger is. QuickBooks is a durable, well-documented, widely-used book that happens to live at a subsidiary; the parent agentic ERP is the system that reasons across all of them. Treat the API as a transport, stage every posting, stamp every write, reconcile every day, and the two ledgers stay in agreement. Skip any of those steps and the agents are writing cheques the controls cannot cash.