The order is in six places. None of them agree.

Where the day actually goes.

• Orders arrive by email, phone and text, in whatever shape the customer prefers, and somebody turns all of it into one format by hand.
• A regular changes their order in a text and the floor never hears about it, so the right thing gets picked and the wrong thing gets sent.
• The same order gets typed into two systems, and the second one is where the mistake lives.
• Every big customer wants something different. Their own reference numbers, their own pallet configuration, their own paperwork, their own portal.
• Nobody can say what is actually leaving today without walking out and counting it.
• Short deliveries are discovered by the customer, which is the most expensive way to find out.
• The price you agreed and the price on the invoice are not always the same number, and nobody has time to check every line.

The awkward part is the edges, not the middle.

Order entry, stock and invoicing are solved problems, and most wholesalers already own something that does them adequately. The trouble is at both ends: getting an order out of the shape a customer sent it in, and getting your paperwork into the shape they insist on receiving it.

That is where the people go. One person reading an inbox and re-keying, another maintaining the pricing sheet, a third rebuilding the same report every Monday because two systems disagree. None of that work shows up as a missing feature, which is exactly why no product fixes it.

Orders · warehouse · stock · dispatch · customers · accounting
↓  one connected operational system

The re-typing is the thing to remove.

• An order arrives however it arrives, and is read into a record rather than retyped. Email and PDF included, in the messy formats that break ordinary parsers.
• A change reaches the floor, because the order and the pick are the same object rather than two copies of it.
• What is leaving today is a screen, not a walk and a count.
• Supplier invoices are checked line by line against the price actually agreed on the purchase order, and what does not match is flagged before it is paid.
• A large customer's forecast is netted against reality, so what they say is coming and what has genuinely been invoiced stop being two separate conversations.

Not all of it, and not on day one. Which of these is worth building is the point of looking first.

Follow one order from arrival to payment.

That is usually enough to find the re-typing, and to work out whether this needs a build at all. A Discovery day is paid, and the Systems Roadmap that comes out of it is yours whatever you do next.

The parts above are proven: order capture, price checking and customer-forecast reconciliation are all running today inside a Sydney food manufacturer that supplies the major chains. The full report.