Roz. Your shop.
One conversation.
Everyday bookkeeping, right inside Telegram.
A message.
A review. A record.
Three ways to prepare the same review. Every route leads back to the shopkeeper’s confirmation. No computer required. Customers only use Telegram.
Sale · PKR 1,200.00
Paid PKR 1,200.00 · cash
Sold 1200 cash
Nothing is saved until you tap Save.
Configured on the server
Send a short entry in English, Urdu script or Roman Urdu. Examples include “sold 1200 cash” and “expense 350 electricity.” You can type even when speaking is inconvenient. The current parser handles supported transaction phrases; it does not treat every free-form conversation as an accounting instruction.
- Send one entry
- Say what happened, the exact amount and how it was paid.
- Check the details
- Review the amount, payment account and person when relevant.
- Save when it is right
- Confirm with Save, resend with Change, or leave it with Cancel.
How review and confirmation work
Send one completed transaction, such as “sold 1200 cash.” Roz prepares a short review showing the amount, transaction type, payment account and customer or supplier when relevant. Save confirms it, Change lets you resend it correctly, and Cancel leaves the books untouched. An unclear message asks for clarification instead of becoming a guessed entry.
The Telegram visuals on this page are illustrations using implemented response text and fictional amounts. They are not captures of a live customer conversation.
Know what should be in the till.
Type “today,” “report” or /today to see recorded sales, stock purchases, expenses, customer collections, supplier payments and owner withdrawals. The reply also shows expected cash, what customers owe and what is owed to suppliers. Everything arrives in the same Telegram chat.
- Opening cash
- PKR 10,000
- Cash sale
- + PKR 1,200
- Electricity paid
- − PKR 350
- Expected cash
- PKR 10,850
Fictional example · Recorded cash balance
Count the till. Compare. Confirm.
Cash closing and this example
Suppose a fictional shop opens with PKR 10,000, records a PKR 1,200 cash sale and pays PKR 350 for electricity. Its expected cash is PKR 10,850. The day’s sales are PKR 1,200. Those are different figures, and neither is automatically the shop’s profit.
Count the physical cash, then send /close followed by the amount, such as /close 10800. Roz shows the expected cash, counted cash and difference for confirmation. In this example, the till is PKR 50 short. Saving the count preserves that observation; it does not silently change the books to hide a discrepancy.
Revenue is not profit. A reliable profit calculation also needs the cost of the stock sold. Roz does not invent that cost, infer losses from sales alone, or claim to prepare statutory financial statements or tax returns.
See the Telegram report preview
The Telegram visuals on this page are illustrations using implemented response text and fictional amounts. They are not captures of a live customer conversation.
The ordinary transactions that make up a day.
Keep sales, purchases and payments separate so money collected is not mistaken for new revenue. These are fictional examples of supported text entries, not buttons that create records.
Cash sale
sold 1200 cashRecords the sale and cash received.
Sale on credit
sold 1200 credit to AliRecords revenue and what Ali owes, without inventing a cash receipt.
Stock purchase
bought 2400 cashRecords stock bought and the cash paid. Purchases are kept separate from everyday expenses.
Shop expense
expense 350 electricityRecords an electricity expense. Cash is the default for this phrase and is shown in the review.
Customer payment
received 500 cash from AliReduces Ali’s existing debt. It does not count the same sale again.
Supplier payment
paid 700 cash to AhmedReduces an existing supplier balance rather than creating another stock purchase.
Owner withdrawal
withdrew 300 cashRecords cash taken by the owner separately from shop operating expenses.
Opening cash
opening 10000 cashEstablishes the starting cash balance before comparing the till with the books.
Your confirmation.
Your record.
You stay in control. Roz only posts what you approve, and preserves the history.
49 automated tests. Real-world voice and document accuracy still to validate.
Review before every financial entry
A proposed entry changes no balance until the owner confirms it. Check the amount, account and person in the review; an owner can still confirm a mistaken value, so review remains essential.
Exact accounting, separate from extraction
Amounts are kept in exact rupees and paisa. The accounting engine calculates balances and requires each saved entry to balance. AI services can propose an entry; they cannot calculate the books or post a transaction on their own.
Repeated saves and corrections
Repeated delivery and repeated Save requests are checked to avoid posting the same entry twice. Corrections add a reversing entry and preserve the original history. They cannot erase a transaction or turn a settled debt into an impossible balance.
Honest delivery and reliability
A delayed or uncertain reply is treated as something to investigate. Passing automated tests does not guarantee error-free accounting, message delivery, transcription or invoice reading. A supervised shop pilot and daily reconciliation are still required.
Private processing, with a clear Telegram boundary.
Voice and photo integrations are designed to use configured self-hosted services, with no automatic fallback to an external AI service. Raw files are processed in memory or temporary private storage rather than kept as a permanent media archive. Message text, proposed entries and confirmed books are retained for review by the shop and its administrator.
Telegram still receives and processes the conversation. Bot chats are not end-to-end encrypted; self-hosting the reading services does not change that. Customers should understand that boundary, avoid sending identity documents, card details or passwords, and know who administers their records. Retention, deletion and backup policies must be agreed before a real pilot.
“Today” means the shop’s day.
For this Pakistan release, daily reports and cash closing use Asia/Karachi. The day runs from midnight in Pakistan up to, but not including, the following midnight. The server’s country and timezone do not choose the reporting date.
At 19:30 UTC, it is already 00:30 the following day in Pakistan, so “today” refers to that new local date. Midnight, month-end and year-end checks were tested with the application and database set to different timezones. Other countries will need an explicit timezone for each shop; automatic country detection and multi-country settings are not available yet.
- Text bookkeeping
- Server deployed
- Voice & invoice reading
- Not connected
- Real-shop pilot
- Next
The next useful step is to test everyday sales, credit, expenses and cash counts with an owner and their bookkeeper, then compare the records with real receipts and the till. Tell me about the shop’s language, workflow and busiest moments so the pilot tests the work that matters.
A closer look.
Built around the shopkeeper’s day.
A small shop runs on hundreds of ordinary decisions: cash taken over the counter, stock bought from a supplier, electricity paid, and a customer who will settle later. When those details live in memory, scattered messages or a notebook, the owner has to reconstruct the day before knowing where the money went.
Roz brings that work into a familiar Telegram conversation. Customers use their phones, with no accounting dashboard to learn and no computer required. The aim is to make everyday records easier to keep while preserving the owner’s control over what enters the books. The first version focuses on owner-operated shops in Pakistan and amounts in Pakistani rupees.
Familiar language, with clear limits.
The initial text interfaces are English, Urdu script and Roman Urdu. Customers can switch language in the chat by typing English, اردو or Roman Urdu. They do not need to use voice to keep their books.
Text support does not establish speech recognition or document-reading accuracy in those languages. Before enabling those inputs for paying users, the system needs representative recordings, receipts and invoices from real shops, with particular attention to exact amounts, payment methods and names. Unsupported or ambiguous input should lead to a clearer entry, not a confident guess.
Customers stay in Telegram. Administration stays separate.
The private web workspace is for the operator to manage shops, memberships and subscriptions, review message-processing problems and inspect audit history. It is not a customer dashboard. Memberships are currently managed manually; automatic billing and payment collection are not enabled. Customers can still ask for their reports when a membership expires, while saving new entries requires an active membership.
Deployed on the server
The administrator workspace and Telegram message worker run on the server with persistent storage. The bot’s HTTPS webhook points to that deployment. Shop onboarding, supported multilingual text entries, review and confirmation, daily reports, debt tracking and cash closing are implemented. A supervised real-shop pilot remains ahead.
Verified so far
49 automated tests cover the ledger, exact amounts, duplicate posting, access boundaries, corrections and local-day reporting. Server sign-in, access restrictions, health and record persistence after redeployment were checked separately. These checks provide evidence about tested behavior, not a guarantee that every real shop scenario is covered.
Still to validate
The speech and photo-reading services need connecting and evaluation. A full real-shop pilot, owner-message delivery checks, representative voice and invoice accuracy checks, and backup restoration remain ahead. This page makes no claim of a completed customer pilot or certified accounting compliance.
The Telegram visuals on this page are illustrations using implemented response text and fictional amounts. They are not captures of a live customer conversation.