Measurement
Part of Marketplace seller software measurement framework
Seller software measurement mistakes: repeated order imports
Trace marketplace seller software measurement mistakes in repeated order imports, with an Amazon example and practical Excel Power Query checks.
Marketplace seller software measurement mistakes can begin when overlapping order exports are appended to a report. An order appears again, and the report treats the repeated record as fresh activity. But deleting every repeated order identifier can remove genuine order lines instead, leaving the report wrong in a different way.
Trace the problem from Amazon order records into Microsoft Excel Power Query. The examples address overlapping imports, joins that multiply rows and duplicate-removal rules that discard valid lines. They use fictional record labels, not seller results, and diagnose a report rather than test a supplier's software.
Locate where the repeated order enters
Start with the report's actual route. An Amazon Seller Central order report downloaded directly into Excel has a different path from an export that passes through seller software first.
If Linnworks sits between the marketplace and your report, include its export and mapping rather than assuming the spreadsheet reproduces the original records unchanged.
Write down the files or feeds used by the affected query, and identify whether each contains a snapshot of orders, order lines or records of changes. A fresh snapshot can legitimately contain an order that appeared in an earlier snapshot. The mistake occurs when the report treats those overlapping copies as additional activity.
Follow the repeated record through these locations:
- The original marketplace download or API response.
- Any export produced by the seller software.
- The files selected for import into Excel.
- The Power Query steps that append, merge or remove rows.
- The table used by the final order count, order-line count or units-ordered report.
Find the earliest point at which the repeated copy appears. A repeated row already present in a downloaded file needs a different investigation from one introduced when a query imports both the current file and an archived copy. Trace each copy through the measurement framework before changing the report.
Read the order identifier and line identifier separately
An order identifier groups records belonging to an order, but does not identify a particular order line by itself. A SKU does not prove line identity either: a product reference describes the product, not necessarily the individual occurrence within an order. Keep those identity levels separate when investigating repeated records.
Amazon's Selling Partner API uses AmazonOrderId for an order and OrderItemId for an order item. SellerSKU identifies the seller's product reference. These names help distinguish the identity levels, but do not assume every Seller Central download or seller-software export exposes those same fields.
Inspect the actual headers and mapping in your file. If the export lacks a dependable line identifier, record that limitation rather than treating order identifier plus SKU as automatically unique. The following example uses readable labels instead of real Amazon identifiers; assume the copies of LINE-BLUE have matching relevant content and no evidence of a correction.
| Extract | Order label | Line label | Product label | Interpretation |
|---|---|---|---|---|
| Earlier export | ORDER-ALPHA | LINE-BLUE | SKU-BLUE | Original order-line record |
| Later export | ORDER-ALPHA | LINE-BLUE | SKU-BLUE | Repeated copy of that line |
| Later export | ORDER-ALPHA | LINE-GREEN | SKU-GREEN | A different line belonging to the same order |
Appending these extracts without resolving overlap repeats LINE-BLUE in an order-line report. Removing duplicates on the order label alone can also discard LINE-GREEN, even though it is a different line. The correct treatment preserves the distinct line while preventing the repeated copy from contributing again.
Before applying that treatment, compare the relevant content in the source. Records sharing an identifier may represent an updated snapshot rather than identical copies. If a quantity or another report-relevant field differs, stop treating the match as a straightforward duplicate and investigate what changed before deciding how the report should handle it.
Check the Power Query operation behind the mistake
Power Query provides useful operations, but their names do not establish that they suit your records. Look at the inputs and selected columns, not just whether a step is called Append, Merge or Remove Duplicates. Keep the quality checklist focused on evidence for the report's intended level.
Append: overlapping files become repeated activity
Append Queries combines rows from its inputs. It does not determine whether an order line in one input represents the same underlying record as a line in another. Check the operation itself, as well as the name of the query step. Also check which files the query selects, particularly when it imports from a folder. An archive copy, renamed download or overlapping snapshots can bring the same record into the report again.
For an order-line count or units-ordered report, that repeated contribution can inflate displayed activity without any additional order being placed. The report then reflects the overlapping inputs rather than a fresh order. Check the selected files and their contents before changing the output, so that the correction addresses the source of the repeated contribution.
Merge: expanding matches multiplies an order row
Merge Queries joins tables using selected columns. If an order row matches several line records, expanding the matched table can repeat the order's fields across those lines. The operations guide can help frame the query as part of the order workflow.
That expansion may be appropriate for a line-level report. It becomes a measurement mistake when a later step counts each expanded row as another order or sums an order-level value on every line. Inspect the table immediately before and after expansion: repeated order fields may be a consequence of the join, not duplicated source orders.
Remove Duplicates: a broad key deletes valid lines
Remove Duplicates uses the selected columns to identify matches. Selecting only the order identifier can collapse separate lines belonging to that order. Review the selected columns against the report's intended level, rather than treating the operation's name as proof that a row is redundant.
A line-level report needs to preserve line distinctions; an order-level view needs a deliberate aggregation, not an unexplained deletion of whichever rows share an order label. Do not use duplicate removal simply because it makes the total look more plausible. Record the review method used to check the change.
Repair a saved copy in seven steps
Work on a saved copy of the workbook and retain the input files used by the disputed output.
Changing the import while fresh orders are arriving makes it harder to tell whether a changed result comes from the repair or from different source data. Keep those inputs available for the checks that follow.
- Name the affected output.Identify whether the problem concerns orders, order lines or units ordered. Note the sheet, table and query that supply it.
- Freeze the inputs.Keep the relevant downloads or exports unchanged for this investigation. Record which files the query actually reads, including any archive copies.
- Trace a suspect order.Find its records in the source file, any seller-software export and the Power Query preview. Compare identifiers and relevant content rather than relying on a familiar order label.
- Classify each apparent match.Distinguish an identical repeated copy, a separate line within the order, an updated record and an unresolved match. Do not silently combine those categories.
- Find the responsible step.Inspect Append inputs, Merge keys and expanded columns, and the columns selected for Remove Duplicates. Locate where the unwanted contribution first appears.
- Make the smallest supported change.Exclude a redundant input file, correct an inappropriate join, or revise a duplicate-removal rule only where the source evidence supports it. Preserve genuine lines and investigate differing content separately.
- Run the saved inputs again.Confirm that the repeated copy no longer contributes as fresh activity and that distinct lines remain. Also inspect unaffected records so that the repair is not merely tailored to the suspect order.
If the export cannot distinguish the records reliably, do not make the uncertainty disappear by deleting a row. Ask the supplier or report owner for the underlying identifiers or a more suitable export, and identify the affected output as unresolved meanwhile. Keep the selection checklist available if the export itself needs review.
Explain the changed report without rewriting the sales story
A lower total after removing repeated imports does not show that marketplace activity fell. It shows that the report's handling changed.
Likewise, restoring a valid line deleted by a broad rule is a reporting correction, not evidence of a newly placed order. Explain the difference without presenting a measurement repair as a change in sales.
Keep a short explanation with the repaired workbook: which inputs overlapped, which query step caused the problem, what changed and which records remain uncertain. A problem statement can hold a reference to the saved extracts and query so another reviewer can find the evidence.
Keep this check within the approved product-stock-to-order journey. Repairing an order report does not itself approve a product, authorise fulfilment or establish an accounting result. Its narrower purpose is to stop repeated imports from masquerading as additional orders while retaining genuine order lines.
