The first thirty days after connecting Shopify
The integration goes live, orders start flowing, and the temptation is to assume it is working because nothing has failed.
Nothing failing is not the same as everything being right. The first month is when the errors that will otherwise persist for years are cheap to find, and there is a sequence that finds them.
Before you connect anything
Three things that are much harder afterwards.
Confirm the order reference reaches your gateway. Place a real order and check that your Shopify order reference appears in the gateway's transaction record. If it does not, fix it now — this single field determines whether matching is deterministic or guesswork forever — see the gateway reference that joins everything.
Pick a period boundary. Start at the beginning of a month. It costs nothing and saves a great deal of explanation later.
Reconcile the prior period the old way, completely. You need one known-good closing position to start from. Beginning with an unreconciled tail means every subsequent difference has two possible causes.
Week one: does anything match
The objective is not clean books. It is establishing that the mechanism works.
Check the order count daily. Orders in Shopify against orders in your system. They should agree exactly. Any gap on day one is a configuration problem and it is trivial to fix now — see Shopify webhooks and why they are not enough.
Verify totals on a handful of orders by hand. Goods, discount allocation, tax, shipping charged. Confirm the numbers arriving are the numbers Shopify holds rather than something recomputed — see Shopify discounts, taxes and line-level allocation.
Watch the exception queue closely. It will be larger than its eventual steady state. What matters is the composition — the categories tell you what needs configuring.
Wait for the first payout and decompose it completely. To the sen. This is the single most informative event of the whole month — see decomposing a payout line by line.
If the first payout decomposes cleanly, the rest is refinement. If it does not, stop and find out why before another three weeks of data accumulates on top.
Week two: the edges
Now the unusual cases start arriving, and each needs checking once.
The first refund. Does it link to its original order, reverse the right revenue, and handle the fee correctly — see what happens to the fee when you refund.
The first partial refund, which tests discount apportionment and is where recomputation errors surface.
The first cancelled order, which should be distinguishable from a refund.
The first failed or interrupted payment, and whether the resulting orphan is visible — see failed payments and the orders they leave behind.
A courier invoice, if one arrives, matched to consignments — see courier invoices and how to reconcile them.
Each of these happens once in week two and hundreds of times over the following year. Checking each one now is the highest-return use of attention in the whole implementation.
Week three: the rules settle
By now the exception categories are visible and repetitive, which is what makes them fixable.
Fix causes, not instances. The same exception type appearing every day is a rule to configure rather than a decision to keep making — see the exception queue and how to size it.
Record resolutions. Why this transaction matched that order. Next month's identical case becomes a lookup.
Watch the tier mix. The share matching on the shared reference should be high and stable. If it is low, something upstream is wrong and it is far cheaper to fix now — see matching orders to transactions to payouts.
Check cost of goods is populated. Margin reporting is worthless without it and this is the moment to find the gaps — see cost of goods sold for Shopify stores.
Week four: the first close
The month end that tells you whether it worked.
Reconcile every payout for the period, with the arithmetic closing on each.
List everything in flight — sales not settled, settlements not paid out, payouts not allocated, reserve held. Four figures, each explicable — see reconciling across a period boundary.
Accrue processing fees on unsettled sales and delivery on uninvoiced consignments.
Compare revenue against Shopify's own total for the period. Allowing for boundary timing, they should be close. A material gap means revenue is being recorded net somewhere — see Shopify gross sales vs net payout.
Clear the exception queue rather than carrying items forward. Anything unresolved now becomes harder, not easier.
What good looks like at day thirty
Five conditions, and they are worth checking against explicitly rather than by feel.
Order counts agree daily. Every payout in the period decomposes exactly. Money earned but not yet available is a known figure with a known composition. The exception queue is small, aged and clearing. And revenue in your accounts matches gross sales, with fees present as their own expense lines.
If all five hold, the mechanism is sound and the following months are maintenance. If one does not, it is a specific, findable problem — and finding it in month one costs a morning, while finding it in month twelve means reconstructing a year — see keeping automated books healthy.
Common questions
What should be checked before connecting a Shopify store to accounting?
That your Shopify order reference actually reaches your payment gateway's transaction record, since that single field decides whether matching is deterministic or guesswork. Also start at a period boundary so no month spans two methods, and fully reconcile the prior period first so you begin from one known-good position.
What is the most informative event in the first month?
The first payout. Decomposing it completely — every transaction inside it, fees, refunds, chargebacks and reserve movements, with the arithmetic closing exactly — establishes whether the whole mechanism works. If it does not close, that is the moment to stop rather than accumulate three more weeks of data on top.
Why check refunds and cancellations specifically in week two?
Because each unusual case happens once early and hundreds of times over the following year. A first refund, first partial refund, first cancellation and first interrupted payment each test a different piece of logic — discount apportionment, fee handling, and whether orphaned payments are visible — and checking them once now is the highest-return attention in the implementation.
What does a successful first month look like?
Order counts agreeing daily between Shopify and your system, every payout in the period decomposing exactly, money earned but not yet available being a known figure with known composition, a small exception queue that is aged and clearing, and revenue matching gross sales with fees present as their own expense lines.
Related: decomposing a payout line by line · how often to reconcile your Shopify store · keeping automated books healthy
Read next
See what you could build
Start a free trial and describe what your business needs in plain language — SmartB Studio builds the module for you.
Start free trial