Allocation Rebalancer - Kibo Documentation

The Allocation Rebalancer is an event-driven inventory rebalancing capability within the Kibo B2B Wholesale OMS that detects supply and demand changes and automatically reprioritizes future shipments and backorder queues in response. In wholesale distribution, inventory conditions change constantly — purchase orders are delayed, quantities are cut, and orders are cancelled. Without automated rebalancing, these changes go unaddressed until the fulfillment team discovers the shortfall at pick time. The Allocation Rebalancer closes this gap by detecting supply and demand change events at the Product-location level and executing a sequential rebalancing flow that re-secures inventory for the right shipments in the right priority order.

How the Allocation Rebalancer Works

The Allocation Rebalancer processes two types of change events: Supply Change Events

Event	Description	Impacts
PO Delayed	A purchase order’s expected arrival date is pushed beyond the time fence	Future Shipments Queue
PO Short-Shipped	A purchase order arrives with fewer units than expected	Future Shipments Queue
PO Cancelled	A purchase order is cancelled entirely	Future Shipments Queue → Backorder Queue

Demand Change Events

Event	Description	Impacts
Order Cancelled	An order is cancelled, freeing previously allocated inventory	Backorder Queue
Order Line Reduced	An order line quantity is reduced, freeing previously allocated inventory	Backorder Queue

Note: Demand Up events (new orders placed, quantities increased) are not tracked by the Allocation Rebalancer. New orders follow the standard order placement flow and result in new future or backorder shipments as appropriate.

Note: All references to purchase order changes in the Kibo platform translate to changes on Future Inventory Records — On Inventory records keyed by UPC, expected delivery date, and destination location. Kibo OMS does not generate purchase orders directly; PO generation is handled in middleware between your ERP and the OMS.

Rebalancing Flow

When a supply or demand change event is detected, the Allocation Rebalancer executes the following sequential flow: Step 1 — Capture and Accumulate Events. Change events are detected and stored. To prevent excessive processing from rapid successive events (for example, a purchase order receipt posting many line items individually), events are accumulated within a configurable debounce window (default: 60 seconds). All events for the same UPC-location within the window are collapsed into a single re-evaluation before the flow proceeds. Step 2 — Identify Impacted Future Shipments. The system identifies all future shipments allocated against the affected future inventory record at the location. Only shipments in Future status are eligible. Shipments in Ready status are never touched. Step 3 — Prioritize Future Shipments. The Future Shipment Rules run against the impacted future shipments to assign each a priority rank. Shipments matching higher-priority rules are protected first during reallocation. Step 4 — Reallocate Future Shipments. The system attempts to re-secure inventory for each impacted future shipment (processed in priority order) from alternate future inventory records within the configured time fence, by calling Order Routing. If reallocation cannot be preserved for a shipment, it is de-allocated and moved to the after-action queue (Backorder, Customer Care, or Cancel) as determined by Order Routing configuration. When supply decreases, the lowest-priority shipments lose their allocation first. Step 5 — Prioritize Backorder Queue. The Backorder Shipment Rules run against the full backorder queue — not only the newly affected shipments — to re-rank all backorder shipments against the revised inventory position. Step 6 — Release Backorders. Backorder shipments are released in priority order. Shipments that can be fulfilled from available inventory are released into the fulfillment pipeline. Shipments that cannot be satisfied remain on backorder.

Note: If a change event produces no impacted future shipments (for example, a demand event such as an order cancellation), Steps 2–4 are skipped and the flow proceeds directly to Step 5.

EDD on Re-pegged and Released Shipments Every shipment produced by the Allocation Rebalancer — whether re-pegged to an alternate PO, moved to backorder, released from backorder to a new future or ready shipment, or split — has its EDD automatically recalculated from the new location and date. A shipment moved to backorder has its EDD cleared, as no delivery can be promised until inventory is secured. A backorder shipment subsequently released by the Allocation Rebalancer receives a freshly calculated EDD from the newly allocated location and date. This recalculation is part of the existing EDD behavior for future inventory changes — the Allocation Rebalancer is one of the triggering pathways. See EDD Recalculation on Future Inventory Changes on the Estimated Delivery Dates page for the full scenario matrix.

