> ## Documentation Index
> Fetch the complete documentation index at: https://docs.twinbay.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# QuickBooks

> Customers, items and accounts, with invoices and the payments that settle them

A small business's books over the QuickBooks Online Accounting API: customers, the chart of accounts, the items an invoice bills for, the invoices themselves, and the payments that settle them. Intuit ships no Python SDK, so the conformance suite pins `python-quickbooks` — the community client the ecosystem uses — and drives the container through the sequence a bookkeeping integration actually runs.

**Slug:** `quickbooks`

## The company is in the path

QuickBooks does not put the company in the token. Every path is `/v3/company/{realmId}/{entity}`, so a caller needs the realm before it can make a single call, and a token that does not belong to the realm it is addressing is a `401` rather than a `404`. One container serves one company, and its realm is `9341454816836284`.

## What it models

| Area               | Modelled                                                                                                                                                                                                                                                                 |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The company        | A furnished sandbox company: its name, address and fiscal year, the preferences the modelled surfaces read, a chart of accounts (`Checking`, `Accounts Receivable (A/R)`, `Undeposited Funds`, `Services`, `Sales of Product Income`), one service item and one customer |
| Customers          | Create, read, sparse update that merges, full update that replaces and clears what the payload omits, and a balance derived from unpaid invoices                                                                                                                         |
| Accounts and items | Create, read, update and query, with `Classification` and `FullyQualifiedName` derived, name uniqueness enforced, and an item's income account resolved rather than trusted                                                                                              |
| Invoices           | Create with lines, read, update, void and delete, with `TotalAmt` from the lines, `Balance` from the payments applied, `LinkedTxn` from those payments, and `DocNumber` from the company's numbering preference                                                          |
| Payments           | Create against one or more invoices, read, and the effect on each invoice's balance, the customer's balance and both sides' `LinkedTxn`; what a payment did not apply is reported as `UnappliedAmt`                                                                      |
| Querying           | The subset of QuickBooks' SQL-like language the rest needs: `select *`, `select *, Sku`, `select count(*)`, `where` on equality, `in` and ordered comparisons, `orderby` either way, and `startposition`/`maxresults` paging with no cursors                             |
| Concurrency        | `SyncToken` on every entity, incremented on every write, with a stale token refused `5010` rather than applied                                                                                                                                                           |
| Authentication     | An opaque Intuit-shaped access token in `Authorization: Bearer`, a realm the token does not hold, an expired token, and per-company throttling answered `429` with `Retry-After`                                                                                         |
| Peripheral         | `batch`, up to thirty items answered one by one, and `cdc` for what has changed since a timestamp                                                                                                                                                                        |

Advancing the sandbox runs the arithmetic of the books again: an invoice against its lines and payments, a customer against its unpaid invoices, and whether a due date has passed. It is what settles a record edited by hand, and a second advance at the same instant moves nothing.

## Scenarios

`overdue-receivables`, `throttled`.

## Not modelled

The OAuth authorization code flow, token refresh and revocation — the twin is handed a live token. Vendors, bills, purchases, estimates, credit memos, sales receipts, journal entries and the rest of the ledger beyond receivables. Taxes: `TxnTaxDetail` is stored and never computed. Reports, attachments, PDFs, sending a form by email, webhooks, the Payments API and the Payroll API. Inventory items, multi-currency, and more than one company per container. Voiding or deleting a payment, and deactivating a customer, an account or an item.

Nobody who built this twin had an Intuit sandbox company, so a handful of faults had to be chosen from Intuit's documentation rather than read off a live one — the throttle envelope, the refusal for over-applying a payment, and the fault a batch over the limit is refused with. The twin's own README lists them under **Where the docs do not reach**.