Validate an Amazon Inventory File

Inventory Loader files are tab-delimited. If a product_description cell contains a literal tab character (common when product descriptions are pasted from PDFs or formatted documentation), the row gets split into too many cells. Validator catches this as row_width error before upload.

Header (10 cols, tab-separated):
sku\titem-name\texternal-product-id\texternal-product-id-type\titem-condition\tprice\tquantity\tproduct-description\tbullet_point1\tbullet_point2

Row 42 (12 cols — two extra tabs inside the description):
SKU-042\tWidget\t012345678905\tUPC\tNew\t12.99\t100\tBlue widget,\t100mm\tx\t200mm\tDurable\tCompact
                                                                              ^^^^^^^^^^^^^^^^^^^^
                                                                              These two tabs were
                                                                              inside the description cell

Validator output:
{
  "row": 43, "column": 1, "columnName": "(row width)",
  "type": "row_width", "severity": "error",
  "detail": "Row has 12 columns; header has 10."
}

Fix: in source, replace tabs inside descriptions with single spaces
     (csv-find-replace with regex `\t` → ` `), or wrap the
     description cell in double quotes if the template supports it.

Amazon's standard_price / list_price columns expect bare numerics — no £, $, €, no comma decimal separator, no inline currency code. Validator infers the column as number and flags symbol-prefixed cells.

Header:
sku,standard_price,quantity

Rows:
SKU-001,12.99,100         ← OK
SKU-002,£14.99,50          ← type_mismatch
SKU-003,15,50              ← OK (whole numbers fine)
SKU-004,16,50              ← OK
SKU-005,18.50 GBP,50       ← type_mismatch
SKU-006,19,99,50           ← type_mismatch (comma decimal — EU locale Excel save)

Validator output (2 issues):
Row 3: Expected number based on the column profile, but found "£14.99".
Row 6: Expected number based on the column profile, but found "18.50 GBP".
Row 7: Expected number based on the column profile, but found "19,99".

Fix: csv-find-replace with regex `[£$€¥]` → `` (empty), then
     csv-find-replace with `(\d+),(\d+)$` → `$1.$2` to swap
     EU comma-decimal to US/UK point-decimal.

Re-pasting the same SKU on two rows is one of the most frequent flat-file mistakes — Amazon's processing report surfaces it as error 8005 ('attempted to change identity attributes'). The validator catches it because seller-sku matches the unique-key heuristic.

Header:
seller-sku\tproduct-id\tproduct-id-type\tprice\tquantity

Rows:
WIDGET-BLUE-100\t012345678905\tUPC\t12.99\t50
WIDGET-RED-100\t012345678912\tUPC\t12.99\t30
WIDGET-BLUE-100\t012345678905\tUPC\t14.99\t20    ← duplicate seller-sku
                                                  but different price/qty

Validator output:
{
  "row": 4, "column": 1, "columnName": "seller-sku",
  "type": "duplicate_key", "severity": "warning",
  "detail": "Value \"WIDGET-BLUE-100\" also appears on row 2.
             This column looks like a unique key."
}

Fix: decide which row wins — keep the first (csv-deduplicator,
     strategy: first) or the last (strategy: last, treats the second
     row as the price/qty update).

Saving the .xlsm template as 'Unicode Text' from Excel-for-Windows produces UTF-16 LE with a FF FE byte-order mark — not the UTF-8 Amazon's docs recommend. PapaParse handles the BOM, but you'll often see a leading \uFEFF on the first header cell that breaks exact column-name matching at Amazon's parser.

Raw hex (first 20 bytes of the file):
FF FE 73 00 6B 00 75 00 09 00 70 00 72 00 69 00 63 00 65 00
^^^^^                                                            
  UTF-16 LE BOM
      ^^^^^ ^^^^^ ^^^^^
      s     k     u   (interleaved with 00 = UTF-16 LE)

Validator output (header parsed as):
  Column 1 name: "\uFEFFsku"   ← BOM stuck to the column name
  Column 2 name: "price"
  ...

Result: the unique-key detector doesn't recognise "\uFEFFsku" as `sku`,
        so duplicate-key checking on SKU silently disables.

Fix in Excel: Save As → File Format dropdown → 'Text (Tab delimited) (.txt)'
              instead of 'Unicode Text (.txt)' — produces UTF-8 + tab,
              not UTF-16 LE + tab.

Fix on existing file: csv-cleaner with the BOM-strip option, or open
                      in a UTF-8-aware editor and re-save without BOM.

If you save the template as 'CSV (Comma delimited)' instead of 'Text (Tab delimited)', Excel-for-Windows defaults to CP1252 / ANSI encoding, not UTF-8. Product names with German / French / Spanish / Polish accented characters re-open as garbage. The validator catches the \uFFFD replacement character pattern.

Header:
seller-sku,item-name,brand_name

Rows (CP1252-saved, opened as UTF-8):
SKU-DE-001,Café Crème (250g),Tchibo               ← OK in CP1252
SKU-DE-002,Bayrische Wei�wurst,Metzgerei Müller   ← \uFFFD (replacement char)
                              ^                    where ß was in CP1252
SKU-PL-003,�ledzie marynowane,Polmlek             ← \uFFFD where Ś was

Validator output:
Row 3, Col 2 (item-name): encoding error — replacement character.
Row 4, Col 2 (item-name): encoding error — replacement character.

Fix path A (re-save in Excel):
  File → Save As → File Format → 'CSV UTF-8 (Comma delimited)' on
  Excel-for-Mac, or 'Text (Tab delimited)' on Excel-for-Windows
  (which now defaults to UTF-8 from Excel 2019+ when extension is .txt).

