What is TDL, and what does a Tally TDL developer actually do?
TDL, Tally Definition Language, is the language TallyPrime itself is built on for screens, reports and print layouts, and Tally Solutions opens it to developers so businesses can extend the product. A Tally TDL developer writes definitions that add to or modify what Tally shows and stores.
Tally describes TallyPrime Developer as its development suite for TDL programmers: an editor, a compiler and tools to package the code. The output is a Tally Compliant Product, a .tcp file, which Tally’s help pages define as a compiled and validated TDL project that TallyPrime can execute.
Day to day, the work looks like this: read how your staff use Tally, find the screens and reports involved, write definitions that alter them without touching data you did not intend to change, and test with your real voucher types. Good TDL is small and targeted. It changes one invoice format, not every print in the company.
A Tally TDL developer is not the same as a Tally partner or an accountant. Partners sell licences and support; CAs decide accounting treatment. The developer turns a business rule both of them agree on into something Tally enforces.
When do you need Tally customisation, and when is it overkill?
You need TDL when a rule or layout matters to your business every day and TallyPrime’s built-in settings cannot express it. You do not need it for things TallyPrime already configures.
Before paying for customisation, check TallyPrime’s own options. The configuration screens, voucher classes, print settings, multiple price levels, cost centres, batch tracking and user security levels cover a lot. A request that sounds like custom code can turn out to need only a setting switched on, and we tell you when that is the case.
TDL is the right tool when the need is specific to your trade: a garment unit that must print size-wise quantity grids, a transporter who needs vehicle and LR numbers on every bill, a distributor who wants credit sales blocked for parties past their limit. It is also right when the same mistake keeps recurring, because a validation stops it at the source instead of your CA catching it at quarter-end.
- Same manual workaround done many times a day: customise
- Customer or regulator expects a specific printed layout: customise
- Mistakes that cost money repeat monthly: add a validation
- Feature exists in F12 or voucher class settings: configure, don’t code
- Need involves other software or the internet: TDL plus integration
Yes, almost completely. A Tally TDL developer can change what appears on the invoice, where it appears, which voucher types use which layout, and how it fits your paper. It is also the change your customers notice first, because they see the invoice every time.
Typical changes include your logo and a signature image, bank details and a UPI QR code, extra item columns such as batch, MRP, size, colour or part drawing number, a transport block with vehicle number and e-way bill number, terms and conditions that vary by voucher type, and totals in words in Hindi or English. Layouts for pre-printed stationery need exact positioning, and A5 or thermal formats need a narrower design.
Two cautions. First, GST rules decide what a tax invoice must contain; the layout can move things around but should not drop mandatory details, and your CA should check the final sample. Second, if you use e-invoicing, keep the IRN and QR area that TallyPrime already prints, or place it deliberately in the new design. For the upstream e-invoice process, see e-invoice integration.
Adding extra fields to Tally vouchers and masters
A new field is a place to store something Tally does not track by default, such as salesperson, site name, vehicle number or warranty expiry. A TDL developer adds the field to the right screen, stores it with the voucher or master, and makes it usable in reports and prints.
The design questions are more important than the code. Should the field be mandatory? Should it offer a list (salespeople) or accept free text (site name)? Should it live on the voucher, on each item line, or on the party master so it fills automatically? A field on the party master that auto-fills the voucher saves more time than a field typed on every bill.
Fields added this way can later be read by integrations, for example sending the salesperson to a CRM. That needs matching TDL on the integration side, which is why we keep a written list of every field we add. If you plan to connect Tally to other software later, mention it now so field names stay consistent; our integration page explains why.
Custom reports: what Tally does not show out of the box
Custom reports answer questions the standard reports need three steps and an Excel export to answer. A TDL report can combine data from vouchers, masters and your custom fields in one screen, with drill-down to the voucher.
Common examples: collections by salesperson for the month, margin by item after scheme discounts, party ageing in your own buckets (0–15, 16–45, 46–90 days), godown-wise stock against reorder levels, and daily cash position across counters. Each can print, export to Excel, and open the underlying voucher with Enter.
Keep reports focused. A report that tries to answer every question becomes slow on a large company and hard to read. If the owner wants a report on a phone away from the office, TDL is the wrong tool; that is a job for a scheduled export, as described on Tally to Google Sheets.
Voucher validations: stopping mistakes before they are saved
A validation is a rule checked when a voucher is saved, which either warns the user or refuses to save until the problem is fixed. It is the most cost-effective kind of Tally customisation, because each rule prevents a repeat error permanently.
Useful rules to consider: sale rate below purchase cost, credit sale to a party beyond its limit or with bills overdue beyond a set number of days, missing GSTIN for a registered party, HSN missing on a stock item, a narration left blank on journal vouchers, a date outside the current month for users other than the accountant, and a discount above a percentage without a reason field filled.
We design each rule with a clear message in plain English or Hindi, so staff know what to fix. Rules can apply to all users or only some. Warnings suit grey areas; hard blocks suit mistakes that cost money or create GST trouble.
Approval flows inside TallyPrime
An approval flow holds certain vouchers in a pending state until a user with authority reviews them. TDL can implement this for cases such as large purchase orders, credit notes, heavy discounts or payments above an amount.
A simple design uses a status field on the voucher (pending, approved, rejected), a rule that prevents printing or posting effects until approved, and a report listing pending items for the approver. Multi-level approvals add levels by amount. The approver’s name and time are stored with the voucher for audit.
Approvals work best when approvers actually sit at Tally. If they are travelling, a notification on WhatsApp with a link to approve from a phone is more realistic, and that needs an integration layer outside Tally. We build both parts; see WhatsApp automation for the messaging side.
Will my old Tally.ERP 9 TDL work in TallyPrime?
Sometimes as-is, often with changes. Tally’s own note on Tally.ERP 9 customisations says the TCP format did not change, so compiled files still load without recompiling, but TallyPrime reworked the toolbar buttons, Gateway menus and the F11 features screen. Customisations that hook into those places need rework; plain reports and print formats more often carry across with smaller edits.
The safe path is to test every TDL on a copy of your data in the TallyPrime release you plan to use, before switching the live system. We list each customisation, what it does, whether it works, and what needs changing. Some old customisations are no longer needed because TallyPrime now does the job natively; retiring them reduces future upgrade effort.
The same applies to upgrades between TallyPrime releases. Tally keeps adding features: its JSON integration guide says Release 7.0 made JSON data exchange a default feature and recommends the JSONEx format for new integrations. New releases rarely break well-written TDL, but a test run on a copy is cheap insurance.
What is a TCP file, and how does TDL licensing work?
A TCP file is the compiled form of a TDL project, and it can be restricted to run only on specific Tally serial numbers. Tally’s help pages describe compiling a project in TallyPrime Developer into one TCP, and using the “Authorisation Required” build option to enable it only for chosen customer serial numbers.
Serial locking protects a developer who sells the same add-on to many businesses. For custom work paid for by you, it can become a trap: if the developer disappears and you change your Tally licence, the customisation stops working and nobody can rebuild it without the source.
Our default is to hand over the full TDL source and an unlocked TCP compiled for your use. If you want it locked to your own serial for internal control, we do that at your request. Either way, keep the source with your own records, not only with the developer.
How a TDL is loaded and managed in TallyPrime
A TDL is loaded either locally on each Tally installation or centrally as an account TDL. Tally’s help pages show the TDL Management screen under F1 (Help) and TDL & Add-On, also reachable with Ctrl+Alt+T, where local TDLs are managed.
Local TDLs are TCP or TDL files on the machine, listed in Tally’s configuration. Account TDLs are uploaded to Tally’s Control Centre and linked to one or more serial numbers through the Tally.NET ID, so every installation picks them up after a licence update. Account TDLs suit multi-branch businesses because a new version reaches every branch without someone copying files.
On handover we load the TDL with you on a screen-share, confirm it appears as loaded in TDL Management, and show your staff where to switch it off if they ever need to isolate a problem.
When several companies or branches share one customisation, plan for version control from the start. The same invoice format running in five places must be the same file, updated in one go.
Account TDLs deployed through Tally’s Control Centre suit this well, because each linked serial number picks up the new version after a licence refresh. Where branches use local TDLs, we name each release with a version number and date inside the TDL, so anyone can check which one a branch is running from TDL Management.
Differences between branches, such as a different bank account on invoices or a different approver, belong in settings rather than separate copies of the code. A Tally TDL developer who forks the code per branch leaves you with five things to maintain instead of one.
How much does a Tally TDL developer cost per customisation?
There is no honest single rate, because TDL work ranges from a column on an invoice to a multi-level approval system. We quote each customisation separately after seeing your sample, and automation bundles that combine TDL with external sending or syncing start at ₹40,000.
Quotes from different Tally TDL developers vary widely. The drivers are consistent, though: how many voucher types and print formats are touched, whether the change affects stored data or only display, how many users and rules are involved, whether existing TDL from another developer must be worked around, and how much testing your release and data need.
Cheap quotes sometimes skip testing on your data, deliver only a compiled file, or lock it to your serial number so every future change must come back to the same person. When you compare offers, compare these terms, not only the headline number.
- Display-only change (layout, column, label): lower effort
- New stored field used in prints and reports: moderate
- Validation rules across several voucher types: moderate
- Approval flow with levels and reports: higher
- TDL plus an outside integration: quoted as a bundle
How to brief a Tally TDL developer so the quote is accurate
Send examples, not descriptions. A photo of the invoice you want, marked up with a pen, is worth more than a page of text, and it is how we produce a quote you can trust.
- Your exact TallyPrime release and whether TSS is active
- A current invoice or report, and the version you want, marked up
- Which voucher types and companies the change applies to
- Rules written as “when… then…”, for example “when discount exceeds 10%, then require a reason”
- Who is allowed to bypass a rule
- Any TDL already loaded, with the developer’s name if known
- Whether other software will need to read the new fields
With this, a quote takes about two working days and is far less likely to change later. Without it, both sides guess.
How to choose a Tally TDL developer: questions and red flags
Choose the developer who asks the most specific questions about your data and hands over source code without argument. Portfolio screenshots are less useful than a clear answer on testing and ownership.
- Ask: will you test on a copy of my company in my release? The answer should be yes.
- Ask: do I get the TDL source? Refusal is a red flag for custom work you paid for.
- Ask: what happens after the next TallyPrime release? Expect a plan, not a shrug.
- Red flag: needs remote access to your live Tally to develop.
- Red flag: cannot explain which screens the change touches.
- Red flag: promises the change also fixes GST return issues.
We work remotely only, by screen-share, and never develop against live books. If you need someone to visit your office, a local Tally partner is the better choice for that part of the job.
Example: what a Tally TDL developer would build for a machine-parts manufacturer
Consider a hypothetical machine-parts manufacturer in Rajkot with one TallyPrime company, eight users, and three recurring headaches: invoices that do not show the customer’s drawing and PO numbers, discounts given by sales staff without approval, and a monthly Excel exercise to see which salesperson collected what.
A Tally TDL developer would add a drawing number field on each item line and a PO number and date on the voucher, both printed on a redesigned invoice. A validation would hold any sales voucher with a discount above an agreed percentage until the owner approves it from a pending list. A salesperson field on the party master would auto-fill vouchers and feed a collections report by salesperson and month.
In this scenario, the quote would list four items: invoice format, item and voucher fields, discount approval, and the report. Build and testing would take roughly two to three weeks on a copy of their data, followed by a week where staff use it live while old invoices stay available.
Where TDL stops and other tools take over
TDL is excellent inside Tally and awkward outside it. Once a need involves the internet, other software, many simultaneous users on phones, or heavy processing, pair TDL with a separate program.
Sending invoices on WhatsApp, syncing with a website, feeding a CRM, showing dealers their ledgers online, or reading bank PDFs all work better as an outside service that uses Tally’s XML or JSON interface, with a small TDL for buttons or fields. Our sibling pages cover each: WhatsApp sending, store orders and bank statements.
And if the business has outgrown what any accounting package should do, such as production planning or field service, a dedicated app talking to Tally beats forcing TDL to do it. See moving from spreadsheets to software for that decision.
Working with a remote Tally TDL developer: what a normal week looks like
Remote TDL work runs on backups and screen-shares rather than office visits, and for most customisations that is faster, not slower. You keep your live Tally untouched while the Tally TDL developer works on a copy.
On day one you share a recent backup of the company (or a trimmed copy if the data is sensitive), your release number and the samples. We restore it on a test machine running the same TallyPrime release. From then on, every question comes with a screenshot: “this voucher type, this field, should it be mandatory for cash sales too?” Answers on WhatsApp are enough; we do not need long meetings.
Midway through, you see a short screen-share demo with your own vouchers. Feedback at this point is cheap to act on. Near the end, the TCP is loaded on one live machine for a day or two before it goes to all users. Calls happen in Hindi or English, whichever your accounts team prefers, and all changes are written into a change list you keep.
What a remote Tally TDL developer cannot do is fix a printer driver, install Tally on a new PC or sit with staff for a morning of training. For those, a local partner or your own IT person is the right call, and we coordinate with them happily.
Tally TDL customisation checklist before go-live
Run through this with your developer before the TDL is loaded on the live system. It prevents the common surprise of a customisation that works on the developer’s copy and fails on yours.
- Tested on a recent backup of your company, in your release
- Every affected voucher type and print format checked
- Validations tested for both allowed and blocked cases
- Users with bypass rights confirmed
- Your CA has signed off invoice layouts
- Source code and TCP saved in your own storage
- A written list of added fields and changed screens
- Staff shown how to disable the TDL in TDL Management if needed