Would you use a free, open-source alternative to subscription-based tools ?

Critical Questions for the Developer

1. How will local data security and client confidentiality (NDA compliance) be maintained?

   • Context: Since the tool is open-source and runs locally, how can practitioners ensure that client financial data, purchase registers, and credentials do not leak or get compromised through malicious third-party code forks or vulnerable local dependencies?

2. How will the tool handle the stringent GSTN API rate limits and frequent portal UI changes?

   • Context: Direct scraping or unauthorized automation of the GST portal often results in IP blocks, CAPTCHA hurdles, and frequent schema updates. Will this rely on official GSP APIs, and if so, how will API token costs be managed without a subscripttion model?

3. What is the liability mechanism when automated reconciliations or return filings fail?

   • Context: If an automated GSTR-2B vs. purchase register match misses a crucial mismatch or if a filing utility errors out, leading to mismatched ITC or penalty notices from the department, who bears the professional liability?

4. How will edge cases in unstructured document parsing be handled?

   • Context: Clients send messy invoices, scanned bills via WhatsApp, and non-standard PDF formats. How robust will local AI models be in accurately extracting line items, GSTINs, and tax split-ups without requiring constant manual corrections?

5. Will the tool support multi-user office environments or remain strictly single-desktop?

   • Context: Most CA firms require role-based access control (RBAC) so that article assistants, senior accountants, and partners can collaborate on the same client files simultaneously. Will local deployments support LAN-based syncing or secure local database sharing?

Thanks for raising these questions. These are exactly the kind of practical challenges I want to address while building this project. Let me explain how I am thinking about each of them.

1. How will local data security and client confidentiality (NDA compliance) be maintained?

The primary goal is to keep client data within the CA's own machine or office infrastructure rather than making cloud storage mandatory.

The application will follow a local-first architecture, with no mandatory cloud synchronization or transmission of financial documents to external AI services by default.

From a development and security perspective, I intend to implement:

• Encrypted local data storage.

• Secure credential management.

• Automated third-party dependency vulnerability scanning.

• Regular dependency updates and security patches.

• Transparent open-source code so that firms can independently audit what they are running.

We will also maintain a software dependency inventory (SBOM) to improve transparency.

Open source does not automatically guarantee security, but it allows independent verification and community contributions towards improving it.

2. How will the tool handle stringent GSTN API rate limits and frequent portal UI changes?

I am considering a hybrid approach rather than making paid GST APIs mandatory for everyone.

Option 1: Browser-assisted automation

The desktop application will be capable of launching and controlling a browser to assist with selected GST workflows.

The CA will remain in control of authentication, entering credentials and solving CAPTCHA/OTP challenges wherever required. Once authenticated, the application can execute the selected workflow based on the user's instructions.

Regarding IP blocking, browser-based automation does carry some risk, but it can reduce certain risks compared with aggressive scraping or unauthorized automation techniques.

I've come across several tools already using this approach, and in my discussions with multiple practicing CAs, IP blocking hasn't been a commonly reported issue.

That said, I don't want to claim that the risk is zero. Portal policies, rate limits and technical changes can still affect automation.

Option 2: Official GSTN API integration

For firms that prefer programmatic access, I also intend to integrate with authorized GSP providers.

There will be two possibilities:

• CAs can bring their own GSP/API credentials and manage their API expenses directly.

• Alternatively, they can use an API service provided through our platform, where we manage the integration and charge for the associated API usage.

This will be an optional paid integration rather than a mandatory subscripttion for using the core application.

Handling government portal changes

One advantage of maintaining the automation engine centrally is that we can continuously test supported workflows and identify breakages when portal interfaces change.

My plan is to:

1. Run automated regression tests continuously in our development environment.

2. Identify broken workflows when government portal changes affect existing automation.

3. Fix the automation scriptts and validate them against supported test environments.

4. Publish versioned updates.

5. Notify desktop application users and distribute updates after testing.

The objective is to minimize downtime and avoid requiring CAs to manually troubleshoot every portal UI change.

3. What is the liability mechanism when automated reconciliations or return filings fail?

This is an important distinction: the tool should assist CAs, not replace their professional judgment.

For example, when reconciling GSTR-2B against purchase registers, the application should highlight:

• Missing invoices.

• Duplicate entries.

• GSTIN mismatches.

• ITC discrepancies.

• Differences in taxable values and tax amounts.

It should not silently make accounting decisions or submit returns without human approval.

I intend to include validation checks, reconciliation reports, audit trails and explicit user confirmation before critical operations.

The CA or authorized professional would remain responsible for reviewing and approving filings. We will also document the application's limitations and terms of use clearly.

4. How will edge cases in unstructured document parsing be handled?

I agree this is one of the more challenging parts.

Invoices can arrive as scanned PDFs, photographs, WhatsApp images, handwritten documents or documents with inconsistent formats.

My approach is to combine OCR with AI-assisted extraction, potentially using local AI models where hardware permits.

However, I don't expect AI to achieve 100% accuracy.

Instead, extracted information should have confidence scores and go through a human verification workflow whenever the system is uncertain.

The objective is to reduce manual data entry, not introduce incorrect accounting entries through overconfident automation.

5. Will the tool support multi-user office environments or remain strictly single-desktop?

I see multi-user support as an important requirement for CA firms.

My initial focus is to get the core application working reliably on an individual machine.

However, I would like the architecture to support self-hosted office deployments in the future, where multiple users can access the same office data over a private LAN.

This would include:

• Role-based access control for partners, senior accountants and article assistants.

• Controlled access to client records.

• Audit logs to track user activities.

• Secure local database sharing.

• Multiple users working on the same client workflows.

I don't want to make cloud hosting mandatory just to enable collaboration.

My overall philosophy

I want to build an open-source CA suite where the core accounting and compliance workflows are not locked behind mandatory monthly subscripttions.

Firms should own their data, have control over their infrastructure, and be free to inspect, modify and extend the software.

There may be optional paid integrations where external infrastructure or services genuinely cost money, such as GSTN API access, but the core software should remain open source.

I don't expect to solve every problem in the first release. The idea is to build this incrementally, work closely with practicing CAs, understand their actual pain points and improve the platform based on real-world feedback.

Ultimately, I want CAs to have the same freedom that software developers have with open-source tools: use them freely, customize them and contribute back to the community.