Tenant and organisation scope
Application reads and writes are scoped to the signed-in tenant and organisation, with separate platform-admin and client-portal access paths.
Security is built into who can see a workspace, how database transport is verified, what gets recorded, and what happens after the month is frozen.
Each layer has a practical job: keep clients separated, reduce unauthorised access, preserve evidence, and make sensitive changes reviewable.
Application reads and writes are scoped to the signed-in tenant and organisation, with separate platform-admin and client-portal access paths.
Production can use Google OAuth. Email passwords are hashed, sessions are signed, and suspended accounts are blocked during access checks.
Production database connections require an explicit CA certificate for hostname verification; insecure certificate fallback is not part of the launch configuration.
Sensitive uploads, freezes, administrative changes, and configuration updates are recorded with request metadata and chained hashes.
A frozen period preserves the approved reconciliation state. A later change must become a visible, reasoned revision rather than a silent overwrite.
Source uploads and generated evidence are designed for private object storage with tenant keys, download controls, and plan-aware retention limits.
Users download GSTR-2B themselves. GSTRecon360 never asks for, stores, or uses GST portal passwords and is independent of GSTN.
A deletion request immediately suspends the account and is queued for manual data removal by our support team, completed within 30 days.
A defensible close needs the source, the reconciliation result, the review decision, and the activity trail to remain linked.
Tell us about your team, deployment, retention, or access requirements and we will answer plainly — without certification theatre.