Vendor Payments Automation Playbook (India)

Quick answer. Vendor payments at scale require: (1) a master vendor file with verified bank accounts and tax data, (2) bills approved through a structured workflow (maker / checker / authoriser), (3) batched payments grouped by rail (NEFT / RTGS / IMPS / UPI), (4) bank-file generation in the format your bank ingests, (5) automated payment-to-bill reconciliation when the bank confirmation lands, (6) fraud controls (vendor-bank-change re-verification, duplicate-payment detection, beneficiary whitelist). Done by hand, this takes a 2–3 person AP team a full week per cycle. Done right, it runs in batched windows and the team handles only exceptions.

The four payment rails, when to use what

In India, a finance team picks from four standard rails for vendor payments. Each has different cost, speed, limit, and reconciliation behaviour:

Rail	Speed	Limit per txn	Cost (typical)	Cut-off	Use case
NEFT	T+0 to T+1 (settles in 30-min batches)	None	Free / nominal	24×7 since Dec 2019	Default for most vendor payments
RTGS	Real-time	≥ ₹2 lakh	₹15–50 per txn	24×7 since Dec 2020	Large single payments (≥ ₹2L)
IMPS	Instant	≤ ₹5 lakh per txn	₹5–15 per txn	24×7	Urgent small payments (refunds, last-minute vendor)
UPI	Instant	≤ ₹2 lakh (per txn, varies by bank)	Free	24×7	Small vendors, freelancers, MSME contractors

A modern AP system picks the rail per payment based on amount, urgency, and vendor preference, without the AP user having to decide. The default rule:

if amount >= 2_00_000 and urgency == 'normal':  use RTGS
elif amount <= 5_00_000 and urgency == 'urgent': use IMPS
elif amount <= 2_00_000 and vendor.upi_id:       use UPI
else:                                             use NEFT

Bank files are generated per rail per bank, you can’t put NEFT and RTGS instructions in the same file most of the time.

The architecture in one diagram

BILLS (approved, ready to pay)
     │
     ▼
PAY RUN (group bills by vendor + due date)
     │
     ▼
RAIL SELECTION (per the rule above)
     │
     ▼
APPROVAL CHAIN (maker → checker → authoriser)
     │
     ▼
BANK FILE GENERATION (per rail, per bank)
     │
     ▼
UPLOAD TO BANK PORTAL / CONNECT API
     │
     ▼
BANK CONFIRMATION (UTR returned per payment)
     │
     ▼
PAYMENT-TO-BILL RECONCILIATION (UTR back-applied to bills)
     │
     ▼
LEDGER POSTING (vendor account credited, bank debited)

Every stage is a candidate for automation. A team that handles 5,000+ vendor payments a month must have at least the bank-file generation + UTR reconciliation automated; the rest follows.

1. Vendor master, the foundation

Every vendor should carry, at minimum:

Verified bank account (account number + IFSC, validated via penny drop or NPCI’s Aadhaar Pay verifier)
Vendor name as registered with the bank (the name validation is critical for NEFT/RTGS, a name mismatch causes return)
PAN (validated via IT API)
GSTIN (if applicable, validated via GST portal)
Udyam URN (if MSME)
Default payment rail (vendor preference)
Default payment terms (net days, with a hard cap for MSME at 45 days, see our MSME 43B(h) playbook)
TDS section + rate (defaulted by vendor, overridable per bill)
Beneficiary status (active / hold / off-boarded)

Bank account verification, penny drop

The single most-skipped step that bites teams later. Penny drop sends ₹1 to the supplied bank account and confirms:

The account is active (not closed / dormant)
The account holder name matches the vendor name (within string-match tolerance)
The IFSC is valid for the branch

Run penny drop:

At onboarding (mandatory)
Whenever vendor changes bank details (mandatory, biggest fraud vector)
Quarterly (defensive)

A penny drop costs ₹1–5 per check via banking partners. Cheap insurance against payments to the wrong account.

