Building flat-files — when bulk beats the UI.

A flat-file is Amazon's bulk-upload format — an Excel or TSV template, one per category, that lets you create, update, or delete many ASINs and SKUs in a single submission. For any catalogue larger than roughly ten items, for any catalogue migration between accounts or regions, and for any update that touches more than five fields per SKU, the flat-file is faster than the Add a Product UI, less error-prone (because every column is validated as a structured field rather than a free-text input), and far more audit-trail-friendly (you keep the upload, you keep the processing report, you can diff before-and-after). It is also the more dangerous tool — a sloppy flat-file can wipe an entire catalogue's localisations in one upload.

Where to find the right template

Seller Central → Catalog → Add Products via Upload → Download an Inventory File. The template selector asks for the product type — pick the one that matches the browse-node category from Episode 08. The template you download is category-specific: a Kitchen template will not validate against an Electronics ASIN, and uploading one against the wrong category triggers either a hard rejection or, worse, silent attribute mapping that corrupts the listing. Always re-download the template fresh for each new project; Amazon updates templates quarterly and old templates can have stale required columns.

The columns that load-bear every flat-file

• feed_product_type. Amazon's internal product type identifier. Distinct from the browse node. Listed in the template's "Product Type Definitions" sheet. Wrong value here = silent rejection of the entire row.
• item_sku. Your own SKU. Acts as the primary key for the row — Amazon uses this to look up whether the row is a create, an update, or a delete. SKUs must be unique within your account, ≤40 characters, ASCII alphanumeric plus hyphen and underscore. Once assigned to inventory, an SKU is effectively permanent (closing and re-creating a SKU has fulfilment consequences).
• external_product_id + external_product_id_type. The GTIN (EAN, UPC, ISBN, GCID) and its type. Leave blank if you have a GTIN exemption for this brand/category combination.
• brand_name. Must exactly match Brand Registry record. Mismatch is the single most common silent-rejection cause for new-ASIN rows.
• parent_sku / parent_child / relationship_type / variation_theme. The four columns that wire variation families together. Parent row has parent_child = parent, child rows have parent_child = child and reference the parent SKU. All children share the same variation theme. Module 5 covers variation flat-files in depth.
• update_delete. The operation column. Values: Update (full row replaces the live record — unspecified fields get wiped to blank), PartialUpdate (only specified non-blank fields are written; blanks are ignored), Delete (closes the SKU and removes the offer; the ASIN survives if any other seller is offering it).
• recommended_browse_nodes. The browse-node ID (numeric, from Episode 08). Pin the primary node here; secondary nodes go in additional browse-node columns.
• standard_price + currency. The offer price. Currency must match the marketplace.
• quantity. Initial stock count for MFN offers. Leave blank or zero for FBA — FBA inventory is managed separately through the FBA inbound flow.

Update vs PartialUpdate — the difference that matters

The single most expensive flat-file mistake is using Update when PartialUpdate was meant. With Update, every blank cell in your row is interpreted as "set this field to empty" and the live record gets wiped on those fields. A flat-file that updates a price column to a new value and leaves the bullets, the description, and the keywords blank will wipe the bullets, the description, and the keywords on the next processing pass. PartialUpdate ignores blank cells and only writes non-blank values. The rule: use PartialUpdate by default, and only use full Update when you explicitly want to clear fields and your row is intentionally complete.

The safest flat-file workflow

1. Download the latest template for the right category from Seller Central. Do not reuse an old template from a previous project — quarterly updates change required columns.
2. Export the current live data for every SKU you will touch, through the reverse-feed flow (Episode 12). This gives you the live record as Amazon currently stores it, in the same column shape as the template.
3. Make changes in a copy of the export. Never edit the live export file directly — keep it as a rollback artefact.
4. Set update_delete to PartialUpdate on every row unless you specifically want full replacement semantics.
5. Validate locally first. Open the template's "Valid Values" sheet and verify every drop-down value (product type, variation theme, currency, fulfilment channel) matches what your row uses. Excel's data-validation will flag the obvious errors before you upload.
6. Upload to the Inventory File queue through Seller Central → Catalog → Add Products via Upload → Upload your Inventory File. Pick the matching template type from the dropdown — wrong template-type selection at upload time silently mis-parses the file.
7. Wait for the processing report (typically 5–30 minutes, sometimes hours during peak). Download the report and read every warning line, not just the error count. Warnings frequently document silent rewrites that succeeded but with unexpected values.
8. Spot-check live SKUs in Seller Central after processing completes. Confirm that the stored values match what you uploaded; investigate any drift before the next upload.

Reading the processing report

The report comes back as an Excel or text file with one row per submitted row, plus error and warning columns. The status field uses:

• OK — row processed successfully. Verify the stored values still match what you uploaded; silent rewrites can apply even on OK rows.
• WARNING — row processed but with a flagged issue. Most commonly a Style Guide rewrite (title capitalisation, banned-word stripping). Read every warning.
• ERROR — row rejected. The error code points to the failing field; the error message describes the validation failure. Fix and resubmit only the failed rows, not the entire file.

Common flat-file failure modes

• Wrong template version. Quarterly template changes break old files. Re-download every time.
• Update instead of PartialUpdate. Wipes fields you didn't intend to touch. Covered above.
• UTF-8 BOM issues. Excel sometimes adds a Byte-Order-Mark to TSV exports that breaks Amazon's parser. Save as Excel (.xlsm) or as plain TSV without BOM.
• Leading zeros stripped from EANs. Excel strips leading zeros from numeric columns, turning 0123456789012 into 123456789012. Format the GTIN column as Text before pasting.
• Wrong product_type for the category. Silent rejection or attribute-mapping corruption. Look up the correct product type in the template's Product Type Definitions sheet.
• Concurrent flat-file and UI edits. A flat-file in flight while a teammate edits the same SKU in the UI produces last-write-wins behaviour that is hard to debug. Establish a "no UI edits during flat-file uploads" team rule.
• Currency mismatch. Submitting USD prices to a EU marketplace silently rejects the offer rows.

Flat-files vs SP-API automated feeds

Manual flat-file uploads are the right tool for ad-hoc bulk operations. For continuous, automated feed integrations — repricers, ERP integrations, multi-channel inventory tools — the SP-API Feeds endpoint is the modern path. SP-API feeds use the same underlying schema as flat-files (the Tab-Delimited Inventory Files format, or the newer JSON schema for some operations), but with programmatic authentication, scheduled execution, and per-row status callbacks. If your catalogue exceeds ~1,000 SKUs or your update frequency exceeds weekly, plan for SP-API rather than manual flat-files.

Seller vs Vendor — flat-files vs NIS

Sellers use the flat-file pipeline described above. Vendors do not — Vendor bulk operations run through the NIS (New Item Setup) form template, which is structurally similar (Excel-style, category-specific) but submitted through Vendor Central and reviewed by Amazon's catalogue team rather than processed automatically. Vendor NIS turnaround is days to weeks rather than the Seller flat-file's minutes to hours. The category of operation that determines whether a Vendor uses NIS or another path: any new ASIN creation or any variation-family change uses NIS; attribute updates on existing live ASINs run through the in-Vendor-Central catalogue editor or through CSV updates within the Items section.

What to take into the next episode

With flat-files handled, the next episode covers the Style Guides — the per-category rules that decide what your title, bullets, and images are actually allowed to contain, and the silent validator that rewrites your content when you cross the lines.