A triage sheet for Amazon Vendor purchase orders

The problem

Vetting Vendor POs by hand, line by line

The brand already had an internal sales management system that collected sales, inventory and advertising data from every marketplace. But vetting Amazon Vendor purchase orders still sat outside it and still ate hours of the team’s time.

• Vetting Vendor POs

  • Amazon Vendor Central sends purchase orders that the team has to accept or reject, line by line, before a deadline.
  • Each decision needed data from four places: the matching SellerCloud order, the kit’s components, box quantity and relabel rules, and stock in two warehouses.
  • Several POs often wanted the same stock, and nobody could see that at a glance.

How it works

One export in, one filled-in sheet out

The buyer uploads the purchase-order export from Amazon Vendor Central exactly as downloaded. The system reads PO number, ship-to location, ASIN, SKU, accepted quantity, unit cost and the ship window. The window dates come in two date formats depending on how the export was saved, and the parser handles both. Then it fills in each line from four sources:

1. SellerCloud orderPulls the last 31 days of Vendor Central orders from SellerCloud and matches each PO to its SellerCloud order number, so the buyer can jump straight to the order.
2. Kit and packing rulesAdds the parent SKU, kit components with quantities, units per box and whether the item needs relabelling, all from the kit templates the warehouse maintains.
3. Live bin stockAdds on-hand quantity per warehouse from bin exports that a scheduled job downloads from the SellerCloud portal. The job runs only on the automation worker and reads its credentials from that machine’s environment configuration, never from code.
4. Fallback inventoryIf a SKU has no bin data, the system uses the daily warehouse inventory snapshot. It checks the SKU itself first, then its “shadow-of” parent, then the kit’s parent SKU.

The sheet the buyer gets back

• SC#
• Ship To
• PO#
• ASIN
• External ID
• Parent
• Expected Qty
• Per Box
• Total Qty
• Warehouse A
• Warehouse B
• Status
• Accept
• Relabel?
• Kit Components
• Ship Window
• Unit Cost

Deciding which POs the stock can cover

The hardest part was POs competing for the same stock. Checking each PO alone against inventory says every PO can ship, and that’s how orders get over-accepted. Instead, the system groups lines by parent SKU and sorts that SKU’s POs from smallest to largest. It keeps a running total and compares it with combined stock in both warehouses. A PO gets Have Stock only if it still fits after every smaller PO for the same SKU. Filling the small POs first means stock covers as many POs as possible.

The Accept column is left blank on purpose. The sheet gathers the facts, and the buyer still makes every call.

Engineering decisions

Why it’s built this way

Outcome

What changed for the team

• Vendor PO decisions start from one sheet with the SellerCloud order, kit, packing and two-warehouse stock data already filled in.
• The stock check stops the team accepting POs that together need more stock than the warehouses hold.
• Warehouse bin data now refreshes on a schedule, without anyone logging in to export it.