Why invoice truth comes before AI

Ask a restaurant system what to do about food cost and it can produce an answer quickly. Ask a narrower question—what did the salmon on the last invoice actually cost per pound after the vendor changed the pack description—and the useful work begins.

Invoices are where a large part of restaurant cost evidence enters the operation. They are also difficult records: abbreviations, inconsistent item names, changing case sizes, catch weights, substitutions, credits, taxes, delivery fees, handwritten corrections, and prices expressed by case, pound, kilogram, unit, or something the vendor assumes the receiver already understands.

The receiving process has always required judgment. The invoice has to be compared with what arrived and, when available, what was ordered. Software does not remove that responsibility. It can make the source easier to inspect and the review easier to repeat.

Reading the line is not the same as understanding it.

An extraction system may correctly read “SALM FIL 18LB,” the quantity, and the extended amount. It may still be wrong about the business meaning. Is the line one 18-pound case, eighteen one-pound units, or a catch-weight total? Does the price include a delivery fee? Is the item equivalent to the salmon already used in the restaurant’s recipe, or is it a different cut, grade, trim, or pack?

A high confidence score cannot answer those questions on its own. Confidence usually describes the system’s view of a bounded task—such as text recognition or candidate ranking—not whether the restaurant should accept the value as canonical cost truth.

That distinction matters because the invoice line does not stay on the invoice. Once accepted, it can reach the ingredient cost history, recipe calculations, inventory valuation, purchasing analysis, and the recommendations a manager sees before service.

The review gate protects everything downstream.

A safer workflow keeps extraction, matching, and confirmation as separate states. First, the system reads the source and proposes structured fields. Second, it suggests which vendor item, pack, or restaurant ingredient the line may represent. Third, a person reviews the source and confirms or corrects the restaurant meaning.

The source page, region, original vendor text, proposed interpretation, review state, person, and revision should remain connected. When the next invoice uses the same shorthand, the system can reuse the reviewed history without pretending that packaging or vendor language never changes.

A line that does not resolve cleanly should remain in review. Missing values should remain missing. An ambiguous unit should not become zero, one case, or one pound because a calculation needs an input.

AI belongs in the assistance layer.

AI is useful for the parts of invoice work that are genuinely fuzzy: reading an imperfect image, grouping words into a line, classifying a likely row type, ranking a match, identifying repeated shorthand, or summarizing what needs review.

It should not decide that an ambiguous vendor description is the same ingredient, confirm a density conversion, choose the restaurant’s recipe yield, or invent a missing amount. Those are source, restaurant, or policy questions. The correct system response may be an abstention and one precise question for the operator.

After the values are reviewed, deterministic arithmetic can do the work it is good at. A unit cost can be normalized under an explicit conversion. A recipe can be recalculated from its versioned quantities and yields. A configured price boundary can be evaluated from the rule the restaurant selected. The calculation should name its inputs and version.

What an operator should be able to inspect

• The original invoice page or source reference
• Vendor, invoice date, item description, quantity, pack, unit price, and extended amount
• What the system extracted and what it inferred
• The candidate restaurant item or ingredient and why it was suggested
• The person, time, and revision associated with the review
• Any later recipe, inventory, or recommendation that used the reviewed value
• A visible state when the source is missing, stale, incomplete, or still disputed

This is slower than pretending the first parse is truth. It is faster than debugging a chain of confident answers built on the wrong unit.

The product principle

Dynamic.ly is being built around a simple order of operations: use software to read and organize the source; ask a person to confirm what only the restaurant can know; calculate from reviewed values and defined rules; keep the recommendation inspectable; let the manager decide.

The point is not that every invoice requires a full manual audit forever. The point is that automation should earn reuse from reviewed history rather than manufacture certainty at the first encounter.

Invoice truth is not glamorous. It is the difference between a cost signal and a cost story the restaurant can defend.