Why the order matters
A repair can only be judged when the layer below it is sound. Checking accounts is pointless while the connection is down, and counts of created documents mean little until each order creates at most one document and every line posts to a known account. The sequence below goes from the most basic condition to the most specific. Work on invented or redacted data on a demo or sandbox target, and stop at the first step that fails. This is a diagnostic order, not a vendor procedure.
- 1. Connection: is the connection alive and who owns renewing it? (See the refresh-token guide.)
- 2. Accounts: does every posted line use an active, approved account, with no default? (See the mapping-table guide.)
- 3. Retries and duplicates: does each source order create at most one document, even after a lost response? (See the request-key guide.)
- 4. Completeness: do source, created, already-present and held counts add up for a recent busy run, and were limits hit? (See the rate-limit guide.)
- 5. Contact identity: does each customer map to one contact by a stored identifier? (See the contact identity guide, for Xero.)
- 6. Updates: do edits to existing documents survive conflicts? (See the SyncToken guide, for QuickBooks Online.)
- 7. Currency: are code, amount and rate correct in each currency? (See the currency guide.)
- 8. Re-count: run a synthetic trading month and compare source, created, already-present and held counts again.
Record what each step shows
Keep the counts, the identifiers of any affected documents and the error text with names removed. A step that fails becomes the first item on the failure list. Each item that has a bounded paid job is named on the relevant guide; the order in which they are fixed matters and belongs in writing.
- Do not delete, void or merge real records to make a step pass; those are decisions for your finance owner or accountant.
- Do not re-run historical batches as a diagnostic step.
When to ask for help
One failing step with a clear cause is a bounded job. Several failing steps that interact are the project "Restore a broken invoice sync, proven on a synthetic trading month", from £2,950, and keeping the sync healthy afterwards is the standing service, £345 a month. Both prices are untested and confirmed after an enquiry; payment follows agreed checks and your sign-off, and nothing here is accounting advice. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.
Sources and limits
- Xero: OAuth 2.0 FAQ Checked 2026-10-11.
- Access tokens last 30 minutes and unused refresh tokens expire after 60 days, after which the user must authorise the app again.
- Each successful refresh returns a new refresh token that must be stored in place of the old one.
- If a refresh request gets no response, the previous refresh token can be retried for 30 minutes before the user must re-authorise.
- Xero: limits FAQ Checked 2026-10-11.
- At the time checked the FAQ states per-connected-organisation limits of 60 calls per minute, 5 concurrent calls and a daily limit (5,000 per 24 hours), plus 10,000 calls per minute across all organisations for an app.
- Going over a limit returns HTTP 429 with a Retry-After header giving seconds to wait; responses carry headers showing the remaining daily, minute and app-minute allowance.
- Xero suggests combining creates or updates in one request (about 50 items is practical under the 3.5MB size cap), paging (100 records at a time) and the If-Modified-Since header.
- Xero: account and payment mapping Checked 2026-10-11.
- Integrations should let users choose accounts from a filtered list, exclude accounts with status ARCHIVED, and not hard-code an account such as the sales account.
- Users can change their chart of accounts after set-up, so Xero advises validating stored mappings, before each call for infrequent integrations, and sending the user back to fix a missing or archived account.
- Payment accounts are filtered by account type BANK or by EnablePaymentsToAccount.
- Intuit: error 5010, Stale Object Error Checked 2026-10-11.
- The error means the update did not use the latest version of the object, which is carried in its SyncToken.
- Intuit recommends either storing each object's identifier, type and SyncToken and refreshing them from change data capture or webhooks, or reading the object before every update.