A client’s books are the most sensitive thing a firm holds.
So this page describes exactly how Audcrix holds them — in terms a CA can check, test in a walkthrough, and put to a client who asks.
01
Each firm has its own instance and its own database
Not a shared database with a firm column in it. Every firm runs as its own application and its own Postgres, brought up and maintained separately — which is why a backup routine on the node has to discover each firm's database in turn rather than dumping one.
02
The Tally connection only ever dials out
A small agent on the client's machine opens a connection to Audcrix and waits on it. Nothing connects inward. No port is opened on the client's machine, no forward is configured and no firewall exception is made, because the direction is how the transport works rather than a setting that has to be kept right.
03
Backups are encrypted before they are written
Every database on the node is dumped nightly and piped straight through AES-256 encryption with a key that stays on the node. An unencrypted dump never lands on disk at any point in that process.
04
A person sees the clients they are allotted, and no others
The rule is applied on every route that names a client, not only on the list that displays them — and the list of such routes is re-derived from the application itself on each run rather than maintained by hand, because a hand-maintained list is one someone forgets to add to.
05
A client sees their own queries and nothing of the file
The portal identifies a client by a signed token rather than by an identifier in the address, no client identifier appears in any portal path, and a team's internal notes are never among what it can return.
06
The node is hardened, and the hardening is asserted rather than assumed
Firewall, intrusion banning and the SSH policy are checked by a script that fails loudly when any of them has drifted — including a check that the database port is not reachable from outside. A security control nobody verifies is a security control nobody has.
Shown, not asserted
Everything above is how the software is built rather than a promise about how it is operated, which means you can watch most of it in a walkthrough instead of taking it on trust. Ask to see the connector dial out with no port opened, ask what happens when a person opens a client they are not allotted, and ask where the backup key sits.
The parts that live in deployment rather than in the application are checked by scripts that fail rather than warn, because a control nobody verifies is a control nobody has.
Where your data lives
Each firm’s instance and database sit on infrastructure Audcrix operates, and the client’s accounting data is read from Tally on the firm’s own machine over the outbound channel described above. An on-premises arrangement, where the whole instance runs inside the firm’s own environment, is a separate conversation — ask, rather than assume it either is or is not available.
Questions this page should have answered
If something your firm needs to know is not here, that is a gap in the page rather than a question to avoid. Write to amshu@sahajaudtech.com or audcrix@gmail.com and it will be answered directly and added here.
Related: how an engagement runs, in Method.