Trigger Mode

An admin can configure how the rebalancing flow is initiated at the site level:

Mode	Behavior
Fully Automated	The system automatically executes the full sequential rebalance flow at configured intervals without waiting for user action. The Run Rebalancer button is hidden in the UI.
Manual Only	The rebalancer executes only when a user clicks Run Rebalancer in the Balancer Run Audit UI.

To configure the trigger mode:

Go to Main > System > Settings > Site
Select the B2B tab.
Under Inventory Balancing & Reservations , set the Trigger Mode to Fully Automated or Manual Only.
Make Sure Allocation Rebalancer is Enabled
Click Save.

Note: The Allocation Rebalancer, Reservation Rebalancer, and Reservation Rules job are orchestrated as part of a single site-level scheduling configuration. See Orchestrator Settings for details on sequencing and enabling or disabling individual components.

Time Fence

The time fence determines the window of future inventory that the rebalancer considers when reallocating future shipments or releasing backorders. It is calculated symmetrically around the shipment’s requested ship date:

Start of Time Fence = requestedShipDate − timeFenceDays
End of Time Fence = requestedShipDate + timeFenceDays

Only inventory available within this window is eligible for reallocation. A purchase order change that falls outside the time fence triggers rebalancing. A change that arrives within the time fence (early or late) does not require rebalancing, as the supply still meets the shipment’s timing requirements.

Segmentation

If your tenant uses inventory segmentation, the Allocation Rebalancer respects segment tags during reallocation and backorder release. Inventory is only allocated from within the designated segment for each shipment.

Prerequisites

Before using the Allocation Rebalancer, ensure the following:

The B2B Wholesale OMS feature is enabled for your tenant. Contact Kibo Support to enable this capability.
Supply Demand UI(new Inventory UI) should be enabled for your tenant. Contact Kibo Support to enable this capability.
At least one Future Shipment Rule is configured and enabled. See Future Shipment Rules.
At least one Backorder Shipment Rule is configured and enabled. See Backorder Shipment Rules.
The Trigger Mode is configured at the site level.
You have Admin or Super Admin role permissions, or a role with Allocation Rebalancer access.

Rebalancer Run Audit

Every rebalancing run produces a full audit trail accessible on the Rebalancer Run Audit page. The audit trail is the primary tool for reviewing what changed in a given run, understanding why specific shipments were prioritized, and tracing outcomes back to the triggering supply or demand event. To open the Rebalancer Run Audit:

Go to Main > Fulfillment > Allocation Rebalancer.
The Rebalancer Run Audit page opens with the Allocation Rebalancer tab selected by default.
Select a Site from the site selector to filter runs for that site.

Run Modes

If the site is configured for Manual Only trigger mode, a Run Rebalancer button is visible in the header. Click it to manually initiate a rebalancing run. Use the dropdown to choose:

Run Rebalancer — Runs both the Allocation Rebalancer and Reservation Rebalancer together.
Run Allocation Rebalancer — Runs only the Allocation Rebalancer.

If the site is configured for Fully Automated mode, this button is hidden. Runs are auto-initiated on the configured schedule and listed in the run table as they complete.

Run List

The Run List is the default landing view within the Rebalancer Run Audit page. It displays a paginated list of all rebalancing runs for the selected site, ordered newest first. A live row count is shown above the table — for example, “5 runs · newest first” — and is always backend-computed.

Search & Filters

Control	Values	Behavior
Search	Free text	Server-side match on Code, Location, Customer, or date across the run’s tracked changes.
Status	All statuses / Completed / Partial / Failed	Server-side filter.
Run Mode	All / Automated / Manual	Server-side filter.
Reset	—	Clears all active filters and restores the full newest-first run list.

