QuickBooks test data that looks like QuickBooks.
Not a generic ledger dump — a QuickBooks-shaped company: the entities, the relationships, and books that actually reconcile.
What you get
QuickBooks is the most mature surface — a native-shaped API and an implemented export pack. The company arrives with the entities you actually integrate against:
| Entity | Notes |
|---|---|
| Customers / Vendors | Realistic names, terms, histories |
| Invoices / Bills | Aged, partially paid, with line items |
| Payments / Bill payments | Applied against the right documents |
| Accounts | A coherent chart of accounts |
| Journal Entries | Double-entry, period-correct |
| Items | Tied to invoice lines |
More via the execute API.
Export pack or live API
Take it as a downloadable pack — CSVs in a zip, shaped like a QuickBooks export — to prototype against today. Or hit the native-shaped v3 API for a live, queryable surface: change the base URL, send your Fictix project key (X-API-Key), and query with ?query=SELECT * FROM Invoice. Most QuickBooks client code works with little or no change.
It reconciles with everything else
Questions
Is the QuickBooks data just random rows?
No — it's a coherent QuickBooks-shaped company: double-entry journals, aged AR/AP, and a GL that reconciles, not arbitrary values.
Can I use my existing QuickBooks integration code?
Mostly. The native-shaped v3 API follows QuickBooks' response shapes (approximate fidelity). Change the base URL and send your Fictix project key (X-API-Key) instead of an Intuit OAuth token; most client and parsing code works with little or no change. An export pack is also available.
Does it tie to Stripe and bank data?
Yes — the same company projects into Stripe and Plaid, so the invoice, the charge and the deposit are the same event for end-to-end reconciliation tests.