Two storefronts sent the warehouse the same order number

The matching number is a store-scoped label, not an error to erase

Two warehouse rows carrying the same order number can have more than one cause. One possibility is that two storefronts each assigned that number independently; another is that a feed duplicated or relabeled one order. On Shopify, stores use incrementing order numbers, and merchants can configure displayed prefixes or suffixes, which makes the same display number possible across stores. Storefront A's order 1042 and storefront B's order 1042 can both be valid records in their own systems, but that has to be confirmed against the actual orders and feed. Treating them as one order, or treating one as a mistaken copy of the other, is the first way this goes wrong.

Be precise about what the documentation establishes. Store-scoped incrementing numbering makes a collision across stores plausible; it does not prove that your two rows are a collision, and it says nothing about how your warehouse integration labeled them. That inference has to be confirmed against the actual feed and the actual orders. Also note what display formatting does not do: changing prefixes or suffixes where supported does not by itself repair or explain mappings the warehouse already received.

Build the reconciliation key from stable identities, not the display number

The key has three parts. First, the source storefront: the actual store or domain whose admin holds the order, not a brand nickname. Second, the native order reference: the identifier the platform itself assigns to the order record, which stays stable even when the displayed number is reformatted or reused elsewhere. Third, the warehouse reference: the identifier on the warehouse row, the pick instruction, or the integration payload that created it. Keep the displayed order number in the record as a convenience for staff conversation, but never as the join between systems.

This mirrors a wider principle your team may already use for payment references: connected identifiers are not interchangeable names, and a number quoted without its system is ambiguous. The same discipline applies here. A warehouse row that says only '1042' is unidentified until the feed that created it names a storefront and that storefront's native record is opened and read.

Trace each warehouse row back before releasing it

Work one row at a time, in order. Open the warehouse row and record its warehouse reference, contents, quantities, and timestamps. Identify which integration, import, or manual process created the row; the feed configuration or the credentials it runs under usually identify which storefront connection produced it. From that source store, open the candidate order by its native reference rather than searching by display number alone, because the other store may hold a same-numbered order that also matches a naive search.

Then verify the candidate against the row: items and quantities, order total and currency, creation time with its time zone, and any fulfillment handoff already recorded. Where the store order shows a payment or fulfillment link, confirm that this order, not the other store's same-numbered one, is the record that was actually handed off. Release the row for picking only after the chain from warehouse reference to feed to storefront to native order record is written down. Repeat the full trace for the second row; do not assume it belongs to the other store just because the first one was resolved.

When the records cannot settle ownership, name the decider

Some collisions stay unresolved after tracing: the integration log was rotated away, the feed does not record its source store, or both candidate orders match the row's contents and timing. In that state, do not ship both rows and do not cancel one by guessing. The operations lead decides which candidate order the physical stock will be allocated against, using the documented comparison. The integration owner determines whether the feed's provenance can be recovered from its configuration, logs, or the platform's event history.

Record the outcome explicitly: resolved with evidence, resolved by operations decision pending integration confirmation, or unresolved with a named owner and next check. An unresolved row stays held. The cost of holding a row is visible; the cost of shipping the wrong storefront's order is discovered later, in someone else's records.

Fix forward without rewriting history

Once the pair is resolved, keep a standing cross-reference from each warehouse reference to its storefront and native order record, so the next support conversation starts from the key rather than the bare number. If the platform supports prefixes or suffixes, distinct display formatting can help staff read future numbers, but do not treat a formatting change as a repair for mappings already made.

If the collision points to a storefront or integration concern you want scoped help with — for example, how two stores hand orders to one fulfillment path — a Prism consultation can discuss that setup. Describe the platforms and the observed collision in ordinary terms, without customer records or credentials, and confirm scope, responsibilities, fees, and terms before any work begins. The provider or platform decides what its own systems support; the reconciliation itself remains your records' job.

Order-collision reconciliation key

Complete one copy per warehouse row involved in the collision. Record only what you opened and verified; write unresolved where a record is missing or ambiguous. Keep the filled sheet in controlled internal records and never enter card data, credentials, or customer details.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.