A customer rings about an order for twelve cases. The service colleague who takes the call opens the order, sees it marked shipped, and says it has all gone. The warehouse knows it shipped seven, because one case came up damaged at the pick and the other four were never in stock. Nobody is lying. The two teams are reading one status that was asked to carry more than it can.

If your orders sometimes cannot go as one consignment, you need order fulfilment software that answers one question: when an order cannot ship whole, how do we keep working it without losing track of what we still owe the customer?

An order is a promise, and every event in fulfilment changes one of four quantities on each line: ordered, allocated, shipped and cancelled. Outstanding is what remains when shipped and cancelled are taken from ordered, and nobody should be able to type over it. A shortage changes what can be shipped now. Only a cancellation changes the promise. A shipment is evidence that part of the promise has been performed; it does not end the order. Software that keeps those quantities apart and records each exception against the original line gives the warehouse, customer service and finance one true picture from the same record.

The four quantities on an order line

Ordered is the quantity the customer was promised when the order was accepted. Allocated is stock reserved for this order and work released to the warehouse to pick it; it says nothing about whether anything has left the building. Shipped is what has gone, with evidence of the handover. Cancelled is a change to the promise itself, agreed with the customer. Outstanding is derived: ordered minus shipped minus cancelled, the balance the business still owes whether or not stock is allocated against it.

The order and its shipments are related records. Each shipment points back to the line it performs and carries its own quantity and date. When a system collapses the two into one record with a status field, the first shipment starts standing in for the whole order.

The lifecycle is short. The business accepts the order, allocates stock and releases work, picks and packs, ships, and closes the order when nothing is outstanding. This article starts after acceptance. Who may make the promise in the first place, when several channels sell from the same stock, is covered in our guide to multi-channel inventory.

One order carried through every exception

The order below is illustrative: one line of twelve cases, taken through each exception a fulfilment team meets. In every row, outstanding equals ordered minus shipped minus cancelled.

When the order is accepted, service can say twelve are confirmed and will be scheduled. The warehouse sees nothing, because no work has been released.

Only eight are in stock and the agreed policy allows partial delivery, so eight are reserved and a pick is released. Service can say eight are being prepared and four will follow when stock arrives. The warehouse sees a pick for eight and nothing about the other four, which are outstanding and unallocated.

The picker finds one of the eight damaged. Seven leave, and shipped records seven, because that is what left. The damaged case goes to a held location for investigation and stops being this order’s stock. The allocation on the eighth is released and the balance returns to outstanding, now five. The line still says twelve, because nobody has changed the promise. Service can say seven shipped today and five are still to come. The warehouse sees the pick closed at seven, one case held, and no open work for this order.

Told that five are still to come, the customer decides they want only three more. Cancelled rises to two, outstanding falls to three, and the seven already shipped are untouched. Service can say seven delivered, two cancelled at the customer’s request, three owed. The warehouse sees no change, because there was no work to change.

The customer then asks for the balance a week later than planned. This changes the remaining commitment and nothing else: no quantity moves and the shipment of seven keeps its original date. Service can say the three will go on the new date. The warehouse sees no work yet, and when stock arrives the release will respect that date.

Stock arrives and three are reserved and picked. Service can say three are being prepared, and then that ten have been delivered across two shipments and the order is complete. The warehouse sees a pick for three, then no open work. The order closes because outstanding is zero, not because a shipment happened.

Weeks later the customer sends one case back. The return is a new record against the second shipment, with its own inspection and credit or replacement decision. Shipped stays at ten, because ten did leave. Service can say the return has been logged against that shipment and what the business’s policy does next. The warehouse sees a return to inspect at goods-in.

Real operations add multiple lines, backorder rules, substitutions and carrier events. None of them change the arithmetic of the line.

What counts as shipped