2. Bill approval, the maker / checker / authoriser pattern

A robust AP shop uses a 3-actor approval chain:

Role	Responsibility	Typical seniority
Maker	Posts the bill from the vendor invoice. Captures GRN ref, GL coding, TDS, GST.	AP analyst
Checker	Reviews the bill for accuracy. Confirms PO match, GRN match, tax treatment.	AP team lead
Authoriser	Approves payment. Confirms vendor relationship is in good standing, applies any holds.	AP manager / Controller

For higher-value payments, additional approval levels apply (e.g., > ₹10 lakh requires CFO sign-off; > ₹1 cr requires CEO).

The approval matrix should be enforced by the system, not by a Slack thread. Each approval stage logs:

Actor (employee ID)
Timestamp
Decision (approve / reject)
Comment / reason
Material change since previous level (e.g., if the maker re-edits after the checker approved, the checker must re-approve)

Without this enforcement, “approved” approvals are common, bills slip through with one signature on a late Friday.

3. Pay run, grouping bills for a payment cycle

A pay run is a snapshot of “everything we want to pay today”. Best-practice cadence:

Twice a week (Monday and Thursday) for a mid-market business
Daily for high-volume operations
MSME priority cycle running every day for vendors approaching the 43B(h) deadline

The pay run logic:

Pull all approved bills with status = ready_to_pay and due_date <= today + N days (N = horizon, typically 3 days).
Group by vendor + bank account + currency.
For each group, net any vendor credits (debit notes, advances).
Compute the net payment amount.
Apply rail selection per the rule.
Apply hold rules (vendor on credit hold, dispute, MSME Form 1 outstanding etc).
Output the pay-run draft for approval.

The output of a pay run is a list of payment instructions, each with: vendor, amount, rail, bank account, internal reference, list of bill IDs being paid.

4. Bank file generation, the bit that can’t be wrong

Each Indian bank accepts payment instructions in a slightly different file format:

Bank	Format	Notes
HDFC	Tab-delimited TXT, fixed-width XML	NEFT and RTGS in separate files
ICICI	XML or fixed-width TXT	Strict on field padding
SBI	CSV with header rows	One of the simpler formats
Axis	XML	Validates against XSD
Kotak	TXT	Has IMPS bulk file
Yes Bank	XLS	Yes, an Excel format. Validate macros are off.

A modern AP system generates the right file per bank automatically. Things that go wrong manually:

Date format wrong, bank rejects the entire file
IFSC length wrong, wrong padding, file rejected
Trailer record missing, file silently truncated, only some payments go through
Special characters in vendor name, bank’s parser chokes
Total in trailer ≠ sum of records, bank’s pre-validation rejects, AP scrambles

Generating these by hand from spreadsheets is the #1 source of “stuck payments” in AP shops.

Direct bank API as the next step

Many banks now offer direct API integration (Connected Banking / H2H connections / Corporate APIs):

HDFC has the Smart Hub API
ICICI has Corporate Internet Banking API
SBI has YONO Business API
Axis has Axis Connect / Centralised Bulk
Kotak has Kotak NetBanking Bulk APIs

API integration eliminates the file upload step entirely, payments flow from your AP system directly into the bank’s payment queue, with status updates streamed back. For volumes above ~500 payments per cycle, the ROI on API integration is 6–9 months.

5. Payment-to-bill reconciliation

When the bank confirms a payment, you receive:

A UTR (Unique Transaction Reference), the bank’s confirmation number
The settlement timestamp
The status (success / failed / returned)

This needs to be automatically back-applied to the bills you intended to pay. The reconciliation logic:

Match the UTR to the pay-run record using the bank’s reference field (which carries your internal reference).
For each bill in that pay-run record, mark paid_at = settlement_timestamp, payment_ref = UTR, status = paid.
Post the GL entry: debit Vendor Account, credit Bank Account. Net of TDS withheld.
Trigger the vendor email confirmation with UTR + invoice list.

