1. Executive Summary

DeltaBooks is a web-based GST reconciliation platform that compares Tally accounting data with data filed on the GST portal — both on the outward side (Tally sales vouchers vs. GSTR-1) and the inward side (Tally purchase vouchers vs. GSTR-2B). Unlike conventional Excel-driven reconciliation, every run is persisted, versioned, and audit-ready in a database, so the manual decisions a professional makes in one month automatically carry forward to the next.

The core promise of the tool is captured in its tagline: Reconciliation that picks up where you left off. A mid-size company's monthly GST reconciliation, which typically takes 8–10 hours in Excel, is compressed to roughly 15 minutes — a ~95% reduction in effort — while simultaneously eliminating common failure modes that cost businesses real ITC (Input Tax Credit).

2. The Problem Being Solved

GST reconciliation in most practices today is a manual, repetitive process that consumes 8–10 hours every month per company. The pain points identified are:

1. Hand-rolled Excel matching. VLOOKUPs and pivot tables dominate the workflow. One slip, and the ITC claim is wrong.
2. No memory between months. Every month's reconciliation starts from zero. Decisions made last month — "this party's GSTIN is actually registered in Telangana, not Delhi" — have to be rediscovered and re-applied.
3. Rounding noise drowns real issues. A ₹2 round-off difference is flagged with the same visual weight as a ₹50,000 tax mismatch, so reviewers waste time triaging trivia before they get to real problems.
4. Multi-state suppliers slip through the cracks. When Tally records a supplier's Delhi GSTIN but the supplier actually filed under their Telangana GSTIN, the invoice appears to be missing on both sides — invisible to the reviewer, and ITC is lost.

These are not edge cases. They recur in every practice, every month, across every client book.

3. The Solution — Two Reconciliation Engines, One Pattern

DeltaBooks runs two parallel engines built on the same underlying architecture:

Sales Reconciliation (Tally ↔ GSTR-1)

1. Compares Tally sales vouchers against what was actually filed in GSTR-1.
2. Handles B2B invoice-wise and month-wise views.
3. Keeps B2C and Export invoices in separate, properly bucketed tabs.
4. Produces a Variance Report with auto-filled remarks and drill-down from any figure.

Purchase Reconciliation (Tally ↔ GSTR-2B)

