WooCommerce Xero integration: use the connector, or build it?

Pick the simplest route that produces correct books. Xero for WooCommerce, the extension developed by Woo, sends orders to Xero as invoices and applies their payments, on a schedule you choose: manually, when the order is created, when payment completes or when the order completes. Several third-party sync apps on the WooCommerce Marketplace and the Xero App Store do the same job with different rules for payments, refunds and stock. Zapier and Make connect the two through general-purpose steps you arrange yourself. And the Xero accounting API lets you write exactly the invoice you want, at the cost of owning the code.

Our position: for most shops, a connector is the right answer and a build is a cost without a return. The connector breaks in three situations. The order is not the event that should raise the invoice, because something happens to it first, such as production, a review or a deposit. The books need rules the connector does not have, such as payment accounts per gateway or credit notes for refunds. Or the invoice must carry data the store does not hold, such as a job number from a CRM. In those cases, an automation platform or the API earns its keep.

We have built one of those cases on Zapier: WooCommerce orders into monday.com, where the team works the order, then into Xero as invoices with one line per item. It is not a published case study, so this article makes no claims about its volume or results. What follows is the decision and the design we would recommend now.

Two settings in Woo's own extension are worth knowing before you decide. It recommends sending invoices on payment completion for most stores, which means an order paid by bank transfer may not reach Xero until its payment is recorded in the store. And it sends discounts as the amount taken off each affected line, not as coupon codes, so a coupon does not show up as a line of its own in Xero. If either suits your accountant, that is one less reason to build.

When all of these are true, and for most small shops they are:

• An order becomes an invoice with nothing in between. Nobody needs to review, schedule or produce it before it is billed.
• Payments can land in one account. Card, PayPal and bank transfer can all clear through one bank or clearing account in Xero, and your accountant is happy to reconcile from there.
• Refunds are rare, or your accountant would rather handle them in Xero by hand.
• Every product posts to one sales account, or the connector's account settings cover the split you need.
• Volume alone is not the reason. A build pays off when the rules are unusual, not simply because the orders are many.

If one rule is missing, try a different connector before building anything. A sync app that maps payments per gateway or writes credit notes on refund is a cheaper fix than a workflow you have to maintain. Test it against a copy of your Xero organisation, or Xero's demo company, with real orders: a discounted order, an order with shipping, a part refund, an order in another currency. What the connector writes for those four tells you more than its feature list.

Where this advice breaks: a connector is also a decision you did not make. Switch on a sync app and it may start creating contacts, items or stock movements in Xero in ways your accountant did not expect. Read its settings with them, line by line, before the first live order.

Moving an order from one system to another is easy. Getting a correct invoice is the hard part, and these eight details are why. A connector has made a decision on each of them already. A build has to make each decision explicitly.

1. One invoice line per order line

A WooCommerce order holds its products as a list of line items, each with a product, a quantity, a SKU and totals, and holds shipping, fees and coupons as separate lists. A Xero invoice holds its own list of lines. The job is to turn one list into the other, keeping quantity, unit price, description and item code, without collapsing an order of five products into one line called 'Order 1234'. A single summary line is easier to build and makes the invoice useless to the customer and to anyone reading sales by product.

2. Tax and account codes on every line

Each Xero line needs an account code, and outside the US it usually needs a tax rate as well. Zapier's own Xero troubleshooting page says non-US users often get a validation error unless Line Account Code is filled in, even though the field is marked optional. Xero treats line amounts as tax exclusive unless the invoice says otherwise, and calculates and rounds tax per line, so totals can differ by pennies from a store that calculates tax on the whole order. If your store prices include VAT or GST, the invoice must say its amounts are tax inclusive, and the store and Xero must agree on how tax is rounded.

3. Contacts that are matched, not duplicated

Xero warns that a contact name may not be unique and advises keying on its ContactID. Match a customer by name and two people called Sam Patel become one contact, while one customer who types their company name differently becomes two. Matching by email is better, and Xero's API supports an exact-match filter on it, but one email can belong to several contacts. Decide the rule, then store the Xero ContactID against the WooCommerce customer so the second order does not search at all.

4. Shipping, fees and discounts

Shipping and fees are separate lists on the order, so a flow that maps only product lines produces an invoice short by the delivery charge. Each needs its own invoice line, usually with its own account code; Woo's own extension asks for separate codes for sales, shipping and fees for that reason. Discounts can go on as the reduced line price, which is what Woo's extension does, or as a negative line against a discounts account. Either is fine. Mixing the two is not.

5. Refunds and credit notes

