Corporate Treasury Bulk Payouts under AFA: SAP, Oracle, Tally & Zoho Compliance Playbook (2026)

Until 31 March 2026, most Indian corporate treasury teams ran vendor payouts, salary disbursals, and refunds through a single-token batch authentication — one OTP, one maker-checker approval, and 500 payments fired from SAP, Oracle, Tally, or Zoho Books in a single API call. From 1 April 2026, that pattern is non-compliant under the RBI Authentication Mechanisms for Digital Payment Transactions Directions, 2025. Every individual debit needs Additional Factor Authentication (AFA) at the transaction-initiation point — not just at session login. This guide covers the treasury workflows that break, the ERP-side fixes, the API patterns your bank now supports, and a 30-day audit plan for finance teams running ₹50 lakh+ in monthly payouts.

What Changed for Corporate Treasury on 1 April 2026?

Pre-April 2026, the typical corporate payout flow worked like this: a maker uploaded a file (NACH, RTGS, NEFT-batch, or IMPS-bulk) into the corporate net-banking portal, the checker approved with one OTP, and the bank processed every individual debit in the batch under that single approval. The 2025 Directions kill this. AFA must apply at the transaction level, not the session level — meaning the second factor either runs per-payment, or the maker-checker workflow itself needs two independent AFA events with the checker logging in afresh per batch.

The RBI's reasoning is straightforward: compromised maker credentials should not authorise ₹10 crore of outgoing payouts in one shot. A breach in the ERP, a poisoned vendor master file, or a credential-stuffed maker account becomes a single-token catastrophe under the old pattern. By forcing per-batch (and ideally per-payment) AFA, the framework caps blast radius.

The treasury workflows that need to change

• Vendor payouts via H2H ERP integration — most exposed.
• Salary disbursal via NACH — narrow carve-out under Corporate IB.
• Statutory remittances (TDS, GST, PF, ESI) — typically pull-based, less exposed but still need session AFA.
• Refunds via RazorpayX / Cashfree Payouts / ICICI iBizz — fintech rails have already updated; verify API version.
• Inter-company sweeps and treasury concentration — exempt only if both accounts are with the same bank under group structure.

Which ERP and Bank Integrations Break First?

SAP S/4HANA's Bank Communication Management module, Oracle Fusion's Payments and Collections, Tally Prime's Banking module, and Zoho Books' Vendor Paymentsall support H2H connectivity with major Indian banks (SBI, HDFC, ICICI, Axis, Kotak, Yes Bank). The old pattern: ERP generates an ISO 20022 pain.001 file or a proprietary bank format, signs it with a digital certificate, transmits via SFTP or API, and the bank executes the batch after a single session-level checker approval.

Post-April 2026, three things change in this pipeline:

1. Bank-side AFA callback — after receiving the batch, the bank pushes an AFA challenge to the registered checker's device per batch (not per file).
2. Per-payment threshold escalation — individual debits above ₹2 lakh (varies by bank) require explicit per-payment OTP from the checker, not just batch approval.
3. Vendor whitelist + cool-off — newly added beneficiaries face a 24-48 hour cool-off plus a fresh AFA challenge on the first transfer. New vendor master entries created during the batch are quarantined.

The Two Compliant Patterns Your Bank Will Accept

Per-payment AFA is operationally painful for high-volume payouts (a 10,000-row salary file would need 10,000 OTPs). So most banks have implemented a hybrid:

Pattern A: Per-batch AFA via dual-authoriser workflow

The maker submits the file from the ERP. The bank's H2H endpoint accepts it, returns a batch reference, and queues it for authorisation. The checker logs into Corporate IB with their own session-level AFA, reviews batch summary (count, total amount, top beneficiaries), and approves with a fresh per-batch OTP. Only after this does the bank execute. Each batch = one AFA event, but it's bound to a specific batch reference and a specific human checker — not to the maker's session token.

Pattern B: Per-payment AFA via API tokenisation

For payments where instant settlement matters (refunds, vendor advances, urgent payouts), banks have rolled out API endpoints where each individual payment carries its own AFA token. This is the pattern RazorpayX, Cashfree Payouts, ICICI iBizz Payouts, and HDFC Smart Hub use. Each payment call includes a one-time token generated by the checker app on their registered device. Higher operational cost, lower blast radius.

