Every restaurant back-of-house tool can read your invoices now. Almost none of them can run your purchasing. The difference is about to sort this market.
Watch the restaurant software market for a season and you will see the same product pitched under a dozen logos: snap or email-forward your supplier invoices, AI extracts the line items, recipe costs update, and a dashboard tells you your food cost percentage before the month closes. Some add stocktake apps. Some add task checklists. Some add an "AI insights" chat on top. The names rotate — the loop is identical.
There is a reason everyone converged here, and it is worth being precise about, because it tells you where this category goes next.
Invoice reading was a moat. Then it wasn't.
In 2019, parsing a supplier invoice was genuinely hard. Distributor invoices are a mess of catchweights, split lines, credits, and handwriting. Companies built real pipelines — trained extraction models, human review queues — and that capability was a defensible wedge. You could build a company on "we digitize your invoices," and several did.
Then large language models made document extraction a commodity. Today a general-purpose model reads a produce invoice with the accuracy that once took a specialized vendor years to reach, and the cost of that capability is measured in fractions of a cent. Every incumbent bolted it on. Every new entrant launches with it. When a capability becomes available to everyone at commodity prices, it stops differentiating anyone — which is exactly why you now see a flurry of near-identical tools. The wedge that used to separate products evaporated, and the category converged on the same feature list.
The tell is in the marketing. When products are structurally identical, positioning inflates: "insights" becomes "intelligence," dashboards become "copilots," and alert emails become "AI managers." The language escalates because the loop underneath cannot.
The rearview mirror problem
Here is the loop those tools actually run: something happens in your restaurant, paperwork is generated, the software reads the paperwork, and a report describes what happened. Invoice scanning, COGS dashboards, variance reports, menu engineering matrices — all of it is descriptive. All of it is the past.
It is not useless. Knowing your food cost weekly instead of six weeks late is better. But be honest about what job it does: it grades your homework. The homework itself — the operator's actual Tuesday-morning job — is still manual. What do we order today? From which supplier? In what pack sizes, respecting which minimums? What did the supplier change after we ordered? Did the receiver know about the substitution before signing? Is the invoice wrong, or did we forget the price bump the rep mentioned in a reply nobody logged?
Insight software watches that work happen and reports on it afterward. The operator is still the integration layer — the person who carries state between the POS, the supplier's inbox, the loading dock, and the accounting file. When a tool's answer to "who does that work" is "you do, but now with better charts," it has described the problem, not solved it.
And there is a quieter tax underneath: most of these systems are only as good as the discipline you feed them. Stocktakes done on schedule. PAR levels configured and maintained. Items mapped, recipes updated, counts entered. The restaurants that can sustain that discipline mostly do not have a food cost problem; the restaurants with the problem are exactly the ones without spare hours to run the software's process. A system whose accuracy depends on the operator's homework, purchased to fix the fact that nobody has time for homework, has a design contradiction it cannot dashboard its way out of.
What actually stays hard
If reading documents is commoditized, what isn't? The unfashionable parts. The parts that are stateful, integration-deep, and unforgiving of error:
Inference. Deriving live inventory from POS sales through recipes — every sale depleting estimated stock, so the system knows roughly what you have between counts instead of what you had at the last count. Handling the ugly cases that make this real: backdated counts, receiving that arrived before it was logged, substitutions, pack-size conversions, waste. A model can read an invoice; it cannot conjure a correct running inventory state without an engine built to reconcile every signal that touches stock.
Decision. Turning that state into an order: consumption rates, lead times, reorder points, safety stock that respects demand volatility, decay-aware PAR for perishables, and the last mile everyone skips — rounding to the supplier's actual pack sizes and clearing their actual minimums. Not "insight suggests you may be low on chicken." A cart, built, priced, ready to send.
Execution. Sending the PO through whatever channel the supplier actually uses — email, WhatsApp, EDI, a portal — and then the part that separates a living purchase order from a PDF: absorbing the reply. "Short on blueberries, subbing strawberries." "Price up 40 cents Thursday." "Half the order ships today." Each of those is a structured change to the order's state, and it arrives days before any invoice. A system that parses supplier replies into reviewable PO updates closes the loop while the order is alive. A system that waits for the invoice reads the obituary.
Reconciliation. Receiving against the supplier-confirmed state, not the original wish. Handing accounting a record where the confirmation, the receipt, and the bill already agree — so three-way matching becomes a formality instead of an investigation. This is upstream reconciliation, and it is the difference between software that observes your purchasing and software that runs it.
None of this is a prompt. It is years of state machines, integration edge cases, and correctness work — which is precisely why the flurry of new tools all landed on the invoice instead. The invoice is the easy part now.
How to evaluate anything in this category
Cut through any back-of-house demo — including ours — with five questions:
- Does it decide? Will it produce actual order quantities from my sales data, respecting pack sizes and minimums — or does it show me a report and leave the math to me?
- Does it transmit? Does the PO reach my supplier through the channel my supplier already uses — or does "ordering" mean generating a document?
- Does it absorb replies? When the supplier confirms, changes, or substitutes, does the order update as a reviewable change my team can see — or does that live in someone's inbox?
- Does receiving check against reality? Does my receiver see the supplier-confirmed state — or the original order the supplier already amended?
- What does accounting inherit? A reconciled record — or a scanned bill and an open question?
A tool can be genuinely useful and still answer no to all five; it is just a different category of tool. Call it what it is — reporting — and price your expectations accordingly. But if your week is being eaten by the supplier loop, five noes means the loop stays open, and you stay the integration layer.
Where this market goes
Commoditized capabilities always sort a market into two groups: products that used the commodity as a feature, and products that were the commodity. The second group is in trouble no matter how the marketing escalates, because "we read documents and chart them" is now a weekend project, and the operators buying software are getting sharper about the difference between being informed and being unburdened.
The first group — the tools that own an execution loop the commodity cannot touch — get stronger, because document-reading slots into their loop as one more input. That is where we planted LineNow: the invoice is confirmation, not revelation; the intelligence lives in what to order, what changed, and what accounting should believe. The rearview mirror is now standard equipment on every model in the lot. Choose your software for what it does through the windshield.