Your supplier sends you an Excel with 47 tabs
Supplier data cleanup is real work that nobody prices. What the hours cost, why better templates don’t fix it, and what a pipeline can take over.
On this page
It arrives on a Tuesday afternoon. A 14MB Excel file from your top supplier. The filename is “PRODUCTS_FINAL_v3_REVISED_USE_THIS_ONE.xlsx.” It has 47 tabs.
Some tabs are organized by product line. Some by region. One is labeled “OLD DO NOT USE” and holds the only correct pricing.
Column headers change between tabs. Cell A1 of Tab 1 says “Hi team, see below” in a merged cell spanning columns A through Q.
Your team has to turn that into structured, enriched, channel-ready product data. By Friday. Across 3 marketplaces, 4 locales, and 2 compliance frameworks.
It may sound exaggerated, but for many product operations teams some version of it lands every week, and it is a common hidden bottleneck that nobody puts on a roadmap.
Telling suppliers to send better data doesn’t work.
The instinctive response is “make suppliers send better data.” Retailers and marketplaces have tried it for years. It doesn’t work, and here is why.
- Many suppliers don’t have a PIM. Their product data lives in ERP exports, personal spreadsheets, and knowledge passed between product managers.
- Every customer asks for a different format. Your template is one of many they maintain. They copy and paste between templates, and the file that arrives matches none of them.
- Supplier product managers move on. How they formatted data for you leaves with them.
- Suppliers don’t see what happens next. The rejected marketplace listing, the customer return from a wrong specification and the 40 hours of manual rework all land on your side.
- Excel accepts anything unless someone sets up checks. It looks structured, which is the problem. It is also what everyone can open, so it is what everyone sends.
- Suppliers build their files for their own operations, not for your catalog. An ERP export is shaped for manufacturing, not for a product page.
Asking suppliers to fix this asks them to pay for your efficiency. They won’t, because the cost never reaches them. The problem is yours to solve in your own systems.
Nobody adds up the hours.
The cost hides because the work is spread out. Different people, different weeks, different systems. For one example batch, the hours look like this:
Scroll sideways to see the whole table.
| Activity | Who does it | Time per batch | What it actually costs |
|---|---|---|---|
| Interpret the spreadsheet structure | Product data analyst | 2-4 hours | Everything else waits on it. It needs knowledge of the file nobody else has, so one person is a single point of failure. |
| Map columns to internal taxonomy | Product data analyst | 4-8 hours | Done again from scratch every time, because the last mapping sits on someone’s laptop. Nothing carries over. |
| Clean and normalize values | Analyst + junior team member | 8-16 hours | Easy to get wrong. The inconsistencies travel downstream. Typos end up as attribute values. |
| Chase missing required fields | Product manager | 4-8 hours, plus a 3-5 day wait on the supplier | Holds up the whole batch and starts an email chain. The supplier sends a “corrected” file that breaks the mapping you already built. |
| Validate against channel requirements | Channel specialist | 2-4 hours per channel | Every channel has its own rules, cross-checked by hand. You find out at submission, when the marketplace rejects the listing. |
| Import into PIM or catalog system | Technical team | 2-4 hours | Custom scripts written 3 years ago by someone who left. They break when a supplier renames a column. |
| Fix post-import issues | Everyone | 4-8 hours | Duplicate SKUs, wrong categories, missing images, attribute values in the wrong units. Found weeks later. |
| Coordinate across teams | Product operations lead | 2-4 hours | Slack threads, status meetings, and someone tracking “where is Supplier X’s data?” by hand. Nobody has a dashboard. |
Note
The arithmetic nobody does
Add up the hours in the table above for one supplier batch. Multiply by a fully loaded hourly rate, then by the number of suppliers and by how often each one sends updates. For many teams the annual figure is uncomfortably large. That is manual normalization labor alone. It doesn’t count the launch delays, the marketplace rejections, the customer returns from wrong specifications, or the products sitting in a warehouse that nobody can buy yet.
The work underneath compounds.
The 47-tab Excel file is the part you can see. What sits under it is what takes the time.
- Every supplier names categories differently. Supplier A calls it “Clothing > Jackets > Waterproof.” Supplier B calls it “Apparel > Weather > Raincoats.” Supplier C sends product codes without any category structure. You need one taxonomy, and the mapping is manual, per supplier, per batch.
- Attribute structures don’t line up. Supplier A gives “weight” in grams. Supplier B gives “weight_kg.” Supplier C puts “gross_weight” and “net_weight” in one concatenated cell. Your schema wants “weight_grams (numeric, required),” and the normalization is manual.
- Languages get mixed. German descriptions with English technical terms dropped into them. French that was Google-translated from Italian. Product names that are internal part numbers rather than something a shopper would read.
- Images and records don’t match. A supplier sends 400 images with filenames like “IMG_2847.jpg” and nothing tying them to product records. Or a link to a Google Drive folder that expires in 7 days. Or images below the resolution a marketplace requires.
- Compliance information arrives incomplete. GPSR fields are missing. DPP attributes don’t exist. Material composition comes as free text, “mostly cotton,” instead of structured percentages. The regulatory data sits in a PDF the supplier attached, not in the spreadsheet.
Any one of these is manageable for one supplier, one time. Multiply it by 20 suppliers, 4 markets, 5 channels and monthly updates, and it becomes a large drag on what your team can ship.
It also grows in a straight line. Every supplier you add adds its own share of the work.
This is an infrastructure problem, not a cleanup problem.
The usual answer is to hire more people to clean data. That grows in a straight line too, and it breaks when you grow. Every new supplier, market or channel adds headcount.
Supplier data onboarding needs a pipeline, not more hands. Here is what the pipeline has to do, how much of each part CataZenta does today, and what it doesn’t do.
Scroll sideways to see the whole table.
| Pipeline part | In CataZenta today | Not in CataZenta |
|---|---|---|
| Intake: take each file in the shape it arrives | CSV and Excel files (the first worksheet), with column headers in the first row, or the REST API. Imports run when someone starts them. | XML files and supplier portals. |
| Column mapping: point each column at the right attribute once | A saved mapping per file layout, reused on the next file. Auto-map suggests attributes by column name. When the columns change, you update the saved mapping. | Mapping learned from sample values. |
| Normalization: one category, one unit and one form for each value | The Taxonomy agent suggests categories for review. Duplicate detection, run after import, flags possible duplicates. | Unit conversion and value rules. |
| Checks: catch bad rows before a marketplace does | Product codes and option values are checked on import, and failed rows come back with the reason. Ranges and formats are checked in the product editor, and channel rules when a product is sent to Amazon or Shopify. | Channel checks at import. |
| Enrichment: fill the gaps suppliers never fill | Agents draft missing attributes and descriptions from the data each product already holds, for review. | Reading PDFs and images. |
| Review: see where each product stands | Your team moves products from Draft to In review to Approved, and agent suggestions wait in the approval queue by default. | A progress view for a whole batch. |
| Channel readiness: know what each channel still needs | The Channel launch agent flags missing channel fields and drafts them for review. | A per-channel score at import. |
CataZenta doesn’t do supplier scoring either: seeing which suppliers send complete, accurate data and which create the overhead, so data quality can become a procurement criterion.
The saved mapping carries over, so the tenth file with the same layout needs no new mapping.
In CataZenta you save a column mapping per file layout, and each import gives you an error file listing every failed row and the reason. Because only the first worksheet is read, a 47-tab workbook goes in as one file per tab, each with its column headers in the first row.
Before and after.
Scroll sideways to see the whole table.
| Scenario | Before (by hand) | After (with a pipeline) |
|---|---|---|
| New supplier onboarding (5,000 SKUs) | A 47-tab Excel arrives. 3 weeks of cleanup by hand. Products trickle live over 8-12 weeks. The team is worn out. | Each tab is saved as its own file, and a saved mapping is built once per layout. The import is checked, and failed rows come back with the reason for each. Agents draft the missing values for review. |
| Monthly supplier update (500 products) | An analyst spends 2 days re-mapping, repeats last month’s normalization work, finds the format has changed, and loses another day. | The saved mapping is reused. If the supplier changed its columns, update the saved mapping, then rerun. Agents fill the new gaps for review. |
| Seasonal launch (3 suppliers, 2,000 SKUs) | All 3 suppliers send different formats. The team runs 3 cleanup projects at once. The launch slips 4 weeks. | Each supplier’s file layout has its own saved mapping, and each import runs with it. The same agents are then run on the results for review. |
| Marketplace expansion (new retailer) | “We need to add 12 new attributes for Zalando across 10,000 existing products.” A 6-week project. | Upload the retailer’s template and map its columns; the Channel launch agent drafts missing channel fields for review. |
| New compliance requirement (GPSR fields) | “Suppliers need to provide safety information.” An email campaign, 3 months of collecting, and it is still incomplete. | A structured GPSR template goes out to suppliers and comes back through a saved mapping. Missing safety fields are flagged per product when you run the Compliance agent on families that define those fields. |
Chaos breaks the AI you put on top of it.
When people did this work by hand, inconsistent supplier data was survivable. Someone read it, worked out what it meant and cleaned it up. Software doesn’t do that.
- AI enrichment needs structured input. Free text, merged cells and inconsistent naming give it nothing reliable to read, and the output inherits the mess.
- Automated runs break on inconsistent schemas. A pipeline built for Supplier A’s file needs separate configuration for Supplier B’s. Automation doesn’t generalize across chaos.
- AI shopping agents read the product data merchants expose through feeds and store catalogs. Products onboarded from chaotic supplier files often have missing or inconsistent attributes, which makes them invisible or unreliable to those agents.
- A shopper asks an assistant “what materials is this made of?” The answer comes from structured attributes. If the supplier wrote “mostly polyester blend” as free text, there is no trustworthy answer to give.
- Listing tools need consistent, typed attributes to format and publish a product. When supplier data varies, every product becomes a manual exception.
- Completeness scoring gets unreliable. When suppliers provide attributes inconsistently, a product can score as complete while holding wrong or unstructured values.
The more AI you run over your catalog, the more the supplier data underneath it matters. Clean, structured input produces automation you can rely on across many products. Inconsistent input produces output that is wrong and confident about it.
Tip
The 47-tab test
The next time a 47-tab Excel arrives, the question isn’t who has time to clean it. It is whether your pipeline already handles it: one file per tab with its column headers in the first row, a saved mapping per layout, and an error file for whatever fails.