The manager no longer checks payment screenshots: automating payments at a language school with n8n and GPT-4 Vision

Sami Residence is a language school for expats in Tbilisi. The school has many groups, teachers, and students, and payments come in the most ordinary way: a person writes to the school's Telegram account and sends a screenshot of a bank transfer.

Before, a manager sorted out every such payment. Now a bot does it: around the clock, in the same Telegram chat, with no separate interface for the student and no black box for the team.

In short

I built Sami Residence a self-hosted n8n bot that reads a payment screenshot or PDF, recognizes the amount, date, and details through GPT-4 Vision, finds the student in MyClass, creates a subscription, records the payment, and writes logs.

In May 2026 the bot processed 144 payments: it ran 139 fully automatically and handed 5 disputed ones to the manager. Payments lost: 0.

Why this isn't just receipt recognition

There are a lot of templates online along the lines of "send a receipt to Telegram, we'll put the amount in Google Sheets". That's useful, but for a business it's not enough.

Sami's task wasn't to recognize an image. The task was to close the whole money process:

1. understand that the message is actually a payment;
2. pull the amount, date, and details from the receipt;
3. figure out which student this is;
4. find or create them in the CRM;
5. create a subscription;
6. record the payment to the right account;
7. leave a log for the team;
8. reply to the student that the payment was recorded.

So the bot doesn't "read a receipt". It brings the payment to a state where it's already in the CRM and you can work with it further.

What it was before

When a payment screenshot arrived in Telegram, the manager did the same set of actions by hand every time:

1. opened the message and figured out who wrote;
2. found out which group the student was in;
3. found them in MyClass;
4. created a subscription;
5. recorded the payment;
6. picked the right account details, because the school has several accounts;
7. replied to the student that everything was fine and the payment was recorded.

All told, about five minutes per payment. Sounds like a little, but in May there were 144 such payments, so around twelve hours of manual work a month just on sorting payments.

The problem wasn't only the time. In this kind of routine it's easy to miss a message, mix up a group, post a payment to the wrong place, or leave a payment "in the manager's head" instead of in the system.

The nastiest scenario: a student paid, but it's not visible in the CRM.

Before and after

Before automation	After automation
The manager sorted every screenshot by hand	The bot checks incoming messages 24/7
You had to find the student and group by hand	The bot finds the student in MyClass itself
If the student wasn't there, the process stalled	The bot creates a card and flags that a check is needed
The subscription and payment were created manually	The subscription and payment are created automatically
You had to remember which account the money came to	The bot takes the details from the receipt
Payment status lived in chats and the manager's head	Every step is saved in logs

How it works now

For the student, nothing changed. They write to the same school Telegram account and send a payment screenshot or PDF, just like before.

The difference is that now this account is watched by the bot, connected through Telegram Business. It works 24/7 and sorts the incoming messages itself:

1. checks whether the message has a file, screenshot, or PDF;
2. determines whether the attachment looks like a payment;
3. sends the file for recognition;
4. pulls the amount, payment date, and recipient details;
5. searches for the student in MyClass;
6. if the student is already in the CRM, uses the existing card;
7. if the student isn't there, creates a new one and flags that a manager check is needed;
8. creates a subscription;
9. records the payment with the right account details;
10. saves a log of each step;
11. notifies the manager;
12. replies to the student: "thanks for your payment".

The flow in n8n didn't come out as three nodes. There's file handling, recognition, checks, branches for different scenarios, MyClass integration, logs, notifications, and human fallbacks.

How we handled the rare scenarios

The ideal case is when the student is already in the database and sent a clear screenshot from a recognizable bank. In real life it isn't always like that, and the most interesting part of tasks like this isn't the smooth scenario but the situations that break out of it. Here's what the bot can sort out itself:

Different payment formats. Students send both screenshots and PDFs. The banks are Georgian and Russian, the receipts look different. The bot brings this to one process.

Unreliable names in Telegram. At first we tried to match students by their Telegram name, but that quickly hit reality: names don't match, people use nicknames, in the CRM they're recorded differently. So we added a separate field for matching in the CRM.

A new student. If the student isn't in MyClass, the bot doesn't crash and doesn't lose the payment. There's a nuance here: by our agreement a subscription can only be created when the student is linked to a group. So if the group is unknown, the bot puts the student into a "no group" group, creates a subscription, and flags for the manager: check for a duplicate and move to the right group.

