Documentation Index

Fetch the complete documentation index at: https://docs.kibocommerce.com/llms.txt

Use this file to discover all available pages before exploring further.

Expand your assortment by onboarding third-party vendors who ship customer orders directly — without holding inventory.

​

Kibo Commerce Conceptual Guide: Dropship

​

1. Strategic Overview

Concept Definition Dropship is the Kibo Commerce capability that lets operators expand their assortment by routing customer orders directly to onboarded third-party vendors who ship to the end customer — without the operator holding the inventory. Business Context Dropship is delivered as a native, pre-integrated module on the Kibo platform. It adds dedicated vendor management capabilities to the existing Operator Portal (Kibo Admin) — invitation, document review, item mapping, and contract pricing — and introduces a new Vendor Portal where third-party suppliers self-onboard, configure their fulfillment locations, and process the orders routed to them. Value Drivers

1. Catalog Expansion Without Inventory Risk: The platform allows operators to widen their assortment with additional SKUs sourced from third-party vendors and shipped directly to the customer, with zero upfront inventory investment, while preserving fulfillment quality through the same Kibo order management system that handles owned-inventory orders.
2. Native, Pre-Integrated Platform Capability: Dropship runs on the same data model, order routing engine, inventory service, and pricing and promotions services as the rest of the Kibo platform. This removes the lag, reconciliation errors, and integration overhead that come with stitching together a separate dropship system, and lowers the total cost of ownership and time-to-market for the merchant.
3. Predictable, Auditable Vendor Operations: A configurable onboarding journey, document review workflow with operator-vendor communication, item mapping with contract pricing, and a deterministic two-step fulfillment workflow combine with SLA indicators, capacity limits, and an immutable activity log to deliver consistent, auditable execution across a heterogeneous vendor network.

Scope Statement

• In Scope: Platform prerequisites, the two-portal model, the vendor lifecycle and onboarding stepper, document verification, item mapping with contracted pricing, vendor roles, the Locations module (operating hours, cut off times, override hours, attributes), the Order Module, the two-step Fulfillment Workflow, the Order Details page, and the EDI message set used in Dropship integrations.
• Explicitly Excluded: API endpoint specifications, JSON payloads, UI step-by-step walkthroughs, screenshots, the Kibo Admin order routing engine internals, Kibo Admin shipment creation logic, EDI Orderful platform configuration, payment or refund processing, and theme-level customization.

​

2. Core Concepts Explained

​

What is Dropship?

Dropship in Kibo is a vendor enablement and fulfillment capability that operates across two surfaces. The Operator Portal — the existing Kibo Admin — gains dedicated vendor management, document review, item mapping, and contract pricing screens. The Vendor Portal is a separate, vendor-facing interface where each vendor self-onboards, configures fulfillment locations, and processes the orders routed to them. An order travels through the system as follows. A customer places an order on the operator’s storefront. The Kibo order routing engine evaluates eligible locations — including the operator’s owned locations and the dropship vendors’ locations — against the configured routing strategy, operating hours, cut-offs, attributes, and capacity limits, and creates a shipment for each fulfillment node selected. A shipment assigned to a dropship vendor’s location appears in that vendor’s Order Module as an incoming order. The vendor-facing PO Number on this order corresponds to the operator’s Kibo Admin shipment number, so the same record can be tracked from both sides throughout fulfillment. The vendor then runs the order through the two-step Dropship fulfillment workflow — Order Acknowledgement (Step 1) and Prepare Shipments / ASN (Step 2) — and the operator sees real-time progress on the corresponding shipment in Kibo Admin.

​

Why does Dropship matter?

1. Operational Benefits: The onboarding document set is configurable on the operator side (titles, required vs. optional), and review combines automated checks with manual oversight and an in-app comment thread, so vendors can be brought live without out-of-band email exchanges. Dropship vendor locations participate in the same order routing engine, inventory service, and SLA framework as owned locations — eliminating the need to operate or reconcile a parallel dropship system.
2. Financial Benefits: Contracted pricing on every item mapping ensures vendor invoices reflect the negotiated cost rather than the storefront selling price. Capacity Limits per location act as a guardrail against overcommitment. SLA Status indicators (On Time, At Risk, Overdue) make the cost of late fulfillment visible at the order list level. Because Dropship is delivered as a native module on the Kibo stack, the merchant avoids the integration and licensing overhead of a separate dropship platform, reducing total cost of ownership.
3. Customer Experience Benefits: A unified routing engine over owned and third-party inventory provides consistent availability and delivery promises regardless of which node ships the order. The deterministic two-step workflow, partial-fulfillment branching, multi-package shipments with per-slip tracking, and the audit log behind every workflow transition combine to deliver consistent, traceable fulfillment across a heterogeneous vendor network.

