Map supplier SKUs to eBay listings by creating a reviewed relationship between the supplier record, your internal product and the exact eBay listing or variation. Preserve original identifiers, check attributes and isolate ambiguous rows before using the mapping for stock proposals. Importing a file successfully does not prove its relationships are correct.
The practical challenge is usually a difference between systems. Your supplier uses one code, your business uses another, and eBay identifies the destination through its listing and variation context. A mapping sheet makes that relationship explicit so the next stock observation has a defensible destination.
This walkthrough is intended for supplier-backed sellers preparing a small, controlled import. It uses invented codes and does not instruct you to change live quantities during setup. Zelluvo publishes this guide and has a commercial interest in supplier-to-eBay mapping workflows.
Gather the minimum records before opening an import screen
Obtain an authorised supplier catalogue or product record and a current view of the eBay listings you intend to manage. Include the relevant account context. If you have several businesses or supplier catalogues, keep their records clearly separated while preparing the data.
For the supplier side, collect the product code, variant code where available, source location and distinguishing attributes. For the destination, retain the listing identifier, local SKU and variation attributes. Add your own internal SKU if it helps connect other operating records.
Do not begin by forcing both systems to use the same code. A mapping can preserve different identifiers and connect them deliberately. Renaming codes simply to make a spreadsheet join work can break other processes that still depend on the original values.
Use a working copy of exported files and preserve the originals. This gives you a reference when a formatting change or normalisation rule produces an unexpected result. Keep credentials, buyer details and other unrelated private data out of the preparation sheet.
Create a worksheet that explains each relationship
| Column | Purpose | Example |
|---|---|---|
| Mapping ID | Tracks the relationship itself | MAP-101 |
| Supplier and catalogue | Provides source context | Sample supplier / clothing |
| Supplier variant SKU | Preserves the source code | 00127-B-M |
| Internal SKU | Links your own record | SHIRT-BLUE-M |
| eBay listing and variation | Identifies the destination | Test listing / blue / medium |
| Pack quantity | Explains the saleable unit | One item |
| Review status and note | Shows whether the relationship is accepted | Pending attribute check |
Store identifier columns as text. A value such as 00127 is not the number 127 when the supplier uses the leading zeros as part of the code. Check an export and reimport cycle to ensure your spreadsheet has not changed it.
Keep the original supplier description in a reference column if it helps review, but do not treat it as the authoritative matching key. Descriptions can omit variant information or change for marketing reasons while the product code remains stable.
Add a clear status vocabulary: proposed, verified, unresolved and retired can be sufficient for a small workflow. Define what evidence is required to move a row to verified. Avoid a single “complete” flag that mixes imported, matched and reviewed records.
Match exact identifiers where their meaning is reliable
Begin with records that share a known, appropriate identifier. Confirm that the identifier refers to the same product level on both sides: a parent product, an individual variant or a pack. An exact text match across different levels can still be wrong.
Include source context when codes are not globally unique. A supplier’s short code may repeat in another supplier’s catalogue. Match on a combination that identifies the intended source rather than allowing the first matching row in a file to win.
When codes differ, create a proposed relationship using the available attributes, then review it. A human-readable description can help locate candidates, but the final decision should account for size, colour, model, compatibility and quantity as applicable.
Consult the official eBay SKU identifier documentation for the listing method involved. Identifier requirements and tracking context matter. Do not assume that a rule observed in one integration applies identically to every eBay listing workflow.
Resolve variants without relying on the parent page
For a multi-variation listing, create a relationship for each variation you intend to manage. A supplier parent page can provide useful context, but it does not establish that blue medium and blue large have the same stock or price.
Open the source and verify the selected option. Check whether the saved source location preserves that option when reopened. If it defaults to another variant, your monitoring tool needs an explicit selection mechanism or a different reliable source. Keep the relationship unresolved until you can identify the intended variant consistently.
Compare pack quantities carefully. A supplier may list a box of six while your eBay variation offers one item. That relationship may require a documented conversion and a fulfilment process capable of splitting the pack. Do not multiply quantities automatically just because the arithmetic looks simple.
Where a replacement model is offered, review the listing promise again. A supplier’s “equivalent” item can have different dimensions or compatibility. Product substitution is a separate commercial decision, not a routine mapping shortcut.
Check the file for conflicts before importing it
Include a simple reconciliation count. If the source file contains 30 candidate relationships, your review might classify 24 as verified, four as unresolved and two as retired. Those invented numbers add back to 30, so nothing has silently disappeared. They do not show that the 24 accepted rows are correct; they show that every input row has an explained outcome. Keep logical validation and completeness reconciliation as separate checks.
After the import, compare the saved relationship count with the accepted input count and inspect any difference. A rejected row, an existing relationship updated in place and a duplicate skipped by the importer have different meanings. Record the actual outcome instead of treating every difference as a failure or assuming every row created a new mapping.
Look for duplicate source keys, duplicate destination relationships, missing identifiers and inconsistent attributes. A clean import format does not detect every logical conflict. Build a small exception list that states why each row needs attention.
Two source rows pointing to one destination may be intentional if your business supports several suppliers, but the selection policy must be explicit. Without a policy, each source can generate a conflicting proposal. Do not combine supplier quantities unless their meaning and independence have been established.
Check for accidental whitespace and character changes. Normalisation can be useful, but preserve the original code and apply the transformation consistently. If a supplier treats letter case as meaningful, converting everything to uppercase may be inappropriate.
Review blank values separately from zero values. Although a mapping sheet primarily contains identifiers, it may also carry initial quantities. An empty field can mean missing data, while zero can be a deliberate stock value. Do not let a general spreadsheet cleanup turn one into the other.
Import a small reviewed batch first
Use the product’s preview or validation mode where available. Start with a handful of reviewed relationships covering a simple listing, a variation listing and an intentionally unresolved row. The objective is to see how the importer interprets your columns and reports exceptions.
- Confirm the intended organisation, store and seller account.
- Select the working file with preserved identifier formatting.
- Map columns to their actual meanings rather than similarly named fields.
- Review the proposed relationships and any rejected rows.
- Import only the accepted small batch through the supported workflow.
- Inspect the saved records individually.
- Verify that unresolved records did not become guessed matches.
- Retain the import result and correction notes.
Test a second import with the same records. Determine whether the workflow updates existing relationships, leaves them unchanged or creates duplicates. Repeated imports are common in normal operations, so this behaviour should be understood before a large catalogue depends on it.
If the software has no preview, reduce the test scope and inspect the effects before proceeding. Do not treat the absence of a preview as permission to run a large uncertain import. The acceptance test is the resulting relationship, not the appearance of a success message.
Validate observations before reviewing stock proposals
After importing, obtain a source observation for each test record using authorised access. Confirm that the observed variant is the one you reviewed and that the timestamp and quantity meaning are visible. A saved mapping can still point to a source whose selection behaviour has changed.
Compare the local observation with a manual check of the same source and conditions. Investigate discrepancies before enabling broader use. A difference may come from timing, location, variant selection or a reading failure rather than an arithmetic error.
When the workflow produces a stock proposal, inspect the current destination, proposed quantity and supporting evidence together. Recent orders or manual edits can make older proposals unsuitable. Approval should depend on the current context, not simply on the fact that the mapping once passed a test.
Zelluvo’s documented process keeps live eBay stock changes approval-first. Mapping and imports support local records and proposals; they do not remove the approval boundary. Confirm the available import format and source support for your account before preparing a large file.
Correct a relationship without losing its history
If a test reveals an incorrect source, record the previous relationship and the reason for changing it. Inspect any dependent proposal that was calculated before the correction. Do not approve an old value simply because the mapping screen now looks right.
Check whether the mistake affects similar rows. A problem with leading zeros, parent-level identifiers or default variants can recur throughout an import. Correct the preparation rule and review the affected group before reimporting.
Keep retired mappings distinguishable from unresolved ones. A retired relationship may have been valid historically but is no longer used. An unresolved relationship has not yet been established. These states support different investigations and should not disappear into the same blank field.
Agree who owns ongoing corrections. If one person edits supplier mappings while another prepares bulk files, they need a way to avoid restoring an older relationship accidentally. A dated working file and clear handover notes can help, provided the software’s own records remain the operating source of truth.
Document the process for the next import
Save a clean template containing column definitions and formatting requirements, without private credentials or customer information. Include one illustrative row and the rules for unresolved data. A template should make the next preparation task repeatable without pretending every catalogue follows the same conventions.
Record what the importer does with duplicate records, missing rows and changed destinations. These behaviours are easy to forget between occasional imports. A short verified note is more useful than an assumption based on the name of an upload button.
Review your process after a supplier changes its catalogue structure or your listing method changes. A file that imported correctly last month can still carry invalid relationships today. Reuse the workflow, but recheck the assumptions that connect it to current data.
For a wider buying framework, read the supplier stock monitoring guide. To assess an eBay-focused workflow, see the inventory software selection guide. You can also ask Zelluvo about your mapping format using a sanitised example with invented identifiers.
Questions about supplier SKU imports
Can I change all supplier SKUs to match my eBay codes?
A mapping usually lets you preserve both systems’ identifiers. Renaming codes can break other records or supplier references. Keep the original values and create a reviewed relationship unless a planned system change specifically requires renaming.
What should I do with unmatched rows?
Keep them in an exception list with the missing evidence identified. Do not guess merely to finish the import. Resolve the product, variant or destination context before using the row for stock decisions.
Does a successful import mean the mapping is accurate?
No. It may only mean the file satisfied the importer’s format rules. Inspect the saved source and destination relationships and compare representative observations with the intended variants.
Should I enable live stock changes during the first import?
Begin with reviewed records and observation or local-proposal checks. Use the required approval process for any appropriate live action, then confirm the destination. Do not use real customer exposure to test an uncertain mapping.