A refund in WooCommerce is its own record with its own lines, and can be partial. In Xero it is usually a credit note. Woo's own extension does not write one: when an order is fully refunded it tries to void the invoice, and a paid invoice cannot be voided that way, so it is adjusted by hand. In Xero's API, a credit note must be authorised before it can be allocated against an invoice, and the creation and the allocation are two separate calls, so a flow that fails between them leaves a credit sitting on the contact.

6. Payments and reconciliation

An invoice without a payment shows as owed until someone matches the bank line. Applying the payment through the API, into the account the money actually lands in, is what lets the bank feed reconcile cleanly. Card processors typically pay out in batches, net of their fees, so a clearing account is where card payments wait until the payout arrives. Decide the accounts with your accountant before building. Note too that once an invoice is fully paid, Xero limits what the API can change on it, which matters if your flow edits invoices later.

7. Never invoicing an order twice

Webhooks are retried, order-updated triggers fire more than once, people replay failed runs, and someone re-saves an order. Each can raise a second invoice. Xero accepts an Idempotency-Key header on create and update requests, but keeps it for only six minutes, so it guards a retry, not a re-trigger next week. The lasting guard is your own record: the Xero invoice ID stored against the order, checked before any create, and a search in Xero by reference before a retry.

8. Currency, and the connection itself

If the store sells in more than one currency, the invoice must carry the order's currency, which needs a Xero plan that includes multi-currency and the currency enabled in the organisation. Which plans include it varies by country, so check Xero's pricing page for yours. Separately, the connection itself can lapse. Xero connections run on OAuth, and as our UK automation page notes, a refresh token unused for 60 days expires. A flow that fails quietly leaves sales missing from the books.

This is the part most WooCommerce to Xero automations get wrong, and the two platforms solve it differently.

Zapier: line items in, one invoice out

Zapier passes lists between steps as line items, and its help centre is clear that both the trigger and the action must support them. Xero's Create Sales Invoice action does. The WooCommerce order trigger supplies the order's line items as a list. Map that list into the action's line-item fields, and one action writes one invoice with as many lines as the order has. On Zapier's billing, that is one task for the invoice whether the order has one line or twenty.

Shipping and fee lines come through as separate lists, so they have to be added to the product lines before the invoice step. Formatter's line-item tools can build or extend a set of line items, and Formatter does not use tasks. Looping by Zapier is the wrong tool for the invoice itself: it runs the steps after it once per item, so an invoice action inside the loop creates one invoice per line, and every action in the loop is a task per item. Looping is right for per-item work elsewhere, such as creating a sub-item on a board for each product, and our Zapier tasks article covers what that costs.

Make: iterator, then aggregator

On Make, the order's line items arrive as an array. An iterator turns the array into one bundle per item, modules after it can reshape each line (look up an account code, set the tax rate), and an array aggregator collects the bundles back into one array shaped for the Xero invoice module's line items. The invoice module then runs once. Shipping and fee lines need merging into the same array, which takes an extra step or an array function.

On Make's billing, each module run per bundle is a credit for non-AI modules, so modules between the iterator and the aggregator cost one credit per line, and the invoice module after the aggregator costs one. The trigger counts as a module run too, and a scheduled trigger's empty checks count as well. Where the lines only need renaming, Make's array functions can sometimes do the reshaping without an iterator. Our Make.com credits article covers the arithmetic. One trap: outputs from modules inside the iterator-aggregator span are not available after the aggregator, so carry anything you need later through the aggregator.

Which platform? If the team that owns the flow already lives in Zapier and the logic is a straight line, Zapier's line-item support handles the invoice cleanly. If per-line logic grows, with account codes by category, conditional lines or bundles split into components, Make's iterator and aggregator are easier to follow than nested Formatter steps. Our Make vs Zapier vs n8n comparison covers the general case.

Whether it runs on Zapier, Make or code, the shape is the same. This is the order we build in, and each step closes one of the failure modes above.

1. 01Trigger on the event that should raise the invoice, not on every update. For card payments that is usually the order being paid. The Zapier Integration for WooCommerce documents its 'Order paid' trigger as designed for instant online payments, and suggests an order-created or status-changed trigger for bank transfer, where payment arrives later.
2. 02Stop early if the order is already invoiced: a filter on a stored Xero invoice ID, as the first step after the trigger. On Zapier a filter is free.
3. 03Find the contact by a stable key, ideally a stored ContactID, then email, and create it only when nothing matches. Store the ContactID back.
4. 04Build the lines: one per product line, then shipping, fees and any discount line, each with its account code and tax rate from a mapping table rather than typed into the step.
5. 05Check the arithmetic before writing: the sum of the lines, with tax, equals the order total within a rounding tolerance you have agreed with your accountant. A mismatch goes to a person, not to Xero.
6. 06Create the invoice once, with the order number in the reference, the right tax basis and the order's currency.
7. 07Write the Xero invoice ID and number back to the order, or to the board or CRM record, straight away. This is what makes every later run safe.
8. 08Apply the payment into the account the money lands in, once the order is paid. Handle refunds as credit notes, allocated in a second step.
9. 09Send every failure to a channel someone watches, with the order number in the message.

