project no. 02
Reconciling payments, mostly automatically
A pipeline that matches payment-gateway payouts to bank credits and drafts the entries, then waits for an accountant to approve them. It took the job from about a day to about an hour per client.
| Item | Gateway ₹ | Bank ₹ | Diff ₹ | Status |
|---|---|---|---|---|
| Payout A | 1,00,000 | 97,640 | 2,360 | fee: 2% + GST |
| Payout B | 45,200 | — | 45,200 | timing: next day |
| Payout C | 12,750 | 12,750 | 0 | matched |
| Credit D | — | 8,400 | 8,400 | no invoice |
| for review: 3 of 4 | ||||
- Role
- Built it, and use it as the accountant
- Timeline
- 2023 – now
- Used for
- 10+ client businesses
- Platform
- Python scripts + n8n
- Posts to
- Tally Prime, Zoho Books
problem
Gateway payouts never equal the sale. Matching them by hand took a day per client.
solution
Rules do the matching and drafting. A person signs off before anything posts.
impact
About an hour per client, every month, with a full trail behind each entry.
· the problem
why the numbers never tie
Businesses that sell through Razorpay, Stripe and bank transfers have a month-end headache:
- gateways pay out in batches, net of their fee and GST, so the bank credit never equals the sale
- payouts land a day or more later, so something is always in transit at month-end
- Excel lookups break on transaction IDs with stray spaces or prefixes
Doing this by hand took me about a full working day per client, every month.
· the pipeline
how it works
Python with pandas does the parsing and matching. n8n moves files between the steps and the accounting software.
automate the arithmetic, never the sign-off.
01
ingest
Bank statements, gateway settlement reports and the sales ledger come in as files. Columns are read by fixed rules; dates are normalised to IST.
02
match
Each payout is matched to a bank credit on UTR, amount and date, within set tolerances.
03
sort
Anything that doesn't tie goes into a bucket: fee, timing or missing invoice. Each bucket has an obvious next action.
04
draft & review
Vouchers are drafted for Tally Prime or Zoho Books. An accountant reviews the exceptions on one screen, then posts.
· the review
what the reviewer sees
Matched items get a tick and need no attention. The reviewer only looks at what didn't tie, and each row already says why (see fig. 01).
On ₹1,00,000, a 2% gateway fee plus 18% GST on that fee is ₹2,360. That's the gap the sheet flags, and the fee voucher it drafts.
· decisions
what shaped it
rules first, AI last.
I first tried OCR and an LLM to read bank statements. It mixed up debit and credit columns. Now fixed parsers read the columns, and an LLM only tidies messy vendor names.
nothing posts on its own.
A wrong fee entry or a missed credit note corrupts the ledger quietly. Drafts are cheap to fix; posted entries aren't.
keep the trail.
Every entry links back to the source row, the difference found and who approved it. That's what an auditor will ask for.
The same approach now handles GSTR-2B matching for input tax credit.
· reflections
before and after
Before:
a day per client, matching by eye, every month.
After:
about an hour, and the accountant only looks at what didn't tie.
The real change is where the time goes. Less of it on lookups, more of it on the exceptions that actually need judgment.