Partially shipped is a state most order workflows do not have
Backorders are routine in distribution and hospital supply. Most automations model an order as open or closed, so the first shipment closes it and everything still outstanding drops out of every report.
This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.
The service level said 98 percent. Three customers said otherwise.
A distributor we worked with last year ran a quarterly review with a service level of 98 percent on the slide. In the same meeting, their three largest accounts each raised a backorder that had gone unanswered for weeks.
Both numbers were accurate. The service level measured whether a shipment left the building against the promised date. It said nothing about whether the order was complete when it left.
Around a fifth of their order lines shipped in more than one go. Every one of those counted as delivered on time, on the day the first box went out.
The event is a shipment, not an order
The webhook that starts these workflows comes from the warehouse or the carrier. It fires when goods leave. It carries an order reference, and that reference is what causes the damage, because it makes the event look like it is about the order.
It is not. It reports one shipment. Whether the order is finished lives in the line items: quantity ordered against quantity shipped, line by line, and nowhere else.
Reading the order header status does not save you either. Plenty of ERPs update that field in an overnight job or at invoicing. Query it a second after goods issue and you get yesterday's answer.
Two states where the business has three
Open and closed is a clean model. It is also wrong for anyone selling physical goods from stock they do not fully control.
The missing state is partially shipped, remainder outstanding, date unknown. In distribution that is one line in five, which makes it the routine case rather than something to handle later.
It gets missed for a boring reason. Whoever built the integration tested it with orders that were fully in stock, because those are the orders you can produce on demand in a test system.
What one premature status change takes with it
Invoicing surfaces fastest. Bill the ordered quantity and the customer sends it back. Bill the shipped quantity with no follow-up process and the remainder never gets invoiced at all.
Stock allocation costs more. Closing the order releases the reservation on the outstanding lines. The replacement stock arrives four weeks later, lands in general inventory, and gets sold to whoever orders it that afternoon.
Then there is the email. A tracking link for twelve of forty cases, wrapped in a message about "your order", generates one phone call per occurrence.
Reporting is what keeps the whole thing alive. Once the order is closed, the outstanding quantity is not on any list. Nobody is ignoring it. Nobody can see it.
The same break shows up on the buying side
Purchase orders have the mirror image of this problem. The PO gets marked received on the first goods receipt, the balance turns up three weeks later with nothing to book it against, and accounts payable ends up matching an invoice to a document that is already closed.
Payments have a version of it too. A payment of 3,000 against an invoice of 4,800 marks the invoice paid in a surprising number of setups, because the workflow checks whether a payment arrived rather than comparing the amount. The remaining 1,800 never enters a dunning run.
Returns are the small version. A customer sends back four of twelve cases, the return is scanned in, and the credit note covers the full line, because the return counted as finished the moment it arrived.
What we set up instead
Status is computed from the lines. An order is complete when no line has an outstanding quantity left, and the workflow does that arithmetic itself rather than trusting a header field it does not control.
A shipment event never closes anything. It records what shipped and triggers the check. Completion is an outcome, not a trigger.
Invoicing follows what shipped. Whether that becomes a partial invoice or a consolidated invoice after the final delivery is a commercial decision, and it needs making before anyone opens the automation tool.
Customer emails carry numbers. Twelve of forty shipped, twenty-eight to follow, expected week nine. That sentence removes the call.
Every outstanding line gets a date and a watcher. This distributor now runs a Monday report listing everything outstanding for more than fourteen days, routed to purchasing. It found eleven lines in the first week that nobody had looked at since the day they were ordered.
Ten minutes to find out
Pull the last twenty orders in your ERP with more than one delivery note attached. Check when the order status flipped to complete, what quantity appeared on the first invoice, and what the customer was told after the first shipment.
If it flipped on the first delivery note, your backorders have been running unsupervised since the integration went live. You will not be able to tell how many there are, because closed orders are missing from the report that would show you.