Finance is where automation returns the most hours, and where a bad build does the most damage. The difference between those two outcomes is usually not ambition or budget. It is whether whoever designed it understood what an accounting API is deliberately unwilling to do.

This is a practical account of working against QuickBooks and Xero: what is straightforward, what is constrained, and the four mistakes that turn a time-saver into a ledger nobody trusts.

In short

An accounting API is not a database with a web interface. It is a ledger with rules, and it will refuse things that would make the books inconsistent. Most of the friction people report is the system declining to let them do something wrong.

Contacts, invoices, bills, payments, ageing and reports are all straightforward on both QuickBooks Online and Xero. What is constrained is constrained deliberately: bank reconciliation stays with a person, double entry is enforced, tax is more opaque than it looks, and closed periods cannot be written into. The damage comes from four mistakes, and the first one, retries that are not idempotent, causes more of it than the other three together.

Straightforward

Constrained, and deliberately

Creating and updating contactsCustomers and suppliers, with deduplication done before the write rather than after.

Bank reconciliation stays with a personYou can pull statement lines, propose matches and rank candidates. Two hours of matching becomes twenty minutes of confirming.

Raising sales invoices and posting supplier billsLine items, terms and tax codes, with the source document attached.

Double entry is enforcedThe API rejects a posting that does not balance. An automation cannot create an unbalanced ledger. It can only fail loudly.

Reading the live ageing and recording paymentsCollections driven off real data instead of a stale export, with payments allocated against open invoices.

Tax is more opaque than it looksWhat the API posts is not always what the interface would have produced. Post a handful in a sandbox and have your accountant check.

Pulling reports, and managing reference dataScheduled reports into a dashboard that refreshes itself; items, accounts and tax rates maintained as data.

Periods closeOnce locked, the API cannot write into a period. Anything posting on a delay must route to a person, not silently land in the current one.

What is genuinely straightforward

Both platforms handle the core objects well, and for these the API is not the hard part. The surrounding process design is.

Creating and updating contacts, customers and suppliers, with deduplication done before the write rather than after
Raising sales invoices from another system, with line items, terms and tax codes
Posting supplier bills, including attachments of the source document
Reading the live ageing to drive collections off real data instead of a stale export
Recording payments and allocating them against open invoices
Pulling reports on a schedule into a dashboard that refreshes itself
Managing items, accounts and tax rates as reference data

That list covers the large majority of what finance teams ask for. If your requirement is on it, the question is about exception handling and approval routing, not integration feasibility.

What is constrained, and why

Bank reconciliation stays with a person

You can do the preparation: pull the statement lines, propose matches, rank candidates, flag the ones that look like duplicates. You cannot fully hand over the confirmation, and you should not want to. Reconciliation is the control that catches everything else going wrong; automating away the human judgment removes the check that makes the rest safe.

A good automation here reduces reconciliation from two hours of matching to twenty minutes of confirming. That is the realistic prize, and it is a substantial one. Anyone promising fully automated reconciliation is describing something else, or has not thought about what happens when the automation is wrong.

Double entry is enforced

The API will reject a posting that does not balance. People new to accounting integrations experience this as an obstacle; it is the single most valuable safety property in the system. It means an automation cannot create an unbalanced ledger no matter how badly it is written. It can only fail loudly.

The design consequence: build transactions completely and validate them before posting. Do not post and then patch.

Tax is more opaque than it looks

Both platforms have automated sales tax logic, and what the API posts is not always identical to what the user interface would have produced for the same inputs. If your tax treatment is unusual (multiple jurisdictions, exemptions, mixed-rate lines), post a handful of real transactions in a sandbox and have your accountant check the result before going near production volume. This is an hour that regularly saves a quarter-end.

Periods close

Once a period is locked the API cannot write into it, and rightly so. Any automation that posts on a delay needs to handle the case where the target period has closed since the transaction occurred. The right behavior is to route it to a person, not to silently post it into the current period and quietly distort two months at once.

Where the two differ

	QuickBooks Online	Xero
Main constraint	Desktop vs Online is a different project entirely	Rate limits shape every bulk design
Throughput	Comfortable for transactional volume; needs care on migration	Per-minute and daily caps per organization; batching required from version one
Webhooks	Available across many entities	Narrower coverage, so some designs still poll
Multi-entity	Per-company connections	Multi-tenant model that handles several organizations cleanly
Reporting dimensions	Classes and locations, if enabled on your plan	Tracking categories, capped at two
Token lifetime	Longer-lived, with refresh	Short access tokens; refresh handling must be solid
Documentation	Comprehensive, occasionally inconsistent with behavior	Clean and generally accurate

Neither is better in a way that should make you switch. If you are choosing from nothing and integration matters, Xero's API is the more pleasant to build against and its rate limits are the price of that. QuickBooks Desktop is the genuine outlier. It needs a connector running on the machine holding the company file, which brings availability and access problems that belong in the estimate from the start.

The four mistakes that cause real damage

1. Retries that are not idempotent

By some distance the most damaging, and the most common. An API call times out. The automation retries. The first call had actually succeeded. You now have the same bill posted twice, and nobody notices until a supplier is paid twice or the reconciliation refuses to balance.

The fix is not complicated: a deterministic reference derived from the source document, checked before every write, plus a duplicate check on the natural key. It has to be designed in from the first version, because retrofitting it after a double-posting means also cleaning up the ledger.

2. Posting first, validating later

Writing the transaction and then checking whether it was right. This treats the ledger as scratch space. Validate completely: supplier known, purchase order matched within tolerance, arithmetic self-checked, coding determined, period open, and only then post. Anything failing validation goes to a review queue, not into the accounts.

3. No review queue, or a bad one

Every document-processing automation holds some proportion back. A realistic straight-through rate after tuning is 75% to 90%, which means one invoice in six needs a person. Where they go matters enormously.

A badly built queue is a spreadsheet of document numbers with "REVIEW" beside them. People stop using it within a fortnight and process those invoices manually instead, which is how a functioning automation gets abandoned despite working exactly as specified. The queue needs the document, the extracted values, the reason it was held, and one-click accept or correct. Budget for it as a first-class part of the build.

4. Treating gross revenue as revenue

Specific to ecommerce and payment-processor integrations, and reliably wrong. A Shopify or Stripe payout is not the sum of the orders: it is orders minus fees, minus refunds, minus chargebacks, timed on the processor's schedule rather than the order date. Posting order totals and calling it revenue produces a set of books that look fine and reconcile to nothing. Fees, refunds and payout timing each need handling separately.

What this costs to build

Invoice and document processing is $3,500 to set up: capture, extraction, validation, two-way matching against purchase orders, a review queue and posting. Three things add quoted scope: a long tail of suppliers sending genuinely unstructured documents, three-way matching against goods receipts, and an accounting system without a usable API, QuickBooks Desktop included.

After launch, changes are $175 each on pay as you go, or included in a plan from $700 a month. Separately, expect $50 to $150 a month in extraction charges and platform operations, paid to the vendors directly. That part scales with volume rather than being flat.

Before you commission anything

Which system, and which edition? Online or Desktop is the first fork. Plan tier decides whether classes, tracking and volume limits are available.
What is the matching tolerance? Within 2% or $25, whichever is lower, is a common answer. There is no universally correct one, and getting it wrong in either direction is costly.
Who owns the review queue? A named person, not a team. Unowned queues are abandoned queues.
What happens when a period closes? Answer it before the first quarter-end, not during.
Is the supplier list clean? Three spellings of the same supplier will defeat matching before any AI gets involved.

What accounting APIs will and will not let you automate