You have a purchase register with 1,400 lines, a portal download that doesn't quite agree with it, and a client who wants to know by Friday why input tax credit looks lower than expected. AI prompts for accountants in India can speed up the boring parts of GST reconciliation: the checklist, the exception list, the plain-language note to the client. They cannot be trusted with the rules or the numbers, and they shouldn't see your client's identifiers.
This post gives you prompts for that work, plus a small matching script I actually ran. Every prompt block below is an untested template: I haven't run these prompts on live client data, and the model outputs shown are illustrative. For the month-end side of the job, see the month-end close prompt pack; for a wider set of tax prompts, see the CA prompt collection for GST, ITR and audit. This one is narrower: reconciliation, explanations and data checks.
What can you safely paste, and what must you keep out?
Decide this before any prompt.
- Keep out: PAN, GSTIN, bank account numbers, UPI IDs, Aadhaar, addresses, phone numbers, and real party names, unless the client has agreed and your firm has a written data policy covering the tool.
- Mask instead: replace parties with codes (V01, C01), round or keep amounts only if the engagement allows it, and keep the code key in your own file.
- Check the plan: a free personal account, a paid personal plan and a business plan have different data terms, and they change. Read the terms for the exact plan. The data retention and training opt-out table is a starting point, and the what not to paste guide covers the general version.
- Prefer code to chat for real data: ask the model to write a script against a sample of fake rows, then run the script locally on the real file. The model never sees the real data.
- Redact automatically if you do send text out: PII masking for Aadhaar and PAN shows a pattern.
- Legal duties: India has a data-protection statute, and your professional body has confidentiality rules. I haven't summarised either here. Check with a qualified professional or your institute's guidance.
If you can't clear these, do the task by hand. A checklist needs no client data at all, so start there.
How do I stop AI from stating tax rules wrongly?
Treat the model as a drafter, never as the source of a rate, section number, due date or eligibility condition. This post states none for that reason, and you should keep your prompts the same way.
The rule I'd adopt: any rule enters the conversation only if you pasted it from the official source that day.
You are drafting for a chartered accountant in India. Rules for this chat:
1. Do not state any GST rate, due date, section number, notification number
or eligibility condition from memory. If one is needed, write
[CHECK ON OFFICIAL PORTAL] and describe what must be checked.
2. If I paste an extract from the official source, use only that extract
and quote the line you relied on.
3. Mark every assumption you make about the client's facts as ASSUMPTION.
4. Your output is a draft for a qualified professional. Do not address it
to the client as final advice.
Put this at the start of the chat, or in a Claude Project or custom instruction. The official places to check are gst.gov.in and cbic.gov.in. I did not fetch either page for this post, so nothing here relies on their current content.
How do I make a GST reconciliation checklist with AI?
A checklist is safe, fast and reusable, because it contains no client data. The comparison it supports is generic: the purchase register in your books against the auto-drafted statement of inward supplies on the GST portal (GSTR-2B), before the return is filed.
Create a reconciliation checklist for a monthly comparison of a client's
purchase register against the GSTR-2B statement downloaded from the portal.
Client type: [e.g. trader / manufacturer / service provider, regular taxpayer]
Accounting software: [TALLY / ZOHO / BUSY / EXCEL]
Approx. invoices per month: [N]
Group the steps as: Prepare the data, Match, Classify differences, Resolve,
Sign-off and record. For each step give: what to do, what evidence to keep,
and who decides. Include a step for invoices in books but not in the
statement, in the statement but not in books, and matched with a different
amount or date. Where a rule or deadline would matter, write
[CHECK ON OFFICIAL PORTAL] rather than stating it.
Expect a sensible skeleton. Your job is to add the firm's own steps: who reviews, where files are stored, how you record a vendor who never responds. Edit once, save it, reuse it.
How do I match a purchase register to GSTR-2B without trusting the model's arithmetic?
Don't ask a chat model to match 1,400 rows. It may drop rows or invent matches without telling you. Ask it to write the matching logic, then run that logic yourself. A model is useful for explaining what each kind of mismatch usually means, and for drafting the follow-up.
Write a Python script using pandas that compares two CSV files:
books.csv (columns: supplier, invoice_no, taxable, tax) and
portal.csv (same columns).
Rules:
- Build a match key from supplier plus invoice_no, uppercased, with all
characters except letters and digits removed (so "C/55" matches "C-55").
- Outer-merge on the key.
- Status per row: match, tax differs (absolute difference over 1 rupee),
in books only, in portal only.
- Print a table and write exceptions.csv with non-matching rows only.
- No network calls. Explain each step in a comment.
I will test it on fake data first.
Here is a hand-made version of that logic that I ran on 2026-10-23 with invented rows (suppliers V01 to V06, no real data, pandas 3.0.5). It is a starting point, not a reconciliation tool.
import pandas as pd
books = pd.DataFrame({
"supplier": ["V01", "V01", "V02", "V03", "V04", "V05"],
"invoice_no": ["A-101", "A-102", "B-7", "C/55", "D-9", "E-1"],
"taxable": [10000.00, 25000.00, 8000.00, 12000.00, 5000.00, 7000.00],
"tax": [1800.00, 4500.00, 1440.00, 2160.00, 900.00, 1260.00],
})
portal = pd.DataFrame({
"supplier": ["V01", "V01", "V02", "V03", "V06"],
"invoice_no": ["A-101", "A-102", "B-7", "C-55", "F-3"],
"taxable": [10000.00, 25000.00, 8000.00, 12000.00, 3000.00],
"tax": [1800.00, 4000.00, 1440.00, 2160.00, 540.00],
})
for df in (books, portal):
df["key"] = df["supplier"] + "|" + df["invoice_no"].str.upper().str.replace(r"[^A-Z0-9]", "", regex=True)
m = books.merge(portal, on="key", how="outer", suffixes=("_books", "_portal"), indicator=True)
m["tax_diff"] = (m["tax_books"].fillna(0) - m["tax_portal"].fillna(0)).round(2)
def status(r):
if r["_merge"] == "left_only":
return "in books only"
if r["_merge"] == "right_only":
return "in portal only"
return "tax differs" if abs(r["tax_diff"]) > 1 else "match"
m["status"] = m.apply(status, axis=1)
print(m[["key", "tax_books", "tax_portal", "tax_diff", "status"]].to_string(index=False))
Real output from that run:
key tax_books tax_portal tax_diff status
V01|A101 1800.0 1800.0 0.0 match
V01|A102 4500.0 4000.0 500.0 tax differs
V02|B7 1440.0 1440.0 0.0 match
V03|C55 2160.0 2160.0 0.0 match
V04|D9 900.0 NaN 900.0 in books only
V05|E1 1260.0 NaN 1260.0 in books only
V06|F3 NaN 540.0 -540.0 in portal only
Note what the normalisation bought: "C/55" in books matched "C-55" on the portal. Note also what it didn't: it can't tell you whether V04's invoice is missing because the supplier hasn't filed, because you booked it in the wrong month, or because it's a typo. That's the judgement part.
How do I draft vendor follow-ups for mismatches?
Feed the model the mismatch type and masked facts, not the ledger.
Draft a short email from [FIRM NAME] on behalf of our client to a supplier.
Situation: our records show invoice [INVOICE NO] dated [DATE] for
[AMOUNT], but it does not appear in the supplier-side statement on the
portal for [MONTH]. (Type: in books, not in portal.)
Ask: please confirm whether the invoice was reported, and if not, when it
will be. Do not accuse. Do not quote any rule, section or deadline; write
[CHECK ON OFFICIAL PORTAL] if one seems needed.
Tone: polite, firm, under 120 words. Plain English, one clear ask.
Leave placeholders for names; I will fill in contact details myself.
Illustrative output, not a real run: a three-sentence note stating the invoice, the gap and the ask, with the rule placeholder left empty. If the draft invents a legal consequence, delete it.
How do I explain a GST concept to a client in plain language?
Clients don't want the statute. They want to know what to do on Monday.
Explain [CONCEPT, e.g. "why a purchase invoice may not show in the
auto-drafted statement"] to a client who runs a [BUSINESS TYPE] and has
no accounting background.
Rules:
- Max 150 words, no jargon without a one-line explanation.
- Use one example from their trade with invented round numbers, labelled
"example, not your actual figures".
- State what they need to do, and who (them or us).
- Do not state any rate, date or rule from memory. Use
[CHECK ON OFFICIAL PORTAL] where one belongs.
- End with a line listing what you assumed about their situation.
The "list your assumptions" line is the part that earns its place. If the assumption is wrong for this client, you see it before they do.
How do I run a month-end close checklist and spot anomalies?
The full month-end prompts are in the month-end close pack, so I won't repeat them. One addition for GST work: add three reconciliation lines to your close checklist (books vs portal statement, books vs filed return, tax ledger vs liability), each with owner and evidence. For anomalies, use the same safe pattern as before: describe the columns, ask for a script, run it locally.
I have a CSV of purchase entries with columns: date, supplier_code,
invoice_no, taxable, tax, narration. Write a pandas script that flags,
without changing the file:
1. duplicate supplier_code plus invoice_no
2. same supplier_code and taxable amount on different invoice numbers
within 30 days
3. round-number taxable values at or above [AMOUNT]
4. tax divided by taxable that differs from the most common ratio for that
supplier_code
5. dates outside the month under review
Output a CSV of flagged rows with a "reason" column. Do not delete or
correct anything. Add comments explaining each check.
Flags are leads, not findings. A round number can be a genuine retainer. A ratio difference can be a mixed invoice. Look at each before you say anything to the client.
Check before you send
- No PAN, GSTIN, bank or real party names went into a chat without consent and a policy.
- Every rate, date, section and condition in the output was checked on the official portal today, or removed.
- Row counts: the number of rows in equals the number of rows out of your matching code.
- Each flagged item was looked at by a person.
- The email doesn't accuse, doesn't threaten, and doesn't cite a rule you haven't verified.
- The note to the client says it is a draft or a summary and names who reviewed it.
What not to automate
- Filing, payment or any portal action. Those stay with you.
- The decision on eligibility of credit. Rules and facts decide it, and a qualified person owns it.
- Anything quoting a rate or due date from the model's memory.
- Opinion letters or notices replies. Draft help is fine, but the signature and the judgement are yours.
- Unreviewed client emails. A confident wrong sentence is worse than a slow right one.
For more reusable templates, browse the prompt library. The hallucinations lesson explains why the "use only the pasted extract" rule works, and giving context explains why the inputs matter more than the instruction.
