"Cannot process this ean, it is present in different feed"

What you see

Cannot process this ean, it is present in different feed --> id: 8f3c21ab-...

Often joined to a second clause:

| Duplicate: This SKU is already in under processing in system. Please do not upload again

What it means

The barcode you are uploading is already claimed by another feed. Ajio is telling you which one — the UUID after the arrow.

It is not a data problem. Your file may be perfect. The row is being refused on identity, before anything in it is examined.

Why it happens

Every Ajio upload creates a feed, and that feed claims the barcodes in it whether the rows passed or failed. Rejection alone is not release; the claim ends when the row is soft-deleted or intentionally cleared from the owning feed.

So the usual sequence is:

  1. You upload. Some rows fail.
  2. You correct those rows and upload a clean new file.
  3. Ajio creates a second feed, which collides with the first.
  4. You correct something else and upload again. Third feed, third collision.

Each attempt makes the tangle worse, and none of it is caused by the data. We have seen an account where 11 of 23 feeds existed purely from this loop.

Read the whole message first

If the message includes "already in under processing in system", the referenced feed is progressing normally with your products. They are not stuck. The correct action is to stop resubmitting and let it finish. Clearing that feed would destroy live work.

How to fix it

First, find out whether the barcode is actually held. Download your Catalogue Report and check the Is SoftDeleted column for those rows:

  • Blank (row still live) → the barcode is held. In 143 out of 143 cases we measured, a new feed was refused. Go to route A if you want to repair it in place, or route C if you want to release it.
  • DELETED → the barcode is released and a new feed will probably take it (71 accepted against 46 refused in our data). Go to route B.

Full detail: Is my barcode free?

Route A — amend the owning feed

  1. Find the feed named in the error (the UUID after the arrow) in Upload History.
  2. Download its rejection file.
  3. Correct the values in that file.
  4. Re-upload that same file, under a new filename — Ajio refuses a filename it has seen before.

The rejection workbook carries the feed ID internally, so Ajio amends the existing feed instead of opening another one.

Route B — a fresh feed

Only if the rows are DELETED. Build a new file for those products on a template that Ajio recently accepted for the same category, fix the original fault, upload once.

Route C — release the SKUs yourself

If the rows are still live but you want to move the products to a new feed:

  1. Download the owning feed's rejection file.
  2. Clear every row belonging to the SKUs you want to release.
  3. Leave all unrelated rows unchanged.
  4. Re-upload the same rejection workbook under a new filename.
  5. After Ajio processes the release, submit the corrected products in a fresh feed.

The feedId in the rejection workbook makes Ajio update the owning feed. This release is self-serve; you do not need your Ajio SPOC.

How to avoid it next time

  • Never correct a rejection by building a fresh file. Always edit the downloaded rejection file for the owning feed.
  • Work your feed list oldest-first. The portal shows newest first, which is backwards — the earliest feed owns the products.
  • Put all fixes for one feed in one file. Two files, and the second overwrites the first on any shared rows.
  • When moving products out of a feed, clear only the complete rows for the intended SKUs.
  • Before concluding a product is blocked, follow the pointer. Feeds referenced in these errors are often succeeding, which means the product is already live.

Related: How Ajio feeds work · Is my barcode free?

Last verified 31 August 2026.

HyndBrain lists apparel catalogues across seven marketplaces. Talk to us.