Data Table Columns

Column	Description
Run	The unique Run ID and the date/timestamp the run was initiated.
Summary	A one-line, human-readable description of what the run processed — for example, “2 supply changes · 14 future shipments evaluated · 8 backorders released.”
Run Mode	Indicates whether the run was user-initiated (Manual) or system-initiated (Automated). For Manual runs, the trigger reference is shown (for example, `PO-4522`). For Automated runs, displays “Automated.”
Tracked	The total count of supply and demand change events captured and tracked in this run.
Evaluated · F / B	A split count of the shipments evaluated during the run. F = number of Future Shipments impacted by the tracked events. B = number of Backorder shipments in the backorder queue at the time of the run.
Results · F / B	A split count of the shipments produced as final outputs of the run. F = total Future Shipments as results. B = total Backorder Shipments as results. Results can exceed Evaluated counts when the run produces newly created split or re-pegged shipments.
Status	A badge indicating the run outcome: Completed, Partial, or Failed.

Run Status Values

Status	Meaning
Completed	The full rebalancing flow executed without interruption. All events were processed, future shipments were evaluated and reallocated, and the backorder queue was prioritized and released as applicable.
Partial	The run was interrupted before completing all steps. Some data was processed and is visible in the Run Detail tabs — what you see reflects the subset of work completed before the halt. The status badge in both the Run List and Run Detail header clearly reflects Partial.
Failed	The run encountered a fault and could not complete. A fault reason consistent with backend fault states (`SKIPPED` / `FAULTED` / `ABORTED`) is surfaced in the Run Detail view. Whatever subset of data was processed before the failure is visible in the Run Detail tabs.

Run Detail

Click any run in the Run List to open its detail view. The Run Detail page provides a full breakdown of what the rebalancer evaluated and what outcomes it produced for that specific run. The Run Detail header displays key metadata for the selected run at a glance:

Element	Description
Run ID + Timestamp	Unique identifier and date/time the run was initiated.
Status badge	Completed, Partial, or Failed — matches the badge shown in the Run List.
Trigger	The event type and reference that initiated the run (for example, “PO date slip / PO-4522”).
Summary	A one-line plain-English description of what the run did.
Metric tiles	Changes tracked; Evaluated shipments (Future/Backorder split); Status.

Note: If a run has a Partial or Failed status, the header badge prominently reflects this. All three tabs still render whatever subset of data was processed before the run halted — data is never silently shown as Completed. A Failed run additionally surfaces a fault reason consistent with backend fault states (SKIPPED / FAULTED / ABORTED).

Tab Bar

The Run Detail page contains three tabs, each with a count badge showing the number of records in that tab:

Supply/Demand Changes (default landing tab)
Shipments · Future
Shipments · Backorder

Supply/Demand Changes Tab

The Supply/Demand Changes tab is the starting point for understanding why a rebalancing run was triggered. It lists every tracked change event detected during the run — supply decreases (PO date slips, PO quantity drops) and demand decreases (cancellations) — and lets you trace forward to see exactly which shipments were impacted.

Search & Filters

Control	Values
Search	Free text — ProductCode, PO number (External ID), Location
Change Type	All change types / Supply / Demand
Sub-type (Supply)	All (Supply) / PO date slip / PO quantity drop
Sub-type (Demand)	All (Demand) / Cancellation
Reset	Clears all filters on this tab

Table Columns

Column	Description
Change	Change type and sub-type chip (for example, Supply — PO date slip).
Entity	Three fields identifying the affected future inventory record: PO number (the External ID of the future inventory record); UPC (the product UPC on the record); Location (the destination location on the record).
Delta	What changed, expressed as before → after. For example: PO date moved from April 5 to April 19, or quantity changed from 1,000 to 700.
Detected	The date and time the system detected the change event.

