.png)
Why inventory software remembers instead of runs57
Watch someone do order entry for an hour and notice how late the system gets involved. An email arrives with a purchase order attached, in whatever format the customer's own system produces. The person reads it. They've recognised the customer from the address before the PDF is open. They know the codes on it are the customer's own versions, and they know, or find out, what each maps to in the catalogue. They see a quantity of twelve and know this customer means twelve cases. If a line doesn't add up, they ring. Only when every question is settled do they turn to the inventory system and type in the answer.
The system's part in all of that is to remember it, and that's deliberate. Inventory software mostly descends from accounting, and accounting software has one job: keep an accurate record of what was decided, with the deciding done elsewhere. The ledgers assumed a person had done the thinking before an entry was made; the software's promise was that the record, once made, stayed right, consistent and recoverable. Inventory systems inherited that shape: they hold the stock levels, the orders, the movements — a record of what the business decided — while the deciding carries on at desks and in people's heads.
I've been building and running these systems for thirty years, and none of this is a complaint. A reliable memory is worth a great deal, and businesses run on it. But it explains something that puzzles people who buy more software expectingless work: the work moves rather than disappearing. Dashboards, alerts and reports make the operation easier to see, and every one of them finishes the same way, with a person deciding whether to act on what they show. More intelligence in that arrangement gives the person better information, and the deciding still lands on them.
Software can now do a decent version of the reading. AI can take that emailed PDF and do roughly what the person at the desk does — work out who the customer is, resolve their codes against the catalogue, understand that twelve means cases. Everyone building operational software has noticed, and the obvious way to use it is to bolt a reading tool onto the front of the systems we already have: capture the document, write the lines to a file, import the file. We went a different way.
A reading is a set of guesses of different strengths. The reader might be certain of the customer, fairly sure of four lines, and half-guessing on the fifth. A file handed from a capture tool to an import carries none of that — the certain line and the half-guess look identical as rows — so the doubt is lost in the handoff, and it comes back later as a wrong delivery and a credit note, or as a person re-checking everything because they can't tell which lines to trust.
So Workhorse does the reading itself. It takes the order out of the email, matches the customer, resolves the codes and builds the sales order inside the one system, with its confidence recorded against every line. A doubt raised in the reading survives to the finished order, where the person checking it can see exactly what was doubted and why.
Doing that raised a question this trade never used to need answered: how anyone knows anorder is safe to act on. When a person keys an order, its existence is the proof — it couldn't be in the system unless someone had already done the reading and the checking, so a status of New has meant checked for as long as there have been order screens, without anyone ever saying so. An order the system built has none of that behind it, and if nothing on the order says so, everyone downstream has to treat every order as suspect, which brings back the checking the automation was meant to remove, on every order.
So the order now says whether it may proceed. Alongside the ordinary status, an AI-built order carries a flag: clear when the system is confident of every line, orheld, with the reason showing — the code that only half-matched, the unit that doesn't fit the pack size. And an email the system can't match at all doesn't become an order — nothing is created, and the person is notified. The clear ones flow, and the checkers' work is the held ones and the ones that failed.
Most of the job has been working out when the flag can show clear. Confidence had to be defined in numbers, and there wasn't one number to set. A customer or a product can be matched more than one way: the name comes back exactly, the spelling is nearly right, or the wording is different and the meaning is the same. Each route is wrong at a different rate, so each needs its own threshold, and we move the thresholds as the checking shows what each route can be trusted with. They're set cautious, so the system holds orders today that an experienced clerk would wave through, and that's what the caution costs at the moment.
Workhorse didn't start this way: it began as inventory software in that tradition, are liable memory with the standard machinery around it, and what we're doing now is rebuilding it around execution a piece at a time, order entry first — the system reading, matching, building and saying whether the result may proceed, with people checking the doubtful cases instead of keying the routine ones. We think that's the right use of what's arrived. Now that the reading exists, a system can take responsibility for the stretch between the email arriving and the order being safe to act on, provided it says, line by line, what it isn't yet sure of.
Most of the effort now goes there: watching what the checkers hold and loosening the thresholds where the evidence allows. That's slow work, and there won't be much to say while it happens — the next of these will come when the checking has taught us something new.