Measuring the value
When to let the machine post and when to make a person press: the auto-post gate in money
Once the draft exists, auto-posting only saves the minutes of the person pressing — while one wrong posting takes back the money of more than a hundred correct automatic ones. The gate's eight conditions, why the auto-post rate fell to zero once bank notices arrived by themselves, and the break-even threshold.
Drag the auto-post threshold — what does it save, and how much does one wrong posting take back?
Each dot is one money transaction in a month, placed by how sure the gate is about the draft. Right of the threshold: the assistant posts it. Left: it waits for a person to reply “post”. Squares are the bank's own notices — they always wait for a person, wherever they sit.
Derived from the threshold and the four numbers above
Assumptions — click to see and edit every number
What a person no longer does
Risk
An estimate, not a promise. Set the reading minutes to zero: every threshold loses money or breaks even. Drag the threshold to 100%: nothing posts itself, both lines are zero. An honest model has to be able to do both.
Once an accounting assistant has the draft ready in the group chat, what is left for a person is reading two lines and replying "post". The next question comes quickly: if the draft is right nine times out of ten, why not let the machine post it as well?
This piece works out exactly that question, in money. The short answer: one wrong posting takes back the money of more than a hundred correct automatic ones. So the auto-post gate has to be narrow, and at the company in this piece it is so narrow it is almost shut — on purpose.
1. What the gate decides
The draft exists already. Amount, date, party, account and the invoice it settles are all on it. The gate only decides who presses the last button: the machine, or a person with the right to. So the money the gate can save is the minutes of the person pressing, not the minutes of keying — keying was counted in the previous piece, and it must not be counted twice.
2. When the gate opens
The gate posts on its own only when every condition below holds. One false, and the draft waits for a person, with a message saying why.
- Auto-posting is switched on for that company.
- The job came from exactly one screenshot, and nobody has written anything more in it. If someone explains or corrects, that person presses post.
- The package does one thing: post its own draft. No cancelling, no editing another voucher, no new customer, supplier or account.
- Exactly one voucher, matching exactly one posting rule a person has confirmed — not a rule under suspicion.
- Amount, date and account on the voucher match an independent reading of the screenshot — never checked against the word of the same assistant that drafted it.
- The party is someone already known: an account number seen before, or an exact name match to one person and only one.
- The reading is certain: no two different amounts, no suspected duplicate.
- The company's own cash account was not guessed.
And one rule running the other way: cancel a voucher the gate posted, and its rule becomes "suspect"; next time, everything matching that rule waits for a person.
3. What happened
In the first week the gate posted 13 of 22 screenshot payments on its own — more than half. Then bank transactions began arriving in the group by themselves: every payment into and out of the company's accounts, no screenshot needed. From that day these transactions always wait for a person, by design — and the auto-post rate went to zero.
The reason is in conditions 2 and 5. A notice from the bank says money moved, not why; nobody in the group has said what it is, and there is no second reading to cross-check — there is only one source. That is exactly the kind of payment the gate has nothing to stand on. A rate of zero does not mean the assistant got worse; it means the gate is doing its job with a new kind of input.
4. Stream one: the minutes a person no longer spends
A small number, and it has to be: the expensive part of a voucher was already taken away by the draft. One correct automatic posting saves about 1,750 VND.
5. Stream two, with a minus sign: extra wrong postings
Only the share a person would have caught is what auto-posting adds. A wrong draft the reader would not have noticed either is wrong anyway; the gate does not make it worse.
6. The break-even threshold
The two streams are equal at exactly one level of certainty:
Below that line, every dot dragged across to the automatic side loses money. The calculator draws the net benefit by threshold right above the strip of dots: it climbs, peaks around 84–85%, then falls fast to the left. Drag the threshold down to 70% and the gate posts 30 more payments, while the net benefit drops from about 85,000 to 56,000 VND.
7. Learning rules pushes dots to the right — but not the squares
Each posting rule a person confirms is a group of payments moving from "wait" to "certain". In the calculator that is the "share matching a rule" field. Suppose there were no bank notices at all (as in the first week): raise the share matching a rule from 60% to 80% and the net benefit at a 90% threshold goes from about 159,000 to 196,000 VND. Learning does not make the threshold more lenient; it makes more payments clear the same threshold.
The squares do not move. A bank notice never posts itself, however sure the assistant is — one source, nobody telling.
8. Adding it up
| Case | Automatic / month | Net benefit / month |
|---|---|---|
| Threshold 90%, half are bank notices | 53 | 85,000 VND |
| Threshold 84% (break-even), as above | 63 | 90,000 VND |
| Threshold 70%, as above | 83 | 56,000 VND |
| Threshold 90%, no bank notices | 99 | 159,000 VND |
| Every transaction comes from the bank (today) | 0 | 0 VND |
On every row the net benefit of auto-posting is under two hundred thousand a month — while one wrong posting is three hundred thousand. The conclusion is not "do not automate": the part of the automation worth the money is the draft, and it is already there. The "post" step is so cheap that keeping it costs almost nothing.
9. What this ROI rests on
The deciding assumption is the share of wrong drafts a reader catches. It has an uncomfortable side: if the person pressing "post" does not read, that share is zero, the extra wrong postings are zero too, and auto-posting always pays. In other words, the gate should be exactly as strict as people really read. If the post step is a ritual, opening the gate wide is the more honest choice; if people really read, the gate must be narrow.
Set the reading minutes to zero: every threshold loses money or breaks even. Drag the threshold to 100%: nothing posts itself, both lines are zero. A model that cannot collapse to zero is a prejudice in arithmetic costume.
10. Measuring it in your own company
- Measure the share a reader catches. Each week, take 20 vouchers a person posted and check them from scratch. Count the wrong ones the person pressing did not see. That number decides the gate.
- Count cancellations by source. How many automatic postings were cancelled, how many human-approved ones — on the same kind of payment.
- Watch the rules that turn suspect. Each rule moved to "suspect" is one time the gate opened in the wrong place.
And one more thing worth measuring every day, not every week: whether the book balance still matches the bank right after posting. A wrong posting, by machine or by person, shows up there first.
11. What to remember
Automating the last step is the cheapest part to build and the most expensive part to get wrong. Once the draft exists, the question is no longer "can the machine post it", but "how many correct postings does one wrong one cost". Here, about 170.
The auto-post gate does not measure how good the assistant is. It measures how expensive one mistake is.
Counts in this piece were measured on a real retailer's system, anonymised and rounded; the error curve, the cost of a wrong posting and every 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?