Note: The PO number displayed in the Entity column is the External ID of the future inventory record — not a Kibo-native PO number. Kibo OMS does not generate purchase orders. Clients are responsible for interfacing the correct External ID value for each future inventory record so that it maps back to their PO reference in their ERP or middleware system.

Supply Down Event Sub-types

UI Label	What It Means
PO date slip	The PO is arriving later than expected and its new date falls outside the time fence — or the PO is arriving earlier than expected and its early date also falls outside the (negative) time fence.
PO quantity drop	The PO’s expected quantity has been reduced.

Demand Down Events

UI Label	What It Means
Cancellation	An order cancellation or order line quantity reduction that freed previously allocated inventory.

Selection & Cross-Tab Pre-filter

Selecting a row (single-select) shows a banner at the top of the table:

“1 change selected · open Shipments · Future or Backorder to see impacted shipments.”

The selected change pre-filters both Shipments · Future and Shipments · Backorder to display only the shipments whose affected shipment IDs include this event. Select “Clear change filter” or uncheck the row to restore both tabs to the unfiltered view.

Note: Selecting a Demand (Cancellation) event and then switching to Shipments · Future displays an empty state — not an error. Demand events never impact future shipments. The same event does feed the Shipments · Backorder tab.

Shipments · Future Tab

The Shipments · Future tab shows every future shipment the rebalancer considered during the run. Use this tab to understand which shipments were evaluated, what priority they were assigned, and what happened to each one. The tab supports two views, toggled at the top of the tab:

Evaluated (default) — The original shipments assessed during the run and their individual outcomes.
Results — The final state of every shipment touched by the run, including newly created shipments produced by splits, re-pegs, or backorder moves.

Search & Filters

Free-text search by Shipment #, Item, Location, or Account.

Evaluated View — Columns

Column	Description
Shipment # / Order #	The shipment ID and its associated order number. Only original shipments considered for rebalancing appear here — newly created split or reassigned shipments appear in Results only. Shipments whose PO delay stayed within the time fence never appear here at all (they were not impacted and required no evaluation).
Line Items	All line items in the shipment (not only the impacted lines). Displays up to three products inline; if there are more, a +N overflow indicator is shown. Also displays the total unit count across all line items.
Location	The location name the shipment is assigned to.
Account	The buyer account name.
Requested Ship Date	The requested ship date on the shipment.
Ship Window	The time fence window (requested ship date ± time fence days) used for inventory search during the run.
Priority	The rank assigned to this shipment by the Future Shipment Rules. Hover over the rank to see a tooltip explaining which rule assigned it and why. Shipments with no matching rule show null priority.
Evaluation Outcome	The outcome determined for this shipment during the run. See the outcome values table below.

Evaluated Outcome Values

Evaluation Outcome	Meaning
No change	The shipment was impacted by the PO change but retained its original allocation — a suitable alternate inventory source was found within the time fence.
Pegged to another PO (Full)	The entire shipment was re-allocated to a single alternate PO. All line items moved together.
Moved to Backorder (Full)	The entire shipment could not be reallocated and moved to the backorder queue. No alternate PO could satisfy any line item.
Partially Reallocated	A mixed outcome across lines. Click the row to open the Shipment Detail Panel for line-level breakdown. Possible combinations: some lines remained on the original shipment and some were pegged to other POs; some lines remained and some were backordered; or a combination of all three — some remained, some re-pegged, some backordered.

Results View — Columns

The Results view shows the final state of every future shipment touched by the run, including newly created shipments from splits, re-pegs, or backorder moves that are not visible in the Evaluated view.

Column	Description
Shipment # / Order #	Includes both original shipments and any newly created shipments resulting from the run (tagged NEW).
Line Items	Same display pattern as Evaluated view.
Location	Location name.
Account	Buyer account name.
Requested Ship Date	Requested ship date.
Ship Window	Time fence window.
Result Type	The final classification for this shipment record. See result type values below.

Results View — Result Type Values

