Reference

Shopify and Xero, and
the decision it turns on

Connecting a storefront to a ledger looks like a plumbing job and is mostly a modelling one. The apps that do it are competent; the reason two businesses running the same app get very different results is that they answered one question differently at setup and nobody told them it was a question.

That question is grain — whether each order arrives in the ledger as its own invoice, or whether a day of trading arrives as one summary journal. Almost everything that later feels wrong about the books traces back to it.

Every commercial relationship, declared

Shopify. StoreBuilder Ltd is a Shopify Partner and earns referral commission when a merchant moves to or upgrades a Shopify plan through the practice.

Xero pays us nothing, and neither does any connector. We are not a Xero partner, we hold no accounting affiliate account, and no integration app on the Shopify or Xero marketplaces has any arrangement with us. No referral fee, no commission, no rebate, no sponsored placement. Nothing below names a product to buy.

Four things have to cross, and only one of them is the sale

Most setups get the first one right and discover the other three at the first month end. They are separate flows with separate timing, and an integration that only carries sales is not finished — it has moved the reconciliation rather than removed it.

1 — The sale

Revenue, tax and the customer, at whatever grain you chose. This is the part every integration does and the part people evaluate on, which is why the other three get discovered late.
2 — The money, which arrives shaped differently

A card processor settles in batches, net of fees, on a lag, and a batch frequently spans a period end. So the bank shows one figure that matches no order, and something has to hold the relationship between the payout and the orders inside it. This is the single most common mess, and it is the reason revenue looks wrong rather than merely untidy.
3 — The fees

Taken out before the money arrives, which means they never appear as a payment and are invisible unless the integration books them explicitly. Left implicit, gross revenue and cost of sale are both understated by the same amount and margin looks better than it is.
4 — Refunds, and their timing

A refund moves money, revenue, tax and often a fee, rarely in the period the sale happened. Whether it lands against the original transaction or as a standalone credit decides whether a customer's history reads correctly a year later.

The grain decision, made once and lived with

There is no universally right answer and there is usually an obviously right one for a given business. What there is not, is a way to change your mind cheaply later — the ledger fills up in whichever shape you chose.

One invoice per order

Every customer and every order exists in the ledger. You can answer a question about one buyer without leaving it, and credit control on trade accounts is possible.

The cost is volume. A few hundred orders a day becomes a few hundred ledger documents a day, reconciliation lists get long, and the accounts package starts being asked to be a CRM — which is a job it will do slowly.

A daily summary journal

One entry a day carrying revenue, tax and fees by category. The ledger stays small, fast and readable, month end is quick, and the accountant is happy.

The cost is that customer-level detail lives only in the storefront. That is usually correct for direct-to-consumer retail and usually wrong the moment there are trade accounts on terms, because you cannot chase a debtor who is not in the ledger.

The short version: summary if every sale is paid at checkout, invoices if anyone buys on terms. A business doing both usually needs both routes, and that is a deliberate setup rather than a default anyone will land on by accident.

What breaks after go-live

A second sales channel

The integration carries the storefront and knows nothing about a marketplace, a trade counter or a phone order. The ledger then reports a position that is confidently wrong on everything it cannot see, and it does not flag the gap.

VAT that somebody else collected

Some VAT is collected by a marketplace rather than the merchant, and treatment differs by destination. This is a specialist question for whoever does your VAT — the integration will faithfully post whatever it was configured to post, including the wrong thing.

Money taken before delivery

Gift cards, deposits and pre-orders are cash now for a sale later. Booked as revenue on receipt they overstate the month and understate the next one, and the correction is manual every period until the mapping changes.

Stock, which the ledger is not for

An accounting package answers what stock was worth at a date that has passed; a stock system answers what can be sold in the next thirty seconds. Asking the ledger for availability is the mistake accounting and stock is about, and stock control software covers what should hold it instead.

What this reference does not yet contain

We have not delivered a Shopify-to-Xero integration, and this page claims none. Everything above is either a property of how batched card settlement works or a decision you have to make — neither needs a case study, which is why it can be written honestly today.

What is deliberately absent is the comparison: which connector app handles payouts properly, how each behaves on multi-currency, and what Xero does against Sage or QuickBooks. Those are product-capability questions, we have not implemented across that field, and a grid assembled from marketplace listings would be indistinguishable from one built out of real work. The same gate applies on accounting and stock, and it is the reason this page compares nothing.

The useful first read is short: what grain is the ledger being fed at, whether fees are booked explicitly, and whether anything holds the relationship between a payout and the orders inside it.

Book the diagnostic

Shopify and Xero, and the decision it turns on