Short answer: The Amazon FBM fulfillment process works as one loop: import orders from Seller Central, turn them into physical demand and see the shortfall, purchase against that demand, receive goods, keep inventory accurate, then pick, pack and ship with evidence and review profit. Most late shipments start with a break between two of those stages.
This guide covers each stage, how it usually fails and the control that prevents it, then gives you a checklist to audit your own operation.
Why FBM breaks at scale
With Fulfilled by Merchant (FBM), you store, pack and ship the order, not Amazon. Amazon's FBM page asks sellers to confirm shipment within their stated handling time and to respond to return requests within 24 hours. It also points sellers to the Account Health dashboard, which tracks rates for order defects, late shipments, pre-fulfillment cancellations and valid tracking. Amazon sets the targets for these metrics and can change them, so check your own dashboard for current figures.
At low volume, one person with a spreadsheet can hold the process together. At scale, three problems appear:
- The tools are separate. Orders sit in Seller Central, stock in a spreadsheet, purchases in email and chat. Every hand-off is a chance for an order to wait unnoticed.
- There is no evidence trail. When a supplier short-ships or a cost looks wrong, nobody can find the invoice or receiving count that would settle it.
- Nobody owns the gap. Buying thinks the warehouse has stock; the warehouse thinks buying is on it. The order ships late.
The fix is connecting the stages so each one updates the next. (For a broader overview of the same chain, see our guide to running FBM operations without spreadsheets.)
Stage 1: Import orders from Seller Central
Amazon describes its Selling Partner API (SP-API) as "a REST-based API that helps sellers and vendors access their data on orders, shipments, payments, inventory, and other business information." Tools connect through Login with Amazon, Amazon's implementation of OAuth 2.0: the seller reviews a consent page listing the permissions requested and approves it. No password changes hands.
Failure mode: orders are exported twice a day, so anything placed in between waits. Control: orders arrive automatically through an authorized connection, not a shared login.
Stage 2: Decode SKUs into physical demand and see shortfall
An Amazon SKU is not always one item. A bundle might be three units and a multipack six. Before you can say whether an order can ship, translate every open order into physical units per item, then compare that demand with stock on hand.
Anything you cannot fill today is a shortfall. It needs an owner and a decision now: buy, transfer from another location or, as a last resort, cancel early.
Failure mode: shortfall is noticed only when the picker reaches an empty shelf, close to the ship-by deadline. Control: one live view of which orders can ship now and which are waiting, by item and quantity.
Stage 3: Purchase against real demand
Group the shortfall into purchase orders by supplier, so you place one order per supplier instead of ten small ones. Each purchase should record the supplier, cost, quantity and the demand it covers.
Then attach proof: the supplier's invoice and the inbound tracking number. Proof keeps unit costs accurate, settles supplier disputes and means the paperwork exists if a marketplace asks where your goods came from.
Failure mode: two people buy the same item, or nobody buys it. Control: purchases are created from the shortfall itself, so covered demand leaves the list, and each purchase carries its proof.
Stage 4: Receive into the warehouse
Receiving is where most stock errors begin. If someone types a number into a sheet, the mistake flows straight into inventory and then into overselling.
Good receiving uses a checklist on a phone: open the expected purchase, scan or count each item, record damage and flag differences between ordered and received quantities. QR codes tied to the purchase make this faster and harder to get wrong. One delivery can cover several purchase orders, so items must be matched to the right PO.
Failure mode: goods sit uncounted for days while the system still shows them as on order. Control: mobile receiving with QR scanning that updates stock when the count is confirmed and flags variances.
Stage 5: Inventory you can trust
The whole loop runs on accurate stock. It gets harder when an operator holds goods owned by one seller, shared by a team or shared by a branch. Each pool needs clear ownership so one client's units never fill another client's orders.
- Reserve stock for open orders so a unit cannot be promised twice.
- Record transfers as movements, not as edits to a count.
- Keep a movement history so every change has a reason, a time and a person.
Failure mode: counts are "corrected" by overwriting numbers, and nobody can explain why they changed. Control: separate seller-owned, team-shared and branch-shared pools, with every change attributed.
Stage 6: Pick, pack and ship with evidence
Pickers need a clear list, packers need to know what goes in each box, and shipping must produce a label and send tracking to Amazon within the handling time. Batching labels by carrier or service saves time at the bench.
Evidence matters as much as speed. A package photo and the tracking number stored against the order give you something to point to when a buyer says an item never arrived.
Failure mode: labels are bought one by one and tracking is pasted in by hand, so some orders never get valid tracking. Control: label batches, clear picked, packed and shipped statuses, and package evidence on every order.
Stage 7: Review profit and losses
Once an order ships, you should see what it earned: sale price minus product cost, shipping and marketplace fees. Review buying performance too: which suppliers deliver complete orders on time, and at what real cost?
Track losses explicitly: damaged stock, short shipments, refunds and write-offs. An audit history of who changed what turns "we lost money last month" into a list of fixable causes.
Failure mode: profit is calculated quarterly, long after loss-making SKUs have shipped hundreds of times. Control: order economics, buying performance and losses in one view, built from the records you run the operation on.
Running several companies, branches or warehouses
Operators who run several seller accounts or serve clients from shared warehouses need two more things:
- Scoped roles. A packer needs the packing queue, not supplier costs, and a client should see only their own orders and stock.
- Separation between organizations. Each company's data stays isolated, with every change attributed, so shared infrastructure never means shared data.
FBM workflow checklist
| Stage | Common failure mode | Control |
|---|---|---|
| Import orders | Manual exports leave orders waiting | Authorized SP-API connection; automatic import |
| Shortfall | Missing stock found at the shelf | SKUs decoded into units; live shortfall view |
| Purchasing | Duplicate or missing buys; no paperwork | POs created from shortfall; supplier proof attached |
| Receiving | Uncounted goods; typed-in quantities | Mobile checklists; QR receiving; variance flags |
| Inventory | Overwritten counts; mixed ownership | Owned and shared pools; reservations; attributed changes |
| Pick, pack, ship | Late labels; missing tracking | Label batches; clear statuses; package evidence |
| Profit | Losses found months later | Per-order economics; loss tracking; audit history |
Where HutsyBoard fits
We built HutsyBoard by ECOMHUTSY to run this loop in one workspace. It is a marketplace-to-warehouse platform for Amazon FBM and multichannel sellers:
- Amazon SP-API connect through OAuth, never shared passwords. Tokens are encrypted at rest, and you can disconnect at any time.
- Orders and shortfall, turning marketplace orders into physical demand.
- Purchasing that groups purchases, attaches supplier proof and reconciles deliveries.
- Receiving with mobile checklists and QR workflows.
- Inventory pools for seller-owned, team-shared and branch-shared stock.
- FBM fulfillment with label batches, pick, pack and ship with evidence.
- Profit intelligence across order economics, buying performance and losses.
- Separated workspaces for companies, branches, teams and warehouses, with role-based access and every change attributed.
Read the full overview of HutsyBoard, our marketplace-to-warehouse platform, see ECOMHUTSY's security approach, or visit HutsyBoard directly. Software makes the process visible and harder to skip, but it does not replace reliable suppliers or a disciplined team, and it does not promise sales, profit or account-health outcomes.
ECOMHUTSY has worked in e-commerce operations since 2016, has processed $150M+ in e-commerce sales and has a team of 100+ e-commerce professionals. If you are still choosing a model, read about FBA wholesale or FBA vs dropshipping.
Frequently asked questions
What is the difference between FBM and FBA operationally?
With FBA, Amazon stores, picks, packs and ships your products, so your main job is replenishing Amazon's warehouses. With FBM, you run the whole chain: purchasing, receiving, storage, picking, packing, shipping, tracking, customer service and returns.
How do I stop late shipments caused by stock shortfalls?
See shortfall when the order arrives, not at the shelf. Decode each SKU into physical units, compare demand with stock and turn the gap into purchases or transfers the same day. Set a handling time in Seller Central that your process can actually meet.
Is it safe to connect a tool to Seller Central?
Use tools that connect through Amazon's SP-API authorization, where you approve a consent page instead of sharing your password. In HutsyBoard, tokens are encrypted at rest and you can disconnect at any time.
Can one workspace handle multiple seller accounts and warehouses?
Yes, if it separates them properly. HutsyBoard keeps companies, branches, teams, marketplaces and warehouses separated, with role-based access so each person sees only their own work.
See the loop in one workspace
See how HutsyBoard runs this loop in one workspace. Tell us how your orders, purchasing and warehouse work today, and we will show you where the gaps are and whether HutsyBoard fits.
Amazon programs, metrics and policies change. This article reflects publicly available Amazon information as of October 2026. Always check Seller Central for current requirements.
Sources
- Amazon, Fulfilled by Merchant (handling time, returns, Account Health metrics): https://sell.amazon.com/programs/fulfilled-by-merchant
- Amazon Developer Docs, What is the Selling Partner API?: https://developer-docs.amazon/sp-api/docs/what-is-the-selling-partner-api
- Amazon Developer Docs, Authorize public applications (Login with Amazon, OAuth 2.0, consent page): https://developer-docs.amazon/sp-api/docs/authorize-public-applications
