Xero invoice stress test checklist for high-volume days

Why invoice automations break on high-volume days

• No new invoices = false confidence. A scenario can appear healthy when there’s nothing new to process.
• Backlogs hide failures. A queue of incomplete executions can mask the real issue until the backlog hits a tipping point.
• Expired or revoked connections. OAuth tokens, user permissions, and tenant connections can change over time.
• Retry storms and duplicates. Without idempotency, a spike day can create duplicate invoices or duplicate downstream records.
• Rate limits. Even well-built workflows can start failing if they don’t throttle or back off under load.

The simple rule: stress test with real invoice volume

1. Create enough invoices to simulate a peak day (not a single invoice).
2. Run the full workflow end-to-end (Xero → automation → downstream systems).
3. Prove the workflow is safe to retry (idempotent, resumable, and observable).

Pre-flight checks (before you generate any test invoices)

• Confirm the automation is actually active. If a workflow was paused, archived, or unintentionally decommissioned, it may require re-enabling before it will process anything.
• Confirm the Xero connection is valid. Make sure the correct org/tenant is connected and authorized.
• Identify the safe place to test. Ideally use a sandbox org. If you must test in production, clearly label invoices and have a cleanup plan.
• Decide your pass/fail criteria before you start. Examples: all 25 test invoices appear in the downstream system within 5 minutes; zero duplicates created on re-run; error rate stays below 5%.
• 100% of invoices are created/approved in Xero as expected.
• 100% of invoices appear downstream.
• 0 duplicates.
• No sustained errors for >15 minutes.

Step-by-step: Xero invoice stress test checklist

1) Create a test batch that matches peak reality

• Pick a target count (start with 25–50; scale up if peak volume is higher).
• Include realistic variance:
• multiple customers
• different invoice totals
• multiple line items
• different tax codes (if applicable)
• Timebox the creation window (e.g., create all invoices within 10–15 minutes) to mimic a real surge.

2) Run the workflow and capture baseline metrics

• start time, end time
• total invoices processed
• error count and error types
• any throttling/rate limit events
• queue depth / incomplete executions

3) Validate downstream results (don’t stop at “success”)

• it exists downstream
• it mapped to the right customer/job/order
• amounts and line items match
• tax fields match
• status is correct (draft vs approved vs sent)

4) Test idempotency: re-run the same batch

• Re-run the workflow for the same invoice set.
• Confirm that no duplicate downstream records are created.
• Confirm that updates are applied as updates—not as new creates.

5) Test a controlled failure and recovery path

• temporarily remove required data (missing field)
• pause the workflow mid-run
• simulate a downstream API timeout

• invoices land in an exceptions queue with a clear reason
• the workflow can resume after the issue is fixed
• the recovery run does not create duplicates

6) Add monitoring signals you can trust

• sustained error rate above a threshold
• time since last successful invoice processed
• queue/incomplete execution growth
• connection/auth errors

7) Document rollback options

• What do you do if duplicates were created?
• How do you identify the affected invoice set?
• Can you safely delete or reverse downstream records?
• Who owns the decision to pause processing?

Common failure patterns (and what to do)

• It runs when you test, but not when invoices arrive later: your trigger condition might be wrong (created vs approved vs sent).
• It fails after “working for months”: connection credentials, tenant permissions, or rate limits changed.
• It only fails on peak days: add throttling, batching, and backoff; confirm retries are idempotent.

When to get help