Amazon flat file

A flat file is an Excel workbook (.xlsm) or tab-delimited text file that Amazon accepts as a bulk listing feed. You download it from Seller Central under Add Products via Upload, fill one row per SKU, and upload it. Amazon parses the rows and returns a processing report naming the SKUs that failed and why.

It is called "flat" because everything about a product — identifiers, price, quantity, title, five bullets, image URLs, thread pitch, voltage rating — lives on one wide row. There is no nesting. Parent-child variation relationships are expressed by extra columns (parent_sku, parentage, variation_theme) rather than by structure.

The important part, and the part that ruins people's weeks, is that there is no single flat file. Amazon issues a different template per category. A Hardware template asks for size_name and material_type. A Lighting template asks for wattage and bulb_type. A Safety template wants compliance fields.

Downloading the wrong template means Amazon rejects the feed outright or, worse, accepts it into a browse node where nobody shopping for a 3/8-16 Grade 8 hex bolt will ever see it.

The category listing report (CLR) is the export you request from Seller Central's inventory reports. It returns your existing listings with their attribute values populated, in roughly the same column vocabulary the templates use.

Ops teams use it for three things:

• Audit. See what Amazon actually holds for your SKUs, not what you think you sent. Amazon's detail page is a merge of contributions from every seller on the ASIN; your feed may have lost to another seller's.
• Round-trip editing. Pull the CLR, change values in place, paste the changed rows into a template, set update_delete to PartialUpdate, and send only what moved.
• Gap-finding. Sort by an attribute column and count blanks. Empty material_type across 4,000 fastener SKUs means you are missing from every material filter.

One caveat worth knowing before you build a process on it: the CLR is a report, not a template. Its columns do not always line up one-for-one with the current upload template for the same category, and Amazon revises templates. Treat CLR-to-template as a mapping step you own, not a copy-paste.

Every template ships with the same tab structure: Instructions, Data Definitions (what each column means), Template (where your data goes), and Valid Values (the controlled vocabulary for closed-list fields). The Valid Values tab is the one people skip and then debug for days. If it says Zinc Plated and you send Zinc-Plated, the row fails.

Here is a Hardware row for a single fastener:

Column	What it holds	Example value
feed_product_type	Which template schema this row uses	hardware
item_sku	Your SKU, the primary key of the feed	HB-38162-G8-YZ
external_product_id	The GTIN	812345006923
external_product_id_type	Which identifier standard	UPC
brand_name	Brand, must match brand registry	Acme Fastener Co.
part_number	Manufacturer part number	0142391
item_name	Title, capped at a category-specific length	3/8-16 x 2 in. Grade 8 Hex Cap Screw, Yellow Zinc, 50-Pack
standard_price	Price, no currency symbol	24.85
quantity	Sellable units	140
item_type_keyword	Legacy browse-node hint; newer templates use recommended_browse_nodes	hex-bolts
material_type	Category-specific attribute	Alloy Steel
main_image_url	Publicly reachable URL	https://cdn.example.com/0142391_main.jpg
update_delete	Feed action	PartialUpdate

The first column and the last one are feed mechanics. Everything else is product data you either have or you don't.

Flat file failures are rarely about the file. They are about the data behind it.

• Category-specific required attributes are blank. Amazon adds a required field to a template. Six thousand of your SKUs have never carried it, and the whole feed fails.
• Values are free text where Amazon wants a closed list. 600V, 600 V, and 600 Volt are three values to a spreadsheet and one product to a human.
• The GTIN doesn't match the brand. A UPC issued under someone else's GS1 prefix throws an identifier error you cannot fix in the template.
• A CLR round-trip overwrites good data with blanks. Blank cells plus a full Update action can wipe attributes you never meant to touch.
• Nobody owns the spread. The same SKU carries one description in the ERP, another in the PIM, and a third on Amazon.

The pattern: the template is a formatting problem sitting on top of a completeness problem. Reformatting is cheap. Filling material_type, thread_pitch, and finish for 6,000 fasteners is the actual job.

A PIM stores the attributes and exports a channel-shaped file. What it cannot do is invent a value that was never entered. If material_type is empty in the PIM, it is empty in the flat file.

Closing that gap means reading the spec sheets and manufacturer PDFs, extracting the values, normalizing them against Amazon's Valid Values for the target category, and routing low-confidence values to a human before they ship. Anglera does that work alongside the PIM ecosystem (Akeneo, Salsify, Syndigo, inriver, Pimberly): completed attributes go back into the PIM, and the PIM keeps exporting the file the way it always has.

The upkeep is continuous rather than one-time. Amazon revises templates. You add categories. Suppliers send new SKUs with a PDF and a part number. A flat file that passed in March fails in September because the schema moved, so the durable answer is a standing process for filling required attributes.