Financial accounting breaks at the junction of the bot and the app
Financial accounting in a hybrid setup breaks not at the level of interfaces, but at the junction: the bot and the app write to different storages, or to the same one but without a shared transaction boundary.
A user enters an expense via chat, then opens the app, doesn't see the transaction, and enters it again — that's how duplicate transaction entry appears.
From there, expenses in the accounting get doubled, and the balance discrepancy accumulates quietly, until the first reconciliation.
The root cause is that the input channels were designed separately. The bot has its own message-parsing logic and its own category rules, while the app has its own forms and validation.
When both sides calculate the balance independently, any synchronization delay or repeated message delivery turns into an extra entry.
The error doesn't reproduce on test data: it shows up on the real stream, where a person writes in the chat within a minute and simultaneously edits a transaction in the app.
For expense accounting this is critical: the figure stops being a basis for decisions, and reconciliation turns into manual untangling. We break down how this is closed at the level of the data model and synchronization, so that both channels work as a single source of truth.
What changes after implementing a unified loop
A unified accounting loop removes the main source of discrepancies — manual transfer of data between the bot and the app.
An operation entered in the chat immediately lands in the same database that the accounting department sees in the app, so reconciliation ceases to be a separate recurring task and becomes a control check.
In practice, this reduces manual reconciliations from weekly to selective — at month-end rather than for every batch of operations.
The speed of entering an operation is determined by the number of actions, not the interface.
In the bot, it is a single message or a photo of a receipt: recognition extracts the amount, date, merchant, and line items, while expense categorization assigns a category based on the history of similar operations.
The share of automatically parsed receipts at typical locations reaches 85–90%, and the rest goes into a confirmation queue — but with pre-filled fields rather than from scratch.
A separate effect is a class of failures that simply disappears. Double entry of the same operation, a lost receipt, a discrepancy between "in the app" and "in the report" — all of these are consequences of two disconnected storages.
When there is a single source, such errors are not corrected but prevented: an operation is either in the loop or it is not.
We build financial accounting on the combination of a bot and a mobile app, where Telegram serves as the input channel and the app as the workspace for review and reporting.
This separation of roles delivers speed at the input and control at the output, without duplicating data between systems.
Ways to Keep Financial Records: Comparing Approaches
Comparing approaches makes sense along three axes: where the data lives, who enters it, and what happens when connectivity is lost. These properties determine how much manual work remains for the owner and how quickly balances reconcile.
| Option | When it fits | Limitations |
|---|---|---|
| Spreadsheets | One-off calculations, low volume of transactions, one person handling everything themselves | Manual entry of every row, formulas break when copied, no edit history or roles |
| Offline app | A stable set of categories, records kept by one employee on one device | Data does not sync between devices, collaboration is impossible, recovery only from a backup |
| Online accounting service | Reports and access from multiple devices are needed | Dependence on connectivity, some transactions are inconvenient to enter from a phone, customization for your own categories is limited |
| Hybrid solution: bot plus app | The flow of transactions comes from chats, and both quick entry and reports are needed | Requires a well-designed data model and synchronization, and support is needed when changes occur |
The key difference lies in the point of entry. Where a transaction is already described in a chat, the bot records it without retyping, while the app handles parsing, categories, and reports.
Spreadsheets and offline apps do not provide this combination: the former lack structure, the latter lack synchronization.
A hybrid solution removes the limitations one by one: transactions land in a shared database from both the bot and the app, balances reconcile on a single set of rules, and offline mode remains as a safeguard in case of connectivity disruptions.
The choice between approaches comes down to how large the flow of transactions is and how many people are involved in keeping records.
How we run a project: from audit to handover
We run the project in iterations: each one ends with a working increment that can be verified on real transactions, not a slide presentation. Below are the stages of implementing financial accounting as a "bot + mobile app" combination.
- Reviewing current accounting. We look at how transactions enter the system today: bank exports, spreadsheets, manual entry. We record the sources, the frequency of data arrival, and the places where amounts diverge. The output is a map of flows and a list of discrepancies that need to be closed.
- Data schema. We design the structure: accounts, categories, counterparties, entries, allocation rules. We determine which fields are mandatory, how edit history is stored, and by which key a transaction is considered unique — this protects against duplicates when a statement is re-uploaded.
- Bot setup. We connect the channels through which transactions arrive, set up message parsing and categorization rules. The user confirms or corrects the allocation right in the chat — corrections immediately become rules for similar transactions.
- Building the app. We bring the data together into a mobile interface: balances, account movement, reports by period. We build the screens around frequent scenarios — quick entry, category reconciliation, viewing dynamics.
- Reconciliation check. We run parallel accounting: we reconcile the data from the bot and the app against the primary sources for past periods. A discrepancy above a set threshold is a release blocker, not a "later" task.
- Handover and training. We hand over access credentials, documentation on the data schema, and the procedure for handling discrepancies. We train the client's team and stay on for support: adjustments to categorization rules and report enhancements proceed as separate iterations.
This order delivers a predictable result: by launch time, the accounting already reconciles with the primary sources, and the team understands how to maintain the system without us. Describe your task — we'll come back with an estimate and a plan by stages.
Synchronizing operations between the bot and the app
A user enters an expense in the subway without a network, while a second one edits the same category on their phone in parallel. Both operations must be captured in the accounting, not get lost, and not be duplicated.
To achieve this, each record goes into a local operation queue on the device with a unique identifier and timestamp, rather than being sent directly to the database.
When connectivity appears, the queue is sent to the server as a batch. The server applies operations in the order they were created, not the order they were received — otherwise a later edit would overwrite an earlier one.
Conflicts are resolved by the "last meaningful edit wins" rule, taking into account the record version: if two devices have modified the same operation, the one based on the more recent version wins, while the losing one is saved to history so it can be restored.
Offline mode is not a separate scenario but a standard one: the app writes to the same queue and shows an "awaiting send" marker. As soon as the channel is restored, sending happens automatically, and the interface updates without any user action. This way, accounting remains continuous even in a basement, on a plane, or while roaming.
Convergence of balances is ensured by the fact that the total is not calculated from the cache on the device but recalculated on the server from the operation log. Even if a device has lost some confirmations, the server stores the full history, and the balance converges.
We build synchronization on the principles used in Git for distributed data work: the local copy lives independently, and merging happens according to formal rules, not "however it turns out."
What the client receives upon launch
After launch, the client receives not "access to the repository," but a working financial accounting framework with clear control points. Below is exactly what we hand over and why each artifact is needed in operation.
- Configured bot — connected to the client's workspace, with role-based access separation: who enters expenses, who views summary reports, who manages categories.
- Mobile app builds — signed versions for app stores and internal distribution, with automated update deployment configured.
- Data schema — a description of accounting entities (transactions, accounts, categories, periods), the relationships between them, and the rules by which data flows into reporting. The schema is needed so that future modifications don't break the analytics already built.
- Categorization rules — an agreed-upon set of rules by which transactions are automatically classified into line items, including handling of edge cases and manual adjustment.
- Support policy — the procedure for handling requests, response times, responsible parties, and the process for updates without interrupting accounting.
- Documentation — user instructions and technical descriptions for the team that will continue working with the system.
Separately, we hand over access credentials and accounts linked to the owner, not to the contractor — so the system remains under your control.
If new accounting requirements emerge during the project, they are recorded in the categorization rules and data schema, rather than getting buried in correspondence.
This package eliminates the main risk: when the contractor leaves, and along with them — the understanding of how the accounting is structured and why the numbers in the reports are exactly what they are.
How a hybrid bot differs from a regular accounting app
A regular accounting app requires a person to open it, wait for it to load, find the right screen, and enter data manually.
A hybrid bot flips this logic: where recording takes seconds — a spend on the go, a short note, a transaction confirmation — input happens right in the messenger, without launching a separate client.
The mobile app remains for what the bot can't do: reviewing history, categories, reports, reconciling balances.
The difference shows up in input scenarios. Mass, frequent, repetitive operations — coffee, taxi, mobile top-up — go faster through the bot: one message instead of three or four taps in the interface.
The speed of recording is what decides whether a person will even bother logging small expenses or just wave it off. The app wins where context is needed: looking at the trend over a month, fixing a category, sorting out a discrepancy.
Comparing solutions comes down not to "which is better," but to what percentage of operations actually get recorded. A pure app loses on small stuff — people are too lazy to enter it.
A pure bot loses on analytics — it's inconvenient to look at the structure of expenses in a chat. The hybrid covers both sides: the bot collects primary data at the moment of spending, the app turns it into the big picture.
Technically, it's one storage and one data model, not two independent products. An entry from the bot and an entry from the app land in a shared ledger, synchronization goes both ways, and conflicts are resolved by transaction time.
The user doesn't choose "where to keep the books" — they choose what's more convenient at a given moment, and the data doesn't diverge.
That's exactly why a hybrid bot delivers more complete financial accounting than either solution on its own: it lowers the barrier to entry for routine entries and leaves the app with what people actually open it for — understanding where the money goes.
Case study: how expense tracking stopped requiring manual reconciliations
The client is a service company with a distributed team: expenses were submitted via a chatbot, and the accounting department reconciled them against bank statements manually in spreadsheets.
Each transaction took several steps, categories were assigned "by eye," and discrepancies surfaced only at the period-closing stage — the message history had to be pulled up and it had to be reconstructed who confirmed what.
We built an integrated setup: a Telegram bot for quick expense entry and a mobile app for analytics and working with reports.
The key change was a single transaction store: both the bot and the app write to one database through a shared access layer, so data does not diverge between channels.
Categories are populated automatically based on transaction history and rules, and expense confirmation records the author and time — reconciliation is no longer a separate task.
What changed in numbers
| Metric | Before | After |
|---|---|---|
| Share of transactions with manual edits | ~40% | less than 5% |
| Time for reconciliation per period | 6-8 hours | 40-50 minutes |
| Discrepancies at closing | 15-20 per month | isolated cases |
We also handled rollback separately: if a categorization rule makes a mistake, a transaction can be reclassified, and this is recorded in the change log — during review it is clear who corrected it and when.
The app and the bot work offline: entered expenses are sent to the server once connectivity appears, and duplicates are filtered out by transaction identifier.
Two months after launch, manual reconciliations had almost completely disappeared from the process, and accounting shifted from restoring data to reviewing ready-made reports.
If your expense tracking relies on manually stitching channels together — we will analyze your setup and show you how to close it.
Common technical concerns before starting
Before starting, almost every team goes through the same list of concerns: where the data physically resides, what will happen to the app in the subway and in the warehouse, how it will integrate with already running systems, and whether everything will have to be set up from scratch. Below are answers to the ones that come up most often.
How is the security of financial accounting data ensured?
Data is encrypted in transit and in local storage on the device, and access is delineated by roles. Session tokens are short-lived, login is via biometrics or PIN, and sensitive operations require re-confirmation.
On the service side, we keep an access log: you can see who requested what and when. Backups are made on a schedule and verified by restoration, not just created.
Does the app work without the internet?
Yes. Operations are written to a local queue and synchronized when connectivity appears; conflicts are resolved by the time the record was modified, not by "whoever is last is right." The user sees the status of each operation — sent, awaiting synchronization, rejected. This is critical for tracking expenses on trips and at locations without stable coverage.
How does the app integrate with existing systems?
Through programmatic interfaces to bank statements, accounting and warehouse systems, and payment gateways. Exchange happens over secure channels, with idempotent operations — resending does not create a duplicate. If a system has no interface, we work out the exchange via files or an intermediate layer.
What about migrating already accumulated data?
We transfer the history of operations, reference data, and balances: first we export and verify integrity on a copy, then we transfer and reconcile checksums. Old records remain available read-only, while new ones go into the working environment. Rollback is possible at any stage — the source data is not overwritten.
Let's discuss your task and come back with a plan
To come back with an estimate and a plan, rather than generalities, we need a minimum of input about the product.
The more specific the input, the more accurate the estimate of timelines and scope of work — and the fewer revisions at the stage when changing the architecture is already expensive.
What we need from you at the first step:
- Accounting scenarios: which transactions the user enters manually, which are pulled in automatically, where categorization of expenses and income is needed.
- Data sources: bank statements, manual entry, file imports — and in what form they arrive.
- Roles and access: personal account, family access, an accountant or partner with limited rights.
- Platforms and coverage: iOS, Android, web account, whether a bot is needed as a separate entry point.
- Reporting requirements: which slices by periods and categories you show to the user.
- Constraints: timelines, integrations with your systems, requirements for data storage and protection.
On our side, we come back with a work plan: breakdown by stages, team composition, order of version releases, and the points where you accept the result.
The estimate is based on your scenarios, not on an averaged template, so the plan shows what we do first, what can be deferred, and where the buffer is built in.
Describe the task in whatever form is convenient — a list, a voice message, or a link to the current product. Then we'll agree on the next step: requirements analysis and locking down the scope of the first version.