Several account details. The school has several accounts. Post a payment to the wrong one and the reconciliation goes sideways later. So the bot determines the recipient details from the receipt and records the payment to the right payment type.

Uncertain recognition. If the bot isn't sure, it doesn't make things up. A disputed case goes to the manager. That's boring, but right: in automating money it's better to call a human one extra time than to make a pretty mistake.

Logs: so the automation isn't a black box

Payment automation without logs quickly turns into magic that's scary to use. So the bot writes down exactly what it did.

In a separate report the team sees the date, the Telegram source, the processing status, and the steps: subscription created, payment created, process finished. If something went wrong, there's no need to guess where it broke.

Plus some of the actions are visible in the CRM itself. The MyClass history keeps records that a subscription, a student account, a payment, or a subscription change was created through the API.

For the team this matters. If a manager wants to check a specific payment, they see not just the result but the traces of the process.

What the team got after implementation

After delivering the project, I don't leave the client with "well, it all works, message me if anything". For projects I write documentation: what was done, how the logic works, where to look at the data, what to do on errors, and where the needed information is.

For Sami Residence the documentation lives in a shared Google Drive folder: a system overview, the infrastructure, the scenarios for payments, events, and reminders, a runbook, and a separate file with credentials.

Files with keys and sensitive data are handed over separately through a secret file, not in plain text in the chat. Yes, it's less flashy than "look how smart the bot is". But it's exactly these boring things that make automation a working system, not a toy.

How much it costs to keep a bot like this running

The bot runs on n8n, which I deployed for the school on their subdomain. It's self-hosted infrastructure on Hetzner: the school pays not per subscriber and not per step inside the scenario, but for its own server and actual recognition usage.

In this project the ongoing technical costs are roughly:

Item	Approximate cost
VPS server for self-hosted n8n	about $8 a month
Recognizing screenshots and PDFs	about $4-5 a month
Total for infrastructure	about $12-13 a month

This isn't a separate server just for one bot. Other scenarios run on the same n8n for Sami: event sign-ups, overdue-payment reminders, group-start reminders. So that $8 for the server covers not one process but the school's whole bundle of automations.

Why this is worth it for them: the school has a lot of incoming messages. If you run a process like this in cloud n8n or in bot builders, the limits quickly start to matter. For example, n8n Cloud's Starter plan at the time of writing costs about $30 a month and comes with a limit on the number of scenario runs. And in a payment bot, every incoming message first has to be checked: is it a payment, a question for the manager, or just ordinary chatter, and these checks also eat into the limit.

Bot builders also often have their own billing logic: by subscribers, contacts, messages, or events. For a school with a lot of students, that can become a noticeable monthly sum.

Self-hosted n8n gives sensible economics in a scenario like this: you can run several bots, not worry that ordinary chatter quickly eats the cloud limit, and keep the data on the client's infrastructure.

The result

In May 2026 the bot processed 144 payments.

Metric	Result
Total payments in May 2026	144
Processed automatically	139
Sent to manual review	5
Share processed automatically	96.5%
Payments lost	0
Time to process one payment	about 5 minutes → 0
Status	Running in production daily

The main thing here isn't only the 96.5%. The main thing is that the remaining 3.5% didn't get lost. The bot handed them to the manager, as it should have.

Before, payments went through a manual routine: open the chat, identify the person, find the CRM, create a subscription, record the payment, reply to the student. Now the manager only deals with disputed cases, and ordinary payments go through on their own.

Where this can be moved to

This setup suits not only language schools. It can be adapted for any business where clients send payment by screenshot or PDF in a messenger:

• online schools and courses;
• language schools;
• studios and classes;
• local services;
• events and clubs;
• small businesses that already have a CRM but still sort payments by hand.

The CRM doesn't have to be MyClass either. If the system has an API or at least a clear way to receive data, you can build a similar process for GetCourse, BotHelp, amoCRM, HubSpot, or a custom database.

---

If your payments are also piling up as screenshots while someone sorts them by hand, this setup can be built for your tools: Telegram, WhatsApp, GetCourse, MyClass, BotHelp, amoCRM, HubSpot, or your in-house CRM.

Write to me on Telegram or leave a request. Tell me how payments work now, I'll look at the process for free and honestly say what can be automated there.