Supplier onboarding: from Excel attachments to validated data

A new supplier is signed in March and their range is live in your shop in September. Between those two dates sits a folder of Excel attachments named Artikelliste_final_v4_NEU.xlsx, four rounds of mail asking for the missing weights, and a category manager copying values into the PIM by hand.

The delay is almost never the supplier being slow. It is that nobody told them precisely what was required until after they had already sent something, and the correction loop runs at the speed of email.

Why the Excel template fails, specifically

Most wholesalers already send a template. It usually still fails, and the reasons are structural rather than anyone's fault:

• The template forks on first contact. The supplier adds a column, deletes a sheet, renames a header. You now have as many schemas as suppliers.
• Validation happens after submission, on your side. The supplier finds out a field was mandatory when you tell them, days later. Every rule is discovered rather than presented.
• There is no state. "Sent", "in review", "rejected", "partially accepted" live in a mail thread and in somebody's memory. Nobody can answer "where is this range" without reading the thread.
• Corrections are re-submissions. A single wrong unit means a whole new file, which has to be diffed against the old one, usually by eye.
• The work lands on the wrong desk. Your category manager researches a packaging dimension that the supplier already has on their own spec sheet.

That last point is the expensive one. Every hour your team spends completing supplier data is an hour spent re-deriving information the supplier holds. The goal of onboarding is not faster typing on your side — it is moving the effort to the party with the answers.

The mechanism: validate at submission, not after

The change that matters is where the rules live. Instead of a document the supplier fills in blind, they work against a form that knows the rules and refuses what cannot be accepted.

A practical rule set for an industrial range has four layers:

• Structural. Which fields exist, which are mandatory for this product category, what type each one is. A supplier cannot submit a length as free text if the field is numeric with a unit.
• Format. GTIN check digit, valid unit codes, date formats, permitted values from a list rather than free typing for things like material or protection class.
• Completeness. A per-category minimum — for example, every item in "pumps" needs flow rate, head, connection size, weight and one image at minimum resolution. Completeness is a percentage the supplier can see rising as they work.
• Business. Duplicate detection against your existing range, plausibility ranges (a 4 kg valve with a 400 g packaging weight), and required documents per category.

The supplier sees a failing rule at the moment they enter the value, with the reason. That single change removes most of the mail loop, because the questions you used to ask by hand are now asked by the form.

The review queue: where judgment still belongs

Validation catches what is checkable. It does not catch a description written in marketing language, a wrong image, or a product that duplicates something you already carry under a different name. Those need a person, and they need a place to work.

A review queue gives the submission a state machine instead of a mail thread:

• A submission arrives as a batch with a status, a submitter, and a timestamp.
• A reviewer in category management sees only what changed and what failed, not the whole file.
• Items can be accepted, rejected with a reason, or sent back for correction individually — the accepted 340 articles do not wait for the 12 disputed ones.
• Every decision is recorded: who accepted what, when, on which version.

That last property is what makes the process auditable. When a specification turns out wrong two years later, you can say which submission it came in on and who released it.

The supplier sends a spreadsheet, someone re-types it into the PIM, and the same corrections are requested again for the next range six months later.

Design the onboarding, not just the tool

Most of the value here is in decisions you make before any software is configured. Four of them, in order:

1. Define required per category, not per supplier. Requirements belong to the product type. A category profile ("what a pump needs") applies to every supplier who delivers pumps, and it is maintained once. Supplier-specific templates are how you ended up with 80 schemas.

2. Decide what you will accept as "good enough for now". There is a real distinction between blocking fields (cannot be listed without) and enrichment fields (wanted, can follow). Making everything mandatory stalls onboarding; making nothing mandatory produces a catalog you cannot publish. Write the two lists.

3. Agree the identifier contract up front. Which identifier is the key — the supplier's article number, GTIN, or your own internal number? Who mints it? What happens when a supplier reuses an article number for a different product, which they will? Get this wrong and every later delta update matches the wrong row.

4. Set a service level in both directions. Suppliers respond faster when they know a review takes three working days, and your team performs better when the queue has a target. Publish both.

Migrating the suppliers you already have

Nobody starts with an empty supplier base, and asking 200 existing suppliers to learn a portal at once does not work.

A sequence that does, in our experience:

• Start with the ranges that change. Suppliers with seasonal or frequently revised assortments feel the benefit immediately; a supplier with 30 static SKUs will not be motivated by anything.
• Import the last good file. Load the supplier's current data as a pre-filled draft so their first session is correction, not typing. The completeness score on that draft is also your baseline — and usually the most persuasive number in the conversation.
• Keep a file path for the tail. Some suppliers will never use a portal. An upload that runs the same validation rules against a structured file is a far better fallback than a mailbox, because the rules stay in one place.
• Report back. A supplier who can see their own completeness score and rejection reasons will fix their data at the source. This is the point at which quality starts improving without you asking.

How this fits the rest of the chain

Validated supplier data is the input side of the same gate that serves the output side. The same canonical model, validation rules and versioning that admit a supplier submission are what feed your customer portal, your API consumers and your ETIM and BMEcat deliveries to technical wholesale. Data that passed at intake does not have to be corrected again at delivery.

The supplier portal — submission, validation, review — is planned for 2026. The category profiles, the blocking-versus-enrichment split and the identifier contract are not; those are yours to write now, and they are the part that determines whether any tool helps.

Key takeaways

• The Excel loop fails because rules are discovered after submission and state lives in a mail thread — not because suppliers are slow.
• Move validation to the moment of entry: structural, format, completeness and business rules, presented as the supplier works.
• A review queue turns a submission into a state machine with per-item accept, reject and correct, so a good batch is not held hostage by twelve disputed rows.
• Define requirements per product category, not per supplier, and split fields explicitly into blocking and enrichment.
• Agree the identifier contract before the first import — who mints the key, and what happens when a supplier reuses an article number.
• Onboard the suppliers with changing ranges first, pre-fill from their last good file, and show them their own completeness score.