Evidence instead of promises

What was wrong with the demonstration file

The test file was assembled with the defect types that break real imports. Each one was found by the standard checks, repaired where the source data allowed, and flagged where it did not:

• Duplicate SKUs across different products — detected file-wide and flagged on both records; neither identifier was changed (the rule is set out below).
• Prices as words and decimal commas — converted where unambiguous; one genuinely unclear price flagged as an exception rather than guessed.
• Supplier headers in place of Shopify headers — mapped to the correct column names and order.
• Variant rows separated from their products — reattached through handle and title repair.
• A missing SKU — left blank and listed as an exception. Even in a demonstration, missing facts are not invented.
• Broken image URLs and encoding faults — corrected or reported.

Input and output records reconcile: 21 products and 88 SKU entries in, 21 products and 88 SKU entries out, with the exact duplicate rows removed during repair recorded in the change log.

How the result is counted

The headline result — zero unresolved validation errors — is a precise claim, so its terms are defined:

• Validation errors — structural or technical defects in the file itself: wrong headers, broken encoding, malformed prices, variant rows detached from their products, unusable references. Zero unresolved validation errors means none of these remain after repair and QC.
• Exceptions — missing or ambiguous source facts: a SKU the source never states, a price that cannot be read with confidence. Exceptions are listed for your decision and never silently filled. They are not counted as validation errors, because the file is not defective — the fact is simply absent.
• Approved unresolved items — changes deliberately left undone because they wait for your approval. The demonstration’s duplicate SKU is one: flagged on both products, changed on neither.

The counting method: the file contained 21 products. The 88 figure is the total number of SKU entries across all variants of those 21 products — one entry per variant row. In the source file, 87 of those entries carried a SKU value and one was blank (the missing SKU, listed as an exception); the count of entries is 88 in and 88 out.

How duplicate SKUs are handled

The same fixed rule as on the CSV Repair page: exact duplicate rows are removed only when confirmed genuinely redundant, and the removal is logged; a duplicate SKU on different products is flagged on both records and never silently changed; no identifier is normalised or changed without the customer’s approval; a missing SKU is left blank and reported; replacement SKUs are never generated automatically.

The QC checks applied to every file

• Header names and column order against Shopify’s specification.
• SKU uniqueness across the entire file — not a sample of it.
• Price and compare-at fields: numeric, correctly placed, consistently formatted.
• Variant structure: every variant row attached to its product, options consistent.
• Handles: one product, one handle; no accidental merges or splits.
• Image URLs: present where the source provides them, well-formed.
• Encoding: clean UTF-8 throughout.
• Reconciliation: product and SKU counts in versus out, differences explained in the change log.

Anatomy of a delivery

• Cleaned file — the prepared data, ready to use.
• QC report — the checks above, marked as performed, with their outcomes.
• Change log — what was changed and why.
• Exception list — everything that needs your decision: missing facts, unclear values, source conflicts.
• Original file — preserved unchanged, as the reference for every change.

The free 10-row sample, exactly

The sample exists so you can judge the work before paying. Its terms are fixed:

• Up to 10 selected data rows from your file.
• One sample per prospective project.
• You receive a preview of the issues identified and the corrections proposed.
• No obligation to place an order afterwards.
• The sample is a preview, not a full repair of your catalog.
• Nothing in the sample is invented or assumed — missing facts are shown as missing.

File acceptance rules

A file is “accepted” when I confirm in writing that it falls within a package (or an agreed quote) and can be repaired responsibly. Acceptance is what starts the 24-hour delivery clock for CSV packages. If a file cannot be accepted as-is — unsupported format, or damage beyond the agreed scope — you are told why, and given the options, before any payment.