Ecommerce accounting integrations: Shopify and WooCommerce to Xero or MYOB without spreadsheets

Quick answer: Connecting Shopify or WooCommerce to Xero or MYOB is the integration most Australian ecommerce businesses build twice. Once with an off-the-shelf connector that mostly works. Again as a custom build when the gaps start costing real money. The gaps are predictable: GST on international orders, multi-currency settlements, partial refunds, inventory valuation, and the “why does the bank deposit not match the daily summary” problem that haunts every store doing over $50k a month.

For any Australian ecommerce business at meaningful volume, the most-trafficked piece of integration plumbing is the one between the store (Shopify or WooCommerce, in most cases) and the accounting system (Xero or MYOB). Done well, it’s invisible — orders land in the books accurately, GST is treated correctly, bank deposits match daily summaries, the bookkeeper doesn’t spend hours every fortnight reconciling.

Done with an off-the-shelf connector, in our experience it works well for the first six months. Then a predictable set of gaps starts showing up for stores at scale. This piece is about what they are, what the custom integration pattern looks like, and when paying for it makes sense.

Where off-the-shelf connectors fit, and where stores typically reach for more

A range of off-the-shelf connectors (A2X, Link My Books, Synder, the official Shopify-Xero integration among them) sit in this space, each with its own design centre and trade-offs. For a store doing AU-only orders, GST-inclusive, with no inventory complexity, in our experience the off-the-shelf path is often a fine fit.

Where stores we work with most often reach for a custom layer is when their operations sit above what a journal-aggregate model was designed for:

• International orders — GST has to be excluded for export sales, but only when the export is properly evidenced. Whether your current connector handles this per-order is worth checking before tax time, not after.
• Multi-currency — Shopify Payments and Stripe settle in AUD but the customer paid in USD or NZD. The FX gap between sale and settlement is real money that has to land somewhere correctly.
• Refunds and partial refunds — a full refund is straightforward; a partial refund on an order that included shipping, discount and multiple line items requires the accounting entry to apportion correctly across each.
• Inventory and COGS — whether cost-of-goods data flows from the store into the accounting system varies by connector and configuration. If you track inventory in your accounting system, this is worth verifying.
• Settlement reconciliation — the bank deposit from Stripe / Shopify Payments is a netted figure (sales minus fees minus refunds minus reserves), not a clean daily total. Matching it to the day’s sales without a reconciliation pass is hard to do reliably.
• Multiple sales channels — if the store also sells via Amazon, eBay, or a marketplace, the integration has to handle each channel’s fee structure and settlement timing separately. How natively a given connector handles each varies.

Each of those issues, individually, is workable with manual journals. The problem is they happen continuously, and the manual journals compound into a part-time bookkeeping job.

Pattern 1 — The order-to-invoice flow that handles real GST

The first job of the integration: each order on the store should become an entry in Xero/MYOB that’s correct for GST purposes from the start.

What that requires:

• The customer’s shipping address evaluated against the GST rules — AU customer = GST applies, overseas customer = no GST (with export evidence), low-value imported goods rules where they apply
• Line-item-level GST application, because a single order can contain GST-applicable and GST-free items (food, certain health products)
• Shipping treated separately, with GST applied or not based on the destination
• Discount codes apportioned across the order’s line items in a way that preserves correct GST calculation
• A clean per-order invoice in the accounting system that an auditor could trace to the customer order if they had to

What works: one invoice in the accounting system per order, not a daily aggregate. Daily aggregates feel cleaner — right up until the day someone asks you to prove a specific transaction.

Pattern 2 — Settlement reconciliation that actually settles

The bank deposit from Stripe or Shopify Payments arrives a day or two after the orders that produced it. It’s never the gross sales figure. It’s gross sales minus payment fees minus refunds minus held reserves, plus or minus FX adjustments.

Reconciliation needs:

• Settlement statements from the payment provider, broken down by order
• A daily journal that records the gross sales, the fees as a separate expense line, refunds as a separate reversal, and the net amount expected in the bank
• Bank feed matching that ties the actual deposit to the expected net, with the variance assigned to a clearing account that’s investigated promptly when it grows
• Reserve adjustments tracked separately so cash flow forecasting reflects what’s actually available

The same reconciliation discipline applies anywhere two systems handling money need to stay coherent. What’s different in ecommerce is the volume. This has to work for hundreds or thousands of transactions a day, not dozens.

Pattern 3 — Inventory and cost-of-goods that’s actually useful

If you track inventory in Xero/MYOB (and most ecommerce businesses should, above a certain volume), the integration has to push COGS information per sale, not just revenue:

• Each line item sold reduces inventory on hand and creates a COGS journal entry
• Returns reverse both the inventory and the COGS
• Stock takes and reconciliations done periodically post to a separate variance account so the auditor can see what’s shrinkage and what’s administrative
• Average cost or FIFO valuation applied correctly — the wrong method here produces materially wrong financial statements

