Reconciling Shopify orders against your ERP: the fields that drift

Shopify and your ERP both think they know what an order is worth, and they're both right — in their own terms. Which is exactly why the totals almost never match on the first pass. Reconciling them isn't hard once you know which identifier to trust and which fields are allowed to disagree. Here's both.

Which identifier do you join on?

Shopify exposes several identifiers, and choosing the wrong one is the most common reason a reconciliation falls apart before it starts.

Join on whatever the two systems actually share. If your ERP stored Shopify numeric order ID at import, use it — it never changes and has no formatting. If it only kept the order name, normalize the # and any location prefix on both sides first.

Where the totals legitimately diverge

An order total is not one number. Shopify and your ERP may each book a different slice, and the differences below are expected, not errors — but only if you account for them explicitly.

• Taxes. Whether tax is inside or outside the total depends on configuration on both sides.
• Shipping. Sometimes a separate line, sometimes folded into the total.
• Discounts. Order-level versus line-level discounts can net differently.
• Currency rounding. Multi-currency orders round at different points.
• Gift cards and store credit. May reduce the Shopify total but appear differently in the ERP.

Refunds, edits, and partial fulfillment

A Shopify order is mutable after creation. It can be edited, partially refunded, partially fulfilled, and refunded again. Each event may or may not flow to the ERP, and on its own schedule. A reconciliation that only looks at order creation will see a clean match and miss that the order was half-refunded yesterday. Compare the current state of both sides, including refund and edit history, not the order as first placed.

Payouts are a separate reconciliation

Shopify Payments, or any processor, settles orders into deposits, batched and net of fees — the three-way problem in a retail wrapper. Matching orders to your ERP is one reconciliation; matching Shopify payouts to your bank is another, with its own key (the payout ID) and its own aggregation. Keep them separate; conflating order totals with deposit amounts is how teams chase a discrepancy that is just the processor fee.

A working sequence

1. Pick the shared order identifier and normalize it on both sides.
2. Match orders; resolve one-sided orders first (in Shopify but not ERP, and the reverse).
3. Compare components — subtotal, tax, shipping, discount — not just the total.
4. Pull in refunds and edits; compare current state, not creation state.
5. Reconcile payouts to the bank as a separate, batch-level pass.

Run in that order, the Shopify-to-ERP gap resolves into a small set of real differences, and the payout timing noise stays in its own lane where it belongs.

← All writing