The problem that
started it.
Running a growing practice across GST, ITR, TDS and ROC on desktop software designed for a single user meant one thing: September became chaos every year. Team coordination happened over WhatsApp. The client tracker lived in an Excel file. Status updates required calling someone.
When a widely used compliance tool was discontinued, the practices that depended on it had to scramble. Most of what was available was either too basic for a multi-module practice, too expensive for an independent professional, or built for a market with an entirely different compliance system.
taxfilo is the product that should have existed — cloud-native, team-aware, built around India's actual compliance system, and designed for how a practice operates rather than how a software vendor imagines it does.
Four positions we
do not trade away.
These are not marketing lines. Each one has cost us a feature, a shortcut or a quarter at some point, and each one is still here.
Tax software should never need an IT consultant.
If you have to call someone to install an update or recover your data, the software has failed you. Cloud-native means the platform looks after its own infrastructure so you never think about it.
Your clients' data belongs to you, not to us.
taxfilo claims no rights over anything you enter. Everything is exportable at any time in a readable format. We are custodians of that data, never owners of it.
No features that demo well and fail in September.
Every feature was designed against the peak-load case — forty returns due in fourteen days and a team that has to coordinate without a single phone call. If it only works in a quiet month, it is not finished.
Built in India, for India's compliance system.
Not adapted from a Western product. GST, ITR, TDS and ROC are India-specific, and the software that handles them should be built by someone who has actually filed them.
Written by someone who
files these returns.
“Every screen sequence matches how a practice actually works, not how a developer imagined the data model. We never simplify at the cost of correctness — full depth, clean surface.”
The test every feature has to pass is simple: does it save real time, prevent a real mistake, or improve a real client relationship? If it only looks good in a demo, it does not ship.
When a rule changes — a threshold, a form, a due date — it ships in days rather than in next year's version. Adapting fast to regulatory change is the whole point.
Regulatory change is the
only roadmap that matters.
The statute sets the schedule
When a notification lands, the change ships in days. There is no version to buy, no installer to run, and no window where half your office is computing on last year’s rules.
Depth before breadth
A module ships when it handles the real cases a practice meets, not when it can produce a return in the happy path. That is why modules arrive one at a time rather than all at once.
The workflow comes from the desk
Screen sequences are drawn from how the work is actually done — challan before deductee rows, client master before returns, enquiry before engagement. Not from the shape of the database.
Correctness is not negotiable
A wrong filing damages a professional reputation permanently. We would rather delay a feature than ship one that computes something almost right.
In beta, with practices
using it for real filings.
We are early and we say so. If you join now you get a direct line to the person building it, and the things you ask for tend to appear within weeks.
Practices already filing
Beta firms are running live GST, ITR, TDS and ROC work through the platform, not test data.
A direct line
Feedback goes to the person building the product. Most requests are discussed the same week they arrive.
Shipping weekly
The platform changes continuously. What you asked for in one filing cycle is usually there by the next.