QuickBooks Alternatives When You Need an API, Not an App
Why platform teams outgrow QuickBooks, what "API, not an app" actually requires, and which alternatives fit which job.
QuickBooks Online is a capable small-business accounting application with a large install base, an OAuth 2.0 REST API, webhooks, and a substantial developer ecosystem. Most teams looking for an alternative are not unhappy with it as an application. They have hit a different problem: they need software, not a person, to keep the books, and QuickBooks is built around the assumption that a person does.
This article is about that mismatch and what to use instead. If you are a small business choosing bookkeeping software, QuickBooks may well be the right answer and none of this applies to you.
Where the mismatch shows up
One API connection is one company file. QuickBooks' API is scoped to a company, identified by a realm. A platform that needs books for 300 seller entities is managing 300 connections and 300 subscriptions, not one account with 300 companies inside it. This single fact is what usually ends the evaluation.
The API is a companion to the application, not the product. Features arrive in the interface and reach the API on their own schedule. When your entire integration depends on a capability being callable, "available in the app" is not the same as available.
Throttling is designed for sync, not for transaction flow. QuickBooks' limits are commonly documented at 500 requests per minute per company, with tighter limits on batch and report endpoints; confirm current figures against Intuit's own developer documentation. That is generous for syncing one business's records and a different proposition when your platform posts entries for thousands of businesses in real time.
EU cross-border tax has gaps. Intuit's own support material states there is no standard procedure for recording IOSS VAT in QuickBooks and points users to a bookkeeper or accountant. For a platform selling across EU borders, distance-selling and One Stop Shop handling is not an edge case, so this is worth confirming for your specific countries before building.
None of these are defects. They are the consequences of building an excellent application for businesses that employ a bookkeeper.
What "API, not an app" actually requires
Before comparing alternatives, it helps to name what platform teams are actually asking for, because "has an API" is met by almost everything.
- Full coverage. Everything the application can do is callable. Nordlet's position here is that the app has no private endpoints — the interface runs on the same endpoints external callers get.
- Multi-company under one account. Books for many entities without many subscriptions.
- Idempotent writes. A retried request cannot create a second invoice or a duplicate journal entry.
- Event delivery. Webhooks that fire on state changes, so your system reacts rather than polls.
- Enforced accounting invariants. Unbalanced postings rejected, closed periods locked, posted documents not editable.
- Tax as data, not as a screen. Rates, place-of-supply decisions, validation results, and registers reachable programmatically.
- A sandbox that matches production, and unlimited test companies so integration tests are cheap.
Score any alternative against that list rather than against a feature matrix.
The alternatives, by what you are trying to do
| Your situation | Reach for | Why |
|---|---|---|
| Your platform must own the books for many tenants | An embedded accounting API such as Nordlet | Multi-company under one account, metered pricing, accounting rules enforced server-side |
| Your customers keep books in QuickBooks and you integrate with them | Stay on the QuickBooks API, or use an aggregator | The books belong to the customer; meeting them there is correct |
| You need books in several accounting apps at once | An aggregator such as Codat, Rutter or Merge | One interface across many underlying systems |
| You need real-time wallet balances, not statutory books | Ledger infrastructure such as Modern Treasury Ledgers | Built for throughput and immutability, not for tax filing |
| You want one system across operations and finance | An ERP such as Odoo | Breadth, at the cost of running it yourself |
| You are a small business with a bookkeeper | Xero, QuickBooks, or a local equivalent | The application is the point |
Embedded accounting API
This is the direct answer to "API, not an app". The accounting system becomes a backend service your product calls, and your users never see a general ledger.
Nordlet is built for this shape: an immutable double-entry ledger where balance is enforced by a database trigger at commit time, gapless document numbering, period locking that rejects postings dated inside a closed month with a 409, an audit record of every mutation, Idempotency-Key support that replays the stored response on a retry, and signed webhooks written to a transactional outbox in the same database transaction as the change. Pricing is metered rather than per company: from €10 per month with 3,000 requests included, with unlimited companies, users, and sandbox companies on every plan.
The honest limits: Nordlet is in early access and onboarding design partners; EU VAT covers per-country rates, VIES validation, and OSS/IOSS return computation, but domestic return packs ship for three countries today — Lithuania (FR0600), Germany (UStVA) and Poland (JPK_V7M) — and payroll is Lithuanian only.
Aggregators
Codat, Rutter and Merge give you one interface into whichever accounting system each customer already uses. If your product's job is to read or write your customers' books — lending, spend management, analytics — this is the right category and an embedded ledger would be the wrong one. If your platform needs to be the system of record, an aggregator cannot be it.
Ledger infrastructure
Products in this category track balances immutably at high throughput without doing statutory accounting. They are a good fit under a wallet or payments product, and they leave VAT, invoicing, and annual reporting to something else.
ERP
Odoo and similar suites cover far more of the business than accounting. The trade-off for platform builders is the integration surface: Odoo's external API works at the data-model level over RPC, its documentation states API access is limited to the Custom pricing tier, and the current RPC endpoints are scheduled for replacement by a newer JSON API. That is covered in Nordlet vs Odoo for platform builders.
If you are migrating away from QuickBooks
A few things that reliably take longer than expected:
- Chart of accounts mapping. Do it deliberately, and keep the old account code as a reference field on the new account. You will need it when someone asks why a comparative figure moved.
- Opening balances. Migrate as balances at a cut-off date, not as re-posted history. Keep the old system readable for the retention period rather than trying to replay years of entries.
- Document numbering. Decide whether new series continue the old numbering or start fresh, and check the requirement in your jurisdiction before you choose.
- Open items. Unpaid invoices, unapplied credits, and partially matched payments need to arrive as open items, not as net balances, or reconciliation will not work afterwards.
- Tax periods. Do not migrate mid-period unless you are prepared to file one return from two systems.
- Run both for one cycle. Post the same month in both and compare the trial balance before you switch off the old system.
FAQ
Is there a free alternative to QuickBooks?
There are free and open-source accounting systems, and Odoo publishes a free tier limited to one application. Free rarely stays free for a platform, because the costs move to hosting, upgrades, compliance updates, and the engineering time to keep an integration working. Price the total, not the licence.
What is better than QuickBooks for a marketplace?
For marketplace accounting specifically, an embedded accounting API is a better structural fit, because it can keep books for many entities under one account, enforce accounting rules server-side, and be driven entirely by your software. QuickBooks remains a better product for a single business with a bookkeeper.
Does QuickBooks have an API for developers?
Yes. QuickBooks Online offers an OAuth 2.0 REST API with webhooks and a developer portal. The constraint for platform use is not the API's quality but its scope: it is designed to integrate with a company's books, not to be the ledger inside another product.
Can I keep QuickBooks and add an accounting API?
You can, and some teams do: the platform's own books live in an embedded ledger, while integrations push summary journals into whatever accounting system each business customer uses. The rule to hold onto is that exactly one system is the record for any given set of books. Two systems both claiming to be authoritative is how reconciliation problems start.
What about Xero instead?
Xero is a strong alternative as an application and has a well-documented API, but it has the same structural shape: subscriptions and API limits are per organisation, and uncertified apps are capped at 25 connected organisations. The comparison is set out in Nordlet vs Xero for embedded accounting.