QuickBooks and Xero to Acumatica: connect, export, and load a test tenant

TLDR

A throwaway demo does not close a QuickBooks or Xero outgrower, and a one-shot go-live is too late to learn. Connect the source books, export a cutover pack (Xero over read-only OAuth via kborovik/acu-xero-export; QuickBooks the same connect-and-export shape), map into versioned config, and load a populated Acumatica test tenant the prospect can click through. The same git tree iterates into a rehearsable cutover — this is a migration engagement, not a tool product you install and run alone.

Prospects want their books in Acumatica before they commit

A canned industry demo proves the product; a populated test tenant with the prospect’s own masters and open balances proves the deal.

Acumatica’s main new-customer funnel is companies outgrowing QuickBooks or Xero. The implementing partner is already selling the deal; what slows the cycle is trust that this business fits the new system. A shared demo company does not answer chart-of-accounts, tax, open AR/AP, or item questions the controller will ask. Waiting until cutover weekend is worse: the first honest load is also the production load.

The motion that shortens the cycle is test-tenant-first: source books in, versioned configuration and master data out, a non-production company the prospect can click through, then the same tree toward go-live.

Xero export is a cutover pack over read-only OAuth

kborovik/acu-xero-export runs a CLI (xero-export) that authorizes a Xero org read-only and writes a dated cutover pack — masters, opening balances, open AR/AP — not a live connector and not multi-year history.

Configure a Xero web app, log in once, pick the org, and export against a cutover date:

xero-export auth login
xero-export export \
  --cutover-date 2026-06-30 \
  --tenant "My Company Ltd"
# → exports/My_Company_Ltd_XeroExport_2026-06-30/

The pack is file-shaped for the migration workshop, not a UI dump:

Area	Examples in the pack
Org / tax	organisation JSON, tax rates
GL	chart of accounts, trial balance
AR	customers, open invoices, aged receivables
AP	suppliers, open bills, aged payables
Items	items, inventory when tracked
Control	control totals + manifest

Open invoices and bills are current authorised documents with amount due. Aged reports and trial balance use the cutover date you pass. For go-live you re-run export on cutover day so open documents match the trial balance. Scopes stay read-only accounting reads plus offline access for refresh — nothing writes back into Xero.

QuickBooks uses the same connect-and-export shape

QuickBooks is not a different product pitch: the engagement expects the same pack path — connect, export masters and open balances, hand the pack to mapping and load — whether the parallel CLI is already in repo or still engagement-scoped.

Xero is the live OAuth exporter today. QuickBooks gets the same connect-and-export shape so both sources feed one cutover pack convention into the Acumatica side. Until a parallel QuickBooks exporter lands, QB extract stays engagement-scoped (authorized company file or export the prospect shares with the VAR). The commercial claim is not “buy our exporter”; it is “source books become a pack, then the same Acumatica tree.”

Field mapping lands in the same git tree as the tenant

Agreed mappings become versioned YAML and seed data next to the tenant configuration — the next workshop reuses them instead of re-keying a dead spreadsheet.

Export is only the front of the pipe. Someone who knows the books still maps Xero/QuickBooks concepts onto Acumatica entities (customers, vendors, inventory, subaccounts, tax). That work product belongs in the same repository as configuration-as-code: apply, diff, and later scenarios all see one tree. AI can accelerate mapping drafts; validation stays against the target schema and human sign-off for the engagement.

The test tenant is loaded so cutover can be rehearsed

Rebuild, load what was scoped, exercise critical paths, prove drift with acu diff, tear down, and repeat — go-live stops being a one-shot when dress rehearsals are cheap.

The migration engagement and the rehearsable cutover destination share one tree. A typical loop on a rebuildable non-prod path:

Reset or rebuild the Acumatica company (hosted bootstrap or self-hosted lab).
Apply scoped configuration and master data from git.
Load open balances / open docs when the SOW includes them.
Exercise day-one paths (scenarios when the path must post documents).
Prove identity with acu diff (exit 0 = zero drift on the scoped surface).
Tear down or roll back; fix YAML or mapping; run the loop again.

Two claims stay honest by measurement: rebuild speed is the measured empty-tenant apply time, and “identical” means the machine-checkable surface scoped in the SOW — neither is a slogan without a lab number.

What this engagement includes and what it does not claim

In scope is a test-tenant-first migration with a rehearsable path to go-live; out of scope is a licensed migration-tool product, multi-year history dump, or live bidirectional connector.

Typical inclusions:

Source connect and cutover export (Xero OAuth pack live; QuickBooks same shape)
Mapping workshops with someone who owns the books
Versioned Acumatica configuration and master data
Populated test/sandbox tenant the prospect can use
Path into cutover rehearsal on the same tree

Explicit non-claims:

Not a product SKU you install in Acumatica and keep running alone
Not multi-year GL history unless the SOW adds historical load
Not a live Xero↔Acumatica or QuickBooks↔Acumatica connector
Not production write until the SOW says so — test and sandbox first

Access stays honest: read-only on the source; write only on the agreed Acumatica non-prod company; Acumatica version pinned for the engagement.