What is Tally WhatsApp integration, and what can it actually send?
Tally WhatsApp integration is a link between TallyPrime and the WhatsApp Business platform that delivers accounting documents to customers and suppliers without anyone downloading, saving and forwarding files by hand. The accounting stays in Tally; WhatsApp becomes the delivery channel.
In practice the documents fall into three groups. The first is transaction copies: sales invoices, credit notes, receipts and delivery challans sent the moment they are created. The second is statements: a party’s ledger for a period, or a bill-wise outstanding statement showing which invoices are still open and how old they are. The third is reminders and short notices: a text message with the amount due and a link or attachment, sent on a date rule rather than after a voucher.
Each of those needs something different from Tally. A copy of one invoice needs the voucher, the party’s mobile number and a print layout. A statement needs a report generated for a date range. A reminder needs bill-wise details and a rule for when to stop. A good Tally WhatsApp integration handles all three with the same number, the same template library and one log, instead of three separate tools bolted on over time.
What it does not do: it does not change your accounting, post entries on its own, or replace your CA’s review. It reads and sends. If you want data flowing into Tally from a website or a store, that is covered on connecting Tally with other software.
Does TallyPrime have WhatsApp built in?
Yes. Tally Solutions’ help pages say WhatsApp for Business arrived in TallyPrime Release 4.0, and it lets you share vouchers and reports from inside TallyPrime as PDFs or images. For many small shops, that is enough and costs nothing extra to build.
The same pages list what it needs and where it stops. You need a paid TallyPrime licence with a valid TSS (Tally Software Services), plus a WhatsApp subscription arranged through Tally, and Meta charges for messages under its normal WhatsApp Business pricing. Tally’s FAQ says the feature does not send to WhatsApp groups, does not schedule messages, sends one attachment per message and is not available through the Tally remote client.
Those limits are where a custom Tally WhatsApp integration earns its cost. If you need statements to go out automatically on the first of the month, a delivery log in your own database, invoices in a customised layout, reminder rules that stop after payment, or sending from an older Tally release, you are past what the built-in option was designed for.
Our advice is simple: if your staff share maybe a few dozen bills a day one by one, and your TSS is active, try the built-in option first. If you run a distribution business, a wholesale counter or a CA practice sending hundreds of statements, read on.
Three ways to build a Tally WhatsApp integration
There are three architectures in use, and most products on the market are one of them in different packaging. Knowing which one you are buying tells you what will break and who controls your data.
1. Tally’s own feature
Runs inside TallyPrime with Tally’s WhatsApp subscription. Least setup, fewest options. Good for manual one-by-one sharing.
2. TDL add-on that sends directly
A TDL file loaded into TallyPrime generates the PDF and calls a WhatsApp API from inside Tally. Quick to use, but everything happens on the billing PC while the user waits, and logging is basic.
3. TDL trigger plus an API bridge
A small TDL add-on only adds the button or the save hook; a separate service on the same machine or network does the heavy work: pulling data over Tally’s XML interface, making the PDF, sending, retrying and logging. This is what we usually build.
The third route takes longer to build than the second, but it survives real conditions: slow internet at the counter, a hundred ledgers at month-end, Meta returning an error for one number, or a staff member closing Tally mid-send. A bridge can queue work and finish it later; a TDL-only add-on usually cannot.
TDL add-on or API bridge: which Tally WhatsApp integration fits you?
Choose a TDL-only add-on when volumes are low, one PC does the billing, and you only need manual sending. Choose a bridge when anything is automatic, when several PCs bill into one Tally company, or when you need a record of what reached whom.
TDL (Tally Definition Language) is Tally’s own customisation language. It is good at adding buttons, fields and print layouts inside TallyPrime, and our TDL customisation work covers that side. It is less comfortable with long network calls, retries and storing hundreds of delivery statuses, which is ordinary work for a small Node.js or Python service.
The bridge talks to Tally through the XML-over-HTTP interface that TallyPrime exposes when you enable it (Tally’s documentation gives port 9000 as the default). It asks Tally for the voucher or report, receives structured data, and never needs your Tally login or a copy of your company data folder.
- One billing PC, under about 50 bills a day, manual sending: TDL add-on or Tally’s own feature
- Auto-send on save, or several billing PCs: TDL trigger plus bridge
- Month-end statements for hundreds of parties: bridge, run on a schedule
- Reminders that stop when a receipt is posted: bridge reading bill-wise details
- Replies from customers handled by a team: bridge plus a shared inbox
How the invoice PDF is generated from a Tally voucher
The PDF is either printed by TallyPrime itself or rebuilt by the bridge from the voucher data; both work, and the choice depends on how customised your invoice already is. If your current print format is what customers expect, we keep it.
Tally-rendered PDFs use the same print definition you already use on paper, including any TDL changes a partner made years ago. The add-on asks Tally to export the voucher to PDF in a working folder, and the bridge picks the file up. This guarantees the WhatsApp copy matches the printed copy line for line.
Bridge-rendered PDFs pull the voucher as data (party, GSTIN, items, HSN, tax split, totals) and lay it out with an HTML template. That gives cleaner mobile reading, room for a UPI QR code for the exact bill amount, and the same layout across multiple Tally companies. It also means the layout must be maintained separately if you change your invoice later.
Either way, a few details matter more on WhatsApp than on paper: the file name should carry the invoice number and date so customers can find it in their chat, the PDF should stay small enough to open quickly on a low-end Android phone, and the first page should show the amount due without scrolling. Meta’s Cloud API documentation allows media files up to 100 MB, so size is never a hard limit for invoices; readability is.
Is it safe to use unofficial Tally WhatsApp software?
No, not for a business that relies on its number. Unofficial tools work by automating an ordinary WhatsApp or WhatsApp Business app login on a PC or phone, which WhatsApp’s terms do not allow, and numbers that send many automated messages this way are regularly restricted or banned.
These products are popular because they need no Meta verification, no templates and no per-message charge, and many can post into groups. The trade-offs appear later: the tool stops when WhatsApp updates its app, messages go out from one staff phone that must stay connected, there is no dependable delivery status, and the number your customers know can be blocked on a busy day.
The official route is Meta’s WhatsApp Business Platform, used either directly through the Cloud API or through a Meta partner. It needs a verified business, a registered number and pre-approved templates for messages you start. Since 1 July 2025, Meta charges per delivered template message by category, and its pricing page says utility templates sent inside an open customer service window are free. Our WhatsApp API cost guide for India explains the categories.
Every Tally WhatsApp integration we build uses the official Cloud API in your own Meta business account. If a vendor cannot tell you which route their add-on uses, assume it is the unofficial one.
How to send ledgers and outstanding statements in bulk at month-end
A month-end run works best as a scheduled job that builds one statement per party, checks it, sends it through a utility template and writes a report, rather than a staff member pressing send two hundred times. For a business with many credit customers, this is where staff hours pile up, so it repays automation quickly.
The run starts from a list: all sundry debtors with a closing balance above a threshold you choose, or only one group such as “Retailers – Zone 2”. For each party the bridge asks Tally for the ledger or bill-wise outstanding report for the period, renders the PDF and checks three things before sending: that a valid mobile number exists, that the balance is not zero, and that the party has not been marked “do not send” in a custom field.
Sending is paced rather than fired all at once, which keeps the run inside Meta’s messaging limits and makes failures easier to read. At the end, the accounts team gets a summary: sent, delivered, read, failed with reason, and skipped with reason. Parties whose messages failed are listed with their ledger names so someone can correct the number in Tally.
- Run on a fixed date, or on a button once the month is closed
- Choose the report: ledger, bill-wise outstanding, or both
- Skip parties below a balance you set, or with no mobile number
- Pace messages and retry temporary failures once
- Email the summary to the accounts head
One-click sending vs automatic sending on voucher save
One-click keeps a person in control of every message; automatic sending removes the chance of forgetting. A sensible split for many offices is automatic sending for sales invoices and one-click for everything else.
With one-click sending, the add-on shows the party’s saved number, lets staff pick another number for this bill, and sends. It suits businesses where invoices are often edited after creation, or where some customers prefer not to receive bills on WhatsApp.
With automatic sending, the add-on hands the voucher over as soon as it is accepted. We usually add a short delay so a quick correction does not produce two messages, and a rule set: skip cash sales, skip parties in a certain group, skip vouchers of a certain type, send a revised copy with “Revised” in the caption if the voucher is altered later.
The awkward case is deletion. If a voucher is deleted after the WhatsApp copy went out, no system can pull the message back. The log records it, and the team decides whether to send a short cancellation note. That kind of rule is agreed in the scoping call, not discovered in week three.
Delivery logs: proving the customer received the invoice
A delivery log is a record of every message with the voucher number, party, number, time and the status Meta reported back: sent, delivered, read or failed. It turns “we sent it on WhatsApp” into something you can show during a payment dispute.
The statuses arrive from Meta through webhooks, a few seconds to a few hours after sending, and not always in order. The bridge stores each update against the message ID and keeps the latest one. Read receipts depend on the customer’s privacy settings, so “delivered but not read” is common and not an error.
The log lives in your database, with a simple screen to search by party, invoice number or date. If you would rather open it as a sheet on your phone, that works the same way as our Tally to Google Sheets reporting. Failed messages carry Meta’s error reason, such as a number that is not on WhatsApp, so staff fix the ledger master instead of guessing.
WhatsApp templates for Tally invoices, ledgers and reminders
Every message your Tally WhatsApp integration starts must use a template approved by Meta, and invoices, statements and reminders normally qualify as utility templates because they relate to a transaction the customer already made. Getting the wording right is what gets them approved first time.
A typical set has five templates: new invoice with PDF, revised invoice, monthly statement, gentle reminder before the due date, and overdue reminder. Each has variables filled from Tally, such as party name, invoice number, amount and due date. Templates can be in English, Hindi or both; if most of your buyers read Hindi, a short Hindi line with the amounts in numerals is quick to scan on a phone.
Things that get utility templates rejected or reclassified: sales pitches added to the end of an invoice message, vague wording like “important update”, and variables placed at the very start or end of the text. Keep promotions for separate marketing templates, which Meta prices differently.
- Invoice: party name, invoice number, date, amount, PDF
- Statement: party name, period, closing balance, PDF
- Reminder: invoice number, amount, due date, how to pay
- Overdue: days overdue, amount, a number to call
How much does Tally WhatsApp integration cost?
With BtechWaleTech, a Tally WhatsApp integration starts at ₹40,000 as a one-time build, plus Meta’s per-message charges paid directly by you. The final figure depends on how many document types, triggers and rules you need.
Quotes in this market vary widely, and it helps to know why. A licence for a ready add-on looks cheap because it is the same file sold to everyone; you pay later if you need a change. A custom build costs more upfront and does exactly what your office does. Hidden costs to check in any offer: a monthly platform fee on top of Meta’s charges, a per-message markup, TSS renewal needed for Tally’s own feature, and whether changes after delivery are billed.
The scope drivers are predictable: number of Tally companies and billing PCs, whether PDFs keep your existing Tally format or get a new layout, auto-send rules, month-end runs, reminder sequences, a reply inbox, and whether you already have a verified Meta business. If you are starting from zero on Meta, allow time rather than money for verification.
Tally runs on an office PC: where does the integration live?
The bridge runs on the same PC as Tally or on another machine in the office network, and it only needs outgoing internet access to reach WhatsApp. Your Tally data never has to move to the cloud.
Because Tally’s XML interface listens on the local network, the bridge can talk to it without opening any port to the internet. Outgoing messages go to Meta over HTTPS. The one piece that must be reachable from outside is the webhook that receives delivery statuses; we host that small receiver on inexpensive cloud hosting in your name, and the office bridge collects statuses from it.
If Tally is closed or the PC is off, the queue waits and resumes. For businesses running Tally on a rented cloud server, the same design applies with fewer moving parts. The wider question of syncing Tally with stores, CRMs and apps is covered on our Tally API integration page.
Who owns the number, templates, code and customer data?
You do. The Meta business portfolio, WhatsApp Business account, phone number, templates and payment method are created under your business, and the add-on and bridge code are handed over with your source files.
We set up the Meta side with you on a screen-share so passwords stay with you, and use a system user token that you can revoke. The delivery log sits in your database. If you move to another developer, they receive the code, the setup notes and the template list, and nothing stops working when our access is removed.
On data: invoice PDFs contain names, GSTINs, amounts and sometimes addresses. The bridge deletes working files after sending, keeps only the log fields you agree to, and never copies the Tally company folder. Customer consent to receive bills on WhatsApp is your responsibility; we add a field in the ledger master so you can record who opted in.
Red flags when buying a Tally WhatsApp module
The biggest red flag is a module that sends from a phone or desktop WhatsApp login, because your number carries the risk. Ask plainly, and ask for it in writing.
- “No Meta approval needed” or “post into any of your existing groups”: almost always an unofficial route
- The WhatsApp number or Meta account is registered to the vendor, not you
- No delivery status, only “message queued”
- Per-message price from the vendor with no mention of Meta’s own charges
- A TDL file supplied only in compiled form with no promise of updates for new TallyPrime releases
- The vendor needs your Tally company data copied to their server
- No way to stop reminders once a bill is paid
None of these mean a product is useless, but each one moves risk onto you. For a wider view of automation tools and how to judge them, our WhatsApp automation page goes further.
Example: a Tally WhatsApp integration for a textile wholesaler
Take a hypothetical saree wholesaler in Surat with two billing PCs, one Tally company, around 180 retailer accounts across Gujarat and Maharashtra, and a manager who spends the first three days of every month sending statements from his own phone.
The build would start with Meta verification and five utility templates in English and Hindi. A TDL add-on adds a send key on sales vouchers and an auto-send switch that skips cash bills. A bridge on the accounts PC reads each accepted voucher over Tally’s XML interface, renders the PDF from the existing print format, and sends it. On the second of each month it runs statements for every retailer with an open balance, then emails the manager a list of failures.
A reminder rule reads bill-wise due dates and sends one polite note three days before, and one after fifteen days overdue, stopping as soon as a receipt is posted against the bill. That is a four-week project in this scenario: most of week one is Meta verification, and week four is a parallel run where staff still send manually and compare.
What the owner gets is not a new habit for staff but the removal of one: nobody downloads, renames and forwards a PDF again.
Checklist before you start a Tally WhatsApp integration
Most delays in a Tally WhatsApp integration come from missing basics rather than code. Sort these out first and the build moves in weeks, not months.
- Which Tally release you run, and whether your TSS is active
- How many Tally companies and billing PCs send documents
- A number to use for the API that is not active on the WhatsApp app, or a plan to move it
- Legal business name, website and registration document for Meta verification
- Mobile numbers stored consistently in ledger masters (one field, with country code)
- Sample invoice, ledger and outstanding statement you want customers to see
- Which vouchers auto-send, which never send, and who approves exceptions
- Who reads customer replies
If mobile numbers are scattered across address lines and notes, we can clean them in a one-time pass. Businesses that also bring sales data in from spreadsheets should look at importing Excel data into Tally so numbers arrive in the right field from day one.
How long a Tally WhatsApp integration takes, week by week
Two to four weeks from approval to go-live is typical, and Meta’s reviews set the pace more than coding does. A business with a verified Meta account already can be live in about two weeks.
Week one covers Meta setup and template drafting, plus reading your Tally data: voucher types, print format, where numbers are stored. Week two builds the add-on and bridge against a copy of your company on a test machine. Week three connects to live Tally with sending limited to your own staff numbers, then a small group of friendly customers. Week four is the parallel run and handover. Month-end runs are tested on the first real month-end after launch, with us watching the log.
You get the source code, a short guide for staff, and a written note of every rule. The next two months of fixes and small adjustments are free.