Fix path B (already-saved file):
  Open in VS Code → 'Reopen with Encoding → Windows 1252' → 'Save with
  Encoding → UTF-8'. Re-run the validator to confirm 0 encoding errors.

Amazon's item-condition field is an enum (New, UsedLikeNew, UsedVeryGood, ...). The validator's suspicious-value detector catches typos and casing/punctuation drift that silently fails Amazon's enum check at the processing stage.

Header:
seller-sku\titem-condition\tprice

Rows (15 rows total — condition column has 3 common values + 1 rare):
SKU-001\tNew\t12.99
SKU-002\tNew\t12.99
...   (10 more rows with "New")
SKU-012\tUsedLikeNew\t9.99
SKU-013\tUsedLikeNew\t9.99
SKU-014\tUsedVeryGood\t8.99
SKU-015\tnew!\t12.99             ← rare value (appears once),
                                    substring-similar to "New"

Validator output:
{
  "row": 16, "column": 2, "columnName": "item-condition",
  "type": "suspicious_value", "severity": "warning",
  "detail": "Rare value \"new!\" looks close to common category \"New\"."
}

Fix: csv-find-replace exact match "new!" → "New".
     Also check for: "new " (trailing space), "NEW" (uppercase),
     "Used - Like New" (Amazon expects "UsedLikeNew", no spaces, no dash).

When you paste or import a 12-digit UPC into Excel, it autoconverts the cell to a number — 012345678905 becomes the number 12345678905 and loses the leading zero. The validator catches this two ways: (1) type_mismatch if other rows kept the leading zero (column profile becomes string, the numeric one stands out); (2) duplicate_key if two different UPCs lose their leading zeros and collide. Amazon error 8541 ('Product ID corresponds to ASIN but attributes don't match') frequently traces back to a stripped leading zero. Fix: in Excel, format the column as Text *before* pasting data; or re-import as a CSV with the column wrapped in ="012345678905" to force text.

Excel-for-Windows older than 2019 defaults to ANSI / CP1252 when saving as .csv. Accented characters (é, ü, ß, ñ, Ś, ł) become ? or \uFFFD when Seller Central reads them as UTF-8. The validator catches this as encoding error wherever the replacement char appears. Fix path A: save as .txt (Tab delimited) which defaults to UTF-8 in Excel 2019+. Fix path B: save as 'CSV UTF-8 (Comma delimited)' in Excel-for-Mac. Fix path C: convert the existing file with csv-cleaner — open the cleaner's encoding option, force UTF-8. Per Amazon's docs, legacy MWS endpoints expected ISO-8859-1; the current Selling Partner API expects UTF-8 — match what your upload path needs.

Tab-delimited templates don't tolerate literal tabs inside cells unless the cell is wrapped in double quotes, and most Amazon templates don't quote any cells. A description pasted from a PDF or formatted source document often carries hidden tabs that split a 30-column row into 32 columns. Seller Central's processing report says something like 'Row has unexpected structure' without giving the column count. The validator reports the row immediately with row_width error and the exact column-count delta. Fix: run csv-find-replace on the description column with regex \t → (literal tab to single space) before re-saving as .txt.

Inventory Loader has ~12 columns; Clothing Listing Loader has ~80; Books Listing Loader has ~30. If you submit a Clothing-template file to the Inventory Loader endpoint (or vice-versa), Seller Central rejects every row with 'Column header doesn't match any defined attribute'. The validator can't tell you you've picked the wrong template (it doesn't know which endpoint you're targeting), but it will show every column the file has — compare the column-profile panel against Amazon's Data Definitions sheet for your target endpoint. Rule of thumb: Inventory Loader is *only* for adding listings to ASINs Amazon already has; for new listings, use the category-specific Listing Loader.

Amazon's older Inventory Loader templates accepted numeric item-condition (1 = Used Acceptable, 11 = New). Current templates accept enum strings. Some teams have legacy spreadsheets where half the rows say 11 and the other half say New — the column profile becomes mixed and every cell of the non-dominant type gets a type_mismatch warning. Fix: pick one convention (string is current-preferred) and find-replace the numeric values with their string equivalent. Don't submit a mixed file — Amazon's processing report will accept some rows and reject others depending on the parser's tolerance, leaving you with a partial-upload state.

For FBA listings (fulfillment-center-id = AMAZON_NA), quantity is left blank because Amazon manages stock from your FBA inventory, not from your file. If your file is mostly FBM (you fulfill yourself) with a few FBA rows, the column will be > 85 % populated and the FBA blanks will trigger empty_cell warnings. This is the validator behaving correctly — don't auto-fill the blanks; verify the warnings correspond to rows with fulfillment-center-id = AMAZON_NA, then ignore those specific warnings. If your file is mostly FBA, the column will be > 15 % empty and the warning won't fire — also correct.

Amazon doesn't publish a hard MB or row cap for inventory file uploads. Sellers and third-party tooling vendors consistently report ~20,000 SKUs per file as the practical ceiling before uploads start failing silently or sitting in the queue indefinitely. The validator on JAD's free tier caps at 500 rows; Pro at 100,000 — so a 19 K-SKU Amazon file fits comfortably under Pro. Mitigation for the Amazon-side cap: split with csv-row-splitter into 10K-row chunks before upload, and submit each as a separate Seller Central job. Each job gets its own processing report — easier to triage than a single 20 K-row failure.

The Active Listings Report (Seller Central → Inventory → Inventory Reports → 'Active Listings') uses different column names from the Inventory Loader (item-name vs product-name, listing-id extra column, no add-delete). If you're using the Active Listings export as a source for an Inventory Loader update, you need to rename columns first — csv-header-rename handles the mapping, then this validator confirms the new headers match the target template's expected names.