GST Reconciliation from Bank Statements: A Practical Workflow

Every GST reconciliation eventually comes back to one question: did the money actually move the way the returns say it did. Purchase registers can be optimistic, vendor invoices go missing, and GSTR-2B lags reality by a filing cycle. The bank statement is the one record the client cannot quietly edit. This guide walks through how to use the statement as the anchor for a GST reconciliation, where the mismatches usually hide, and how to skip the part everyone hates, which is turning the PDF into something you can actually work with.

Why start from the bank statement

A GST reconciliation done only inside the accounting software is a reconciliation of one set of the client's numbers against another set of the client's numbers. Useful, but circular. The bank statement breaks that circle. It is third party evidence of what was paid and received, dated to the day, and it does not care what the purchase register claims. When you tie the books and GSTR-2B back to the bank, you are checking the story against the cash, which is where real errors surface.

• Payments to vendors on the statement should have a matching purchase invoice and an input tax credit claim in GSTR-2B.
• Receipts from customers should tie to outward supplies declared in GSTR-1.
• Direct taxes, bank charges and interest are not GST events but clutter the feed, so they need to be recognised and set aside cleanly.
• Round tripping and personal expenses run through a business account show up here first, long before the returns do.

Getting the statement into a workable shape

You cannot reconcile a PDF. Before any of the matching starts, the statement has to be in columns you can sort, filter and pivot, which almost always means Excel. This is the step that quietly eats an afternoon per client at quarter end, because bank PDFs pack the narration, reference and counterparty into one dense column that generic converters split in the wrong places.

What you want on the other side is a clean grid: date, narration kept whole, debit, credit and running balance, each in its own column. Keeping the narration intact matters more than it sounds, because the UPI handle, the NEFT reference and the vendor name inside that field are exactly what you match against later. If the converter chops the narration across cells, you lose the one clue that tells you which vendor a payment belongs to.

The reconciliation workflow

Once the statement is in Excel, the reconciliation itself is a sequence, not a guess. Work it in this order and the mismatches sort themselves into buckets.

1. 1Classify every line. Tag each transaction as a vendor payment, a customer receipt, a tax or statutory payment, a bank charge, or a non business item. Most of this can be done by filtering on the narration.
2. 2Pull the GST relevant subset. Vendor payments and customer receipts are the lines that touch GST. Set the rest aside in their own tab so they are accounted for but out of the way.
3. 3Match vendor payments to purchases. For each payment, confirm there is a purchase invoice in the books and that the supplier appears in GSTR-2B for that period. A payment with no matching 2B entry is an input tax credit you cannot claim yet.
4. 4Match receipts to outward supplies. Tie customer receipts back to the sales recorded in GSTR-1. A receipt with no invoice is either an advance, which has its own GST treatment, or a sale that never got billed.
5. 5List the exceptions. Anything that did not match is your working list: timing differences, missing invoices, supplier not filed, or a genuine error. This list is the actual output of the reconciliation.

Where the mismatches hide

Most GST reconciliation differences are not fraud. They are timing and paperwork. Knowing the usual suspects lets you clear the list faster.

Supplier has not filed

You paid the vendor and you hold the invoice, but the supplier has not filed their GSTR-1, so the credit is not in your GSTR-2B yet. The bank confirms the payment is real. The action is to chase the supplier, not to adjust your books.

Timing across the period end

A payment lands on the last day of the month and the invoice sits in the next period, or the other way round. The bank statement dates the cash precisely, which is exactly what you need to decide which return the entry belongs in.

Advances and part payments

A receipt on the statement with no matching invoice is often an advance against a future supply. Under GST that can trigger a liability at receipt for services, so a bank receipt with no invoice is a flag to check, not a line to ignore.

Reversed or bounced transactions

A payment goes out and comes back a day later. Both lines are on the statement. If you only picked up the debit, your reconciliation will show a payment with no invoice that does not actually exist. Reading the full statement, both directions, avoids chasing a ghost.

Doing this across a portfolio of clients

One statement is manageable by hand. A practice running GST for thirty clients, each with two or three bank accounts, is a different problem. The reconciliation logic does not change, but the data preparation becomes the bottleneck. The realistic way to keep quarter end sane is to standardise the front of the process: same clean Excel layout for every bank, every client, so the classify and match steps look identical no matter whose account you are on.

That is the part worth automating. StmtSnap converts each client's statement PDF into a clean Excel file with the narration preserved, and it reads Indian bank formats specifically, so an HDFC, SBI or ICICI statement all come out in the same workable grid. If the client's statement is password protected, which most emailed statements are, you can convert it without stripping the password by hand first.

For guidance on the returns themselves and the current matching rules, the GST portal is the authoritative source, and the reconciliation offset in GSTR-2B versus 2A is worth reading there before you finalise a client's input tax credit position.