Sending 1C reports to Telegram means the accounting system pushes its own numbers into the manager's chat: revenue and incoming payments for the day, stock balances, customer debts. 1C triggers the run on a schedule and a Telegram bot delivers it, so the owner never has to open the database or ask the accountant for a summary. It can be set up on a standard configuration, without replacing the accounting system.
Key takeaways
A digest arrives on its own and needs neither a login nor an open laptop, while a dashboard has to be opened. These are different tools: a digest reaches the manager where they already are and suits five to seven key numbers, while a dashboard shows a dozen metrics with breakdowns that people come to on purpose. Which metrics belong on that screen is covered in the article on the management dashboard.
For the owner of a small or mid-sized company the digest is usually the first step. It runs on the 1C that already exists, needs no separate data warehouse and changes the habit at once: the numbers get read every day instead of once a month at closing.
Telegram works better than email here: the message is visible on the lock screen, the person in charge can be asked a question in the same chat, and the bot does more than push a digest — it also takes a request such as "show the warehouse balances". Why business in Uzbekistan runs through Telegram at all is covered in the piece on Telegram bot development for business.
A digest carries the numbers a manager can act on the same day. Everything else stays in a report that is opened once a period.
The last group pays off most and costs almost no reading time: the message arrives only when something has actually happened.
| Trait | Scheduled digest | Event alert | Report on request |
|---|---|---|---|
| When it arrives | Morning and evening at a set time | Right after a document is posted | After a command in the bot |
| What is inside | Five to seven numbers for the period | One event and its amount | A finished report in a file |
| Who it is for | The owner and the director | The person in charge of the area | Whoever asked for it |
| What is set up in 1C | A scheduled job | A subscription to document writing | Handling of bot commands |
| What you risk | People get used to it and stop reading | Too many messages pile up | A heavy report ties up the session |
The third format can be made conversational. An AI assistant sits on top of the existing set of reports: the manager types "how much do they owe us in Tashkent", and the assistant picks the right report and returns the figure. It is a layer, not a replacement: it answers only from the reports opened to it and calculates nothing by itself.
It is better to start with a single digest. One message a day, five to seven numbers, two weeks of watching — and it becomes clear which lines the manager reads and which ones get scrolled past.
The delivery is built in five steps, and none of them requires rewriting the accounting system.
The other direction is taking commands from the manager. For that the bot has to listen to Telegram events somewhere and pass them into 1C; how webhooks and polling work and how they differ is covered in the article on Telegram bot integration with CRM.
Standard configurations built on the Standard Subsystems Library already run a report distribution mechanism: a list of distributions, a choice of recipients and reports, scheduling, file format, archiving and encryption. What it lacks is Telegram delivery: the built-in channels target email and a file directory.
So the additions are small: a module that calls the Bot API, a catalogue of recipients with their chat identifiers, and message templates. Scheduling, report generation and the result log come ready-made.
The second question is where the database lives. In client-server mode the server cluster manager starts the scheduled jobs and nothing else is needed. In file mode, as the 1C developer's practical guide puts it, the jobs are run by a separate thread that starts together with the client application.
Important If 1C runs in file mode on the accountant's computer, the digest arrives only while that computer is on and a session is open in the database. For a daily distribution the database is moved to client-server mode or a dedicated service session is kept on the server.
Telegram caps message frequency and file size, and on a distribution to dozens of recipients that shows up immediately.
Practical rules follow from this. A distribution to dozens of employees is queued with a delay instead of being fired in one loop. A heavy report goes as a file rather than as text. A very large export does not go into the messenger at all: the chat gets the digest and a link to the file in internal storage.
A response with code 429 means the limit has been exceeded and the message has to be repeated later. A bot that does not handle that response quietly loses part of the digests, and this surfaces a week later.
Anything that turns a digest into an export of personal data is taken out. Company totals and quantities are not personal data, while a list of clients with phone numbers already is.
In Uzbekistan such data is governed by the Law on Personal Data. Article 27-1, in the wording of 26 March 2026, requires biometric and genetic data, as well as the data of users of telecom operator services, to be stored inside the country; other personal data may be processed abroad if one of the conditions in part three of the same article is met — the current wording is published on lex.uz.
Mistake A shared "Management" chat where the bot posts everything. New people keep being added to such a chat, nobody clears the history, and a year of client data ends up visible to those it was never shown to.
A distribution dies not from technical failures but from becoming inconvenient to read. The mistakes repeat in companies of any size.
The last point is closed by a single setting: a failed scheduled job is reported to whoever runs 1C, instead of being discovered by the owner through a missing digest.
There is no separate "reports in Telegram" service: the work is assembled from routine automation and system integration. The prices are listed on the service pages.
If the numbers are needed from CRM as well as from 1C, the exchange between the systems is set up first: the methods and the rules are covered in the article on CRM integration with 1C. Go through a short list before launch.
We start with analysis rather than code: which decisions the owner makes every day and which numbers those decisions need. Then we look at where those numbers sit in 1C, how they are calculated and whether they match what CRM shows. At this stage it often turns out that part of the requested metrics is not maintained in the database at all, and the accounting has to be put in order first.
After that we build the distribution on the native 1C mechanisms, add Telegram delivery, separate the recipients and set up execution control. Rights to the code are transferred under the contract after full payment, so the distribution can be developed in-house later.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
The built-in report distribution delivers files to email and to a file directory, and Telegram is not on that list. So a module that calls the Bot API and a catalogue of recipients with chat identifiers are added, while the rest is taken from the ready-made distribution mechanism.
A common reason is file mode: there the scheduled jobs are run by a thread that starts together with the client application, so as long as nobody has opened the database, the job never starts. The second case is a 1C server with no outbound access to api.telegram.org over HTTPS.
The limit is not in 1C but in Telegram: sending more than one message per second into a single chat is not recommended, and a bot posts no more than 20 messages per minute into one group. For dozens of people the messages are queued with a delay and the response with code 429 is handled.
Through the official Bot API a bot uploads files of up to 50 MB. An export that does not fit is shortened by period or kept in internal storage, while the chat receives a short digest of the key numbers and a link to the file.
No, 1C alone is enough for revenue, incoming payments, stock balances and overdue receivables. CRM becomes necessary when the digest has to show deals in progress and conversion: the accounting system does not keep that data, so the exchange between the systems is set up first.
That is best avoided: the digest turns into an export of personal data, which is governed by the Law on Personal Data. The messages keep amounts and quantities, and counterparties are named by company name, without phone numbers or addresses.
One person has to own it, and it is not the owner. Usually the role goes to whoever runs 1C: they receive the alert when a scheduled job fails, adjust the timing and change the set of numbers at the manager’s request.
Sources
Cover photo: Stephan Seeber, Pexels
