Drop in one supplier invoice, a PDF or a photo of the page. In about thirty seconds you get your own lines back with a price per kilogram beside each, worked out in plain arithmetic you can check against the paper. Anything it cannot price honestly is set aside where you can see it.
No invoice to hand?
Your file is held in memory for one request, sent once to Anthropic's API to be transcribed, and dropped when the answer comes back. No copy is written anywhere: no database, no storage, no log of what was on the page.
Under Anthropic's commercial terms, what is sent through the API is not used to train models. Nothing here asks who you are.
Still, cover anything you would rather not send. Prices and pack sizes are all it needs.
An invoice tells you what a case cost. It does not tell you what the thing inside cost, and that is the only number that compares. One supplier sells mozzarella as 5 x 2.5 kg, another as a 25 lb case, a third by the bag. Until each becomes a price per kilogram, nobody can say which is cheaper or whether last month's was, and so in practice nobody does.
One model call, in one place: reading the page. Every distributor lays out an invoice differently and changes it every few years, which is exactly what twenty years of OCR templates were bad at and what a model reads well.
The model transcribes. It never calculates. It is asked for every amount as the text printed on the page. From there it is ordinary code: the pack size is parsed, pounds and ounces become kilograms, the line total is divided by the quantity, and the lines are added up and compared to the invoice's own subtotal. A model asked to produce the final figure would simply be believed. Code that does the arithmetic can be checked, and the check is on the page.
A line with no pack size printed has nothing to divide by, so it gets no price. Neither does a pack described as "box", a credit, or a line that works out to a figure no food costs, which almost always means a misread digit. Each one is listed with the reason, below the prices, and none of them is folded into a number.
If the lines do not add up to the subtotal printed on the invoice, the page says so in orange. Either a digit was misread or the supplier's own arithmetic is off. Both are worth knowing before trusting anything else on the page.
When you upload a file, the reading is real and so is every number. When the demo is switched off, has used its budget for the day, or cannot read your file, it shows a sample invoice instead and says so at the top in plain words. The sample is a document we typed in for a fictional group called Harbour & Co. It goes through exactly the same arithmetic, but it is not yours, and the page never pretends otherwise.
One invoice gives you prices. Twelve weeks of them give you movement: the cheese that crept up 6% while the pizza price stayed where it was in February, or the same chicken bought from two suppliers at two prices in the same month. That is what the morning sheet does with invoices forwarded from an inbox, and it starts with exactly this read.
With one question: do you know what you paid per kilogram for your three biggest ingredients last month, from each supplier? If the answer involves a spreadsheet somebody updates when they remember, that is usually a twenty minute conversation.
Yuriy Romanyuk, in Vancouver. I ran restaurant operations before I built software for them, which is why this reads one invoice properly instead of promising to read all of them.