What Praxida does

Eight modules, each built because a chartered accountancy practice needs it to close a month — not because it looked good on a feature list.

Compliance calendar

The work appears before anyone has to remember it.

Record which registrations each client holds — GST, TDS, income tax, and the rest — and Praxida generates that period’s statutory task from the calendar automatically.

Generation is calendar-driven, not chained to the previous period being completed. This matters more than it sounds: in a completion-chained system, one filing that stalls in June silently stops July, August and September from ever being created, and nobody notices until a notice arrives.

Each task carries its financial year, period type and period key, so the same return for the same client and the same period can never be created twice.

Filing status grid

Every client against every period, on one screen.

The grid answers the question a partner actually asks — which of my clients have not filed yet — without opening a single client record.

Filter by registration, period or status. Outcomes are recorded against each filing, so the grid reflects what was actually done rather than whether someone remembered to tick a box.

Tasks with a real review stage

Work moves through stages the firm already recognises.

Created, assigned, in progress, waiting on client, under review, completed, archived. A partner can require review before anything is marked done, so nothing reaches a client without a second pair of eyes.

The stage machine lives in the database, not in the interface, and task status is derived rather than settable — so a stage cannot be skipped by anyone poking at the API. Every transition is written to an immutable history.

Client portal

Stop chasing documents over WhatsApp.

Each client gets a login that shows only their own records, and only the items you have explicitly marked visible to them. There is no setting that accidentally shows one client another’s data — the restriction is enforced in the database.

Clients see what is pending, upload what you asked for, and work through a document checklist. They can see their invoices and what is outstanding.

Documents and versioning

A permanent file that stays organised on its own.

Documents are stored privately and served only through an authenticated, authorisation-checked request. Uploading a new version keeps the old one and resets approval to pending, so a replaced document is never silently treated as already approved.

File types are validated by content rather than by filename, and downloads are forced as attachments.

Billing and receivables

Fees tracked where the work already lives.

Rate cards per client and service, invoices with GST fields and SAC 9982, and receipts that record TDS deducted under section 194J.

An outstanding ledger per client and across the firm, plus a fees-hold flag that surfaces on the task and the filing grid — so whoever is doing the work can see that the client has not paid.

DSC and UDIN registers

The registers a practice is expected to keep.

The DSC register tracks which digital signature certificate is where, who is holding it, when it was issued and when it expires — with movement recorded rather than remembered. Expiry reminders come automatically.

The UDIN register records UDINs alongside ARNs for filings made, so the number and the filing it belongs to stay together.

Team and permissions

Article assistants should not see the fee ledger.

Departments, roles and a per-employee permission editor let you decide exactly what each person can see and do — down to individual capabilities such as viewing billing or approving documents.

Permissions are resolved inside the database as part of the security policy, not checked in the interface, so they hold even against direct API access.