Two stores use the same order number: preserve the source account in every match

When combining several stores or marketplaces, retain the source account and stable platform order identifier beside the customer-facing number. A short reference such as 1042 can appear in more than one system. Matching only that label can apply a payment, refund or fulfillment cost to the wrong customer even when each individual export is correct.

Shopify documents global object identifiers in its GraphQL APIs and distinguishes them from numeric identifiers used elsewhere. The practical requirement for finance is to preserve the identifier's meaning and source. Ask the integration owner which field is stable and what scope makes it unique before designing spreadsheet matches or automated imports.

Use a documented combination of provider, merchant or store account and stable order ID where the source requires it. Keep display numbers in a separate column for human reference. Preserve identifiers as text so spreadsheet formatting does not remove leading zeros or round long numbers. Retain the original value before applying any cleanup.

For a hypothetical example, Store A's order 1042 and Store B's order 1042 are two separate purchases. A refund from Store B must resolve to Store B's payment and order even if Store A's order has the same amount. Adding the store identifier to the matching rule removes that ambiguity; matching by amount or customer surname does not reliably do so.

Carry the same source fields into warehouse, returns and payment exports. A stable order key that disappears from the refund file cannot prevent a later cross-store allocation error.

When a connector imports an external order into another platform, retain both the external source ID and the destination ID. Record the relationship once. A marketplace order mirrored into a storefront should not become a second commercial order merely because the destination creates its own identifier. Confirm which system owns the sale and which records only fulfill or report it.

For migrated stores, preserve old-to-new mappings and the effective cutoff. Returns can arrive against the old display number after the new store begins trading. The support team needs a search route that finds the original payment and approved remedy without guessing which current order resembles it. Restrict manual remapping to reviewed exceptions.

Check for duplicate matching keys in each source and for one-to-many joins that multiply amounts. A lookup that returns the first match can silently hide a collision. An automated join can duplicate a $100 refund across two orders. Compare row counts and total values before and after matching, then inspect the records responsible for any increase.

Retain unmatched rows in an exception list with their source accounts and original identifiers. Resolve them through source evidence rather than forcing a match by date and amount. At the close, the accountant should be able to trace each material payment and refund to one intended commercial order and explain any legitimate split or combined relationship.