Partial Deliveries Decide Whether Your Order Automation Pays Off

The normal case in order processing takes a day or two to build. An order arrives, goods go out, an invoice follows, the customer gets a message. What makes a project cheap or expensive is everything beside that. In wholesale, and in supplying hospitals, the most frequent of those cases is not an exception at all. Part of the order ships today, the rest follows later.

Commission an order automation without describing that state first, and you are buying automation for the smaller share of your orders.

Two states are not enough

Most workflows know open and completed. What is missing between them is the state that occurs most often in practice: partly delivered, remainder outstanding, date possibly unknown.

The reason it is missing is mundane. Builds are tested with sample orders, and sample orders are fully available. Sign off an automation on three test orders and you will almost certainly hit three complete deliveries. Backorders appear only in live operation, and they appear without an error message, because from the software's point of view everything worked.

The trigger is a shipment, not a completed order

The technical core is quickly explained and it matters for your buying decision. The trigger for this kind of automation almost always comes from shipping. It reports that a consignment has left the building. It does not report that an order is finished.

Because that message carries an order number, the automation reads the order and treats the event as completion. Whether the order is actually complete is not recorded in the order header but in the line items: quantity ordered against quantity delivered, line by line.

The header status in your leading system cannot be trusted at that moment. Many systems only update it in an overnight run, some only at invoicing. Query it a second after goods issue and you read the previous state. This is not an implementation detail. It is the difference between an automation that carries your everyday business and one that is only correct for complete deliveries.

What depends on that single status change

The invoice is noticed fastest. An invoice for the ordered rather than the delivered quantity comes back, and it comes back through a process in the customer's accounts payable that costs you more than the invoice is worth. When supplying hospitals there is an added effect: a wrong invoice runs into a formal check and delays the whole payment.

Then comes the customer message. A notification announcing a complete shipment when half of it is missing produces exactly the phone call the automation was meant to remove.

Finally there is the backorder itself. If the order counts as completed, the outstanding quantity hangs on nothing. When the manufacturer's replenishment arrives, goods receipt books it into free stock, because there is no open order left to assign it to. From then on the goods sit in your warehouse, the customer waits, and nobody has a task in the system. It surfaces when the customer asks, often weeks later.

The number you should know before requesting quotes

You do not need a consultant to size this in your own company. Take a hundred orders from recent weeks and count how many line items could not be delivered in one go.

If the share sits in the low single digits, partial delivery really is an exception and may stay a manual case. If it is higher, and in ranges affected by supply shortages it usually is, then an automation that does not know this state is not an offer for your business.

The same count also answers whether the project pays. Every line item that cannot ship in one go creates manual work today: noting the backorder, informing the customer, tracking the replenishment, adjusting the invoice.

What the scope document has to state

Five points make an offer in this area reliable. The trigger, meaning whether the workflow reacts to shipments or to orders. The status model, with the intermediate state named explicitly. The invoicing rule, meaning a partial invoice per shipment or a collective invoice on completion, which also depends on what you agreed with each customer. The exact wording the customer receives on a partial delivery, including whether a date for the remainder is quoted. And who maintains the backorder list, plus what happens when the manufacturer gives no date at all.

Nobody can answer these for you. They take about an hour to settle, and they prevent the most expensive variant, which is rebuilding after go live.

What a proper implementation takes off your desk

Once the intermediate state exists, the work shifts. The outstanding quantity stays visible on the order, the replenishment is assigned to the open order at goods receipt, the customer receives a message that matches the box that arrived, and your office works through a maintained backorder list instead of reconstructing it from memory and customer calls.

Sophera Consulting writes exactly these states and exceptions down before building, then builds, then quotes a fixed price on that basis, with no subscription and with handover and documentation. The entry point is the free Automation Check.

The recommendation

Count how often you actually deliver in parts and put the result into your enquiry. Then ask every supplier one question. What does the automation do when twelve of forty boxes ship and twenty-eight stay on backorder.

A supplier with a concrete answer has understood your business. An offer that never mentions this case has been priced for the exception and will be renegotiated once it meets your everyday operation.