​

When to deploy Dropship?

Dropship is typically deployed in one of two scenarios:

1. Catalog Expansion as an Add-On: A merchant already on Kibo Commerce and / or Kibo OMS wants to drive incremental revenue by expanding the assortment without growing inventory exposure. Dropship is implemented from scratch as an additive module on the existing platform, leveraging the same data model, routing engine, and inventory service.
2. System Consolidation or Replacement: A merchant is conducting a broader business transformation and consolidating or replacing operational systems. Dropship is adopted alongside an OMS or commerce replacement, eliminating a separate dropship platform and the integration overhead of stitching it to the rest of the stack.
3. Maturity Requirements: The DropShipEnabled tenant attribute is enabled by Kibo support; the operator creates a dedicated dropship location group and assigns the dropship fulfillment workflow to it; the operator’s catalog must include the UPCs that vendors will be mapped to. A vendor reaches Active status as soon as at least one Item Mapping exists and a Primary Contact phone number is on record.

​

The Dropship Vendor Lifecycle

Every Dropship vendor follows the same four-stage lifecycle, regardless of integration mode:

1. Invitation: The operator creates a vendor record by entering a Vendor Name, an invitation email address, and the vendor type (currently restricted to Dropship). Duplicate names or email addresses throw an error before the invitation is sent.
2. Onboarding In Progress: After the invited user registers, the vendor enters this state and works through the four-step onboarding stepper. Operators can review documents and map items in parallel.
3. Active: The operator flips the status to Active from the Overview tab once the activation requirements are met. The Vendor Portal displays an Active chip and orders begin to flow.
4. Inactive: The operator can set the status back to inactive at any time. Inactive vendors stop receiving routed orders.

​

3. Functional Components & Configuration Deep Dive

​

Component Architecture

The Dropship system is composed of four interconnected components:

1. Platform Foundation: The DropShipEnabled tenant attribute and the dedicated dropship location group, with the dropship fulfillment workflow assigned to that group. These prerequisites activate the Dropship module in Kibo Admin and route shipments destined for vendor locations into the correct two-step fulfillment sequence.
2. Operator Portal — Vendor Module: The vendor module inside Kibo Admin, comprising the vendor listing, the Invite New Vendor flow, and the per-vendor record with three tabs: Overview (vendor information and status control), Documents (per-document approval or rejection with reasons), and Item Mapping (UPC, Vendor SKU, Contracted Price).
3. Vendor Portal: A separate vendor-facing interface with three modules: Onboarding (a four-step stepper covering Basic Corporate Information, Add Users, Business Verification, and Integration Setup), Locations (four tabs covering Location, Hours, Cut Off Times, and Attributes), and Orders (summary cards, list, fulfillment workflow, and order details).
4. Fulfillment Workflow: A deterministic two-step sequence applied to every Dropship order — Step 1 (Order Acknowledgement and stock validation, with partial-fulfillment branching) and Step 2 (Prepare Shipments / ASN, packing slips, tracking, and invoice generation).

​

Configuration-Level Deep Dive

​

Vendor Invitation Fields (Operator Portal)

​

Onboarding Step 1 — Basic Corporate Information

The vendor captures three groups of information in this step: Company Information (Company Name, Legal Business Name, Tax ID/EIN, Business Type, Website, Company Description, Founded Year, Number of Employees range), Business Address (Street Address, City, State/Province, ZIP/Postal Code, Country), and Contact Information (Primary Contact Name, Primary Contact Email, Primary Contact Phone, Billing Email, Support Email). The Primary Contact Phone is mandatory for operator-side activation — without it, the vendor cannot be marked Active. The email used during invitation is non-editable on the registration screen.

​

Onboarding Step 2 — Add Users (Optional)

This step is optional; the vendor may proceed without inviting any users. To invite a user the vendor selects a role — Vendor Admin or Vendor User — and provides First Name, Last Name, Email Address, and an optional Company affiliation. The roles differ as follows:

• Vendor Admin: Full administrative access to all vendor portal functions — manage all products and orders, access financial reports, manage team members and permissions, and configure integrations and settings.
• Vendor User: Limited access to manage daily vendor operations — view and manage products, process orders, view reports. No access to team management or settings, and cannot invite other users.

Invited users appear with a Pending status until they accept; once they register, the status flips to Active.

​

Onboarding Step 3 — Business Verification Documents

The Business Verification step displays a configurable set of documents that the operator defines on the Operator Portal. Each document type is configured with its title and a Required or Optional flag, and the configured set is what the vendor sees on their onboarding journey. Each uploaded document moves through Not Uploaded → Pending Review → Approved or Rejected, with a 5 MB upload cap. Operator rejection requires a free-text comment of at least 10 characters; that comment is surfaced to the vendor in red below the document title, and the upload control is re-enabled so the vendor can replace the file. The Vendor Portal also surfaces a top-of-page “Action Required — View details” link whenever any document is in Rejected state.

​

Onboarding Step 4 — Integration Setup Modes

A vendor may continue to use the Vendor Portal even after selecting EDI or API; the manual portal remains accessible. After completing this step, the vendor sees a “You’re all set!” summary with Integration Type, team members added, documents uploaded, and Verification Status, plus a “Go to Orders” call-to-action.

​

Item Mapping & Contracted Pricing (Operator Portal)

Item Mapping is performed entirely on the operator side and is a mandatory prerequisite for vendor activation — at least one mapping must exist before the operator can flip the vendor status to Active.

​

Locations — Basic Information, Address, and Contact

A vendor location captures three groups of fields in the Location tab. Basic Information includes Location Type (dropdown configured by the Kibo Admin or operator), Status (Active / Inactive), Name, Code, and an optional Description. The Code must be unique per Kibo client (not just per vendor) because the location is mirrored into Kibo Admin — attempting to create a location with a code already in use by another vendor returns a duplicate error, and the operator can later edit any location field except the code. The Duplicate action on a location pre-populates all fields, appends “Copy” to the Name, and leaves the Code blank for the vendor to set fresh. Contact Information includes Shipping Origin Contact (the company-name display surfaced on shipping documents), Phone Number, Email, secondary Phone, and Notes — all optional except the Shipping Origin Contact. The Address group includes Address Type (Commercial / Residential), Address Lines 1 and 2, City, State/Province, Postal/ZIP Code, Country, Latitude and Longitude (used by routing logic for proximity calculations), and an optional Fax.

​

Location — Fulfillment Settings

​

Operating Hours and Fulfillment Cut Off Times

The Hours and Cut Off Times tabs share the same configuration model, both feeding order routing and EDD calculation. The Cut Off Times tab additionally supports holiday or maintenance overrides. A Quick Setup helper at the top of each tab (Weekdays / Weekends / All Days × Custom hours / 24x7 / Closed) lets the vendor bulk-apply a configuration to a day set without touching each day individually.

​

Order Details Page

The Order Details page is the canonical record of an order from acknowledgement through completion. The page header shows the Order ID and placement timestamp, with top-right action buttons for Cancel Order, Download Invoice (disabled until generated), and Start Fulfillment. The summary block surfaces Status, PO Number (the Kibo Admin shipment number — the vendor-side PO Number corresponds to the operator’s shipment number), Shipping Method, and Shipping Cost. Customer and Vendor sections list contact details and addresses. The page exposes the following tabs:

• Order Items: Product (image + name + SKU), Price (unit), Qty, Discount, Item Adjustment, Total. The Price is the contract price, not the storefront selling price. Below the table, a price breakdown lists Subtotal, Total Discounts, Total Adjustments, and Total.
• Canceled Items: Conditional — appears only when at least one item was canceled during the order’s lifecycle, with a count badge. Columns: Product, Qty Canceled (in red), Cancellation Reason. For products where the reason was “Other”, the primary line displays “Other” and a secondary line displays the custom reason text the vendor entered.
• Shipping: Tracking Information section showing carrier name with icon, delivery-status badge, tracking number, and a Track Package link per packing slip.
• Activity: Order Activity timeline in reverse-chronological order. For a completed order the timeline includes (newest to oldest) Order completed, Invoice generated, Order shipped, ASN created, Fulfillment started, Order acknowledged, and Order created.
• Invoice: Invoice Preview with a Download Invoice button — shows the INVOICE header, Kibo company details, invoice metadata (Invoice #, Order #, Date, Due Date, PO #), Bill To, Ship To, line items, and totals (Subtotal, Shipping, Tax, Duty, Total).

​

Vendor Settings & Activation Mechanics

The Vendor Settings block on the Overview tab is where the operator changes the vendor status. Two conditions must be satisfied before flipping to Active: at least one Item Mapping must exist, and a Primary Contact phone number must be on record. The dropship location group with its workflow assignment must also exist, or vendor fulfillment will not route correctly.

​

4. Key Capabilities and Business Applications

​

Capability: Self-Service Vendor Onboarding via a Configurable Stepper

Functional Explanation: The platform guides a newly invited vendor through a four-step sequence — Basic Corporate Information, Add Users, Business Verification, and Integration Setup — with the right rail showing real-time completion progress and required-step indicators. The Business Verification document set is itself configurable from the Operator Portal: the operator defines each document’s title and whether it is Required or Optional, and the configured set is what the vendor sees on their onboarding journey. Operator review combines automated checks with manual oversight; rejected documents carry a free-text comment back to the vendor (surfaced in red on the onboarding screen) with the upload control re-enabled so the file can be replaced. The vendor can build out locations and explore the Orders module while document review remains in progress, eliminating the typical onboarding bottleneck where a vendor must wait for full approval before doing any work. Business Application Example:

• Industry: Marketplace Operator
• Scenario: A multi-vendor home-goods marketplace is expanding its merchant network and needs to bring 30 new vendors live in a quarter without dedicating a customer success manager to each. The operator configures the document set required for its compliance program, invites each vendor by email, and each vendor walks through the four-step stepper at its own pace. Because vendors can build out locations and acknowledge their integration mode in parallel with the operator’s document review, calendar time to first-order-fulfilled drops substantially compared to a fully sequential review process, allowing the operator to scale the partner base without scaling its onboarding team.

​

Capability: Item Mapping with Contracted Pricing

Functional Explanation: Item Mapping is performed entirely on the operator side and bridges the operator’s catalog UPCs to vendor SKUs while simultaneously capturing the contract-level cost in the Contracted Price field. The mapping gates vendor activation: an operator cannot mark a vendor Active until at least one mapping exists. The contracted price drives the price displayed on vendor-facing order items and on the invoice — distinct from the storefront selling price the customer sees. Business Application Example:

• Industry: Enterprise Electronics Retailer
• Scenario: An electronics retailer offers a vendor’s smart-lock line at a public selling price of $199, but the negotiated cost from the vendor is $90 per unit. The operator maps the operator UPC to the vendor’s SKU “RL-CHAIR-001” with a contracted price of $90.00. When an order for two units is routed to the vendor, the vendor sees a unit price of $90 and an order total of $180 on the order item record and on the resulting invoice, ensuring financial accuracy on the vendor’s side without exposing the storefront markup.

​

Capability: Unified Routing Across Owned and Third-Party Inventory

Functional Explanation: Dropship vendor locations are exposed to the same Kibo order routing engine that handles owned-inventory locations. The routing engine evaluates a unified set of factors — proximity, operating hours, cut-off times, capacity limits, and attributes flagged for routing — without distinguishing between owned and vendor nodes, so the same routing scenario, sort strategy, and assignment preference apply to dropship and non-dropship orders alike. Item Mapping ensures that the operator’s catalog UPC and the vendor’s SKU resolve to the same physical product for inventory and routing purposes. Business Application Example:

• Industry: B2B Industrial Distributor
• Scenario: A distributor of MRO supplies operates six owned warehouses and a network of 25 specialty dropship vendors. A customer order for an industrial pump arrives. The routing engine evaluates all 31 nodes against a single sort strategy — proximity to the customer, remaining daily capacity, and on-time SLA performance — and selects a vendor 80 miles from the customer with available stock and capacity over a more distant owned warehouse. Customers receive faster delivery, owned-inventory capacity is preserved for SKUs not available from vendors, and the operator avoids running and reconciling a parallel routing system for dropship.

​

Capability: Two-Step Fulfillment Workflow with Partial-Fulfillment Branching

Functional Explanation: Every Dropship order flows through a mandatory two-step workflow: Order Acknowledgement (Step 1) and Prepare Shipments / ASN (Step 2). In Step 1, the vendor validates stock against the original order quantities. If any quantity is reduced, the row is highlighted yellow, a banner indicates the partial-fulfillment count, and on confirmation the system creates a separate Canceled order containing the unfulfilled units with their reasons; the original order continues to Step 2 with only the fulfilled quantities. Reason capture supports an Apply-to-all dropdown, per-product overrides, a defined catalog of reasons, and a free-text “Other” option capped at 250 characters. Business Application Example:

• Industry: Direct-to-Consumer (DTC) Brand
• Scenario: A DTC home-fragrance brand’s vendor receives an order for four units of a single SKU but discovers during pick that one unit is damaged. The vendor reduces Validate Stock to 3, the row turns yellow, and on acknowledgement the partial-fulfillment popup surfaces. The vendor selects “Damaged Or Defective Item” for the unfulfilled unit and confirms. The system creates a one-unit Canceled order with the recorded reason, the original three-unit order proceeds to Step 2, and the audit trail captures both the cancellation and the workflow advancement, letting the operator’s reporting later quantify damage-driven cancellations across the vendor base.

​

​

5. Platform Integration Map

​

Upstream Dependencies

1. DropShipEnabled Tenant Attribute: Without this attribute, the vendor module does not appear in Kibo Admin. Kibo support enables it on request.
2. Dedicated Dropship Location Group with Workflow Assignment: The operator must create a location group reserved for dropship locations and assign the dropship fulfillment workflow to it. Without this assignment, vendor shipments will not enter the Order Acknowledgement → ASN sequence.
3. Operator Catalog with UPCs: Item Mapping requires operator-side UPCs to bind vendor SKUs to. The operator’s catalog must therefore exist before mappings can be created..

​

Downstream Impacts

1. Order Routing: Vendor location hours, cut-off times, override hours, capacity limits, and routing-flagged attributes feed the routing engine that selects the fulfillment node for each order.
2. Order Lifecycle: Dropship orders flow through the dedicated two-step fulfillment workflow rather than the standard fulfillment path, generating activity-log entries at every transition.
3. Customer Tracking Experience: Per-package tracking numbers entered in Step 2 propagate to the Shipping tab and become the source of truth for the customer-facing shipment record.

​

Synergistic Features

1. Dropship + Order Routing: Vendor location attributes, time-zone-scoped operating hours, cut-off times, and override hours provide the routing engine with a rich, vendor-specific data set, so the same routing scenarios, sort strategies, and assignment preferences apply uniformly to owned and dropship locations.
2. Dropship + Fulfillment SLAs: The SLA Status indicators (On Time, At Risk, Overdue) on each Dropship order draw thresholds from the platform’s Fulfillment SLA framework, exposing late-fulfillment risk at the order list level with the same threshold-based visibility as for owned-inventory orders.
3. Dropship + Item Mapping & Contracted Pricing: Combining the two produces accurate vendor invoices automatically at the end of every order, eliminating manual reconciliation between operator selling price and vendor cost.
4. Dropship + EDI Message Set (850 / 855 / 856 / 846): For high-volume vendors, EDI integration combined with the structured two-step workflow yields fully automated purchase-order, acknowledgement, ASN, and inventory exchange while preserving the same vendor lifecycle and audit log used by manual vendors.

​

6. Related Conceptual Guides

For foundational knowledge, refer to:

1. Locations & Location Groups: A grasp of how location groups and fulfillment workflow assignments operate is a prerequisite, since the dropship location group and workflow assignment are part of the platform setup.
2. Catalog & Product Attributes: Item Mapping requires that the operator’s catalog exist with UPCs for vendor SKUs to be mapped against; a foundational catalog is therefore a hard prerequisite.

To understand downstream impacts, refer to:

1. Order Routing: Vendor location attributes, hours, cut-offs, and capacity limits feed directly into the routing engine that selects the fulfillment node for each customer order.
2. Order Fulfillment: Explains how the two-step Dropship fulfillment workflow expresses itself on the operator-side order record, including how acknowledged quantities, cancellations, packing slips, and tracking are persisted.

For complementary strategies, refer to:

1. Inventory: Capacity Limits on a vendor location complement broader inventory controls by capping the daily order volume the location can absorb.
2. EDI & API Integrations: The Dropship integration setup interacts with the platform’s broader EDI and API integration framework; understanding this framework deepens the value of EDI- or API-based vendor partnerships.