Listing Not Approved: Rejection Causes and How to Check Them
When a listing is refused the cause is usually data mismatch rather than content. How to check barcodes, mandatory category attributes, image rules and brand approval, in order.
A listing not being approved is frustrating because the reason often goes unstated or arrives as a generic phrase. In fact rejection causes are finite, and checking them in order finds the answer quickly.
Separate one thing up front: the problem is usually data mismatch, not the quality of the copy. Rewriting the description is wasted effort in most cases. A rejection is about a field that breaks a rule, not about tone, and the field is what needs correcting.
Read the rejection message first
If the channel stated a reason, the job is half done, provided the message is read correctly. Messages fall into four groups, and each group points somewhere different.
- If a field or attribute name appears, the cause is mandatory category attributes. Go straight to cause one.
- If barcode, GTIN or EAN appears, the cause is a conflict or an invalid barcode. Go to cause two.
- If a brand name appears, the cause is the brand definition or selling authorisation. Go to cause three.
- If image, picture or dimensions appear, the cause is image rules. Go to cause four.
If the message is generic, or there is no message at all, work through the order below from the top. It is arranged by frequency.
1. Mandatory category attributes
This is the most common cause. Every category carries its own required attributes: fabric, age group, warranty period, origin, volume. When the category changes, the set changes, so a product that passed in one category is refused in another.
Check: are all the mandatory attributes for this category filled? A single empty required field is enough to stop a listing. There is a second trap: a field can be filled while its value is not on the list the channel accepts. Where free text was typed and the channel expects a closed list, the value is refused. Category trees and attribute lists differ per channel, so this is not work you do once and leave; the detail is in marketplace category and attribute mapping.
2. Barcode conflict
If a barcode is already bound to another listing, a new one will not open. This happens when you previously uploaded the same product under a different code, or when another seller used the barcode.
Check: is the barcode valid, and is it bound to another listing on this channel? There are also cases where the barcode itself is invalid; a barcode with a wrong check digit is refused quietly. You can check a barcode with the free barcode validator before you upload it. Where barcodes come from, and why codes you invent yourself cause trouble, is covered in the GS1 and EAN barcode guide.
The conflict can also come out of your own catalogue: if the same barcode was given to two different SKUs, the second listing is refused every time and the cause gets hunted on the channel side.
3. Brand approval
Most marketplaces approve at brand level. If the brand is not defined, or the seller does not appear authorised for it, the listing will not open. This is the least often stated rejection reason and the one that wastes the most time.
Check: is the brand defined on the channel, and is your seller account authorised for it? Spelling matters too; where the channel keeps a closed brand list, a small difference in spelling tries to bind the listing to a new brand and produces a rejection. If you have spelled the same brand differently across channels, that alone is a source of faults.
4. Image rules
Image rules differ by channel: minimum resolution, background colour, framing, no text overlay, the first image showing the product alone. An image with campaign text burned in passes on one channel and is refused on another.
Check: does the first image meet this channel's rule? Image count and order fall under the rules too, and some categories expect shots from specific angles. What images do to your quality score, and the content side as a whole, is the subject of marketplace product content and quality score.
5. Variant structure
If colour and size are not built the way the channel expects, the listing is either refused or opens with missing variants. The second is more dangerous, because the listing goes live but some sizes never sell.
Check: is every variant opened and barcoded individually? Each variant needs its own barcode, and the bond between the parent product and its variants has to be built the way the channel expects. How to build the matrix is covered in variant management and the colour-size matrix.
6. Documents and restricted product groups
Some product groups require documentation or are restricted. Cosmetics, supplements, electronics and children's products frequently attract document requests. Without the document, the listing does not open.
There is no point waiting here; resubmitting before the paperwork is complete produces nothing. Learning which groups require documents before you open a new channel is the cheapest route; the checklist is in the new marketplace launch checklist.
Approved, but not visible
This is a separate situation and it gets confused with rejection. The listing passed approval and was later withdrawn. The causes differ: stock falling to zero, a price moving outside the range the channel accepts, performance-related restrictions, or a content warning that arrived afterwards.
Telling them apart is easy: if the listing never opened it is a rejection; if it opened and then disappeared it was suppressed. The causes of the second are taken one by one in marketplace listing suppression reasons.
A pre-upload checklist
The sequence below ends the rejection cycle before it starts. It takes a minute for a single product, and in bulk uploads it is a habit you set up once and run every time.
- Is the category chosen, and are that category's mandatory attributes filled?
- Were the values picked from the list the channel accepts?
- Is the barcode valid and unique within your own catalogue?
- Is the brand defined on the channel, and spelled the same as on other channels?
- Does the first image meet the channel's rule?
- Is every variant open and barcoded?
- Does the product fall into a group that requires documentation?
In bulk uploads these checks belong before the send rather than after it; the method is in bulk product listing on marketplaces.
The durable fix: catch it before upload
Most of these six can be checked before sending. If a product with an empty required field, an invalid barcode or a non-compliant image arrives in front of you as a list before it is sent, the rejection cycle never starts.
Uploading, waiting, then hunting for the reason is the slowest method. Validating product content against the channel's rules in advance means doing the work once. An unapproved listing also carries a cost on the stock side: stock updates sent to a listing awaiting approval are not accepted either, which is why the two faults often appear together. For the stock side, see stock not updating on the marketplace.
In Bulutegra the result of a bulk send is followed row by row and rejected rows are listed with their reason; missing colours, short titles, empty categories and items with missing barcodes are gathered in the quality tab, where you fix them in one place and resubmit. The whole panel is described on the Why Bulutegra? page, or you can request a demo.
Frequently asked questions
Why was my product not approved?
The most common cause is missing mandatory category attributes. Every category carries its own required set, and the set changes as the category changes. The second most common is a barcode already bound to another listing, the third is missing brand approval.
How long should I wait for an unapproved listing?
Waiting is not a fix. If a rejection reason was given, read it and correct it. If none was given, start with mandatory category attributes and work through barcode and image rules in order.
The same product is approved on one channel and refused on another. Why?
Every marketplace has its own catalogue rules and mandatory attribute set. Information that suffices on one channel can count as missing on another. Thinking about product content channel by channel creates less work than sending one version everywhere.
