GST Reconciliation Tool (2A vs Books) - looking for people to test it on a real file

Critical questions to ask

1. Data privacy & confidentiality

   Does the tool process the GST/2A data entirely locally, or are invoices/data uploaded to your server/cloud? If uploaded, where exactly is the data stored and for how long?

2. Access to sensitive information

   Does the tool require GST portal credentials, API access, OTP, or any login credentials at any stage? If yes, why is this required?

3. Data deletion

   If a tester uploads a real client's file, what is the exact mechanism for permanently deleting the uploaded data after testing?

4. ITC matching methodology

   What exact matching logic are you using for GSTIN, invoice number, invoice date, taxable value, tax amount, amendments, credit/debit notes, and partial matches?

5. GST legal basis

   You mentioned that the tool tells the "actual GST section behind why it's flagged." Could you provide a few examples of the GST provisions/notifications/circulars used for those classifications?

6. False positives / false negatives

   Has the tool been independently tested against manually reconciled datasets? What percentage of mismatches are false positives or false negatives?

7. 2A vs 2B

   Since you specifically mention 2A, how does the tool distinguish between a genuine reconciliation difference and an ITC eligibility issue that should actually be evaluated with reference to GSTR-2B/current law?

8. No installation risk

   Does the tester need to install any .exe, .dmg, browser extension, macro-enabled Excel file, or other executable component? If yes, can the source code or security documentation be reviewed?

9. Macro/VBA risk

   If the tool is Excel-based, does the workbook contain VBA/macros, external links, Power Query connections, or hidden sheets/connections? Can you provide a macro-free sample first?

10. Ownership & credentials

    Who owns/develops the software, and is there a registered entity/website/privacy policy under which the tool is being offered?

11. Why real client data?

    Why is testing on a "real file" necessary? Would an anonymised GST reconciliation file not be sufficient for initial testing?

12. Independent verification

    Can you provide a sanitized sample output showing the original purchase data, 2A data, matching result, mismatch reason, and GST provision identified—without requiring anyone to upload confidential client data?

Hi Aashok, I appreciate you actually digging into this properly, going through your questions one by one.

1. Data privacy: The core reconciliation happens entirely inside Excel; no network calls, nothing goes anywhere. There is one optional bit, a vendor name matching feature that uses AI, and if it's ever turned on, it sends just a GSTIN and vendor name to check if two names are probably the same company. Nothing gets stored after that, and no amounts or invoice numbers are ever part of it. Right now it's off; nobody's even set up an API key for it. If we ever turn it on by default for everyone, I will say so clearly, since that's really the only way any data would ever leave your machine.

2. Credentials: No, none. No GST portal login, no API key, no OTP. It just reads what's already sitting in your workbook.

3. Deletion policy: Honestly don't have one yet, mainly because there is no real backend running for anyone testing this right now. If a memory feature ever goes live, it would only ever store generic stuff like column headers, never actual GSTINs or amounts.

4. Matching logic: GSTIN + invoice number, tolerant of the usual formatting mess (leading zeros, different separators), but only counted as a match if the taxable value and tax amount also line up within ₹1. A real typo in the invoice number still gets flagged as a mismatch, not waved through. Credit/debit notes are not specifically handled yet, just offered as one possible explanation when something doesn't line up. Amended invoices aren't modelled at all yet, being upfront about that.

5. Legal basis, some real examples: Section 16 for ITC matching, Section 16(2) (aa)/Rule 36(4) since ITC actually needs to be in 2B not 2A, Section 8 for place of supply/IGST vs CGST-SGST, Section 17(5) for blocked credits, 9(3)/9(4) for RCM, and Rule 88C for the GSTR-1 vs 3B threshold.

6. False positives/negative rate: No real number yet, being straight about that. What I do have is an independent verifier, a second, separately built check that re-does the math from scratch on every finding, and so far it's agreed with everything across every real file tested. That's a consistency check, though, not the same as measured accuracy against someone's actual manual answer key. 

7. 2A vs 2B: It's 2A only right now. Every finding involving 2A carries a note saying 2A keeps changing, but 2B is what actually locks in what you can claim, so anything flagged still needs a separate 2B check before treating it as final.

8. Installation: No macros, no exe, nothing like that. Just a one-time add-in sideload, paste a manifest link into Excel, accept one prompt, done. Not a proper one-click install yet, but no account or signup either.

9. Macros/VBA: No, genuinely cannot have any; Office add-ins are just JS and structurally can't contain macros.

10. Ownership: Being fully honest, it's just me, a prototype right now, no registered company, no privacy policy yet.

11. Why real data: Fair point, honestly. An anonymised file works fine for this stage; it's probably better to start there anyway.

12. Sample output: Here's what a real finding actually looks like, made up numbers: 

GSTIN 27ABCDE-1234F1Z5, Invoice INV-XXXX/22-23, eighty-five thousand taxable, ₹7,650 CGST, ₹7,650 SGST, flagged because it shows up in books but not in 2A, with a note that the supplier might not have filed it yet or filed it under a different number, and the actual provision cited (Section 16(2)(aa)/Rule 36(4)) explaining why that matters.

Happy to put together an anonymised file for you so you can test it yourself rather than just take my word for any of this.