1. Overview and Objective

GRACE — GST Reconciliation & Compliance Engine — is a browser-based GST compliance platform developed by CA Ashish Chadha, a Chartered Accountant having industry experience over 15 years of hands-on experience in Indirect Taxation compliance, litigation, and tax technology transformation.

The platform was conceived and built from a direct, first-hand understanding of the compliance challenges that arise in large organisations with multi-state, multi-location GST registrations. It addresses a specific, recurring operational problem: reconciling GSTR-1 data against e-invoice data across many locations, identifying discrepancies before they lead to department notices, and generating filing-ready outputs — without relying on manual Excel-based processes.

The tool was initially developed and tested using Supabase (a cloud-based PostgreSQL platform) as the database layer. Following successful proof-of-concept validation, the database was migrated to a company-owned server and the application was deployed on the organisation's internal intranet, making it fully operational within the enterprise IT environment. For the purpose of this demonstration and submission, the tool has been hosted on Netlify, with all organisation-specific credentials and internal data replaced with demonstration data, since the intranet deployment cannot be accessed externally.

This deployment journey — from prototype to intranet production — itself reflects the practical maturity and real-world applicability of the solution.

What GRACE Does

1. Accepts GSTR-1 data uploads (B2B, CDNR, Exports, HSN, B2CL, B2CS, Documents, Nil/Exempt) from location users across multiple registration locations within a state
2. Accepts e-invoice data and automatically reconciles it against the uploaded GSTR-1 data, invoice by invoice
3. Classifies every invoice into one of six reconciliation categories — Matched, Value Mismatch, Date Mismatch, GSTIN Mismatch, GSTR Only, and E-Invoice Only
4. Generates a filing-ready Excel export structured in the same column order as the Government's GSTR-1 Excel Workbook Template, allowing direct copy-paste into the official utility
5. Maintains a live compliance dashboard showing upload status per location per period, with deadline tracking
6. Provides a complete audit trail of every upload, reconciliation, export, and user action
7. Supports three user roles — Admin, Nodal Officer, and Location User — with appropriate access boundaries for each

2. Background and Problem Statement

2.1   The Reconciliation Problem

An organization with operations across 10-15 registration locations under a single state generates hundreds of invoices every month. Each location's data is uploaded to the GST portal separately. The e-invoice data, generated at the time of invoice creation through the IRP, represents a separate record of the same transactions.

Reconciling these two datasets manually — to identify invoices that are missing, values that do not match, GSTINs that differ, or dates that conflict — was being done in Excel, location by location, period by period. The process was time-consuming, prone to formula errors, and difficult to audit. A single missed mismatch could result in a GST notice months later, requiring reconstruction of old data under significant time pressure.

Beyond the reconciliation itself, there were two further challenges:

1. Data collection from branch locations involved email follow-ups and manual consolidation, creating delays and version control problems
2. Preparing the filing export required reformatting the reconciled data to match the Government's GSTR-1 utility column structure — additional manual work every period

2.2 Why Existing Tools Did Not Solve It

Enterprise GST compliance software exists, but is designed for large corporate finance teams, carries significant licensing costs, and requires dedicated IT setup and maintenance. For a large finance function operating as a centralised services model — handling compliance for multiple business units and project sites — a lightweight, browser-based tool that could be deployed on the intranet and accessed by location users without any installation was a more practical fit. GRACE was built to meet exactly these requirements.

3. Solution Architecture

3.1 Design Philosophy

GRACE is built as a single HTML file — all application logic, styling, and interface code in one deployable file. This was a deliberate design choice driven by two practical requirements: the application needed to be deployable on an intranet without a complex server-side setup, and updates needed to be rollable or managing dependencies on end-user machines.

When a new version is ready, one file is replaced on the server. All users across all locations get the update immediately on their next page load. No installation, no version management, no software distribution — the update cycle is as simple as it can be.

3.2 Technology Stack

3.3 Database Migration — From Supabase Cloud to Company Server

The initial prototype was built on Supabase, an open-source PostgreSQL platform available as a managed cloud service. Supabase was chosen for rapid prototyping because it provides a hosted PostgreSQL database, built-in Row Level Security, and a JavaScript client library that works directly from the browser — allowing the entire application to be built as a single HTML file without any backend server code.

Once the prototype was validated and the tool was approved for internal deployment, the database was migrated to a company-owned server. Since Supabase is built entirely on standard PostgreSQL, this migration was straightforward: the schema, data, Row Level Security policies, and user records were exported and restored on the organisation's internal PostgreSQL instance. The application's database connection string was updated to point to the internal server. No changes to the application logic were required.

This migration ensured that all GST-sensitive organisational data — invoice details, location configurations, user accounts — resides entirely within the organisation's own IT infrastructure, with no data transmitted to any external cloud service in the production environment.

3.4 Workflow Modules

4. The Reconciliation Engine in Detail

