Most Indian contractors already run Tally for books and GST — the question isn't whether to replace it, but what to use for everything Tally was never built to track.
Tally is a genuinely good accounting and GST compliance tool, and it is deeply embedded in how Indian SMBs handle books, invoicing and tax filing — construction contractors included. This is not a case for replacing it. It is a case for recognizing what it was scoped to do, and what it was not.
Tally has no native concept of a BOQ, a site log, planned-vs-executed quantities, material reconciliation against work done, equipment utilization, or a measurement book. A contractor entering purchase invoices in Tally has accurate books — and zero visibility into whether the cement bought against those invoices matches what the site should have consumed for the work completed.
The two tools solve different layers of the same business: Tally for statutory books, GST returns and financial statements; a construction-specific system for the operational layer — site progress, material and labour cost control, BOQ tracking — that ultimately feeds accurate numbers back into the books. Most contractors running both find the construction layer is what was missing, not a replacement for their accounting system.
| Feature | Rebota | Tally |
|---|---|---|
| GST-compliant accounting & filing | Basic tracking | ✔ Purpose-built, industry standard |
| BOQ tracking | ✔ Built in | ✘ No native concept |
| Site-level material reconciliation | ✔ Built in | ✘ No native concept |
| Daily site progress logs | ✔ Built in | ✘ No native concept |
| Equipment cost & utilization tracking | ✔ Built in | ✘ No native concept |
| Measurement book (MB) | ✔ Built in | ✘ No native concept |
| Mobile, field-friendly usage | ✔ Designed for site use | ✘ Desktop-oriented workflow |
Contractors already running Tally for accounting who have no structured way to track BOQ consumption, site progress, or material reconciliation against what was purchased — i.e., the books are fine, but nobody can answer "what actually happened on site" without calling someone.
A contractor with a single small project, or one whose Tally usage is already minimal (a bookkeeper handles it monthly), likely doesn't have enough operational complexity yet to justify a second system — the reconciliation pain has to actually be felt before the switching effort is worth it.
For statutory accounting, GST filing and financial statements, Tally is purpose-built and industry-standard — Rebota tracks GST on purchases/billing for reconciliation visibility, but does not replace a dedicated accounting workflow or a CA's filing process. If all you need is books and filing, Tally alone is the right and sufficient tool.
A single project with a small team and low material value can often be tracked in a well-maintained spreadsheet alongside Tally — the case for a dedicated system strengthens with project count and value, not as a universal starting point.
This is rarely an either/or choice. Keep Tally for books and GST; add a construction-specific system once BOQ/material/cash-flow tracking has outgrown what a spreadsheet next to Tally can reliably hold together.
Contractors who run both tools well keep a clean boundary: Tally owns the statutory ledger (GST returns, vouchers, financial statements), and the construction-specific system owns the operational ledger (BOQ, site progress, retention, cash flow timing) that feeds accurate numbers back into Tally rather than being reconstructed from it after the fact. The failure mode to avoid is treating Tally as the source of truth for project profitability — it can only show what was invoiced and paid, not what retention is currently locked up, what a payment delay is costing in financing terms, or whether material purchases match BOQ consumption.