Audit tools for the work that's actually painful.

Your data never leaves your laptop. Every tool on this site is a single HTML file with JavaScript that runs entirely in your browser tab. There is no upload, no server call, no cloud LLM processing.

Want to verify? Open the Three-Way Match tool, then open your browser's Network tab (F12 → Network). Run a full audit on sample data. You will see zero outgoing network requests during analysis. The only network activity is the initial page load of the HTML file itself, after which you could literally disconnect your laptop from the internet and the tool would still work.

Close the browser tab and nothing persists. The next time you open the tool, your previous file and findings are gone. This is by design.

The honest answer: I built this for the article version of me. Three years at S.P. Chopra and I spent hundreds of hours on Excel work that should have taken minutes. I'm building these tools as a portfolio piece and because they genuinely help people I care about (articles, finalists, qualified CAs in small and mid-size practice).

No login walls. No tracking. No selling your email. If I ever need to charge for something heavy (a server-side processing tier for 100K+ records, custom-built tools for firms), that will be a separate paid track and clearly labelled. The core analytics on this site stay free.

Yes, with the same professional judgement you would apply to any audit tool. The output is designed to be paste-ready into a working paper, but it is your audit evidence and your conclusion. The tool computes; the auditor signs off.

For partner-side comfort: show them the principle. Tools run in browser. Data never uploads. No cloud processing. No persistent storage. The only way client data leaves your laptop is if you screenshot it or download the Excel report yourself. From a confidentiality standpoint, this is closer to using Excel macros than using a cloud SaaS.

I have used the v3 engine on my own articleship work to cross-check manually-prepared exception reports. Found three real exceptions the manual reports missed, including one fuzzy duplicate.

The detection engine is rule-based, not AI-inference. That means every flag is deterministic and auditable: you can see exactly which threshold was crossed, what the variance percentage was, why a tier was assigned. No black-box, no "the model said so."

Thresholds are configurable. The default materiality framework (Rs. 10K / 1L / 10L / 50L breakpoints) and variance tiering (2% / 5% / 10% / 25%) are ICAI-aligned, but you can adjust them per engagement to match the client's risk profile and your firm's internal materiality.

The severity filter defaults to "Medium and above" so you do not get flooded with low-risk noise. Switch to "All" if you want to see every variance regardless of materiality.

Deliberate distinction. AI was used to engineer the tools (writing the JavaScript, designing the detection logic, building the UI). AI does not run inside the tools at execution time. There is no LLM call, no cloud inference, no model running in the background analysing your data.

This matters because LLM-at-runtime would mean sending your data to a cloud API, which would break the privacy promise. By making the tools deterministic rule engines, the data never has to leave the browser. AI-built, but never AI-fed.

Most "AI audit tools" you will see at vendor conferences are the opposite: thin UI + cloud LLM inference. They are useful for some things but they cannot make the privacy promise we make.

Email me or DM on LinkedIn with a description of what happened. If you can share a redacted sample file that triggers the issue, even better. I read every report personally and ship fixes weekly.

This is a v1 product built by one person. Bugs are real and I am open about that. Your bug report is genuinely valuable to me because every fix benefits every other article using the tool.

Important: always cross-verify high-stakes findings manually. Treat the output as a first-pass screen, not an audit opinion. Your professional judgement remains the controlling layer.

Comfortable up to about 40,000 to 50,000 rows per file on a typical office laptop (8 GB RAM, modern browser). The XLSX parsing is the bottleneck, not the detection logic.

Beyond 50K, you may hit browser memory limits depending on your machine. If you regularly work with 100K+ row populations, this is the point where a server-side processing tier becomes useful. That is on the roadmap as a paid track if there is demand. For now: split the file by month or vendor, run separately, consolidate the Excel outputs.

Easier for me, not safer for you. A cloud SaaS would mean: signup, login, file upload to my server, processing on my infrastructure, storage of your file even temporarily, my company assuming responsibility for data residency under DPDP Act 2023.

Every one of those is a reason an article cannot use the tool. Their partner would (rightly) refuse to authorise uploading client data to a random CA's website. The cloud path closes the door for the exact audience this is built for.

So I kept it client-side. Less convenient to build features, much safer to use. That tradeoff is the entire point.