If the payment fails or is returned:

Roll back the bills to status = pending_payment
Flag the vendor master entry for bank-detail re-verification
Notify the vendor and AP team
Re-queue for the next pay run

A common failure mode: partial payment returns in a batch. Bank confirms 100 of 105 payments; 5 returned for various reasons. The system must tear apart the batch and reconcile each line independently, manual handling here is slow and error-prone.

6. Fraud controls, what to lock down

Vendor payments are a top fraud vector in India. Reported losses run into hundreds of crores annually. The controls that matter:

Vendor-bank-change re-verification

Any change to a vendor’s bank account triggers a fresh penny drop + a 24-hour cool-off + a second-level approval before the first payment to the new account.
Many fraud cases involve a “vendor changes bank account” email that’s actually from a phisher. The system should never accept bank-detail changes from email, only from a verified, signed channel.

Duplicate payment detection

Hash every payment by (vendor_id, amount, period). Flag any two payments within 7 days of each other matching this hash for manual review.
5–10% of AP shops we’ve audited find at least one duplicate payment per quarter.

Beneficiary whitelist

A new vendor cannot be paid more than ₹X (e.g., ₹1 lakh) until they’re whitelisted.
Whitelisting is a separate approval chain.

Maker / authoriser separation

The same user cannot post a bill AND authorise its payment. Enforce at the system level, not just policy.

Authorisation thresholds tied to seniority

Authorisation matrix tied to the current employee role, not a static config, when someone leaves, their pending approvals are reassigned automatically.

Anomaly detection on payment patterns

Unusual payment to a low-volume vendor (e.g., 10x normal)
Multiple payments to the same vendor in a short window
Vendor whose UPI ID changed recently being paid
Round-number payments (less suspicious individually but a pattern flag)

Common operational pitfalls

Pitfall	Impact	Fix
Manual bank file uploads	Slow, error-prone, occasional file rejection	Move to bank API for high volume; templated file generation otherwise
No penny drop on bank changes	Fraud risk	Enforce penny drop on every bank-detail update
Single-file batch covering many rails	Bank rejects	Split files by rail (NEFT / RTGS / IMPS)
UTR not back-applied to bills	”Paid but unreconciled” entries	Automate UTR → bill reconciliation
Payment return not fanned out	Bills stay in incorrect “paid” state	Reverse on return; re-queue
Approver bottleneck	Payment delays, MSME 43B(h) risk	Multi-approver alternatives, mobile approvals, escalation rules
TDS deducted but not deposited timely	Section 201 interest	Tie TDS deposit to payment cycle, automate challan
GSTIN-PAN mismatch on vendor master	TDS goes wrong	Validate GSTIN-PAN linkage at onboarding

CFO dashboard, what to watch weekly

Total payment value processed, by rail, by bank, by vendor tier
Failed / returned payments, count, value, root cause
Payment cycle latency, days from bill posting to payment
MSME bills past 30-day window, at-risk for 43B(h)
Vendor master integrity, % with verified bank, PAN, GSTIN, Udyam (where applicable)
Duplicate-payment alerts, count, status
Bank file rejections, count, root cause
Open approvals > 48 hours, bottleneck signal

The 60-day implementation plan

For an AP team moving from spreadsheet + portal uploads to a structured platform:

Week	Milestone
1–2	Vendor master cleanup. Penny-drop verify all active vendors. Tag MSME, GST, TDS section per vendor.
3	Approval matrix design. Document maker / checker / authoriser per spend tier.
4	Bill approval workflow live. Move all in-flight bills to the new flow.
5–6	Pay run logic configured. First batched pay run executed via the new system.
7–8	Bank file generation per bank format. Sandbox testing with bank pre-live environment.
9	Production go-live with one bank. Monitor first three pay cycles closely.
10	Add second bank. Add UTR reconciliation automation.
11–12	Add fraud controls (penny drop on changes, duplicate detection, beneficiary whitelist).