1. Compares Tally purchase vouchers against what suppliers filed (available in GSTR-2B).
2. Matches on the supplier's invoice number captured as the voucher reference.
3. Surfaces ITC availability flags per row.
4. Includes the PAN-level fallback (see Rule #2) to catch multi-state supplier situations.

Both engines share the same workflow, the same variance report format, and the same persistence model — so a professional learns the interface once and uses it on both sides of GST.

4. The Reconciliation Cockpit (UI/UX)

The interface is designed to feel like Excel — the format professionals already know — but with browser speed and database memory beneath it:

1. Persisted runs saved per Company × Financial Year × Month.
2. Single-run-per-scope — no history clutter; one canonical reconciled state per period.
3. Manual decisions carry forward automatically from month to month.
4. Instant FY / Month switching with no recomputation — the saved run loads immediately.
5. Click-through drill-down from any cell to the contributing invoice list.
6. Grouped headers in the classical audit format: Books · GST · Difference, with Taxable / IGST / CGST / SGST sub-columns under each.

This is the month-wise B2B summary view: row per month, columns grouped into three blocks (what's in books, what's in GSTR, what the difference is), with one click opening the invoice-level detail behind any number.

5. Three Rules That Make the Engine Intelligent

The real value of the tool lies in three domain-specific rules encoded in the matching engine — rules that reflect how a seasoned CA actually thinks about reconciliation.

Rule #1 — Finding the Customer GSTIN (3-Step Cascade)

Invoices with a blank buyer GSTIN should not silently fall into B2C. The engine runs a three-step cascade:

1. Direct — use the GSTIN entered directly on the voucher (the happy path).
2. Consignee fallback — if buyer GSTIN is blank, use the consignee's GSTIN.
3. Customer master fallback — match the party name against the ledger master and pick up the GSTIN from there.

Why it matters: an invoice that should be B2B doesn't get misclassified as B2C simply because a data-entry operator left one field blank. If the GSTIN exists anywhere in Tally, the engine finds it.

Rule #2 — Multi-State Supplier Rescue (Two-Pass Matching)

This solves one of the most common invisible ITC losses in the country.

The problem: A supplier with operations in multiple states may have the same invoice booked by the buyer against one GSTIN (e.g., 07AAFCB3158E1ZX — Delhi, state code 07) while the supplier actually filed it under a different state GSTIN (e.g., 36AAFCB3158E1ZW — Telangana, state code 36). The PAN in the middle of both GSTINs is identical, but the state codes differ, so a naïve match treats them as two completely different suppliers — one invoice appears as "2B Only" and the other as "Books Only."

The solution: the engine runs two passes:

1. Pass 1 — exact match on (GSTIN, Invoice Number).
2. Pass 2 — for leftovers, fallback match on (PAN, Invoice Number).

Suspected pairs are flagged as "PAN Match ⚠" and surfaced to the user, who then confirms or rejects the pairing. Once confirmed, the decision persists.

Rule #3 — Don't Panic Over Rounding

Not every mismatch deserves equal attention. The engine classifies every difference into one of three buckets:

1. MATCHED — taxable value, tax components, and invoice total all agree within a ₹1 tolerance.
2. VALUE DIFF ONLY — tax components match exactly, only the gross invoice total drifts. Typically benign: rounding or a small freight/charge variation. Can be acknowledged and moved on from.
3. TAX MISMATCH — taxable or IGST / CGST / SGST differs. This is a real GST issue that demands reconciliation.

This triage is the difference between a reviewer chasing ₹5 round-offs for two hours and a reviewer finishing genuine tax issues in fifteen minutes.

6. The Variance Report — Where Action Happens

After the engine runs, the reviewer works out of a single Variance Report that contains only invoices requiring attention. Its design choices mirror how CAs actually want to review:

1. Only differences, no noise — matched rows are filtered out automatically.
2. Books · GSTR · Difference — three-column grouped headers that mirror the audit format most firms already use in Excel.
3. Auto-filled, editable Remarks — the engine seeds a likely reason (Round-off, Not filed, State mismatch, Extra in GSTR-1, CGST off, etc.); the reviewer can override, and the remark survives re-runs.
4. Confirm / Reject in place — every manual decision is captured as state in the database. It persists and carries forward.
5. Reconciliation identity — total difference on the Variance Report tab equals the total difference on the Month-wise tab. No numbers disappear between views.

A typical row looks like: Apr · BENZER DEPT · −₹7,612 · Value Diff · "Round-off" — giving the reviewer every piece of context they need in one line.

7. The Memory Layer — What Makes It Different

This is the feature that separates DeltaBooks from every other reconciliation utility:

1. Persisted Runs. Every reconciliation is saved. Run once, review forever.
2. Manual Matches Survive. A match confirmed today is preserved in next month's run.
3. Single-Run-per-Scope. No endless list of historical runs to sift through — one canonical state per Company × FY × Month.
4. Browse Without Re-Run. Switch FY or Month, and the saved page loads instantly without recomputing.
5. Carry-Forward Remarks. Every typed note travels with its row across every subsequent re-run.
6. Engine + UI Separation. The matching logic lives in one reusable engine, shared across every reconciliation page.

In a profession where the same questions get re-asked every month, this memory layer is what reclaims real time.

8. Measured Impact

For a mid-size company running monthly GST reconciliation, the platform delivers:

The experience goal is simple: finish the return cycle in a coffee break — with the confidence that every manual decision is remembered for the next month.

9. Why This Is Relevant to ICAI's AI Initiative

1. It addresses a universal pain point. Every CA firm in India does GST reconciliation. The 8-hour problem is not niche.
2. It encodes professional judgment. The three rules (GSTIN cascade, PAN fallback, rounding triage) are exactly the heuristics an experienced CA applies mentally — now made explicit, repeatable, and sharable.
3. It is audit-ready by design. Persistence, versioning, and carry-forward remarks produce a decision trail that stands up to review — a quality most current-generation tools lack.
4. It is built by a practicing CA. Every workflow decision reflects real bench experience rather than a generic software vendor's guess at what the profession needs.
5. It is extensible. The same engine-plus-memory pattern applies naturally to TDS reconciliation, 26AS/AIS matching, bank reconciliation, and other recurring compliance workflows.