We Encoded 61 Indian Business Filings Into Software

A compliance engine is software that turns business law into a computed list: give it a handful of facts about a company — entity type, turnover, registrations, key dates — and it returns the exact filings that company owes, with deadlines, penalties and the provision each one comes from. This is the story of building one for Indian business filings, and what the law taught the code.

The short answer: sixty-one filings went into the model. About forty behaved like a specification — fixed dates, clean formulas. Twenty-one fought back: deadlines that move by circular, portals that contradict the guidance, dates anchored to meetings that haven't happened. The lesson is not that law can't be encoded. It's that the deterministic seventy percent is the easy part, and the remaining thirty — reading intent, resolving contradictions — is where the liability lives, so a practitioner reviews every deadline before a user ever sees it. The working result is our compliance fee calculator.

Sixty-one filings went into the model. Forty behaved like a spec. Twenty-one fought back. This is what we learned turning India's business compliance rules into working software — where tax law compiles cleanly, where it resists, and why a human still approves every deadline.

The problem that looked trivial

A compliance calendar looks like the easiest software on earth. Filing X, due on date Y, penalty Z. A spreadsheet handles it. An intern handles it.

Then you meet the actual rules. Due dates move by circular, sometimes days before the deadline. One penalty is "₹100 per day" and another is "₹50 per day, ₹20 for nil returns." A deadline is "30 days from the AGM" — a date that differs for every company and doesn't exist until the meeting happens.

Our goal was a system that produces the exact filings a business owes, with correct deadlines and penalties — not a generic checklist, the right list, computed. Sixty-one filings across MCA/ROC, income tax, GST, labour and FEMA — the same set you can browse as dates on the compliance calendar.

The data model that survived

Every filing became a record with the same shape. Five fields:

• Trigger — what makes this filing apply to you. Entity type, a registration you hold, a threshold you crossed.
• Cadence — monthly, quarterly, half-yearly, annual, or event-driven.
• Deadline rule — a fixed calendar date, a day-of-month, or an offset from another event.
• Penalty rule — a formula, never just a number. Per-day fees, tiered rates, nil-return exceptions.
• Authority — which regulator governs it, and which notification currently says so.

The surprise was how much fit cleanly. GSTR-1: monthly, due the 11th of the following month, applies to every GST registrant. GSTR-3B: monthly, due the 20th, late fee ₹50/day or ₹20/day for nil. GSTR-9: annual, 31 December. DPT-3: annual, 30 June, applies to companies with deposits or exempted borrowings. AOC-4: 30 days from the AGM. MGT-7: 60 days from the AGM. ADT-1: 15 days from the AGM. DIR-3 KYC: triennial since the March 2026 notification, next due 30 June 2028. Pure rules. They compile beautifully.

About forty of the sixty-one behaved this way. The rest taught us humility.

Where the law resists encoding

Deadlines that move by press release. Indian regulators routinely extend due dates through circulars — sometimes days before the original deadline, sometimes after businesses already filed. The statute didn't change. A notification did. So deadlines became versioned data in our model: the statutory date, plus an overlay of circulars that can shift it. A daily monitor scans regulator notifications for date changes. Every detection lands in a human review queue. Nothing goes live automatically. A wrong deadline pushed to users is worse than no deadline at all.

Circulars that contradict the portal. Occasionally a department issues guidance that conflicts with what its own filing portal enforces. When that happens, we encode the portal behaviour as the operational truth and annotate the conflict next to it. Software must file what the system accepts, not what the PDF says.

Relative dates with missing anchors. "30 days from the AGM" is simple arithmetic once you have the AGM date. For a new company that hasn't held one, the anchor doesn't exist. So the model needs a fallback — the statutory last date for the first AGM — plus a flag that says "estimate, confirm." We ended up marking every computed date with a confidence level: statutory, estimated, or confirmed by the user. Dates without provenance are just guesses with formatting.

"Months" that mean calendar months. In Indian company and trademark law, a month deadline means calendar months, not thirty days, and evidence clocks run from service dates, not order dates. We hard-coded the interpretation and cited the provision next to every such rule. If you can't cite it, you can't ship it.

Thresholds that phase in over time. Several filings apply above turnover or employee thresholds that change every few years, so the threshold itself became versioned data with effective dates. A company incorporated in 2023 and one in 2026 can owe different filings for the same activity. Time-travel in the data model — fun to build, extremely easy to get wrong.

The review queue is the product

We could have shipped a fully automatic engine. We chose not to, and the architecture reflects that choice.

The monitor finds a notification. A practitioner reads it, decides whether it changes any deadline, approves the change, and only then does the system update. To an engineer this looks like a bottleneck on a good pipeline. It is the entire point.

The reason is asymmetry of failure. If the engine misses a filing, the user pays the penalty. If it invents a wrong one, the user wastes a day and trusts the system less. Software is fast at computing dates and bad at reading regulatory intent — a circular titled "extension of due date" sometimes extends one form while quietly mentioning another.

So the loop is: machine computes, human approves, machine reminds. The engine never delivers a deadline to a user that a practitioner hasn't verified. That constraint shaped everything downstream — the approval interface, the versioning scheme, the audit trail. We built the review queue before the rule engine. We'd do it in that order again. It is the same principle we argue for in compliance by design: software carries the map, humans make the calls.

What we'd tell anyone encoding regulation

Start from the law, not the form. The statute gives you the real rule; the form gives you the current interface. Forms change every year, statutes rarely — anchor the model to the stable layer.

Version everything with effective dates. Deadlines, thresholds, fee rates, even whether a filing exists at all. Regulation is a time series, not a snapshot. If your schema can't answer "what was the rule on this date," it can't answer the questions users actually ask.

Separate the rule from the reminder. The rule says GSTR-3B is due the 20th. The reminder policy — nudge at T-15, T-7, T-1 — is a product decision. Mix them in one field and both become harder to change; we learned this by changing a reminder cadence and accidentally forking a deadline.

Cite the provision next to the computation. Every deadline carries its source — section, rule, notification number — so "why this date" is one click away. Writing the citation also forces the builder to check whether the encoded rule is the rule that exists.

Design for the contradiction. The system will eventually hold two true statements that disagree — circular vs portal, old notification vs new. Decide in advance which wins, and make the choice visible. Silent precedence rules are how bugs hide.

Your practical takeaway

Encoding law into software is mostly respecting what code can't do. Dates, fees and triggers are the easy seventy percent; the remaining thirty — reading intent, resolving contradictions — is where the liability lives. Build the machine for speed. Keep the human for meaning.

Questions readers ask us about the compliance engine

How does a compliance calendar actually compute a deadline?

Each filing is a record: trigger, cadence, deadline rule, penalty formula, governing notification. The engine matches your company's facts against the triggers, applies the deadline rule — a fixed date or an offset like "30 days from the AGM" — and returns the date with its source cited.

Why do due dates keep changing after the software ships?

Because regulators extend them by circular, sometimes days before the deadline. Deadlines are versioned data — statutory date plus a circular overlay — and a date moves only after a practitioner approves the change.

Can compliance software be fully automatic?

It can compute automatically. It should not publish automatically. A missed filing costs the user a penalty and a wrong one costs trust, so every deadline a user sees has passed a human review queue first. Machine computes, human approves, machine reminds.