Tooling: what to look for

Multi-bank file format library, one config per bank, validated outputs
Direct bank API support for at least HDFC / ICICI / Axis (the dominant corporate banks in India)
Penny drop integration with vendor master changes
Maker / checker / authoriser as first-class workflow primitives
Pay run with rail auto-selection
UTR back-application as a scheduled job
TDS deduction + 26Q population as a side-effect of payment, not a separate workflow
MSME deadline awareness, the system surfaces 43B(h)-at-risk bills first
Approval-time SLAs with mobile approval for partners on the go
Audit trail with actor, timestamp, before/after on every state change

OneFinOps treats Payables as one record across bills, approvals, payments, and bank reconciliation. TDS, GSTR-2B, MSME 43B(h), and audit trail are by-products. Start a free trial or book a 30-min walkthrough.

Frequently asked questions

Should we use NEFT or RTGS for payments above ₹2 lakh?

RTGS for any payment ≥ ₹2 lakh that’s time-sensitive (deadline today / tomorrow). NEFT settles in 30-minute batches now (24×7), so for non-urgent payments NEFT is fine and free. Default rule: NEFT < ₹2L, RTGS ≥ ₹2L if urgent.

How do we handle payments to non-resident vendors?

Wire transfer (SWIFT) via your bank, with Form 15CA / 15CB as required (Form 15CA always; 15CB above ₹5 lakh per remittance from a CA). Most corporate banking platforms support bulk SWIFT files; the AP system can generate the data, but the form filing happens at the bank’s end with your CA’s certification.

Can we pay vendors via UPI for B2B amounts?

Yes, UPI works up to ₹5 lakh per transaction for some banks (₹2 lakh for most). UPI Bharat Bill Payment is even more limited. For now, UPI is suitable for small-vendor payments (consultants, contractors, MSMEs). Treat it as a parallel rail, not a replacement for NEFT.

How do we automate TDS deduction at payment time?

The bill’s TDS line is computed when posted (per the vendor’s section + rate). At payment, the system pays gross_amount - TDS_withheld to the vendor and posts the TDS to a “TDS Payable” GL. A scheduled monthly job generates the OLTAS challan and remits the consolidated TDS. See our TDS Automation Playbook for the full workflow.

What’s a typical AP team headcount for X invoice volume?

Industry rough numbers: 1 AP analyst handles ~500–1,000 bills/month with average automation, ~2,000–3,000 with full automation. A team of 5 with strong automation can handle the AP load of a ₹500 cr+ revenue company.

Are corporate cards a substitute for vendor payments?

For T&E and small-ticket purchases, yes. For structured vendor relationships (recurring services, materials), no, cards generate per-transaction fees, weaker reconciliation, and don’t tie to PO/GRN. Use cards for the long-tail, AP for the core spend.

What about international vendor payments (USD, EUR)?

Two paths: (1) wire transfer via your bank with FEMA/RBI compliance handled per regulation, or (2) cross-border payment platforms (Wise, Salt, Intermex) that aggregate FX and reduce fees by 1–2%. The compliance overhead (Form A2, LRS limits if individual, Foreign Tax Credit on TDS to non-residents) is the same either way.

Sources

RBI, NEFT, RTGS, IMPS Operating Guidelines.
NPCI, UPI Operating & Settlement Guidelines.
RBI Master Direction on Digital Payment Security Controls (Feb 2021), fraud controls baseline.
Income Tax Act, 1961, Section 195, 195A, 197, 206AB, relevant TDS provisions for vendor payments.
GSTR-2B Reconciliation Playbook and TDS Automation Playbook, adjacent OneFinOps guides.

This guide is operational, not legal advice. FEMA/RBI compliance for cross-border payments and high-value structured payments should be reviewed with your treasury and tax counsel.

Vendor Payments Automation: The Indian Finance Team Playbook