How to create and manage B2B purchase orders from shared catalogs
The point of a shared catalog is the order at the end of it. This guide walks the full purchase-order loop: a reseller builds a draft from the products and prices they''re approved to see, submits it, and the vendor takes it from an inbox through acknowledgment to fulfilled — with every question living on the order itself. A fictional reseller and vendor carry the example end to end.
1. Introduction
Throughout this guide we follow a fictional pair: reseller Northline Design Supply ordering three lighting products from vendor Cedar Peak Lighting's shared catalog. All company names, SKUs, quantities, prices, totals, dates, and messages shown are fictional demo data.
The platform side of this workflow is Purchase Orders, working from the reseller's portal.
2. What a catalog-to-purchase-order workflow means
Ordering by emailed spreadsheet means retyped SKUs, stale prices, and a vendor guessing what the reseller meant. A catalog-to-PO workflow removes the retyping: the order is built directly from the catalog the reseller already has access to, at the prices their Catalog Rules produce.
3. Before creating a purchase order
Two prerequisites: the reseller relationship exists (invited directly or approved from the marketplace — the full setup is in the catalog-sharing guide), and the vendor's catalog is assigned and current. Orders are only as good as the catalog behind them — vendors keeping prices and stock fresh (see the updates guide) is what makes the numbers on the order trustworthy.
4. Confirm vendor and catalog access
In the portal, Northline sees the vendors it works with and the catalogs each has granted. What's visible is what's orderable: products excluded by the vendor's rules never appear, and the prices shown are Northline's own approved numbers — not a list price to negotiate down from.
5. Select products from the permitted catalog
Northline browses Cedar Peak's catalog and adds products to the order. Because selection happens inside the permitted catalog, there's no way to order a SKU that was excluded, discontinued out of view, or priced for a different tier — the guardrails are the catalog itself.
6. Review SKU, quantity, and pricing
Each line carries the SKU, the quantity, and the reseller's displayed price:
| SKU (fictional) | Product | Qty | Unit price | Line total |
|---|---|---|---|---|
| CPL-PENDANT-140 | Cedar Peak 14" Pendant | 6 | $118.00 | $708.00 |
| CPL-SCONCE-225 | Cedar Peak 22" Sconce | 4 | $86.00 | $344.00 |
| CPL-CHANDELIER-410 | Cedar Peak 41" Chandelier | 2 | $412.00 | $824.00 |
All quantities and prices fictional. The unit prices are the rule-applied numbers Cedar Peak approved for Northline — the same figures the portal displays.
7. Create the purchase-order draft
The order starts life as a draft: editable, private to the reseller, and not yet visible to the vendor. Drafts are where quantities get adjusted, lines get added and removed, and ship-to details get filled in — nothing is committed until submit.
8. Understand draft autosave
Drafts save themselves as you work — step away mid-order and the draft is waiting when you come back.
Autosave begins once you actually start editing the order — untouched forms don't save noise into your drafts.
9. Use saved customer information where supported
Where saved customer information is supported, ship-to details can be picked from the reseller's customer book instead of retyped per order — and a new ship-to can be saved back to the book while building the order. Repeat destinations become a two-click step instead of a form.
10. Apply a supported promotion code where applicable
Vendors announce promotions through the promotions calendar, and a promotion can carry a code. Where one applies, the reseller references the code on the order so the vendor sees exactly which offer is being claimed. The vendor applies the promotion's terms when processing the order — the code is a reference between the two of you, not an automatic recalculation of the order lines.
11. Review the order total and details
One last read before submitting:
Check the same three things every time: quantities (typos double orders), ship-to (the book makes this fast, not automatic), and any line whose price surprises you — surprises are cheaper to raise before submitting than after.
12. Submit the purchase order
Submitting turns the draft into a real order: it locks its snapshot (section 20), leaves the draft state, and lands with the vendor. From here on, changes go through the vendor — that's what makes the order a dependable record for both sides.
13. What the vendor sees in the vendor inbox
Cedar Peak works from a purchase-order inbox — every incoming order, current status at a glance:
14. Vendor acknowledgment
Acknowledging tells the reseller "we have it and we're working on it." It's the professional heartbeat of the workflow: Northline stops wondering whether the order arrived, and Cedar Peak has a queue that distinguishes seen from unseen work.
15. Vendor denial
Not every order can be accepted — a discontinued line the reseller caught mid-transition, a minimum not met, an account issue. Denying the order closes it cleanly, and the reason belongs in the order thread so the record shows the why alongside the what. A denied order isn't a dead relationship; it's usually followed by a corrected order.
16. Marking the order fulfilled
When Cedar Peak completes the order on its side, it marks the order fulfilled — the workflow's done-state inside InventaCloud.
| Vendor action | What it tells the reseller | Order state |
|---|---|---|
| Acknowledge | We received it and are on it | Open, in progress |
| Deny | We can't accept this order (reason in the thread) | Closed without fulfillment |
| Mark fulfilled | We've completed this order on our side | Done |
Fulfilled is a platform order status — it isn't carrier tracking. It doesn't prove carrier pickup or customer delivery, it doesn't create shipment tracking, and it doesn't reserve inventory. Shipping information or a tracking number may be exchanged as plain text in the purchase-order thread, but InventaCloud does not provide a structured carrier-tracking workflow.
17. Requesting cancellation
Plans change. Cancellation runs through the order workflow rather than a side channel:
Because the request is on the order itself, there's no "didn't see the email" ambiguity about whether cancellation was asked for, or when.
18. Communicating through the purchase-order thread
Every order carries its own conversation thread — questions about this order stay attached to this order:
The thread is scoped to the order — it's not a general team-chat tool, and that's the point: six months later, the carton-pack decision is right there on the order it affected. Broader vendor–reseller messaging lives in Chat & Collaboration.
19. Understanding unread and email notifications
Unread indicators show where new activity is waiting — a new order in the vendor inbox, an unread reply on a thread — and related email notifications reach the other party when something needs their attention, so neither side has to sit inside the app waiting. Treat email as the nudge and the order record as the truth: the order page always shows the current state.
20. Why purchase-order snapshots matter
Catalogs are living things — prices update, products retire. Orders can't be. On submit, the order keeps a durable snapshot of the relevant order data: the products, quantities, and prices as they stood when the order was placed.
Next week Cedar Peak raises the pendant's price, or discontinues the sconce. Northline's submitted order doesn't move — the lines, quantities, and prices stay exactly as ordered, permanently. New orders are built at the new numbers; existing orders are history, not spreadsheets that re-calculate. A snapshot is a record — it doesn't reserve live inventory, and it doesn't push the order into accounting or ecommerce systems.
21. Reviewing the order history and current status
Both sides see the same order, the same status, the same thread:
Where the order list shows history and current status, use it as the single answer to "where does that order stand?" — for every vendor the reseller works with, in one place.
22. Common purchase-order mistakes
"We always order that sconce" fails the week it's discontinued. Build from the live shared catalog, not memory — that's what it's for.
Quantity changes agreed in email don't change the order. Put the question — and the answer — on the PO thread, then adjust through the workflow.
An unacknowledged order reads as an unseen order. Acknowledge fast, even when fulfillment will take a while — the status is the communication.
Quantity typos and wrong ship-tos are painless in a draft and painful after submit. Thirty seconds on the summary panel is the cheapest fix in B2B.
23. Purchase-order checklist
- Vendor relationship active and catalog access confirmed
- Products added from the permitted catalog — never retyped
- Quantities checked (carton packs and minimums included)
- Ship-to picked from saved customers, or saved for next time
- Promotion code referenced where one applies
- Summary reviewed: lines, total, destination
- Submitted — and the snapshot locked
- Vendor side: acknowledged promptly, denied with a reason in the thread when needed
- Questions asked on the PO thread, not in scattered email
- Fulfilled marked when complete; cancellations requested through the order
Common questions
Can the reseller order products the vendor hasn''t shared with them?
No — the order is built from the permitted catalog, so excluded products never appear as options and prices are always the reseller''s own rule-applied numbers. The catalog is the guardrail.
What happens to a submitted order when catalog prices change?
Nothing. Submitted orders keep a durable snapshot of the products, quantities, and prices as ordered. New orders pick up the new prices; existing orders stay exactly as they were placed.
Does marking an order fulfilled include shipment tracking?
No — fulfilled is the order''s done-status inside InventaCloud; it doesn''t prove carrier pickup or delivery. Shipping information or a tracking number may be exchanged as plain text in the purchase-order thread, but InventaCloud does not provide a structured carrier-tracking workflow.
How do we handle a change after the order is submitted?
Raise it on the purchase-order thread so the request is attached to the order, and handle the outcome through the workflow — the vendor can deny an order that can''t proceed, and the reseller can request cancellation. The decision stays on the record either way.
From shared catalog to signed-off order.
Start a 14-day free trial and run your first purchase order through the loop — onboarding call included on every vendor plan.