How to avoid double-counting Shopify, Amazon and TikTok orders

To avoid counting an ecommerce order twice, record where the customer bought separately from who fulfilled the order. Then link each platform's records to one business order before adding up revenue.

A TikTok Shop purchase can appear in a connected Shopify store and in Amazon fulfillment data. Those records can describe one purchase, not three sales. Amazon documents MCF integrations for TikTok Shop, including routes through Shopify. The exact records and identifiers depend on the integration, so check what your connector actually sends.

This is the mistake I'd look for before trusting a dashboard that adds Shopify, Amazon and TikTok totals together.

Three records, one purchase

Take an illustrative $60 merchandise sale, excluding tax and shipping. The customer checks out on TikTok Shop. An integration creates a corresponding order in Shopify. Amazon MCF ships it.

Record	What it describes	Sales contribution in the combined model
TikTok order T-100	Customer purchase	$60
Shopify order S-200	Linked operational copy	$0 additional
MCF fulfillment F-300	Shipment for that purchase	$0 additional

The combined result is one order and $60 of merchandise sales. Adding the purchase and its Shopify copy would produce $120. Treating a fulfillment value as another sale could inflate it further.

These IDs are examples, not patterns to search for in a real account. Don't classify orders by an assumed prefix. Use the connector's documented origin fields and verified cross-platform references.

Keep three separate fields

Sales channel answers where checkout happened. Fulfillment provider answers who shipped the goods. Source system answers where this particular record came from.

For the example, those values might be TikTok Shop, Amazon MCF and Shopify. There is no contradiction. A Shopify source record doesn't prove that the customer used the Shopify online store.

Keep acquisition channel separate too. TikTok advertising that sends someone to a website is different from checkout inside TikTok Shop. An ad attribution report isn't another order ledger. The daily ecommerce scorecard explains how these dimensions affect channel comparisons.

Build an explicit order crosswalk

Start with the originating order system and retain its native order ID, store or seller account, and marketplace where relevant. Create a business order key and link the operational copies and fulfillment records to it.

The crosswalk should retain the original identifiers, how the match was established, and its review status. Don't overwrite the source IDs with a cleaned display number. You need them when someone opens an order in the source application.

Use direct references where the integration provides them. If references are missing, amount and timestamp can help investigate a candidate match, but they aren't sufficient proof. Two legitimate customers can place identical orders seconds apart. Leave uncertain matches in an exception queue rather than silently deleting one.

Decide which source owns each measure. The originating order can own ordered merchandise value, a financial ledger can own posted fee events, and the fulfillment feed can own shipments. Choosing one authority per measure doesn't require discarding the other records.

Don't replace one duplication problem with another

Linking IDs is only the first check. One order can have several items, shipments and refunds. Joining all three detail tables directly can multiply rows even when every ID is correct.

For example, two order lines joined to three shipment records can create six rows. Summing the repeated order total now overstates revenue. Aggregate each source to the intended level before joining, or keep separate fact tables with deliberate relationships.

Count business orders once at order level. Count units at line level. Count shipments at shipment level. Label replacements, exchanges and canceled orders according to the reporting definition instead of assuming that every new source row represents another customer purchase.

The bronze, silver and gold order example shows why preserving raw events before building reporting tables makes these corrections easier.

Reconcile a small batch before the whole history

Pick a closed day and trace several orders through the actual systems. Include a direct website order, a marketplace purchase, a routed TikTok order, a split shipment and a refund.

For each one, record the source IDs, original channel, selected sales amount and reason for excluding operational copies. Compare the resulting counts and values with the source reports using the same currency, time zone, status rules and cutoff.

Then run three checks across the batch: no duplicate business order keys in the order table, no unexplained increase in sales after a join, and no missing origin hidden inside a guessed channel. Keep unresolved value visible alongside the clean total.

Make the exceptions visible in Sigma

Once the reporting model reconciles, use Sigma data models to provide a shared source for workbooks. A useful reconciliation view shows business order key, native IDs, sales channel, fulfillment provider, sales value and matching status.

Sigma doesn't decide which platform owns the sale for you. That rule belongs in the model and its documentation. The dashboard should let someone inspect a disputed order without rebuilding the joins in a spreadsheet.

If your combined sales are higher than the individual channel reports suggest, start with ten traceable orders. Finding exactly where the extra row entered is more useful than applying a blanket percentage adjustment to the total. For help building that shared reporting layer, see ecommerce data warehouse services.