Result Type	Meaning
No change	The shipment retained its original allocation with no modification.
Backorder (New)	A new backorder shipment was created as a result of the run — the original shipment could not be fully reallocated.
Pegged to a PO (New)	A newly created future shipment resulting from a re-peg, reassignment, or split.
Partially Reallocated	The original shipment retained some lines after a split — other lines were moved to backorder or re-pegged to other POs.

Shipments · Backorder Tab

The Shipments · Backorder tab shows the full backorder queue evaluated during the run. Unlike the Shipments · Future tab — which only shows shipments newly impacted by the triggering event — this tab always shows the entire tenant backorder queue, because the Backorder Shipment Rules re-rank all backorders together against the revised inventory position on every run. The same Evaluated / Results toggle pattern applies.

Search & Filters

Free-text search by Shipment #, Item, Location, or Account.

Evaluated View — Columns

Column	Description
Priority	The rank assigned by the Backorder Shipment Rules for this run. Hover to view a tooltip showing which rule assigned the rank and why. Null-priority shipments are shown at the bottom.
Shipment # / Order #	Shipment ID and associated order number.
Line Items	All line items in the shipment. Displays up to three products inline; overflow shown as +N. Total unit count shown.
Location	Location name.
Account	Buyer account name.
Requested Ship Date	Requested ship date on the shipment.
Ship Window	Time fence window (requested ship date ± time fence days from the matched Backorder Shipment Rule).
Evaluation Outcome	The outcome for this backorder shipment during the run. See outcome values below.

Evaluated Outcome Values

Evaluation Outcome	Meaning
Pegged to a PO (Full)	The entire backorder shipment was fully pegged to an incoming PO / future inventory record.
Released as Ready (Full)	The entire backorder shipment was fully released using available on-hand inventory and moved to Ready status.
Remain in Backorder with Partial Release	Some lines were released (either pegged to a PO or released as ready), while others remain in backorder. This can result from a line-item split or a quantity split.
No change	The shipment remained fully in backorder — no inventory was available to fulfill it during this run.

Results View — Columns

Column	Description
Priority	Priority rank assigned during this run.
Shipment # / Order #	Includes both original backorder shipments and any newly created shipments.
Line Items	Same display as Evaluated view.
Location	Location name.
Account	Buyer account name.
Requested Ship Date	Requested ship date.
Ship Window	Time fence window.
Result Type	Final classification for this shipment. See result type values below.

Results View — Result Type Values

Result Type	Meaning
Pegged to a PO (New)	A newly created future shipment was produced by releasing this backorder shipment against an incoming PO.
Ready Shipment (New)	A newly created Ready shipment produced by releasing this backorder against current on-hand inventory.
Remain in Backorder with Partial Release	Some lines were released, producing new shipments; remaining lines stay in backorder. Can result from a line-item or quantity split.
No change	The shipment remained fully in backorder with no inventory allocated during this run.

Shipment Detail Panel

Clicking any row in Shipments · Future or Shipments · Backorder opens the Shipment Detail Panel — a side drawer that provides a full breakdown of a single shipment’s evaluation context, outcome, and line-level detail. The panel is read-only. The panel layout and fields are consistent across both tabs, with minor differences in outcome terminology between future and backorder contexts.

Panel Header

Element	Description
Shipment #	Shipment identifier.
Order #	Associated order number.
Line count	Total number of line items in the shipment.
Location	The location the shipment is assigned to.
Allocation state badge	Current allocation state of the shipment.

Overview Tab

The Overview tab provides a summary of the shipment’s evaluation context and outcome, organized into four blocks:

Status Block

Field	Description
Affected chip	A chip indicating the shipment was affected by the rebalancing run.
Reason-code chip	A machine-readable reason code describing what happened to the shipment during the run (for example, `re-peg-on-slip`, `moved-to-backorder`, `gain-on-release`). The text is data-driven from the Rule Snapshot API — never hardcoded.
Plain-English explanation	A one-line description of the outcome in plain language, generated from the reason code.