ERP Configuration: What Your IT Team Must Change

The compliance fix doesn't require a full ERP upgrade. Most changes sit in the bank-connector configuration and the vendor-master workflow.

SAP S/4HANA

• Activate the Bank Status Monitor in transaction code FBPM to receive AFA-callback acknowledgements.
• Update house-bank configuration (FI12) to enable per-batch acknowledgement codes (PAIN.002).
• In Payment Medium Workbench (PMW), set payment-method supplement to require AFA reference before posting.
• Vendor master (LFA1 / LFBK): add the AFA cool-off flag for new beneficiaries; cool-off period configurable per company code.

Oracle Fusion / Oracle EBS

• Payments module: update funds-capture process profile to require External Authorisation for outbound batches.
• Payment instruction status workflow: add an "Awaiting Bank AFA" state between "Confirmed" and "Settled".
• Vendor onboarding: enable the New Beneficiary Hold with bank-specific cool-off durations.

Tally Prime

• Banking module: configure e-Payment Authorisation to require checker login with fresh OTP per file upload.
• Disable the legacy single-token mode if it was enabled before April 2026 — check Banking → Configuration → Authorisation Mode.
• Vendor ledger: add UDF (user-defined field) for beneficiary registration date; payments to vendors registered <48 hours ago trigger manual review.

Zoho Books

• Vendor Payments: switch to the ICICI / HDFC / Yes Bank direct integration that uses per-batch AFA callbacks.
• Disable the bulk-export-to-bank file workflow if your bank's H2H endpoint requires per-payment tokens.
• Enable two-step approval under Settings → Users & Roles for the Payouts module — separate maker and checker.

The Vendor Master Audit Nobody Wants to Do

Failed payments cost more than mismatched ones because each retry needs a fresh AFA event. A typo in IFSC code, a closed beneficiary account, or a renamed-bank scenario (think the IDFC First Bank rebrand, or the recent merger wave) creates retry loops that flood the checker's device with AFA challenges. Treasury teams that haven't audited vendor master data since 2024 will see exception queues balloon.

Salary Disbursal: The Narrow Carve-Out and Its Limits

RBI guidance allows a streamlined workflow for salary payouts via Corporate Internet Banking. The maker uploads the salary file, the checker reviews aggregate (total amount, headcount, payroll period reference) and approves with one OTP — provided the maker and checker are distinct authorised signatories and both complete independent session-level AFA at login. This is effectively Pattern A with a relaxed per-payment threshold.

But the carve-out has limits. If the file contains a new joinee (beneficiary registered within 30 days), that line item is held back for explicit per-payment AFA. If any individual line crosses the per-payment threshold (typically ₹5 lakh for salary, varies by bank), it requires line-level approval. If the file deviates >10% from prior-month aggregate, the bank's anomaly engine forces line-level review.

Refunds: Why E-commerce and SaaS Treasury Teams Have a Different Problem

For e-commerce, refunds are continuous, low-ticket, and customer-experience-critical. Waiting for an end-of-day batch is unacceptable. Most fintech-rail refund flows (RazorpayX Refunds, Cashfree Payouts, Stripe Refunds India) have moved to Pattern B — per-payment AFA via API. The token is generated by a registered service account on a hardware-bound device, not a human checker. This is permitted under the Directions as long as the device is in possession of an authorised employee, the cryptographic chain is auditable, and individual payment limits are enforced programmatically.

The trade-off: higher per-payment cost (API token issuance + transaction fee), but no human bottleneck. For SaaS treasury teams running 5,000+ refunds/month, Pattern B is the only practical route. Reserve Pattern A for high-value, low-frequency disbursements like vendor advances.

What Auditors Will Look For Under SOX / IFC in 2026-27

Statutory auditors signing off on Internal Financial Controls (IFC) reporting for FY 2026-27 will add AFA compliance to their payment-cycle walkthrough. Expect questions on:

• Maker-checker segregation — is it documented in the delegation of authority?
• AFA token custody — who holds the device or hardware token; what happens at exit?
• Vendor master change controls — who can add/modify; is there independent review?
• Failed-payment monitoring — is there a documented escalation for AFA-failure spikes?
• Service-account hygiene — for Pattern B, who provisioned the API token; what's the rotation cadence?

