Measuring the value
A robot fetches the supermarket's goods receipts: 4,239 loaded by hand in 60 days, and one chain never in the system
An accountant downloads receipts from the supplier portal on the mornings someone has time: a receipt waits 45.5 hours on average, and the second chain has none in the system at all. When a robot fetches them twice a day and matches them to delivery notes, where is the value and how large is it?
How long does a supermarket's goods receipt wait before your system has it?
Enter receipts per day, average goods value per receipt, minutes of manual work per day and the cost of an hour. The waiting time is simulated from the load schedule, not typed in. Everything is editable.
Derived from the load schedule
Assumptions — open to see and change each one
Loading by hand
Robot
Money
This is an estimate, not a promise. Line B is the softer one: a receipt that arrives earlier only becomes cash that arrives earlier if the invoice is raised right after it. Set "minutes still spent" equal to today's minutes and the cost of capital to 0: the total goes to zero. An honest model has to be able to.
Every morning, an accountant logs into a supermarket chain's supplier portal, filters by date, downloads the goods receipts page by page and loads the file into the system. At a fresh-food distributor we counted it in their own system: 4,239 receipts from chain A were loaded by hand over 60 days, on 32 of those 60 days. Counting from the start of a receipt's day until it existed in the system, a receipt waited 45.5 hours on average, and 38% waited more than two days. In October, 4 of the 19 loads happened after 11 a.m. — on a day the accountant was busy with something else, the receipts waited too.
Chain B was further away still: in 60 days the system held not one receipt from chain B. Checking what was delivered against what the chain received happened outside the system, in spreadsheets and in people's heads.
This piece asks: what is it worth to let a robot fetch the receipts twice a day and match them to delivery notes by itself?
1. What changes
- The robot runs on a schedule, twice a day: 7:30 and 17:00 for chain A, 7:40 and 17:10 for chain B. Each run takes the receipts of the last three days and pages through all of them, so a receipt a store enters a day or two late is picked up by a later run. Chain A's portal accepts a username and password, so the robot logs in itself. Chain B's portal has a human-verification step and allows one session per account, so the robot never logs in by itself: it shares the session the accountant opened in their own browser and keeps it alive. When the session expires, a named person gets one notice.
- Every receipt is matched to a delivery note. With a purchase-order number, by that number. Without one, from the store to the customer, then to that customer's delivery notes from the few days before the receipt, not yet invoiced, containing most of the receipt's items. Hard cases go to the AI, and that match is learned for next time. What is still ambiguous is left for a person to pick on screen — and the person's choice is learned too.
- The robot does not overwrite a person's work. A receipt already in the system is skipped, not rewritten; one an accountant corrected by hand keeps the correction.
On its first day the robot loaded 816 receipts: 185 new ones from chain A and 631 from chain B, covering 14 days of receiving. 765 (94%) were matched to a delivery note with confidence: for chain A, 155 of 185 by PO number; for chain B, 232 by PO, 366 by store and items, 12 with the AI. The remaining 51 carry only a suggestion and wait for a person. Matching by store and items is not decoration: delivery notes to chain B's small-format stores almost never carry a PO number — 2 of 526 in 14 days.
2. First stream: manual hours
How to measure it. Time one week, from opening the portal to the last receipt matched. The system records only the moment of loading — in the measured data, the loading itself usually took a few minutes — while the download from the portal and the matching by eye leave no trace at all. That is why the 30 minutes in the example is an assumption; replace it with your own stopwatch.
How far to trust it: medium. The days can be counted; the minutes you have to time yourself.
3. Second stream: the days a receipt sits waiting
The model goes easy on the old way: it gives 38 hours where the measurement gives 45.5, because in reality some loads happen close to noon and some stores enter receipts late. If the model is wrong, it is wrong in the old way's favour.
How far to trust it: less than the first stream. A receipt that arrives sooner only becomes cash that arrives sooner if the invoice is raised right after it. Invoicing at the quantity the chain received is a separate piece; the days counted here are part of the delay counted there, so if you add the two pieces together, take only one of them.
4. Adding it up
| Stream | Per year |
|---|---|
| Manual hours (125 hours) | 7.5 m |
| Cost of capital of 0.8 days of waiting | 13.9 m |
| Total | 21.4 m |
About 21 million VND a year at the example's numbers. That is a modest figure, and it should be: the robot replaces a small task repeated every day. What the spreadsheet cannot price sits with chain B — 631 receipts in the system for the first time, each already joined to its delivery note. Before, a gap between what was delivered and what chain B received was known only when someone sat down with the spreadsheets.
5. What this ROI rests on
The chain's portal stays the same. The robot reads pages the way a person does; when the portal changes its layout, the robot breaks. Every run records its result — how many receipts on the portal, how many newly loaded, how many already there, how many waiting for a person, which errors — and an error reaches a named person. A robot that fails quietly is worse than no robot.
Chain B's login lives in the accountant's browser. If the accountant presses "Log out" on the portal, that also logs out the session the robot is using. That is a habit to change, not a line of configuration.
The item-matching threshold was measured on 76 real receipts from one chain. A second chain may need a different one — measure again before trusting it.
6. Measuring it in your own company
- Take a baseline. The wait of each receipt: from the date on the receipt to when it exists in the system (the record's creation time is enough). Time one week of downloading and matching.
- Run the robot for two weeks. Record daily: receipts loaded by the robot, the confident-match share, receipts left for a person, runs that failed or found the session expired.
- Compare like with like. Same chain, same season, the same mix of weekdays — Mondays carry more receipts than Saturdays.
7. What to remember
A number on someone else's portal is not your data until it is in your system. Loading by hand turns it into data on the days someone has time; a robot turns it into data twice a day, including the days nobody has time.
A task repeated every morning is not expensive because of each time it is done. It is expensive because of the mornings it is not.
The receipts loaded by hand over 60 days, the days with a load, the average wait, the share waiting over two days, the receipts the robot loaded and the share it matched were measured on a fresh-food distributor's live system on 30/10/2026 — the robot's first day — and anonymised. The minutes, wage, value per receipt, cost of capital and every other assumption in the calculator are illustrative. Replace them with your own.
Read next
-
Never invoice twice: ask the accounting ledger before creating — 199 of 209 invoices were already there
When invoicing moves from the accounting package into the ERP, there is a stretch when both create invoices. If the ERP asks the accounting ledger before it creates one, how many duplicates does a cutover avoid — and what is each duplicate you never clean up worth?
-
Sharing an estimate by one link: what the mailed-Excel loop costs, and "which version is the latest?"
An estimate passes through 2–4 people as Excel files sent by mail, so someone always asks "which version is the latest?". When the whole set — drawings, quantity table, where every number comes from — sits behind one shared project, with people invited by email or sent a view-only link that needs no account, how many hours a month does the review loop get back?
-
Invoicing at the original PO price: the delivery note says 21,000, the chain's PO says 30,000
A retail chain pays the price on its own PO, not the price on the supplier's delivery note. When a machine reads the PO price, invoices at it when the gap is plausible and corrects the price list for next time, what is that worth a month — and which lines still need a person?