Shipped is the quantity that has left the business’s control, and the evidence for it is the handover, not a person’s intention. A commerce platform will usually let someone mark an order fulfilled while the parcel is still on the packing bench. That is a status, and a status can be set early, late or twice. If shipped is fed by it, the customer can be told their goods are on the way while the carrier has not collected them, and finance can invoice a shipment that a stock count still finds on the shelf.

The business has to decide what its dispatch event is: the carrier’s collection scan, the closing of a manifest or a signed collection note. The shipped quantity should move when that event is recorded and not before. The same event releases the reservation on the stock side, which our inventory management process guide covers along with how reservations behave between allocation and dispatch.

How a single status loses the order

Run the same twelve cases through a system that treats the order as one status and the failures are predictable. If shipping seven had marked the order complete, the five would have disappeared the moment the first parcel left, and the customer’s call about the balance lands on a colleague looking at a finished order.

If the short pick had been recorded by editing the line down to seven, the promise of twelve is gone. The customer is later told that seven was what they ordered, the damaged case has no order to be held against, and when the customer cancels two there is nothing for the cancellation to come out of.

If the balance had been re-keyed as a new order for five, the customer has two order numbers for one purchase and nobody owns the link between them. When two are cancelled, which order loses them? Finance invoices two orders and reconciles them against one payment.

If the date change had been made by editing the order’s ship date, the seven that left earlier carry a date they did not ship on. The dispatch record no longer matches the carrier’s, and the invoice date follows the wrong one.

Our guide to what ERP software is poses these questions in its systems map: who authorises a partial shipment, and where the balance stays open. The four quantities answer both.

Five scenarios to run before buying order fulfilment software

A list of products will not tell you whether a system keeps these quantities apart. A demo run in your own numbers will. Take one order from your history that could not ship whole and ask the vendor to walk it through five scenarios: a partial allocation because stock is short, a short pick after allocation, a cancellation of part of the balance, a date change on the balance, and a return of shipped units.

After each scenario, ask to see three views. The warehouse view should show the work open for this order and nothing else. The service view should show ordered, shipped with dates, cancelled, outstanding, and any allocated work against it. Finance should receive the shipped quantities and dates it will invoice against, and the cancellations. If outstanding can be typed over, if the short pick is handled by changing the order line, or if the return reduces shipped, you have found the failure before you bought it.

You may not need new software at all. If your commerce platform or your existing ERP’s order module already keeps the four quantities apart, and your team trusts how it behaves on a partial fulfilment, the work is to write down your split-shipment and cancellation policy and train to it. A small operation that splits an order a few times a year needs that written policy more than a new system.

Where Keel fits

Keel is an operations platform shaped around how a business releases, splits and closes its orders. For the team in this example, the order view shows the remaining promise beside the shipments that have performed part of it. When the picker closes the pick at seven, the service colleague on the phone sees seven shipped and five outstanding on the same record. When the customer cancels two, a guided step applies the business’s own cancellation rule, updates outstanding and adjusts what work the warehouse may release. The history of what shipped when is never overwritten. When the business changes its split-shipment or cancellation policy, the rule and the screens people work in change together.

Keel supports tailored operator tools, workflows that combine human steps with processing, and business rules expressed in code. An implementation of this example would need to define the order-line model and how shipments relate to it, how reservations are held and released, what happens when two people edit the same order at once, what evidence counts as dispatch, how carrier updates arrive, what finance receives and when, and what happens when an update fails and must be retried. Those need to be built and tested for this business. Keel does not ship an order management product, a carrier connector or a commerce integration, and it is not a fulfilment warehouse. Keel leads the implementation and agrees the handover with your team.

Keel is not the answer if your existing order module already does what the table above shows and your team runs it well, or if your splits are rare enough that a written policy would fix them. Keel is the right conversation when the split, cancellation and closure rules, and the operator experience around them, need to be your own and need to keep changing while staying connected to the commerce and finance systems you already run.

If you would like to talk it through, bring one order that could not ship whole and the point at which your team lost sight of what was still owed. We can talk through how your split, cancellation and closure rules should work and whether Keel fits.