Where this breaks: steps 2 and 7 only protect you if nothing else writes to the same order. If a connector is also switched on, or an old Zap is still live, each will invoice independently. Switch off one before switching on the other, and search Xero for a few recent order numbers to check.

This is the case where building beats the connector. Orders from WooCommerce land on a monday.com board, or in HubSpot, where the team schedules, produces or approves them, and the invoice is raised when the record reaches a status, not when the order arrives. The connector cannot see that status. The design above still holds, with the trigger moved from the store to the board, and the line items now read from the board record or its sub-items rather than from the order.

Our Make write-up on CRM-triggered invoicing is the published example. Six Make scenarios for a training provider raise and email a Xero invoice when a monday.com status changes, write the invoice number, date and link back onto the item, and chase unpaid invoices. Across them, Make's counters show 78 runs and 782 operations with one error, a duplicate contact name in the create-contact step. The write-up is candid about its gaps, which are the same gaps this article warns about: creating an invoice is not idempotent, so selecting the trigger label again raises a second invoice, and one scenario matches contacts by name with no fallback. That build uses one line per invoice built from the CRM's price, item code and description. Multi-line invoices add the line-item work described above.

HubSpot has its own route. HubSpot's Xero data sync pushes HubSpot invoices to Xero once they are in the Open state; drafts are skipped. HubSpot recommends syncing contacts and products first, and says its automated sales tax invoices do not sync. So the native route goes from deal to HubSpot invoice to Xero, and someone still creates the HubSpot invoice. If you want a deal reaching a stage to raise the Xero invoice directly, that is a build on Zapier, Make or the API, with the same rules for lines, contacts and duplicates. Our accounts receivable automation page covers what happens after the invoice: reminders, payment status and write-backs.

On monday.com specifically, one detail matters: an automation that updates the item which triggered it can trigger itself again. Write the invoice ID back to a column the trigger does not watch, and filter on it. Our monday.com automations article covers the board side.

When the rules outgrow a workflow tool, the volume makes per-task or per-credit billing the largest cost, or the integration is part of a larger system you already run. Code gives you full control: credit notes and their allocations, payments split across accounts, tracking categories, attachments, and a run history you design. It also gives you the connection, the limits and the developer terms to look after.

• Pricing changed in 2026. Xero moved its developer pricing to five tiers (Starter, Core, Plus, Advanced, Enterprise) on 2 March 2026. The free Starter tier is capped at five connections and 1,000 API calls a day per organisation; Core and above allow 5,000. Check Xero's developer pricing page for the current terms.
• For one business's own books, Xero's Custom Connections are its machine-to-machine option, connected to a single organisation and, according to Xero's FAQ, kept on the same commercial terms through the 2026 change. They are available in Australia, New Zealand, the UK and the US.
• Rate limits are per organisation: 60 calls a minute and five in progress at once, on top of the daily limit. A backfill of last year's orders has to be paced to stay inside them.
• Use the Idempotency-Key header on every create, and store your own order-to-invoice mapping as well, because the key only lasts six minutes.
• When updating an invoice, send each line's LineItemID. Without it, Xero deletes the lines and recreates them.
• Through Zapier or Make you do not choose a developer tier. As we read Xero's pricing page, the tier belongs to whoever registers the app, which there is the platform.

Where it breaks: an API integration is software, and somebody has to be on call for it. If nobody in the business can read the code or its logs, a workflow on Zapier or Make that the team can open is the better trade, even if each run costs more.

WooCommerce's own webhooks add one more trap. WooCommerce disables a webhook after more than five consecutive failed deliveries, and a disabled webhook stays off until someone re-enables it. If your flow starts from a webhook, a short outage on the receiving end can stop invoices for good. Our article on why automations break covers the general pattern.

Skofi is paid to build integrations on Zapier, Make and the Xero API, so we gain when you build rather than buy a connector. Our advice for a plain shop is still the connector. Our evidence is a Zapier build of WooCommerce orders into monday.com and on to multi-line Xero invoices, which is not a published case study, and the CRM-triggered invoicing write-up on Make, which is, with its limits stated. We are not a Xero, WooCommerce, Zapier, Make or HubSpot partner.

Before any decision, write down the four test orders (a discount, shipping, a part refund, another currency) and what your accountant expects each to look like in Xero. Run them through the connector you are considering. If every one comes out right, you are done. If one does not, that one is the scope of the build, and it is usually smaller than people expect.