Telegram expense bots: verify amounts, currencies, and category totals

A bot replying “saved” to “12.50 lunch” has not demonstrated correct bookkeeping. It might misread the decimal separator, choose the wrong currency, or count a refund as another expense. Before asking AI to understand everything, define what can be saved, how amounts are represented, and which records a total includes.

A historical Telegram Business Accounting Bot client brief asks for message-based expense entry, category prompts, persistent storage, and reports by category and period. It also mentions currencies, tax fields, and independent server deployment. The page displayed Closed when checked November 4, 2026; its absolute publication date was unknown. It is demand evidence, not a BitBear delivery case or an open opportunity. The narrower scope and acceptance rules below are proposed examples, not decisions accepted by that client.

Start with expense records before a full accounting workflow

A first version can use private chats, separate records for each user, manual categories, and reports requested by command. Accept explicit expense and refund inputs. Exclude bank connections, automatic tax calculations, invoice compliance, and model guesses about missing amounts.

That does not fulfill every requested supplier field, tax workflow, CSV/PDF report, or VPS deployment. Scope them separately. A team ledger also needs rules for viewing, changing, and exporting other people's records; personal data isolation does not establish shared financial permissions.

Useful record fields include an independent ID, owner, expense/refund type, amount, currency, category, transaction date, optional note, and active status. Do not keep only the original sentence and reinterpret it whenever a report runs: changing a parser could then change historical totals.

Make decimal input explicit

One proposed first-version policy asks the user to select a ledger currency and accepts digits with a decimal point, without grouping separators, scientific notation, or mixed currency symbols. Inputs such as 1,234, 12,50, two amounts, or a cross-currency entry lacking a currency need clarification rather than a guess.

Show the full amount, currency, type, category, and date before confirmation. Ask for a missing category; reject a missing amount. A small expense/refund system can require positive amounts for both types and let the type determine direction. Negative numbers must not alternate between refunds and corrections without a declared rule.

Limit precision too. In a ledger configured for two decimal places, 12.345 should require correction rather than silently becoming 12.34. Automatic rounding is another policy, requiring an agreed method and stage.

Preserve exact amounts before formatting them

The official SQLite floating-point explanation describes binary floating-point values as approximate: many decimal amounts have no exact representation. This is not peculiar to SQLite. Formatting a result to two places does not establish correct storage and accumulation beforehand.

For a ledger explicitly configured for two decimal places, one possible design stores integer minor units: 12.50 becomes 1250; 0.10 and 0.20 become 10 and 20, totaling 30, displayed as 0.30. Convert validated decimal text; doing approximate floating-point arithmetic first and multiplying by 100 cannot be assumed to repair earlier errors.

An appropriate exact-decimal facility is another option, subject to runtime support. This article does not require arbitrary dependencies or database extensions. Either design needs limits for individual entries and totals, plus checks across parsing, API transport, storage, accumulation, and display. A database's large-integer capacity does not prove that its calling runtime can transmit that entire range exactly.

Currency belongs in the record

ISO's currency-code introduction describes alphabetic and numeric ISO 4217 codes and the relationship between currencies and minor units. Do not assume every currency uses two decimal places; verify current maintenance-agency information before adding one.

Start with one confirmed currency. A later multi-currency version should preserve explicit codes and precision rules on records and report separate totals. Do not add different currencies together or relabel the combined number as one currency.

Conversion into a reporting currency introduces exchange-rate sources, dates, direction, rounding, and fees as additional requirements. Retain original amounts. Without a verified conversion source, omit the fictional unified total.

Reconcile expenses, refunds, and voids separately

A proposed report can show active expenses, active refunds, and expenses minus refunds as a net figure. Link a refund to its original expense; allow partial refunds but prevent cumulative refunds exceeding that confirmed amount, or route the discrepancy for review. These are simplified product rules, not a complete accounting standard.

For an expense of 12.50 with a 3.00 refund, show expense 12.50, refund 3.00, and net 9.50. Voiding an erroneous entry is different from receiving money back: retain the original ID and a reason instead of inventing a refund merely to subtract an amount. Category subtotals must use the same active-status and refund definitions.

Label reports with currency, transaction-date range, time zone, generation time, and metric definitions. Decide whether the period follows transaction dates or record-creation dates. Scheduled reports are outside this first version; see the scheduled notification guide. Whether editing the original message changes a confirmed entry follows a separate edit-confirmation policy; an edit should not become another expense.

Using BotFatherV2, and identifying custom work

As checked November 4, 2026, BotFatherV2 publicly supports AI-assisted creation and modification of Telegram Serverless bots, importing existing Serverless bots, publishing versions, and code rollback retaining current business data. The requested /en-US entry was inaccessible during verification; the accessible English homepage was used to check capabilities. Its Build with AI documentation includes persistent tools isolated by user in the initial scope. A structured expense-entry prototype is therefore a reasonable requirement to explore, after checking SDK fields, queries, and precision handling.

This is not a claim of a ready-made accounting module. The fixed SDK does not support arbitrary npm packages or Node/Bun APIs, and the initial release does not add paid-AI-dependent runtime capabilities. Natural-language or voice parsing, shared ledgers, Google Sheets/Notion, PDF/CSV export, tax workflows, and external deployments each need separate verification. AI-assisted development does not automatically provide model-based parsing after deployment.

If Python and a client-owned Linux VPS remain mandatory, evaluate an independent custom project; a Serverless artifact does not fulfill that delivery by default. BotFatherV2 operates independently of Telegram's official BotFather. Confirm the small record workflow and monetary capabilities, then generate a small version and test it in Telegram with sample data.

A first-version brief for an AI builder

Create a private-chat expense-entry prototype where each user can view and modify only their own records. Use one explicit currency and a confirmed decimal precision. Accept type, amount, category, date, and note; preview before confirmation. Reject ambiguous separators, missing amounts, excessive precision, and out-of-range values. First explain whether the current SDK supports exact amounts end to end, persistent records, and queries by currency and category. Identify gaps rather than hiding errors with display formatting. Link refunds to expenses and retain reasons for voids. Reports separate active expenses, refunds, and net totals. Exclude banking, spreadsheets, tax, model parsing, file exports, and scheduled delivery initially.

Reconcile a small sample before adding automation

• 0.10 plus 0.20 in active expenses totals 0.30, remaining consistent after a restart and new code release.
• A two-decimal ledger rejects 12.345. Commas, multiple amounts, zero, and negative inputs follow the declared policy rather than silently creating records.
• A 12.50 expense refunded by 3.00 produces the three figures 12.50, 3.00, and 9.50; excessive refunds are rejected or reviewed.
• Voids remain distinct from genuine refunds; category subtotals reconcile with the same report scope.
• A multi-currency extension keeps totals separate. Another user cannot access entries by guessing their IDs.
• Test individual and accumulated limits and period boundaries. A failed confirmation must not leave a partial entry counted in reports.

Sources and dates

• Freelancer, Telegram Business Accounting Bot, English client project 39751453. Checked November 4, 2026: Closed; absolute publication date unknown. Only the client brief is summarized, not bidder claims.
• SQLite project, Floating Point Numbers, English technical documentation without one publication date; checked November 4, 2026. Supports precision facts, not support for arbitrary SQLite types or extensions in BotFatherV2.
• ISO, ISO 4217 — Currency codes, English introductory page without a stated page-publication date; checked November 4, 2026. Supports currency-code and minor-unit concepts rather than certifying the proposed business rules.
• BitBear Studio, English homepage and Build with AI, capabilities checked November 4, 2026. The requested /en-US entry could not be retrieved during verification.