The reconciliation engine is the functional core of the platform. When a reconciliation is initiated for a given state and period, the engine fetches all GSTR-1 data uploaded by all active locations under that state, fetches the corresponding e-invoice data, and performs an invoice-level comparison.

4.1 Matching Logic

Invoice numbers are normalised before comparison — spaces removed, case standardised, common formatting differences handled (e.g., INV/2026/001 treated as equivalent to INV-2026-001). Date fields are normalised across multiple formats (DD/MM/YYYY, YYYY-MM-DD, DD-Mon-YYYY). Numeric values are rounded consistently before comparison. A configurable value tolerance (default ₹4) prevents rounding differences from being flagged as genuine mismatches.

This normalisation step is critical. Without it, a significant proportion of genuinely matching invoices would appear as mismatches simply due to formatting differences across ERP systems and manual data entry practices.

4.2 Six Reconciliation Categories

4.3 Export After Reconciliation

1. Reconciliation Report (Excel): A multi-sheet workbook with a summary tab showing counts by category and one detail sheet per GSTR-1 table type. All six categories are included — matched, mismatched, and unreconciled — giving a complete working paper for audit purposes.
2. GSTR-1 Filing Export (Excel): An 8-sheet workbook structured with columns in the same order as the Government's GSTR-1 Excel Workbook Template (v2.2). The CA can open this file alongside the official utility and copy data across sheet by sheet without reformatting. Sheets covered: B2B/SEZ/DE, B2CL, B2CS, CDNR, Exports, HSN, Documents, Nil/Exempt.

5. Role-Based Access Control

GRACE has three user roles designed to match the actual structure of a finance compliance operation in a multi-location organisation:

This structure eliminates the data collection bottleneck. Instead of the central finance team chasing each location for data, location users log in directly, upload their data for the period, and the system validates and stores it. The nodal officer and admin can see in real time which locations have completed their uploads and which are pending — without any emails or phone calls.

Row Level Security at the database level enforces these boundaries independently of the application code: even if a location user's session were manipulated, the database would reject any query for data outside their permitted locations.

6. AI and Technology Features

6.1 Intelligent Column Mapping

Different ERP systems and different locations export GSTR-1 data with different column names. One system exports "Invoice No.", another exports "Inv Number", a third exports "Document No." — all referring to the same field. GRACE uses fuzzy matching against a curated alias dictionary covering over 200 known column name variations to automatically map uploaded headers to the correct internal fields. Where automatic mapping is uncertain, the user is presented with a dropdown mapping interface.

This feature alone eliminates a significant source of upload failures and user frustration, particularly in large organisations where different units use different ERP configurations.

6.2 Normalisation-Based Matching Intelligence

The reconciliation matching algorithm applies systematic normalisation to invoice keys, dates, and amounts before comparison. This handles the real-world messiness of data from multiple ERPs and manual entry points — where the same invoice may be represented differently in the GSTR-1 upload and the e-invoice system due to spacing, case, punctuation, or date format differences. The result is a materially higher match rate compared to simple string comparison.

6.3 Duplicate Detection

When a location user uploads data for a period that already has records on file, the system checks for duplicate invoice numbers within the same location and period before inserting any rows. If duplicates are detected, the user is warned and must confirm before the upload proceeds. This prevents accidental double-counting, which would distort the reconciliation and the filing totals.

6.4 Planned AI Enhancements

The architecture supports integration of AI-driven features at multiple points. Planned additions include:

1. Statistical anomaly detection: flagging invoices with values that deviate significantly from historical patterns for the same location and period
2. Natural language query: allowing authorised users to query reconciliation data in plain language (e.g., "show all B2B mismatches above ₹50,000 for March 2026")
3. Predictive compliance calendar: analyzing historical upload patterns to identify locations at risk of missing the deadline and generating early alerts

7. Impact and Measurable Benefits

7.1 Time Savings

7.2 Accuracy and Consistency

Manual reconciliation in Excel introduces errors through formula mistakes, copy-paste issues, and the natural fatigue of checking hundreds of invoices. GRACE applies the same normalization and matching logic to every invoice, every time, without variation. The six-category classification is deterministic and auditable. Once a reconciliation is run on a fixed dataset, the output is the same regardless of who runs it or when.

7.3 Compliance Risk Reduction

The GSTR ONLY and E-INV ONLY categories directly address a common source of GST notices: invoices that appear in one system but not the other. By identifying these discrepancies before filing — rather than after the department raises a query — the tool shifts the organization from a reactive to a proactive compliance posture. Given CA Ashish Chadha's extensive experience in managing departmental assessments and litigation at BHEL, this practical risk-reduction focus reflects a real operational priority.

7.4 Scalability Within and Across Organization’s

The database structure supports any number of states, locations, periods, and users. Adding a new location takes approximately 2 minutes. Onboarding a new client or business unit (for a CA practice context) takes approximately 15 minutes. The tool has no practical transaction volume ceiling within normal PostgreSQL operating parameters.

8. Deployment and Current Status