Identity & Current State Block

Field	Description
Order number	The sales order number associated with this shipment.
Location	The fulfillment location.
Customer / Account	The buyer account name.
Ship window	The time fence window (requested ship date ± time fence days).
Allocation state	The current allocation state of the shipment (Future, Backorder, Ready).
Fulfillment type	The fulfillment type (for example, Direct Ship, Delivery).
Line items	Total number of line items.
Total units	Sum of all unit quantities across line items.

Outcome Block

Shows the original shipment and every shipment that resulted from the run:

Entry	Description
THIS	The original demand shipment evaluated by the run, with its unit quantity.
NEW	Every resulting shipment created from this shipment during the run (re-pegged shipments, backorder shipments, ready shipments), each tagged with NEW and its unit quantity.

For shipments that were not split — for example, a shipment fully re-pegged as a whole or fully moved to backorder — the Outcome block still shows a one-line summary rather than an empty state. For example: “Original demand #1163 · 420 units — Fully re-pegged into one shipment” or “Moved to Backorder (Fully).”

Triggered by These Changes Block

Lists every supply or demand change event that caused this shipment to be evaluated during the run:

Field	Description
Change type	Supply or demand change (for example, PO date slip, Cancellation).
PO / Order reference	The External ID of the future inventory record or the order number.
Location	The location of the affected inventory.
Before → After	The delta — what changed (date moved, quantity reduced, order cancelled).

Note: For shipments on the Shipments · Backorder tab, the Triggered by these changes block can include both Supply events (PO date slip, PO quantity drop) and Demand events (Cancellation) — unlike the Future tab where only Supply events apply.

Lines Tab

The Lines tab provides a line-by-line breakdown of every item in the shipment, including the supply source assigned to each line.

Lines Tab Columns

Column	Description
Line #	The line item number within the shipment.
Line Item ID	The product UPC or SKU identifier.
Supply Source	The PO reference (External ID) of the future inventory record the line is pegged to. For backorder shipments released from on-hand inventory, this shows the on-hand inventory record.
Supply Date	The expected delivery date of the pegged PO — the date the supply is expected to arrive at the location.

Summary Chips

Summary chips at the top of the Lines table (for example, “2 re-pegged,” “2 unchanged,” “126 units re-pegged”) also act as clickable filters. Clicking a chip filters the Lines table to show only the lines matching that outcome category.

​How the Allocation Rebalancer Works

​Rebalancing Flow

​Trigger Mode

​Time Fence

​Segmentation

​Prerequisites

​Rebalancer Run Audit

​Run Modes

​Run List

​Search & Filters

​Data Table Columns

​Run Status Values

​Run Detail

​Header

​Tab Bar

​Supply/Demand Changes Tab

Search & Filters

Table Columns

Supply Down Event Sub-types

Demand Down Events

Selection & Cross-Tab Pre-filter

​Shipments · Future Tab

Search & Filters

Evaluated View — Columns

Evaluated Outcome Values

Results View — Columns

Results View — Result Type Values

​Shipments · Backorder Tab

Search & Filters

Evaluated View — Columns

Evaluated Outcome Values

Results View — Columns

Results View — Result Type Values

​Shipment Detail Panel

​Panel Header

​Overview Tab

Status Block

Identity & Current State Block

Outcome Block

Triggered by These Changes Block

​Lines Tab

Lines Tab Columns

Summary Chips

How the Allocation Rebalancer Works

Rebalancing Flow

Trigger Mode

Time Fence

Segmentation

Prerequisites

Rebalancer Run Audit

Run Modes

Run List

Search & Filters

Data Table Columns

Run Status Values

Run Detail

Header

Tab Bar

Supply/Demand Changes Tab

Shipments · Future Tab

Shipments · Backorder Tab

Shipment Detail Panel

Panel Header

Overview Tab

Lines Tab