Automate Amazon Vendor Central purchase orders, with a person on every rejection
Updated · By Ecomsellertool editorial team
To automate Amazon Vendor Central PO acceptance, pull new purchase orders through the Selling Partner API, check each line against available stock, your agreed cost and the ship window, and propose one acknowledgement per line: Accepted, Backordered or Rejected. Full, clean lines go out on their own. Rejections, backorder dates and cost differences wait for a person. Then send the ship notice and match the invoice to what Amazon received.
- This recipe covers Amazon's purchase orders to a 1P brand (Vendor Central), from a new PO to the invoice, not the POs a brand sends its own suppliers.
- Amazon's Vendor Orders API is listed as vendors only; it retrieves purchase orders and accepts or rejects them through submitAcknowledgement (checked October 20, 2026).
- Each acknowledged line carries a code, Accepted, Backordered or Rejected, with a quantity, and a rejection can give a reason such as TemporarilyUnavailable or ObsoleteProduct.
- Amazon's ship notice (ASN) goes through the Vendor Shipments API's SubmitShipmentConfirmations, and invoices through the Vendor Invoices API's submitInvoices.
- In this recipe rules propose every line decision; a person approves rejections, backorder dates, cost differences and anything that could lead to a chargeback.
The step map: who runs each step
Trigger: A new or changed Amazon purchase order in Vendor Central, found by a scheduled pull of the Vendor Orders API; then each shipment and invoice for that PO.
| Step | What happens | Who runs it |
|---|---|---|
| 1 | A scheduled job pulls new and changed purchase orders with getPurchaseOrders, stores every line with its ASIN, vendor SKU, ordered quantity, unit of measure, net cost and ship window, and starts an acknowledgement clock per PO. | Rule |
| 2 | For each line, rules compute available-to-promise units from sellable stock, open reservations, the safety buffer and inbound stock that lands before the ship window, including kit and multipack components. | Rule |
| 3 | Rules match the line to the PO line decision table: full accept, accept part and backorder the rest, accept part and reject the rest, reject with a reason, or hold for a person when the cost, case size or product does not match. | Rule |
| 4 | A planner reviews every proposed rejection, backorder date, cost difference and held line, with the evidence beside it, and approves or changes the decision. | Person |
| 5 | The workflow submits one acknowledgement per PO with every line, records the transactionId and checks it with the Transaction Status API until Amazon reports the result. | Rule |
| 6 | Accepted units are reserved in the warehouse system; when the shipment is packed, the ship notice is sent with SubmitShipmentConfirmations and logged against the PO. | Rule |
| 7 | The invoice is built from what shipped and sent with submitInvoices; later, PO status shows accepted and received quantities, and any gap between confirmed, shipped, received and invoiced units goes to finance. | Rule |
| 8 | Finance decides what to dispute: shortages, cost differences and chargebacks, using the PO, ASN and invoice trail the workflow kept. | Person |
6 rule steps · 0 AI model steps · 2 person steps. A rule follows fixed logic you approve; an AI model handles messy input and its output is checked by rules; a person makes the calls listed below.
What stays with a person
- Rejecting a line or part of a line, and the reason sent with it
- Backorder ship or delivery dates that Amazon will plan on
- PO cost that differs from your agreed cost, and whether to raise it with your vendor manager
- Lines held for a product, case-size or vendor-code mismatch
- Disputing shortages, deductions and chargebacks
Which tools can run it
- Vendor Central by hand, for a few POs a week and a short catalog
- An EDI provider, if you already trade with Amazon over EDI, with your own rules sheet deciding each line
- Zapier, Make or n8n calling the Selling Partner API, for steady volume and a small number of exceptions
- Custom code on your accounts, for many POs, kits or several warehouses, with stock reservations and invoice matching in one place
Systems it connects
- Amazon Vendor Central
- SP-API Vendor Orders, Shipments and Invoices APIs
- Inventory or warehouse system (stock and reservations)
- ERP or item master (SKUs, case sizes, agreed costs)
- Accounting system (invoices and deductions)
- Slack or email for approvals
Build size: Medium
The API calls are simple; the work is an honest available-to-promise number per line and keeping one trail from PO to invoice.
When you sell to Amazon as a vendor, Amazon is your biggest wholesale customer and its purchase orders arrive on its schedule, not yours. Each one has to be answered line by line: how many units you will ship, when, and which you cannot. Done by hand, this means a planner copying POs into a sheet, checking stock in another system and typing answers into Vendor Central before the window closes. This recipe automates that work for a 1P brand, from a new PO to the invoice. It is one page of our automation library.
It is the mirror image of our supplier PO acknowledgement and ETA tracking recipe. There, you are the buyer chasing your suppliers. Here, Amazon is the buyer and you are the one acknowledging.
How should each line of an Amazon purchase order be decided?
This table is the core of the build, and you can run it from a spreadsheet today. Each row is a situation a PO line can be in, the acknowledgement it leads to, the rule that picks it, who decides and what it changes downstream. The codes and rejection reasons are the ones in Amazon's submitAcknowledgement reference; the isBackOrderAllowed, isPOChanged and cancelled-item fields come from the getPurchaseOrders reference (both checked October 20, 2026). Thresholds are yours to set.
| Situation on the line | Acknowledgement | Rule that drives it | Who decides | Downstream effect |
|---|---|---|---|---|
| Available-to-promise covers the full quantity, the PO cost matches your agreed cost, the ship window is reachable | Accepted, full quantity, with a scheduled ship date inside the window | ATP ≥ ordered units, cost within your tolerance, warehouse can ship by the window's end | Rule; nobody | Units reserved for this PO; the ship notice and invoice follow |
| Part of the quantity is on hand, the rest lands inside a date you can commit to, and the line allows backorders | Accepted for the units on hand, Backordered for the rest with a new scheduled ship date | isBackOrderAllowed is true and a confirmed inbound covers the remainder | Rule proposes; planner confirms the date | Amazon plans on the date you send, so it must be one the warehouse will meet |
| Part is on hand, the rest will not arrive in time or backorders are not allowed | Accepted for the units on hand, Rejected for the rest with TemporarilyUnavailable | ATP below ordered units and no qualifying inbound | Planner approves the rejected units | Fewer units confirmed than ordered; shows up in your confirmation rate |
| Nothing on hand, replenishment due after the window | Backordered if allowed and the date is firm, otherwise Rejected with TemporarilyUnavailable | ATP is zero; inbound ETA compared with the window | Planner | A missed line here is a stockout on Amazon's shelf later; see stockouts |
| The ASIN or vendor SKU is not in your item master | Hold; then Rejected with InvalidProductIdentifier only if the product is truly not yours | No match on ASIN or vendor product identifier | Person checks for a mapping error first | Fix the item master so the next PO matches |
| The product is discontinued | Rejected with ObsoleteProduct | SKU marked discontinued in your item master | Planner | Tell your vendor manager and update the catalog so Amazon stops ordering it |
| The PO's net cost differs from your agreed cost | Hold | Line cost outside your tolerance, per unit and currency | Person: accept, or raise it with your vendor manager | Accepting the line at the wrong cost carries into the invoice and payment |
| Ordered in cases and the case size differs from yours | Hold | unitOfMeasure is Cases and unitSize differs from the item master | Person | A wrong case size multiplies every downstream quantity |
| Amazon changed the PO after placing it | Re-run every row above on the updated order | isPOChanged is true | Same as the row it lands in | Amazon's docs say vendors must fulfill the updated order, not the original |
| Amazon cancelled an item | No new acknowledgement; release the reservation | poItemState is Cancelled, quantity now zero | Rule | Units go back to available-to-promise for the next PO |
| A rush order you cannot meet | Hold | purchaseOrderType is RushOrder and the window is shorter than your pick-and-ship time | Planner | Decide before the clock runs out, not after |
The rule behind most rows is one number per line. Measure it the same way every time:
Available to promise = sellable units on hand − units reserved for open POs and other channels − safety buffer + confirmed inbound units that land before the ship window starts
For kits and multipacks, compute it from the parts: the lowest result of (component units available ÷ units of that component per kit), rounded down. A two-pack can sell out while single units sit on the shelf, and a kit is only available if every component is. The days of cover and safety stock entries explain the buffer side.
One measure we suggest you track yourself, not an Amazon metric: confirmation rate, accepted units divided by ordered units, per week and per ASIN. It tells you whether rejections come from a few ASINs or from planning in general.
What does Amazon's Vendor Orders API let you automate?
The pulling and the answering. Amazon's Vendor Orders API overview lists it as vendors only, with operations to retrieve purchase orders, get one PO's details, get PO status and submit acknowledgements that accept or reject fulfillment (checked October 20, 2026). It is part of the Selling Partner API, so the same app registration and roles cover the shipment and invoice steps.
The getPurchaseOrders reference sets the limits a scheduler has to respect: a date range of no more than 7 days per call, data for the past 6 months, up to 100 orders per page with a token for the next page, and a filter for orders in the New state, which it describes as needing the vendor's acknowledgement. Each line carries the ASIN, your vendor product identifier, the ordered quantity in cases or eaches and the net cost. The order also carries a ship window and a delivery window.
An acknowledgement covers one PO and lists its lines. Each line holds a list of item acknowledgements, each with a code, a quantity and optional scheduled ship and delivery dates, which is how the split rows in the table are expressed. The reference says an acknowledged quantity should not be zero. Amazon answers with a transactionId, and the Transaction Status API (checked October 20, 2026) tells you whether it went through. A workflow that never checks the transaction can believe it answered a PO that Amazon never accepted.
What happens after the PO is accepted?
Three more documents, and each one has to agree with the one before. The Vendor Shipments API includes SubmitShipmentConfirmations, which its overview describes as submitting Advance Shipment Notifications (ASNs) to Amazon. The Vendor Invoices API has one operation, submitInvoices, for invoices on shipped items and credit notes for returns, pricing corrections and allowances. Its submitInvoices reference makes the PO number mandatory on an invoice (all checked October 20, 2026).
The getPurchaseOrdersStatus reference (checked October 20, 2026) closes the loop. Per line it reports accepted and rejected quantities, a confirmation status (accepted, partially accepted, rejected or unconfirmed), and the received quantity with the last receive date. That gives a rule everything it needs to keep one row per PO line:
| Ordered | Accepted | Shipped (ASN) | Received by Amazon | Invoiced | What the rule does |
|---|---|---|---|---|---|
| 120 | 120 | 120 | 120 | 120 | Closes the line |
| 120 | 80 | 80 | 80 | 80 | Closes the line; the 40 rejected units count in your confirmation rate |
| 120 | 120 | 120 | 108 | 120 | Flags 12 units to finance with the ASN and carrier proof |
| 120 | 120 | 96 | 96 | 120 | Flags an invoice for more than shipped, before Amazon does |
The numbers are illustrative, not client data. The point is that every gap has an owner the day it appears, while the paperwork is still easy to find.
What should stay with a person?
Anything that tells Amazon you will not deliver, or that touches money. Rejections and their reasons, backorder dates Amazon will plan on, cost differences, case-size and product mismatches, and every dispute over shortages, deductions or chargebacks stay with your team. Amazon's own deadlines, scorecards and chargeback rules sit in Vendor Central help behind the login, and they differ by agreement, so we do not quote them here. Put yours into the rules sheet, set alerts well before each deadline, and let the workflow show the planner the stock, dates and costs behind every proposal.
Which tool should run it?
| Level | Fits when | What to know |
|---|---|---|
| Vendor Central by hand | A few POs a week, a short catalog | The decision table still helps as a checklist |
| An EDI provider | You already trade with Amazon over EDI | X12 has the 850 purchase order, 855 acknowledgment, 856 ship notice and 810 invoice (checked October 20, 2026); the provider moves messages, your rules still decide each line |
| Zapier, Make or n8n calling the Selling Partner API | Steady volume, few kits, one warehouse | Our Zapier vs Make vs n8n comparison covers the trade-offs; log every transactionId |
| Custom code on your accounts | Many POs, kits and multipacks, several warehouses, invoice matching | Can run on Ecomsellertool Growth OS beside inventory and replenishment |
If Amazon stops buying and you move to Seller Central, our 1P to 3P transition checklist covers what changes. If other wholesale buyers send you orders by email or PDF, the B2B order entry from email recipe handles those.
Who builds this for vendor brands?
Ecomsellertool builds purchase order workflows like this on your own accounts and systems. We have built software on Amazon's seller APIs since 2017 and shipped 50+ tools for 100+ teams. We start with your item master, your stock locations and how your planners decide today, then turn those decisions into the rules sheet, the approvals and the API calls. Send a project brief below, or read how our workflow automation service works.
The building blocks are work we have shipped:
- Rules with limits and a log. For TRAKTOR we built rule-based automation for Amazon ad budgets: each rule has criteria, a lookback window, a run frequency and minimum and maximum limits, and an action log records every change with the old and new values. The PO decision table works the same way.
- Kits, multipacks and components. For Cheddy we built stock management for Amazon sellers whose kits, multipacks and single-pack ASINs map to warehouse components, the mapping that available-to-promise for a kit depends on.
You keep your accounts, your data and the custom code we build; the Growth OS base is licensed to you.
Get this workflow built
Send us your version of this workflow
Describe the workflow you want automated. We reply with a written plan: scope, timeline and a fixed price.
Frequently asked questions
Can I automate accepting Amazon Vendor Central purchase orders?
Yes. Amazon's Vendor Orders API lets a vendor pull purchase orders and send acknowledgements. A workflow can check each line against stock, cost and the ship window and send clean full accepts on its own, while a person approves rejections, backorder dates and anything with a cost difference.
What do Accepted, Backordered and Rejected mean in a Vendor Central acknowledgement?
They are the three codes the Vendor Orders API accepts per line. Accepted means you will fulfill the quantity. Backordered means you will fulfill it with a scheduled ship or delivery date different from the PO's expected date. Rejected means you will not fulfill it, optionally with a reason such as TemporarilyUnavailable, InvalidProductIdentifier or ObsoleteProduct.
Can I accept part of a line on an Amazon PO?
The API schema gives each line a list of item acknowledgements, each with its own code and quantity, so one line can be split, for example into accepted and backordered units. Backorders only make sense when the PO line allows them. Test the split in Amazon's sandbox and confirm it in Vendor Central before you rely on it.
How fast do I have to acknowledge an Amazon purchase order?
Use the deadline in your own Vendor Central help pages and vendor terms. Those pages sit behind the Vendor Central login, so we do not quote a deadline here. Whatever it is, set the workflow's alert well before it, so a held line reaches a planner while there is still time to decide.
Should the workflow reject PO lines on its own?
No. A rejection changes what Amazon expects from you and can affect how it orders later, so the workflow proposes the rejection with the stock and dates behind it, and a planner approves it. Full accepts of clean lines are the safe part to run without a person.
How do I match Amazon's payments to what I shipped?
Keep one trail per PO line: units ordered, accepted, shipped on the ASN, received by Amazon and invoiced. The Vendor Orders API reports accepted and received quantities per line, so a rule can flag any gap. Finance then decides which shortages, cost differences or deductions to dispute.
