A2X and Link My Books are strong tools for steady-state posting. Most accountants use them because they remove routine manual work. The pain starts when you inherit a month that was already off, and the client expects the sync app to magically fix historical drift.
Normal month processing is repetitive: import the payout summaries, map accounts, review tax treatment, and reconcile bank lines. Good sync tooling handles this well. Rescue mode is different. Rescue mode starts when the opening balances are wrong, prior adjustments are unclear, and control accounts contain old manual entries that no one can explain.
In that state, data can still flow from Shopify to Xero without technical errors, but the month does not close. The software did what it was asked to do, post current activity. The missing part is forensic logic across periods. Which differences belong to this month, which come from older mistakes, and which are duplicate postings from prior attempted fixes.
This distinction matters for client communication. If you frame it as "the app failed," people expect a settings tweak. If you frame it as "we inherited a broken period that needs structured cleanup," the plan becomes clearer and faster.
Many Shopify to Xero problems start before your team even touches the file. Previous bookkeepers may have posted net deposits straight to sales, used temporary suspense accounts that were never cleared, or applied broad journals to force a close. Once those entries exist, current month sync output lands on top of a weak base.
The result is confusing account behavior. Revenue may look low in one report and high in another. Clearing balances carry unexplained residues. Bank reconciliation includes old unmatched lines that keep resurfacing. Without identifying inherited issues first, teams end up creating new journals each month just to get reports out.
Start by isolating legacy entries that touch Shopify clearing, sales, fees, refunds, and dispute accounts. Tag what belongs to historical repair versus current month activity. This separation reduces noise quickly and shows where cleanup should begin.
Refund drift happens when refund logic is posted inconsistently over time. One month refunds may have been recognized on order date, another month on payout date, and another month through manual corrections. Even if each month looked "close enough" at the time, the combined history produces balances that no longer reconcile.
Sync tools can only post the data they pull now. They do not automatically reinterpret old accounting choices. So you still need a controlled refund review: identify refund events, trace cash deduction timing in payouts, and confirm how each was booked in Xero. Where treatment changed, document and normalize it.
If you skip this step, you can reconcile bank lines while still carrying a distorted profit picture. That is why accountants often feel the month is "technically matched" but not trustworthy.
Manual journals are useful when they are specific, documented, and reversible. They are dangerous when used as bulk patches with vague notes. In Shopify to Xero files, repeated manual journals often overlap with sync-generated entries and create double counting in fees, tax, or refunds.
Before posting any new correction, check three things: was this amount already posted through sync output, does the journal have a clear business reason, and can another accountant reverse it without guessing? If the answer is no, stop and redesign the fix.
A disciplined approach is to stage proposed fixes in a working paper first, then post only what closes a defined gap. This avoids the cycle where every month starts with "undo last month" work.
Useful Patch focuses on this exact exception scenario. You keep your existing sync setup, and run one broken month through a structured leak scan to see what still blocks close.
Scan one broken month free