Most stores realise they need this when the accountant looks at the gross-margin number and asks where the COGS line came from. The right answer: “from the integration, calculated per order, against the cost of goods that were in stock when the order shipped.” The wrong answer: a quarterly inventory count plugged in as a single journal.

Pattern 4 — Refunds, chargebacks, and the “what actually happened” trail

Refunds are easy in concept and complex in execution. The clean flow:

• Customer requests refund in Shopify / WooCommerce
• Refund processed via the payment platform
• Refund mirrored to the accounting system, reversing the original invoice line items in their correct GST treatment
• Inventory returned to stock (if applicable) and COGS reversed
• Bank feed showing the refund deposit (negative) matches the accounting entry

Chargebacks are messier. The payment dispute, the held reserve, the eventual outcome (refunded or returned), and the dispute fee all need to land correctly. The shape: a chargeback in progress sits in a clearing account; the final outcome (won or lost) settles to either reversed sales or final loss.

Pattern 5 — Multi-channel sales without three different reconciliation processes

If the business sells through more than one channel — the main Shopify store, plus Amazon, plus eBay, plus a wholesale Shopify store — each channel has its own fee structure, settlement timing, and accounting treatment. The integration job is to normalise all of it into one chart-of-accounts view.

The shape:

• Each channel feeds into the accounting system independently, with channel-specific tracking categories
• Settlement reconciliation runs per-channel
• Cross-channel revenue and margin reports built in the reporting layer
• Customers de-duplicated across channels when the same email appears, with the channel-of-acquisition recorded for marketing attribution

Many off-the-shelf connectors are designed around the one-store, one-channel case. In our experience, multi-channel businesses are where custom integration earns its place, because the channel matrix has to be handled coherently.

When the off-the-shelf connector is still the right call

Three cases where it is:

• Stores under ~$30k/month, AU-only, no inventory tracking. An off-the-shelf connector is often a fine fit; build nothing custom.
• Stores in their first six months. The shape of the business is still emerging; building against patterns that will change is wasted effort.
• Stores about to migrate platforms (Shopify to Shopify Plus, WooCommerce to Shopify, etc). Don’t build integrations for the platform you’re leaving.

The threshold where custom integration earns its place is roughly $50-100k/month in revenue, multiple sales channels or international orders, and a bookkeeper or finance team who can already articulate where the manual reconciliation work is going.

Our approach

Most ecommerce accounting projects start with an audit of where the current connector is producing wrong or incomplete data, ranked by bookkeeper hours and the risk of GST or audit consequence. The replacement plan stages the GST-correct order flow first (highest compliance risk), then settlement reconciliation (highest cash-flow visibility value), then inventory/COGS (highest reporting value), then multi-channel as the business grows into it.

Running an Australian ecommerce operation on Shopify or WooCommerce, pushing into Xero or MYOB, and finding the gaps above on your books? That’s the reconciliation worth taking apart first.

What an ecommerce accounting integration typically costs

A first custom store-to-accounting integration typically lands in the $15,000–$45,000 range (ex GST) for a V1 build, depending on how many of the patterns above are in scope and the depth of each. A GST-correct per-order invoice flow for a single AU store sits at the lighter end; settlement reconciliation, inventory and COGS, and multi-channel normalisation across several marketplaces sit at the heavier end. Build timelines are usually 6–16 weeks from engagement, with the GST-correct order flow and settlement reconciliation being the longest single workstreams because that’s where the compliance and cash-flow risk concentrates. Plan for an ongoing maintenance retainer — typically $500–$1,500/month — covering API change monitoring, hosting, and light support, because an integration that touches the books needs someone watching it.

Common questions

Do we have to replace our off-the-shelf connector to do this? Not necessarily. For an AU-only store with no inventory complexity, in our experience the off-the-shelf path is often a fine fit and a custom build isn’t warranted. The custom layer earns its place when the gaps — international GST, multi-currency, partial refunds, inventory valuation, multi-channel — start costing real bookkeeper hours.

Will it handle GST correctly on international orders? That’s the first pattern we build. The customer’s shipping address is evaluated against the GST rules per order — AU customer means GST applies, properly evidenced exports mean GST is excluded — with line-item-level treatment so a mixed order is still correct.

How does it solve the “bank deposit doesn’t match the daily summary” problem? A daily journal records gross sales, fees as a separate line, refunds as a reversal, and the expected net, then bank-feed matching ties the actual netted deposit to that expected figure with any variance assigned to a clearing account that’s investigated promptly.

Will it break when Shopify, Xero or MYOB changes its API? APIs change, so the maintenance retainer covers monitoring those API changes and keeping the integration current. The build itself uses idempotent, well-tested patterns so a transient error doesn’t produce a wrong ledger entry.

How soon do we see value? Most projects stage the GST-correct order flow first because it carries the highest compliance risk, so the books are landing accurate, auditable per-order invoices within the first few weeks rather than at the end of the build.