By Bernardo Campelo, Forbes Business Council E-Commerce Leader, Amazon SPN Certified provider, and Founder of PrepVia.
There is a specific kind of stuck that only an Amazon seller knows. The inventory is prepped, labeled, and boxed. The truck is available. The deal calendar is ticking. And Seller Central simply will not create the shipment. The Send to Amazon workflow errors out, loops, or offers something so absurd you assume it is a bug. No help article names your error. The seller forums are a cemetery of identical threads that end with someone asking, months later, whether anyone ever found a fix.
We run an FBA prep center in Miami, Florida, and shipment creation is our daily work. When the workflow breaks, we cannot shrug and try again next week, because our clients have freight windows. So we have spent real weeks inside broken shipment plans, in the web workflow and through the SP-API, mapping exactly what blocks creation and what un-blocks it.
Every blocked plan we have ever diagnosed ran into one of three walls. Amazon never tells you which wall you are on. The error messages point everywhere except the cause. This post names the walls, the signals for each, and the honest fix, including the one nobody wants to hear: sometimes the correct move is deleting the entire plan and starting from zero.
The 60-second version
Wall 1 is your catalog. Invalid or stale MSKUs: suppressed listings, deleted SKUs, and old drafts pointing at SKUs that no longer exist. The fix is cleaning the catalog, never retrying the plan.
Wall 2 is prep classification. The requires-prep-owner error, and the ping-pong where a global prep setting fixes half your SKUs and breaks the other half. The only stable exit is setting prep owner and label owner item by item.
Wall 3 is placement and confirmation. Amazon offers only absurd splits, sometimes six or more destinations for a handful of units, or a confirmed shipment comes back orphaned with no confirmation ID. Packing groups go stale on Amazon's side. Past a certain age, delete the plan and recreate it fresh.
Diagnostic order: catalog first, prep second, placement last. Upstream walls disguise themselves as downstream errors.
The Three Walls, and Why Amazon Never Names Them
Send to Amazon is a pipeline: choose SKUs and quantities, declare packing, receive placement options, confirm, print labels. The SP-API walks the same stages under different names. Each stage validates against a different internal Amazon system, and a failure in an early system frequently surfaces as a confusing error two stages later. That is why sellers spend days fighting the wrong wall.
| Stage in Send to Amazon | The system doing the validating | The wall that lives there |
|---|---|---|
| Step 1: choose inventory | Catalog and listings | Wall 1: invalid or stale MSKUs |
| Step 1, packing details | Prep guidance | Wall 2: prep and label ownership |
| Step 2 onward: placement and confirm | Placement planner | Wall 3: splits and stale packing groups |
Everything below is those three rows, expanded.
Wall 1: The Catalog Wall (Invalid and Stale MSKUs)
The signals
You will see one or more of these: a banner saying certain MSKUs are not valid, a SKU that exists in your inventory but never appears in the Step 1 picker, a saved draft that throws an error the moment you open it, or an API call that rejects one item while accepting the rest. The common thread: the failure traces back to item selection.
What is actually happening
The inbound system validates every MSKU against your live catalog at plan time. Three catalog states break that validation. The listing is suppressed or inactive, so the SKU technically exists but is not eligible to inbound. The SKU was deleted from the catalog but is still referenced somewhere. Or the SKU is set to merchant fulfilled, and only FBA SKUs can join an FBA shipment.
Drafts are the sneaky one, and they deserve their own sentence. A Send to Amazon draft stores MSKUs by name and never updates itself when your catalog changes. Delete a SKU on Monday and the draft you saved in March will fail forever, with an error that never mentions the draft is the problem. We have watched sellers rebuild listings and contact support when the culprit was an old draft quietly pointing at a SKU that no longer exists.
How to clean it
- Copy the exact MSKU names out of the error. Do not work from memory. Stale SKUs often differ from live ones by one character.
- Look each one up in Manage All Inventory. Three checks per SKU: does it exist, is the status Active, and does the channel say Fulfilled by Amazon.
- Suppressed or inactive: fix the listing first. The suppression reason (missing image, restricted keyword, pricing error) is a listings problem, and no amount of shipment-side clicking resolves it.
- Deleted: recreate the SKU or remove the line. If the product is gone for good, the line has to leave the plan.
- Merchant fulfilled: convert to FBA and wait for the conversion to complete before touching the plan again.
- Old drafts referencing dead SKUs: delete the draft. It cannot be repaired from inside. Rebuild from the live catalog.
- After any listing fix, wait before retrying. Catalog changes propagate to the inbound system on a delay measured in hours, not seconds.
One boundary: this wall is about the plan refusing to exist at all. If the plan creates but specific items refuse to join it, that is a different failure family, covered in our deep dive on items that cannot be added to an FBA shipment.
Wall 2: The Prep Classification Wall (the Prep Owner Ping-Pong)
The signals
The error is usually literal: an item requires a prep owner, but none was assigned. Sometimes it is quieter, and the plan simply refuses to advance past packing details, or the confirm action fails without a message. Either way, the plan is alive, the items are valid, and the blocker is prep classification.
The mechanics: a global setting against a per-SKU requirement
Amazon records two ownership decisions for every SKU: who performs prep (you or Amazon), and who applies the FNSKU label. There is also an account-level default in the prep and labeling settings, and that default is the trap. The setting looks global. The enforcement is per SKU.
Picture a real mixed catalog. Half your SKUs need prep (poly bag, bubble wrap, taping) and therefore require a prep owner to be recorded. The other half are classified as needing no prep, and certain owner configurations on those SKUs are invalid. Now the ping-pong begins: you flip the account default to satisfy the flagged half, and the other half starts flagging. Each global correction breaks the opposite half of the catalog, and the error never once suggests that the global setting is the wrong tool.
The exit: set ownership item by item
- Stop touching the account-level default. Whatever it is set to right now, leave it.
- List every flagged MSKU from the error message.
- Open the prep and labeling details for each flagged line inside the Send to Amazon item list, or from Manage Inventory.
- Record what Amazon says the prep requirement is, then explicitly assign the prep owner for that SKU.
- Assign the label owner explicitly on the same screen. Label ownership gaps produce the same class of stall.
- If the plan was created before your changes, remove and re-add the affected items. Plans cache prep data from creation time, and a cached gap survives your fix.
- If you think the classification is wrong, unstick the shipment first. Accept what Amazon requires today, ship, and dispute the classification through Seller Support as a separate track. A stuck shipment is not leverage.
If the physical prep is the real pain behind this decision, that is what a professional FBA prep center absorbs: the SKU says prep owner seller, and your prep center does the work under that flag.
Wall 3: The Placement Wall (Absurd Splits and Orphaned Confirmations)
The signals
This wall has two faces. The first is placement options that make no commercial sense. Say you are sending 300 units across a few SKUs, and Amazon offers a split across six or more destinations as the no-fee option. Or every option routes to distant, expensive fulfillment centers. Or the consolidated option you always use is simply missing today. The second face is the confirmation failure: you click confirm, the page returns, and the shipment is a ghost. No confirmation ID. Nothing clean in the shipping queue. Labels will not generate. Sometimes a charge estimate appears for a shipment that does not exist.
What is actually happening: packing groups go stale
Placement options are not computed in your browser. They are generated server side from packing groups, and both the groups and the option quotes carry an expiry. A plan you built on Tuesday references packing groups that Amazon's planner may have already discarded by Friday. Editing items or quantities after options were generated invalidates the math behind those options. Confirming against a stale group is exactly how a shipment ends up orphaned: half-created, unconfirmed, and unrepairable from the UI.
Retry or recreate: the honest decision table
| Situation | The right move |
|---|---|
| Fresh plan, first strange split offer | Regenerate placement options once, review quantities, try again |
| Plan older than 48 to 72 hours since packing details were entered | Delete and recreate from zero |
| Items or quantities edited after placement options were generated | Delete and recreate from zero |
| Confirmed, but no confirmation ID after a few hours | Treat as orphaned: delete what you can see, recreate, and check for duplicates before confirming |
| Two consecutive fresh plans, same absurd splits | The problem is your quantity structure or Amazon-side: see the next two sections |
Deleting a plan feels like defeat. In practice, recreation takes about fifteen minutes when your packing information is ready, and a fresh plan generates fresh packing groups, the one thing a stale plan can never do. The split offers usually come back sane on the rebuild. Keep your carton data organized so re-entry is fast; our guide on adding box content information to an FBA shipment covers the format that makes this painless.
The split-versus-fee decision, briefly
When the splits are wide but legitimate, you are in fee territory, not bug territory. Amazon's inbound placement fee structure charges for shipping to fewer destinations, and the current math is detailed in the 2026 FBA fee changes. Two operational notes from our dock: very small quantities spread across many SKUs invite wide splits, so consolidating more units per SKU per shipment tends to produce saner options. And the choice between paying the placement fee and eating the multi-destination freight is a real calculation, not a reflex; we walk through it in how to avoid inbound placement fees.
The Diagnostic Order
When a shipment will not create and the error is ambiguous, run the walls in order. An upstream failure wears a downstream costume: an invalid MSKU can surface as a packing error, and a prep ownership gap can surface as a confirmation failure. Debugging placement while the catalog is broken turns a one-hour problem into a one-week problem.
- Catalog first, two minutes: every MSKU in the plan exists, is Active, and says Fulfilled by Amazon. Any miss, fix it and rebuild before judging anything else.
- Prep second, five minutes: every SKU has an explicit prep owner and label owner. Any gap, set it per item, then remove and re-add the item.
- Placement last: only after the first two pass cleanly do the placement options deserve your attention. Strange splits or a ghost confirmation on a clean plan means regenerate once, then delete and recreate.
- Never debug two walls at once. Change one variable, rebuild, observe. Shipment creation is a pipeline, and pipelines are debugged upstream to downstream.
Your Problem or Amazon's Problem
Some days it is not you. Amazon's inbound systems have bad afternoons, and knowing the difference saves you from rebuilding a healthy catalog at midnight.
| Evidence it is on your side | Evidence it is on Amazon's side |
|---|---|
| The error names a specific SKU or item | The error is generic and names nothing |
| The same failure repeats on a brand-new plan | A minimal test plan with one known-good SKU also fails |
| Behavior is consistent every attempt | Behavior is intermittent: works, fails, works |
| Only your problem SKUs are affected | Placement options fail to load for everything |
Once the shipment exists and leaves your dock, keep the paper: carrier documents, weights, pallet photos. If Amazon later shows fewer units than you sent, that argument is won with records made at shipping time, the subject of how to prove Amazon received your FBA shipment.
Frequently Asked Questions
Why does Seller Central say my MSKUs are not valid?
The inbound workflow validates every MSKU against your live catalog when the plan is built, and it fails any SKU that is suppressed, inactive, deleted, or still set to merchant fulfilled. Old drafts are a common hidden cause, because a draft references a SKU by name forever, even after it is gone. Fix the listing state in Manage All Inventory, delete drafts that point at dead SKUs, and allow a few hours for catalog changes to propagate to the inbound system before rebuilding the plan.
How do I fix the prep owner required error on FBA shipments?
Stop adjusting the account-level prep and labeling default and set ownership per SKU instead. Open the prep and labeling details for each flagged item and explicitly assign both the prep owner and the label owner. Amazon enforces the requirement SKU by SKU, so a single global setting will always break part of a mixed catalog while fixing the rest. Once each SKU has explicit owners recorded, the setting persists and future shipments stop hitting the error.
Why did Amazon split my shipment into so many destinations?
Placement options come from Amazon's network planner, which weighs your quantities against where it wants inventory positioned across the country. Small quantities spread over many SKUs tend to generate wide splits, sometimes six or more destinations for a few hundred units. Regenerating a fresh plan often returns saner options, and consolidating more units per SKU per shipment reduces splitting. When wide splits persist, compare the multi-destination freight cost against the inbound placement fee for a consolidated option and pick the cheaper total.
Should I delete and recreate a stuck FBA shipment plan?
Yes, in three situations: the plan has aged more than two or three days since packing details were entered, you edited items or quantities after placement options were generated, or a confirmation came back without a confirmation ID. Packing groups go stale on Amazon's side and a stale plan rarely heals. Recreation takes about fifteen minutes when your box content data is ready and almost always beats days of fighting. Before confirming the new plan, check your shipping queue for duplicate or ghost shipments from the failed attempts.
Talk to PrepVia: we un-stick FBA shipments every week →
24-36h prep · No minimums · Amazon SPN Certified · Miami, FL
Related Reading
- Items That Cannot Be Added to an FBA Shipment: the item-level cousin of these three walls
- How to Prove Amazon Received Your FBA Shipment: the records that win receiving disputes
- How to Avoid Inbound Placement Fees: the fee side of the split decision
