An accounting assistant in the group chat: from a transfer screenshot to a posted voucher

Staff send screenshots as they always did, the assistant drafts two lines, a person with the right replies “post”. Keying hours alone do not pay for running it; what turns the sum positive is books that learn of money sooner and fewer keying errors.

At a fruit retailer, money passes through a dozen doors a day: customers pay by bank transfer, staff pay for stock, money moves between the company's own accounts. The evidence for each payment is usually a screenshot posted into a group chat. Then one person — almost always one person — reads every screenshot again, guesses what it was, opens the ERP and keys a voucher.

This piece works out the ROI of another way: an accounting assistant that sits in that same group chat, reads the screenshot, looks things up in the books, drafts the voucher, and posts it only when someone with the right to do so replies "post". The keying hours are the most visible part, and on their own they do not pay for running the assistant. What turns the sum positive is two things almost nobody measures: how long the books take to learn that money has arrived, and how many keying errors never happen.

1. What a payment goes through today

1. Money lands in the account. Somebody posts a screenshot to the group, or nobody does.
2. The accountant sees it — when there is time. Usually at the end of the day, sometimes the next morning.
3. The accountant guesses: which customer, which invoice, or is it a transfer between two of our own accounts. When the guess fails, a question goes back to the group, and then a wait.
4. Open the ERP, key a receipt or a payment, pick the account, match the invoice, post.

Step 4 is where everybody looks. Steps 2 and 3 are where the cost is: for that whole wait, the books do not know the money has arrived, and whoever asks "has this customer paid?" gets no answer.

2. What the assistant does

1. The input is the group chat itself. The screenshot a member of staff posts, or the bank's own notice arriving in the group. Nobody has to open another screen.
2. Read and look up. Amount, date, account, transfer note; find the party by an account number seen before or by name; find the open invoices to match.
3. Draft, do not post. It replies in the group in two lines:

RV-0001 · Customer A · 3,200,000 VND
Dr Bank A / Cr 131 · no invoice matched
↪ Reply: post · drop

4. A person with the right replies "post" — in the group. The voucher is posted under the assistant's own account, and its description says who sent the screenshot and who said post. Cancelling a voucher, or a complex journal entry, needs a senior approver.
5. Work can be given in words too: "@assistant receipt from customer X, 3.2 million" produces exactly such a draft.
6. It learns as it goes: posting rules, the shorthand people use in transfer notes, which account number belongs to whom.

When the machine may post on its own, without waiting for anyone, is a separate question, long enough for a piece of its own. Here only the firmest part is counted: every voucher still has a person who reads two lines and replies.

3. Why the chat, and not making everyone open the ERP

The people sending screenshots are sales staff, buyers, a shop owner — none of them has a reason to open the ERP. The group chat is where they already are. Put the assistant there and their cost of taking part is zero: they send the screenshot as they always did. Make them open a data-entry screen, however good, and you have added a step for people who are not paid to do accounting — and a step nobody needs is the step that gets skipped.

The price is real too: follow-up questions happen in front of the whole group, and the assistant asks a lot. In the first twelve days about a third of all jobs ended in "asking back". That is not a defect; it is the place where the accountant used to guess alone.

4. The first twelve days, measured

Measured on the live system, rounded:

• About 300 jobs: two fifths from transfer screenshots or bank notices, a third given in words, a sixth checks of vouchers somebody else keyed by hand.
• About 90 vouchers posted: three quarters receipts and payments, a fifth journal entries.
• From the assistant receiving a job to the voucher being posted: about 1.5 hours on average, waiting for a person's reply included.
• Roughly one job in ten could not be posted (information missing, the sender never answered); a handful of errors.
• The assistant learned 10 posting rules and 6 pieces of shorthand.

90 vouchers in 12 days is about 220 a month — the headline input of the calculator above.

5. Stream one: fewer keying hours

The dumbbell chart in the calculator shows the thing worth noticing: the "today" dots spread out, the "with assistant" dots bunch together. The work that is left is the same for every kind — read two lines, reply — so whichever kind takes longest to key today saves the most. Customer receipts are not the slowest kind, but they are the most numerous, so they come first.

How to measure it. Time the accountant keying 20 vouchers of each kind in an ordinary week. The reading minutes come from the chat itself: when the assistant sent the draft and when someone answered — minus the stretch they were busy with something else.

How far to trust it: fairly. But as the piece on keyboard shortcuts argued, freed hours only become money when they go into work that has a price. If the accountant does nothing more, read this line as capacity, and do not add it to anything else.

6. Stream two: the books know sooner

How to measure it. Count the "has the customer paid", "has the money arrived" questions in the group over two weeks, and the time of the payment they asked about. Today's delay is the time on the screenshot to the time the voucher was created in the books.

How far to trust it: low on the number, high on the direction. The amount is small because the calculator counts only the minutes spent digging. It does not count the reminder sent to a customer who had already paid, or goods held back from a customer whose money arrived that morning — those cost goodwill, and goodwill has no input field.

7. Stream three: fewer keying errors

How to measure it. Count vouchers cancelled and reposted over the past three months, and the adjustments made at reconciliation. The "after" figure is already there: the assistant also checks vouchers other people keyed by hand, and every error it finds is a line in its own job log.

How far to trust it: the lowest of the three. The 2% is an assumption; the cost of one error spans a very wide range, from five minutes' correction to a double payment nobody gets back.

8. What has to be subtracted: running the assistant

This is the only line in the calculator that is certain to be real, and it is not small. Leave it out and the calculator looks better and is wrong.

9. Adding it up

With a build cost of 15 million VND and two months to full run, it pays back around month 19. That is a modest number, and this piece does not make it bigger. At twice the volume every line doubles — the running cost included — and payback comes around month 10.

10. What this ROI rests on

The heaviest assumption is jobs per voucher, not minutes. Bring it from 2.5 down to 1.5 — fewer needless rounds of asking back — and the net benefit almost doubles, to about 1.45 million VND. Set the two error rates equal and the two delays equal and it falls to minus 0.24 million VND: on keying hours alone, the assistant cannot pay for its own running. What turns the sum positive is books that are more right and know sooner, not the keyboard. Set the keying minutes equal to the reading minutes as well: every gain goes to zero and only the running cost is left. A model that cannot collapse like that is a prejudice in arithmetic costume.

One thing sits outside the calculator: the moment money arrives and the voucher is posted, the system also puts the book balance next to the bank's balance, right under the "posted" message. On the first day it did so, it exposed a gap of more than a hundred million VND. What that is worth is big enough for its own piece.

11. Measuring it in your own company

1. Take a baseline. Two weeks: count money vouchers by kind, time the keying, measure the delay from the time on the screenshot to the time the voucher was created, count cancellations and reposts.
2. Run it for four weeks in one group chat. Record the assistant's jobs per voucher and the cost of each — that number decides more than any other.
3. Compare the same season, the same volume. The month before Tết does not compare with an ordinary month.

12. What to remember

Put the tool where people already stand. The person sending the screenshot changes nothing; the person keeping the books is left with reading two lines and replying. The expensive part of a voucher was never the typing — it was the stretch of time when nobody knew it existed.

The books are late not because the accountant types slowly. They are late because the money arrives in one place and the books live in another.

Counts and ratios in this piece were measured on a real retailer's system, anonymised and rounded; the customer name, the amounts in the sample messages and every assumption in the calculator are illustrative. Replace them with your own.