A rejection arrives as an event: a notice, a code, a listing that did not go live. It feels like something that happened at the moment of submission, and the response is organized accordingly — someone opens the file and changes it until it passes.
That framing is wrong in a way that costs the same money repeatedly. A rejection is detected at submission. It was caused somewhere else, usually much earlier, often by a person who did not know the rule existed.
Detected there, caused earlier
Consider what a check at submission actually does. It examines a finished file against a set of conditions and reports whether the file satisfies them. It has no view of how the file came to be, and it cannot report anything about that, because none of it is in the file.
The framing persists because a notice looks like a diagnosis. It is specific, it names a property, and naming a property feels like naming a cause — the image contains text, the background is not uniform, the product does not fill enough of the frame. Each of those reads as an explanation and is a description. Knowing that a file has a property tells you nothing about why it has it, and the sentence is constructed so that the distinction never comes up.
So the notice describes a property of an image, and the property was determined by a decision. A crop was chosen, a prop was placed, a background was lit, a model was styled, a template was built, a garment was selected. By the time any check runs, all of those are history.
What the specific conditions are, and how they are actually evaluated, is a separate subject with its own difficulties — rules that read as stable while the thing reading them changes: how image requirements are actually enforced. This article is about the other half: where the property being measured came from.
Where the decisions actually get made
Tracing a rejection means asking which step determined the property that failed. In most operations the candidates are few:
• The brief, where what the images should contain was specified, or was not.
• The shoot, where composition, styling, props, and framing were settled in the room.
• Retouching, where backgrounds, shadows, edges, and cleanup were decided.
• Assembly, where a set was selected for a page and ordered and cropped to a template.
• Submission, where files were exported and sent.
Only the last of those is near the notice. Everything else happened days or months earlier, in a different room, frequently by people who never see a rejection and would not connect one to their work if they did.
The stylist who added a prop was making a picture better. The retoucher who removed a shadow was following a house preference. Neither was making a compliance decision, and neither will hear that they made one.
The notice reaches the person who cannot fix it
Here is the structural part, and it explains more than any list of reasons could.
A rejection notice goes to whoever submitted the listing. That person sits at the end of the chain. They have the file, a deadline, and no authority over the shoot that produced it — and they are measured on getting the listing live, not on why it failed.
The incentives point the same way as the information does. Whoever handles submissions is measured on listings going live, has a queue, and gains nothing from establishing why something failed. Tracing a cause is unpaid work that delays the thing they are accountable for, so even a conscientious person rationally declines it. Nothing here requires anyone to behave badly; the structure produces the outcome on its own.
So they fix it where they are. They crop the prop out, they re-export at another size, they swap in a different frame, they cover something. The fix works, the listing goes live, and the event closes. Nothing travels back, because there is no path back: no field to record a cause, no routine that reaches the brief, and nobody whose job includes asking where this started.
Why the same reasons recur
The consequence follows directly. The causing decision is still in place — still in the template, still in the styling convention, still in the retouching preference — so it produces the same property in the next batch, which fails the same check and generates the same notice.
Every one of those events was successfully fixed, and none of them was ever solved. From the submission end, the work looks like competent problem-solving: a problem appeared, it was handled, the listing went live. From any distance, it is the same problem being handled repeatedly by the only person who cannot prevent it.
The aggregate cost stays invisible because it is distributed. Each instance is small — a crop, a re-export, half an hour — handled by one person, closed the same day, and never counted anywhere. Nobody sees the yearly total, because nothing in the process adds it up, and a cost that is never totaled is never weighed against the cost of fixing the cause. That comparison, if it were ever made, would usually be lopsided.
Teams usually notice the pattern eventually and respond by building a pre-submission checklist. That helps with speed and not with cause, because a checklist also sits downstream — it catches the property earlier without changing what produces it. Work still gets redone; it is just redone before submission rather than after.
Two kinds of rejection, at different distances
Not all rejections trace the same distance, and separating them tells you where to send each one.
Format and technical failures — dimensions, aspect, file properties — have a short trace. They are determined at export, which means they can be genuinely solved at the submission end by fixing a setting or a template once. Handling them locally is correct rather than a patch.
Content and composition failures have a long trace. What is in the frame, how it is arranged, what is written on it, and who is in it were all settled at the shoot or in the brief. At the submission end the only available actions are cropping, covering, or substituting — all of them recoveries rather than repairs, and each costs the image something. Content rejections also tend to concentrate in categories sellers do not think of as content at all, which is its own subject: where listings actually get rejected.
Sorting each rejection into one of these two before responding is the cheapest available improvement, because it determines whether the right answer is at your desk or upstream of it.
What makes a rejection traceable
None of this works if a file cannot be connected to the decisions behind it. In most libraries it cannot: an image arrives, gets a name, and carries nothing about which shoot produced it, which brief governed it, or who approved it.
The minimum that makes tracing possible is small — which session or source an image came from, which brief it was made against, who delivered it, and when. Those cost a line at the time and cannot be reconstructed later, which is the same timing argument that applies to every record produced as a by-product of work.
There is one case where the chain legitimately ends inside nothing: an image supplied from outside the company. The brief, the shoot, and the retouching all happened somewhere you have no record of, so tracing stops at the supplier. That is not a failure of your bookkeeping, and it does change what you can do — the cause has to be sent as a requirement rather than as a correction, and it has to be sent before the next set arrives rather than after.
With them, a rejection becomes a question somebody can answer in minutes, and the answer names a step rather than a file. Without them, the chain breaks at the first link and the question cannot even be asked. The place to catch most of this before it becomes a notice is the point where a set is assembled for a page, since that is the last moment anyone sees the images together and in context: where the set comes together.
Questions teams ask about image rejections
Why do we keep getting rejected for the same reason?
Because the cause has never been changed, only its symptoms. Each notice is resolved by the person who received it, at the end of the chain, in the file in front of them, and the decision that produces the failing property is still in the template or the styling convention. Repetition is the expected outcome of fixing things where they surface.
Should we build a pre-submission checklist?
It will reduce how often you are surprised and will not reduce how often you redo work, because a checklist also operates downstream. It catches the property earlier rather than preventing it. Worth having, and not a substitute for sending causes back.
Who should receive a rejection notice?
Whoever can change the thing that caused it, which is rarely the person who submitted. The practical version is that the submitter handles the listing and separately routes the cause to the step that produced it. That second step is the one almost no workflow includes.
Can we tell in advance which images will be rejected?
For format and technical properties, yes, since those are determined at export and can be checked before sending. For content and composition, prediction means knowing the current requirements for each marketplace you sell on and applying them at the brief stage, which is where those properties are actually decided.
A prop caused a rejection. Can we just crop it out?
You can, and the crop costs the image something — composition, context, sometimes the reason the shot existed. That is a recovery rather than a repair, and it is often the right call for a listing that needs to go live today. It leaves the styling convention that placed the prop entirely untouched.
How do we know which decision caused a rejection?
Only if the image can be connected back to its session, its brief, and whoever delivered it. That connection is made when the image is produced and is essentially unrecoverable afterward. Where the connection is missing, the honest answer is that the cause cannot be determined, which is itself worth recording.
Where this leaves you
Rejections are reported at the end of a chain and created near the beginning of it, and everything difficult about them follows from that gap. The notice reaches the person with the least power to prevent a repeat, they resolve it competently, and the cause stays where it is. Sort each rejection by how far it traces — a setting you can fix at your desk, or a decision made in a room months ago — then send the long ones back to the step that made them, and keep enough of a record that the step can be identified at all.
Route the cause, not just the file
The next time a listing is rejected, do two things instead of one. Resolve the listing as you normally would, then decide whether the cause was set at export or at the shoot. If it was set at the shoot or in the brief, write down which decision it was and send it to whoever owns that step, even informally. Keep a short record of session, brief, and deliverer on your images so the second step is possible at all.
Written by
