Connect Xero with WooCommerce by agreeing when invoices are posted, how payments are recorded and how the totals will be reconciled. Test those three decisions separately. A successful connection does not prove that an order reached the right accounts, that a payment was applied once or that processor settlements match the accounting records.
Use the documented Xero for WooCommerce extension as the scope of this checklist. A custom integration using Xero’s API would need its own evidence and acceptance tests. API capabilities should not be treated as features of the installed extension, and an extension setting should not be assumed to govern a different connector.
Which order events create invoices and payments?
The Xero for WooCommerce extension sends sales invoices and order detail including shipping, discounts and tax. The extension offers separate Send Invoices and Send Payments settings. The extension documentation describes several posting triggers, including manual actions and payment or order completion. Write down the selected trigger for each process before running a test order.
Xero can apply an exported payment only after its invoice exists and is authorised. This makes sequence part of the acceptance check. If an invoice appears but the payment does not, inspect the order notes and the accounting record before retrying. Repeatedly changing several settings can make a straightforward mapping problem harder to diagnose.
The extension uses one configured Payment Account for every WooCommerce payment gateway. If a business expects separate clearing treatment for different gateways, bring that requirement to the accounting owner explicitly. Do not assume that selecting several checkout methods produces several accounting destinations through this extension.
A successful invoice export adds the Xero invoice ID to the WooCommerce order notes. Retain that identifier in the test worksheet so the reviewer can compare the exact order and invoice. A screenshot of an invoice with a similar customer name is less reliable than a record linked by identifiers.
How should tax mapping be agreed?
WooCommerce tax documentation explains software configuration rather than deciding when or what tax to charge. Use the tax settings guide to understand the controls, and have the business’s accounting adviser define the appropriate treatment. This separates a configuration task from a local tax determination.
WooCommerce can calculate tax using the shipping address, billing address or shop base address. Record the selected basis with the approved test cases. If the two systems calculate or label a charge differently, inspect that basis and the corresponding account and tax mapping rather than assuming the connector should silently correct the difference.
WooCommerce offers subtotal-level tax rounding instead of per-line rounding. Decide which configured method the test expects and compare the line, tax and total figures together. A small difference still needs an explanation; accepting every variance as rounding can conceal an incorrect mapping or a missing order line.
The Xero extension requires the tax rate associated with each Xero account to match the corresponding WooCommerce tax setup. Give the accounting reviewer the actual labels, account codes and example records from the test environment. Avoid copying example account codes from documentation into a live business merely because they appear in a setup illustration.
| Decision | Store-side evidence | Accounting-side check |
|---|---|---|
| Invoice trigger | Selected Send Invoices setting | Correct invoice created at the intended event |
| Payment trigger | Selected Send Payments setting | Payment applied to the intended invoice once |
| Product mapping | Order line, quantity and discount | Matching invoice line and account |
| Tax basis | Approved address and tax settings | Expected tax label and total |
| Payment destination | Configured Payment Account | Intended clearing or bank treatment |
| Settlement review | Gateway settlement record | Fees and differences explained separately |
What does reconciliation need beyond a successful export?
The extension does not retrieve fees charged by payment processors. Treat the order total, the payment applied to an invoice and the amount arriving through a settlement as separate observations. The accounting owner needs a process for explaining the difference instead of expecting the connector to import fee information it does not retrieve.
The extension does not provide a two-way inventory synchronisation. A successful invoice test therefore does not establish that stock quantities will stay aligned between the store and Xero. If inventory continuity is a requirement, describe it as a separate workflow with its own selected software and evidence.
Keep payment confirmation distinct from fulfilment. A store’s order status can be meaningful operationally, but the acceptance record should identify the actual event chosen to trigger the export. That avoids a handover where one team believes posting occurs when money is confirmed and another believes it occurs after dispatch.
For checkout behaviour itself, use WooCommerce payment-method tests. For the merchant journey and settlement ownership, see website payments and reconciliation. This checklist starts where those order and payment facts become accounting entries.
Original order-to-ledger exception worksheet
Consider this hypothetical test batch for a shop selling physical products. Use authorised test data in a separate environment. The original worksheet links store event → export evidence → accounting entry → settlement explanation for each case, with a named owner for any mismatch.
Case A: ordinary paid order. Include a product, a delivery line and the accounting-approved tax treatment. Record the order identifier, selected posting triggers, Xero invoice identifier and payment reference. Compare quantities, descriptions, discounts and totals against the approved expected record. Mark the invoice and payment checks separately so one cannot conceal failure of the other.
Case B: order awaiting payment. Use the selected workflow to establish when an invoice should exist and when a payment should remain absent. Inspect the actual result. If the business expects a different sequence from the installed settings, resolve that requirement before the connector is accepted; do not alter the test expectation simply to match whatever appeared.
Case C: discounted order. Record the discount allocation across the affected lines and compare the invoice output with the store record. Inspect the tax result as part of the same case. Keep the test free of real customer data and use a clearly identified test discount so the evidence remains understandable later.
Case D: payment export exception. In the planned test procedure, identify the supported way to demonstrate an invoice-without-payment condition. Read the recorded error, name the responsible reviewer and document the correction before a controlled retry. Inspect the existing invoice and payment records first so the recovery does not become an unexplained repeat export.
Case E: settlement difference. Compare the gross payment record with an illustrative settlement statement that has a separately identified fee. Write the fee-handling responsibility in the worksheet. The expected outcome is an explained difference and a traceable accounting process, not a requirement that every system display the same figure for different business events.
Add a final row for refunds and restricted accounting periods. Ask the accounting owner to approve the intended handling and have the implementer demonstrate the supported behaviour. These cases deserve their own acceptance evidence because the original paid-order result cannot prove them.
What should be signed off before routine posting?
Retain the selected settings, mapping table, test identifiers and unresolved exceptions in one handover. Assign responsibility for reviewing failed exports and for checking settlement differences. Keep integration credentials outside the worksheet and redact personal information from shared logs or screenshots.
A focused brief should state the connector, order triggers, accounting destinations and exception owner. Use business systems for wider integration planning and get started with the completed worksheet and the posting decisions that still need agreement.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.