Auditors will also test a sample of payments end-to-end: from PO/invoice to ERP entry to bank transmission to AFA reference to settlement confirmation. Missing AFA reference IDs in the audit trail are an IFC deficiency — even if the payment ultimately settled.

The 30-Day Treasury Audit Plan

1. Days 1-5: Inventory all H2H integrations. List bank, ERP, file format, and current authorisation pattern. Identify single-token configurations.
2. Days 6-10: Request written AFA-compliance confirmation from each bank's corporate relationship manager. Get it on letterhead with the bank's compliance officer's sign-off.
3. Days 11-15: Run vendor master audit. Clear duplicates, dormants, and unverified IFSCs.
4. Days 16-20: Configure ERP-side changes — bank-connector AFA callbacks, beneficiary cool-off flags, dual-authoriser workflow.
5. Days 21-25: Run parallel reconciliation — process one cycle (salary, vendor batch, statutory) under both old and new flow. Document exceptions.
6. Days 26-30: Update DOA, IFC walkthrough, and standard operating procedure. Train backup checkers. Issue revised treasury manual.

How Bizeract Helps Treasury Teams

We work with mid-market finance teams to map existing payout flows, identify single-token gaps, and configure ERP-bank integrations to the new AFA standard — without disrupting payroll cycles. Typical engagement: 4-6 weeks of parallel-running, vendor master cleansing, and DOA documentation. Talk to our automation team if you're carrying SAP, Oracle, Tally, or Zoho exposure into the next quarterly close.

Frequently Asked Questions

Is single-token batch authentication completely banned after April 2026?

Yes for new transactions. A single OTP authorising a batch of 500 payments — without per-batch or per-payment AFA bound to a specific human checker — is non-compliant under the 2025 Directions. Legacy pre-authorised standing instructions registered before April 2026 may continue, but new batch authorisations must follow Pattern A (per-batch AFA via dual-authoriser) or Pattern B (per-payment AFA via API token).

Do bulk salary disbursements still need AFA per employee?

No, with conditions. A salary batch can be approved with one per-batch OTP if maker and checker are distinct authorised signatories, both complete independent session AFA at login, and no line item triggers an anomaly (new joinee within 30 days, amount above per-payment threshold, or >10% deviation from prior cycle). Line-level AFA kicks in for anomalies only.

Which Indian banks have implemented AFA-callback APIs for H2H corporate payments?

All major banks have rolled out AFA-callback support: SBI Corporate Internet Banking, HDFC ENet and Smart Hub, ICICI Corporate Internet Banking and iBizz Payouts, Axis Power Access, Kotak FYN, and Yes Bank YBL Connect. Each uses slightly different ISO 20022 or proprietary acknowledgement formats. Always request the bank's H2H API specification document dated post-April 2026.

What is the per-payment AFA threshold for corporate accounts?

Bank-specific — typically ₹2 lakh for vendor payouts and ₹5 lakh for salary. Above this threshold, individual payments need explicit per-line approval from the checker, even within a batch. Below the threshold, a single per-batch OTP suffices. Check your corporate net-banking limits screen under "Per-Transaction Authorisation Thresholds".

Are inter-company fund sweeps within the same group exempt from per-transaction AFA?

Yes, if both accounts are held with the same bank, under documented group ownership, and the sweep is pre-authorised via a standing instruction registered before April 2026 or under the bank's treasury-concentration product. Cross-bank sweeps and new standing instructions registered post- April 2026 follow the normal AFA rules. Verify with your relationship manager in writing.

What happens to ERP-bank integrations that haven't been updated by 1 April 2026?

The bank will progressively block batches that arrive without an AFA acknowledgement chain. The first signal is usually a held-batch alert in Corporate IB requiring fresh checker login and manual approval. Persistent non-compliance leads to the bank suspending the H2H channel and requiring all payouts to be processed via Corporate IB directly — operationally disruptive but not illegal.

How is liability split between the bank, the corporate, and the maker-checker in case of fraud?

Under the 2025 Directions, the issuer (bank) absorbs fraud liability if AFA wasn't properly enforced. If AFA was correctly applied and credentials were compromised due to corporate-side negligence (shared OTP devices, weak service-account hygiene), liability shifts to the corporate. Internal liability between maker, checker, and supervisor is governed by the DOA and employment contracts — auditors review this in IFC walkthroughs.