Our finance team at Softechinfra was burning 9 hours a week on the morning Tally-vs-Razorpay reconciliation: download settlements CSV, paste into Excel, VLOOKUP against Tally vouchers, manually flag mismatches, email Hrishikesh. We rebuilt it as a 16-node n8n workflow that runs at 8:15 am every weekday. The output: a Slack message in #finance-recon listing the previous day's settlement, matched vouchers, and any mismatch with the suggested fix. Total monthly infra: ₹62. This post is the exact build, pulled from our own production n8n instance, with the four traps that quietly burn your reconciliation time if you skip them.
## TL;DR — what this workflow does in 60 words
At 8:15 am IST, n8n calls [Razorpay's settlements API](https://razorpay.com/docs/api/settlements/) for the previous day. It fetches the matching payments via the payments API, pulls the corresponding Tally sales vouchers via [TallyPrime ODBC](https://help.tallysolutions.com/article/Tally.ERP9/Data_Management/ODBC/install_odbc_driver.htm), matches by amount + reference, and posts the result to Slack. Mismatches get an "investigate this" Slack thread with one-click links.
## Why this matters now — November 2025
Razorpay's [n8n node](https://razorpay.com/blog/introducing-the-razorpay-node-for-n8n-ai-powered-payments-for-every-builder/) shipped in mid-2025, removing the need for custom HTTP-Request glue code. Tally Prime 5.0 (released Q3 2025) added a JSON-over-HTTP API alongside the legacy XML format, which means the data shape on both sides is finally clean enough to script against without 200 lines of XML parsing. The integration was technically possible in 2024; it became boringly reliable in November 2025.
The other trigger for us: Diwali 2025 settlement volumes were 23% higher than 2024 (per [Datum Intelligence's wrap-up](https://www.freepressjournal.in/business/diwali-2025-festive-season-wraps-up-with-24-growth-in-order-volumes-23-surge-in-gross-merchandise-value-for-indias-e-commerce-sector)), which meant our finance team's manual reconciliation went from 5 hours a week to 9. The pain was loud enough to justify the build.
## The architecture, in one diagram
## The 5-step pipeline in plain English
## DIY walkthrough — build it yourself in 4 hours
Below is the full build, in the order we shipped it. Each step has a verification check before moving on.
## The matcher code (paste this in)
This is the JavaScript that runs in the Code node. We open-source it under MIT — copy it.
The narration regex matches because our finance SOP requires every Tally sales voucher posted from a Razorpay payment to have the payment_id in the narration field. This is a one-line addition to your sales-voucher creation script in Tally — and it pays back forever.
## The 4 traps (each one cost us a day to debug)
Trap #1: GST rounding makes amounts disagree by ₹0.01 to ₹0.50. Razorpay reports amounts in paise. Tally rounds to 2 decimal places. CGST + SGST split causes off-by-one paise. Hardcode a ₹0.50 tolerance. Strict equality matching loses 12-18% of legitimate matches.
Trap #2: T+2 settlement cycle means yesterday's API call returns nothing on Mondays. Razorpay's standard settlement is T+2 business days. A Monday morning cron looking at "yesterday" (Sunday) finds zero settlements. Our cron looks at "T-2 calendar days" instead, with logic to skip weekends. The first Monday we deployed this without that logic, finance got an empty Slack message and panicked for 40 minutes.
Trap #3: Tally's ODBC connection times out under heavy load. If you query Tally during a heavy book-closing (month-end), the ODBC driver returns "connection refused" or hangs. Wrap the Tally call in a 90-second timeout with two retries spaced 30 seconds apart. We learned this on November 1, when finance was closing October books while our cron tried to query — and the workflow silently failed for two days before we noticed.
Trap #4: Razorpay returns settlements in pagination of 100, finance does ~280/day. The settlements API returns max 100 records per page. If you do not paginate, you silently miss everything beyond 100. n8n's Razorpay node handles this if you set "Return All" to true. Verify this is on. We caught this one because the unmatched-vouchers list was suspiciously long for two weeks before we figured out the API was clipping settlements.
We rounded ₹802 to "₹62/month" in the headline because the Hetzner CX22 is a shared cost — the same instance runs four other Softechinfra workflows. Per-workflow allocation is roughly ₹160/month. If you are spinning up a CX22 just for this one workflow, the honest number is ₹802. Either way, it is a fraction of the labour cost it replaces.
For comparison: [Zapier's equivalent](https://zapier.com/apps/razorpay/integrations) workflow at the same volume runs ~₹4,200/month. [Make.com](https://www.make.com/) ~₹2,800/month. n8n self-hosted is the right choice once you have a developer comfortable with Docker.
## Comparison: managed vs self-hosted automation tools
We picked n8n self-hosted for our own books because we run 14 workflows on the same instance and the per-flow cost is the lowest. For a one-workflow client, Make.com is often the better start.
## When NOT to build this workflow
Three cases where the manual reconciliation is fine.
Your monthly Razorpay volume is under ₹4 lakh. At that scale, an SDR or finance assistant can reconcile manually in 35 minutes a week. The 4 hours of build time is not paid back inside a year.
Your CA does the reconciliation. Some external CAs charge a flat monthly fee that includes reconciliation. The workflow does not save them time (they have their own tooling) and does not save you money. Skip.
You are still on Tally ERP 9 (not Tally Prime). The ODBC layer in ERP 9 is older, more brittle, and the field naming differs. The build effort doubles. Either upgrade to Tally Prime (which we recommend for its API and faster ODBC) or skip.
## Real example — our own books
We dogfooded this for 6 weeks before writing the post. Across that window:
- Total Razorpay payments processed: 1,847
- Auto-matched on first run: 1,841 (99.7%)
- Mismatched (multiple voucher candidates): 4 (0.2%)
- Unmatched (no voucher): 2 (0.1%)
The 4 mismatched cases were all duplicate Tally entries posted manually by finance during the rush of October's GST filing. The 2 unmatched were Razorpay refunds that had not been booked as Tally credit notes yet — caught within 24 hours of happening, instead of at month-end.
Time saved: 8.7 hours/week of finance team labour, repurposed to vendor follow-ups and credit-note processing. At the team's loaded rate of ₹460/hour, that is roughly ₹17,400/month of labour saved for ₹820/month of infra. The build paid back in 9 working days.
The Reddit thread on [r/IndiaBusiness](https://www.reddit.com/r/IndiaBusiness/) where founders share Razorpay reconciliation horror stories is depressingly long — the same patterns we hit show up there in dozens of variations. The fix is more boring than people think.
## A common question we get about Tally ODBC
"Is the ODBC connection secure to expose to a remote n8n instance?"
The honest answer: barely, if you are careful. Tally's ODBC was designed for LAN use, not internet exposure. Three things to do.
1. VPN, not public IP. Run a Wireguard or Tailscale tunnel between your Hetzner n8n instance and the Tally machine. The Tally ODBC port is never on the public internet.
2. Read-only ODBC user. Tally Prime supports user-level access controls. Create a user with read-only voucher access; use that for n8n credentials. The damage from a compromised credential is limited.
3. Daily snapshot of Tally data. Independent of the workflow, take a daily Tally backup to a separate location. If the workflow ever writes (which it should not, but human error happens), you can roll back.
For higher-volume or multi-entity setups, we recommend [Tally on Cloud](https://tallysolutions.com/tally/tally-on-cloud/) hosted with a managed provider. The ODBC concerns go away because the provider handles network isolation.
## Pre-deploy checklist
Email contact@softechinfra.com if you want the n8n workflow JSON export before our call — we share it with anyone serious about building this themselves.
16
n8n nodes (incl. error branches)
₹62/mo
Total infra cost (Hetzner CX22 + Razorpay API)
9 hrs
Finance team time saved per week
99.7%
Auto-match rate on Razorpay-Tally voucher pairs
Step 1: Cron at 8:15 IST
After Razorpay's nightly settlement run completes (typically 6:30-7:30 am for T+2 cycles). 8:15 gives a buffer.
Step 2: Pull yesterday's settlement
Razorpay's settlements API returns the day's settlement object plus the payments included. One call per settlement bucket (UPI, cards, netbanking).
Step 3: Pull Tally vouchers
ODBC query against Tally Prime gets all sales vouchers for the same date. We pull the narration field — that's where the order_id usually lives.
Step 4: Match in JavaScript
A Code node runs the join: amount within ₹0.50 (handle GST rounding), payment_id appearing in voucher narration, settlement_id matching voucher reference field.
Step 5: Slack output
One green summary message + a thread for each mismatch. Mismatches include a one-click "create Notion ticket" button for finance to track.
1
Self-host n8n on a Hetzner CX22
Spin up a Hetzner CX22 in the EU region (₹740/mo for 2 vCPU, 4GB RAM, 40GB SSD — plenty for SMB workflows). Use the [official n8n Docker compose](https://docs.n8n.io/hosting/installation/docker/) with PostgreSQL persistence. n8n Cloud's Starter is ₹2,070/mo and the Pro tier ₹4,150 — self-hosted is the right call once you cross 5 active workflows. Verify: log in at https://n8n.your-domain.com, create a "Hello World" workflow, run it.
2
Generate Razorpay API keys
Razorpay Dashboard → Settings → API Keys → Generate Test Key (start here). For settlements, you only need the read-only "Settlement Read" permission. Copy the Key ID and Key Secret into n8n's Credentials store as a "Razorpay" credential. The official n8n Razorpay node was released mid-2025 and is the right starting point. Verify: add a "Razorpay" node to a test workflow, set operation to "Get All Settlements", filter date = yesterday, run it. You should see one or more settlement objects.
3
Wire Tally Prime ODBC
Tally Prime 5.0 ships with an ODBC driver out of the box. On the Tally machine: F1 → Help → About → Configuration → ODBC Server: enable, port 9000. Open port 9000 to your n8n instance's IP. In n8n, add a Microsoft SQL Server node (Tally's ODBC speaks a SQL-like dialect) with the connection string. Verify: run `SELECT $Date, $VoucherNumber, $Amount, $Narration FROM Voucher WHERE $Date = "20251107"` and confirm rows return.
4
Write the matcher Code node
A JavaScript Code node receives two inputs: settlements_with_payments and tally_vouchers. The matcher iterates payments, finds the voucher with matching amount (±₹0.50 for GST rounding) and matching payment_id in narration. We share the full code below. Verify: output structure should be { matched: [...], mismatched: [...], unmatched_payments: [...], unmatched_vouchers: [...] }.
5
Build the Slack output
A Slack node posts to #finance-recon with the green summary. An IF node routes mismatched items to a Loop → Slack thread reply pattern. Each mismatch reply includes Razorpay payment_id deeplink and Tally voucher number. Verify: on a day with at least one known mismatch, check the Slack thread renders and links open.
6
Add the cron trigger and error branch
Workflow Trigger: Cron at 0 15 8 * * 1-5 (8:15 am IST, weekdays). On any node failure, route to a Slack node posting to #ops-alerts and a PagerDuty trigger if the failure count exceeds 2 in 24h. Verify: simulate a Tally connection failure (turn off port 9000 for 30 sec), observe the alert reach Slack within a minute.
javascript
// Inputs (set in node Input Variables):
// - settlements: array of { id, amount, payments: [{ id, amount, order_id, ... }] }
// - vouchers: array of { date, voucherNumber, amount, narration, ... }
const TOLERANCE_PAISE = 50; // ₹0.50 — handle GST rounding
const matched = [];
const mismatched = [];
const unmatchedPayments = [];
const unmatchedVouchers = new Map(
vouchers.map(v => [v.voucherNumber, v])
);
for (const settlement of settlements) {
for (const payment of settlement.payments) {
// Razorpay amount is in paise; Tally amount in rupees with decimals
const paymentAmountPaise = payment.amount;
const candidateVouchers = vouchers.filter(v => {
const voucherAmountPaise = Math.round(v.amount * 100);
const amountDelta = Math.abs(voucherAmountPaise - paymentAmountPaise);
const narrationMatch = v.narration && v.narration.includes(payment.id);
return amountDelta <= TOLERANCE_PAISE && narrationMatch;
});
if (candidateVouchers.length === 1) {
matched.push({
payment_id: payment.id,
voucher_number: candidateVouchers[0].voucherNumber,
settlement_id: settlement.id,
amount: payment.amount / 100,
});
unmatchedVouchers.delete(candidateVouchers[0].voucherNumber);
} else if (candidateVouchers.length === 0) {
unmatchedPayments.push({
payment_id: payment.id,
amount: payment.amount / 100,
order_id: payment.order_id,
razorpay_url: https://dashboard.razorpay.com/app/payments/${payment.id},
suspected_cause: 'No Tally voucher with matching amount + payment_id in narration',
});
} else {
mismatched.push({
payment_id: payment.id,
candidates: candidateVouchers.map(v => v.voucherNumber),
amount: payment.amount / 100,
suspected_cause: 'Multiple Tally vouchers match — likely duplicate posting',
});
}
}
}
return [{
json: {
matched,
mismatched,
unmatched_payments: unmatchedPayments,
unmatched_vouchers: Array.from(unmatchedVouchers.values()),
summary: {
total_payments: settlements.flatMap(s => s.payments).length,
matched_count: matched.length,
mismatched_count: mismatched.length,
match_rate: matched.length / settlements.flatMap(s => s.payments).length,
},
},
}];Production gotcha: Razorpay's API rate limit is 100 requests/minute on the standard plan. A workflow that fetches settlements + payments + (per-payment) detail can exceed that on a high-volume day. Add a 600ms delay between batched calls — saves you from rate-limit 429s during festive volume.
## Cost breakdown — every paisa
| Component | Provider | Monthly cost (₹) |
|---|---|---|
| n8n self-hosted | Hetzner CX22 (2 vCPU, 4 GB RAM) | 740 |
| n8n license | n8n (self-hosted is free for fair use) | 0 |
| Razorpay API | Read-only API calls (free) | 0 |
| Tally Prime ODBC | Bundled with Tally Prime license | 0 |
| Slack workspace | Free tier (90-day message retention) | 0 |
| Backup VPS storage | Hetzner snapshots | 62 |
| Total | 802 | |
| Tool | Setup time | Monthly cost (this flow) | When to pick it |
|---|---|---|---|
| n8n self-hosted | 4 hrs (with Docker familiarity) | ₹740-820 | You have a developer; you'll add 5+ workflows in year 1 |
| n8n Cloud Pro | 2 hrs | ₹4,150 | You don't want to operate Docker; team will use the editor heavily |
| Make.com | 3 hrs | ₹2,800 | Simpler workflows, better visual editor, no code-node need |
| Zapier | 2 hrs | ₹4,200 | Already paying for Zapier for other flows; not budget-sensitive |
| Custom Python script + cron | 2 days | ₹740 (same Hetzner) | You want full control; comfortable owning the maintenance |
- n8n self-hosted on Hetzner with HTTPS via Caddy or Cloudflare Tunnel
- Razorpay test-mode API keys verified in n8n credentials
- Razorpay live-mode API keys swapped in only after 7 days of test-mode runs
- Tally Prime ODBC enabled on port 9000, accessible only via VPN tunnel
- Read-only Tally user created for the n8n credential
- Matcher node tested with 50+ historical payments (manually verified output)
- Cron set to 8:15 IST, weekdays only (handles weekend settlement gap)
- Razorpay "Return All" set to true on the settlements node
- Tally query wrapped in 90s timeout + 2 retries spaced 30s apart
- Error branch posts to #ops-alerts, escalates to PagerDuty after 2 failures
- Slack channel #finance-recon created, finance team subscribed
- Notion database for mismatch tickets linked from Slack messages
voucher_type filter in the Tally query.
### What if my Razorpay account has multiple sub-merchants (Razorpay Route)?
The settlements API returns the merchant_id field. Add a filter step in n8n that splits the workflow per merchant_id before matching. Each sub-merchant needs its own Tally book; the matcher then runs once per (merchant, day) pair.
### Can n8n handle high-volume reconciliation (10,000+ payments/day)?
Yes, but the Tally ODBC becomes the bottleneck before n8n does. At that volume we recommend skipping Tally Prime entirely — move to Zoho Books or a custom Postgres ledger. n8n itself happily processes 100k+ records per workflow on the CX22.
### Is there an open-source template for this workflow?
We are publishing the n8n JSON export under MIT in our [GitHub example repo](https://github.com/softechinfra) by end of November 2025. Email contact@softechinfra.com if you want early access — we share it with serious askers in advance.
## Where this fits in our work
We build automation flows like this for our AI automation clients regularly — finance reconciliation, lead enrichment, sales rollups, vendor onboarding. The pattern is the same: pick the boring grunt task that eats 6+ hours of a salaried role per week, build a 4-16 node n8n workflow that runs on a ₹740/month box, save the time, repurpose the human.
This post was written by Hrishikesh Baidya, our CTO, who built and runs this workflow against our own books. For an SMB e-commerce build where the same automation philosophy was applied to lead capture, see our Radiant Finance case study.
For more on the BFCM-day stack checks that pair with this reconciliation flow, see our Nov 27 Black Friday post. For the Diwali post-mortem that explains why these workflows became urgent in 2025, see Diwali 2025 Was the ₹60,700 Cr Week.
Want This Auto-Reconciliation Flow Built for Your Finance Team?
We ship this n8n + Tally Prime + Razorpay workflow as a fixed-scope 5-day engagement. ₹62,000 all-in for SMB-scale Tally Prime setups. Includes the workflow, hosting setup on your or our Hetzner instance, finance-team training session, and 30 days of bug-fix support. Suitable for SMBs doing ₹50 lakh to ₹15 Cr in monthly Razorpay volume.
Book a 30-min Build CallTags:
n8nTally PrimeRazorpayReconciliationFinance AutomationWorkflowIndian SMB
