Retail Procurement (RP) in Amazon Vendor Central: End-to-End Workflow (Collect vs Prepaid) + Common Mismatch Points

A practical operations guide for 1P vendors: PO ACK, routing/ASN, appointments, receiving, invoicing, and dispute-ready evidence

In Part 1, we broke down Vendor Central Direct Fulfillment (DF) and why operational success is really about package-level data integrity—PO acknowledgements, labels, tracking, and shipment confirmation forming a reliable chain.

👉 Amazon Vendor Central Operations: The Real“Order Workflow” Behind Direct Fulfillment (DF)

Part 2 shifts to the other dominant operating mode in Amazon Vendor Central: Retail Procurement (RP)—shipping into Amazon’s network (FCs / receiving locations). The key point up front:

RP isn’t“dramatically harder” than DF—it’s evaluated through different proof points.

DF is largely judged through package-level shipment signals. RP is judged through inbound traceability and receiving alignment—especially ASN accuracy, appointment execution, and the documentation trail that makes receiving and reconciliation possible.

This post breaks down the RP workflow end-to-end, then explains the fork that changes how you operate: Collect vs Prepaid.


DF vs RP: Same Backbone, Different “Proof of Completion”

DF and RP share a familiar backbone—PO → ACK → execution → reconciliation—but Amazon evaluates completion differently:

  • Direct Fulfillment (DF): completion is proven through package-level shipment signals, especially
  • PO ACK → label/package details → tracking + shipment confirmation.
  • Retail Procurement (RP): completion is proven through inbound readiness and traceability, typically
  • PO ACK → compliant shipment prep → routing/carrier plan → ASN → appointment/delivery → receiving → invoice/settlement evidence.

This is why running RP with a DF mindset often creates a predictable issue: the freight arrives, but the document chain doesn’t match the physical shipment, and the mismatch surfaces later as receiving friction, reconciliation gaps, or deductions.


RP Backbone: The Step-by-Step Workflow

Think of these steps as your operational index—each step should have clear outputs, ownership, and a defined exception path.

Step 1: Receive the PO (Validate Terms and Windows)

An RP PO is more than items and quantity. Validate:

  • Ship/delivery windows
  • Destination FC/receiving node
  • Freight terms (Collect vs Prepaid)
  • Packaging/carton/pallet requirements (when applicable)

Many downstream issues are simply earlier constraints that weren’t captured in the operating plan.

Step 2: PO Acknowledgement (ACK) = Your Supply Commitment

In RP, PO Acknowledgement is your supply commitment: what you can ship, when you can ship, and whether the PO will be split.

Common mismatch patterns:

  • ACK quantity differs from packed shipment / ASN
  • Split shipments aren’t represented consistently
  • Plan changes occur but are not propagated downstream

A scalable approach is to treat ACK as the upstream “source event” that drives routing, ASN creation, and appointment planning—rather than a standalone task.

Step 3: Shipment Preparation (Compliance Is Cost)

Shipment prep is where downstream cost often begins:

  • Carton/pallet labeling inconsistency
  • Packaging spec drift across facilities
  • Late changes not reflected in the document chain

Operational takeaway: maintain a single system-of-record for carton/pallet specs and label templates, and validate packed shipment totals before submission steps.


The Key Fork: Collect vs Prepaid (What Changes Operationally)

Collect: Routing Request → Reference/Pickup Plan → Carrier Docs → ASN

Under Collect, Amazon arranges pickup/transportation. Your workflow typically includes a routing request step where you provide shipment details (carton count, weight, cube, pickup location and window). Amazon uses this to plan pickup and returns reference/pickup plan information used across the flow.

A typical operational risk is multiple versions of shipment truth:

  • Routing request uses estimated values
  • Warehouse packing generates actual values
  • ASN becomes a third version

Practical sequencing note: after you receive the reference info/pickup plan, teams typically generate or receive carrier docs (labels/tracking/BOL, etc.) and then create the ASN to bind actual packed shipment data to those transport identifiers.

This reduces mismatches that often show up later as appointment/receiving coordination work and reconciliation friction.

Prepaid: Book Carrier → Carrier Docs → ASN (Change Management Matters More Than Day 1 Accuracy)

Under Prepaid, you arrange the carrier and delivery. The workflow can look simpler—until changes happen:

  • Appointment timing shifts
  • Carrier/trailer changes
  • A PO ships in multiple loads
  • Carton/pallet counts adjust after packing

Under Prepaid, once you book the carrier you can generate/receive carrier docs (labels/tracking/BOL). The ASN step is best treated as a binding and pre-advice event, not the moment transport identifiers are created.

Practical guidance: treat “any material change triggers updates to the same source record (plan + carrier docs + ASN linkage)” as a hard rule, with clear auditability.


ASN + Appointment + Receiving: The Second Hard Gate

In RP, ASN is a critical input for appointment planning and receiving. When ASN is incomplete or inconsistent, you may see:

  • Slower appointment progression
  • Delivery timing misalignment relative to windows
  • Receiving mismatches that later appear as shortage/overage narratives

A reliable operating pattern is: lock packed shipment data → generate carrier docs → create ASN, so appointment and receiving operate from a consistent record.

A key truth: you’re not “done” until the shipment is correctly received in Amazon’s records.


Invoicing, Settlement, and Disputes: RP Is an Evidence Chain

Many teams stop thinking after delivery—finance cannot. Month-end is where fragmented artifacts become real cost.

A dispute-ready RP evidence chain typically includes:

PO → ACK → routing/ASN → carrier docs (BOL/tracking, etc.) → appointment/delivery → proof of delivery / receiving records

If those artifacts live in email threads and PDFs without linkage, disputes and reconciliation become slower and more manual. A scalable RP workflow captures and links evidence as part of the process—not after the fact.


RP Workflow Diagram (Copy/Paste Friendly)

Key Takeaways: What to Standardize or Automate First

If you want RP to scale reliably, prioritize:

  1. ACK-to-shipment consistency (commitment, ASN, and physical shipment must align)
  2. One-time document generation (routing + ASN should not be manual copy/paste)
  3. Change management with auditability (carrier/appointment/split-load changes must propagate)
  4. Dispute-ready evidence capture (link PO → ACK → ASN → delivery/receiving artifacts)
隐私概述

本网站使用 cookie,以便我们能够为您提供最佳的用户体验。 Cookie 信息存储在您的浏览器中,并执行一些功能,例如在您返回我们的网站时识别您,并帮助我们的团队了解您认为网站的哪些部分最有趣和最有用。

必要的 Cookie

应始终启用 Strictly Necessary Cookie,以便我们保存您的 Cookie 设置首选项。

第三方 Cookie

本网站使用 Google Analytics 收集匿名信息,例如网站访问者数量和最受欢迎的页面。

保持此 cookie 启用有助于我们改进我们的网站。