Rules for Receiving USD Payments in India (2026)

The rules for receiving USD payments in India are set by the Foreign Exchange Management Act (FEMA) and the RBI's Master Directions, because inbound export earnings are treated as a current-account transaction, not a capital one.

The single point most guides get wrong: the Liberalised Remittance Scheme (LRS) cap of USD 250,000 per resident per financial year applies only to money you send out of India. It does not limit the money you receive. For a genuine IT or ITeS service export, there is generally no ceiling on what you can be paid.

What matters instead is the channel. Funds must arrive through an authorised dealer (AD) bank or a licensed cross-border payment aggregator, carry the correct RBI purpose code, be realised within the prescribed timeline, and be documented for GST and income tax. This page is the regulatory overview. Each rule below links to a detailed guide, so treat this as the map and follow the links for depth.

No. This is the costliest myth in USD to INR payment regulations, and it appears on bank pages, fintech blogs and forum answers alike.

The LRS is an outward scheme. It lets a resident individual remit up to USD 250,000 per financial year abroad for permitted purposes such as travel, education, investment or gifts (as of August 2026, per the RBI). It says nothing about inbound receipts.

When you export software or IT-enabled services and get paid in USD, you are on the receiving side of a current-account transaction, and the LRS ceiling is simply the wrong rule to cite.

If you want the outward side explained properly, see the foreign remittance limit guide and the difference between inward remittance vs outward remittance. The direction of the money decides which rulebook applies.

Receiving USD is governed as a current-account transaction under FEMA, which means it is generally permitted so long as it flows through an authorised channel and is reported correctly. Current-account transactions cover trade in goods and services, while capital-account transactions cover investments and borrowings, and the two sit under different parts of the law. For the underlying framework, read capital and current account transactions under FEMA under FEMA.

In practice, legitimate export receipts reach you one of two ways:

• Through an AD Category-I bank using the SWIFT network, credited to your current or EEFC account.
• Through a licensed cross-border payment aggregator authorised by the RBI under the PA-CB framework, which collects the USD abroad and settles INR to your Indian account.

Both routes are legal. The aggregator route usually adds automated documentation and a mid-market exchange rate, which we cover below. If you are new to the concept, the primer on inward remittance explains the mechanics, and the broader guide to foreign inward remittance walks through the end-to-end flow.

The USD can land in one of three account types, and the choice affects when you convert to INR. A normal savings or current account credits you in rupees on arrival at the bank's rate, which suits an exporter who wants INR at once but removes any control over conversion timing.

An Exchange Earners' Foreign Currency (EEFC) account lets an exporter hold the proceeds in USD and convert when the rate is favourable, rather than being converted the moment funds arrive (as of 2026). A dedicated receiving account, such as a PA-CB provider's virtual account, collects the USD abroad and then settles INR to your Indian account with automated documentation.

For an IT-services exporter billing in USD across the year, the ability to hold and time conversion matters, because FX spreads compound across many invoices. Match the account to your cash-flow and hedging needs rather than defaulting to whatever your bank opens first.

There is no general RBI ceiling on genuine export or service receipts. An IT exporter can receive USD 5,000 or USD 5 million against valid invoices, provided the payment carries a correct purpose code and the funds are realised on time.

Limits that do exist are channel-specific and rarely bind a services exporter:

For an exporter, SWIFT or a PA-CB aggregator is the route that matters, and it carries no ceiling. The RDA and MTSS caps apply to trade sub-cases and personal transfers, not to a standard USD service invoice. These channel caps are about routing, not tax, and they do not restrict a standard USD service invoice.

Every inbound payment must carry an RBI purpose code that describes the true nature of the receipt. For inward remittances the codes begin with "P", while outward codes begin with "S". Tagging the wrong code, or worse, tagging export income as a personal gift (code P1301), is a FEMA breach, not a shortcut.

For IT and ITeS exporters, the commonly used inward codes are:

Pick the code that matches the service you actually delivered. The full list, with edge cases, sits in the dedicated guide to the purpose code for inward remittance, so this page keeps to the codes an IT exporter meets most often.

Export proceeds must be realised and repatriated within nine months from the date of export. This applies to service exports, including software, and is set out in the RBI's Master Direction on the Export of Goods and Services.

A caution on timing: the nine-month period was temporarily relaxed to fifteen months and then restored to nine months under the 2026 amendment, and a fresh set of FEMA export and import regulations is scheduled to take effect from 1 October 2026 (as of August 2026).

Any guide quoting a flat "15 months" is reading an interim relaxation that no longer stands. Because the framework is mid-transition, confirm the current window with your AD bank or a chartered accountant before you rely on a specific date.

Missing the realisation deadline is not fatal, but it turns a routine receipt into a follow-up your bank must report against the RBI's Export Data Processing and Monitoring System (EDPMS). Realising on time keeps that ledger clean.

Four documents get conflated constantly, and they are not interchangeable. Knowing which one you need for GST, for DGFT benefits, or for a simple audit trail saves hours later.

For most IT exporters the working document is the eFIRA, one per payment, showing the UTR, the rate applied and the INR credited. Do not assume a payment platform's own receipt equals a bank FIRA or an eBRC. They are different records with different legal weight, so store the eFIRA for every transaction.

This distinction trips up software companies specifically. A SOFTEX form is required for the export of software products transmitted electronically. IT-enabled services, where software is merely the tool used to deliver a service such as support, BPO or consultancy, generally fall under ordinary service-export reporting rather than SOFTEX.

The line is not always clean. A firm shipping a licensed software product should expect SOFTEX obligations; a firm billing for implementation, support or data processing usually should not. Because the classification drives your EDPMS and eBRC reconciliation, confirm your category with your bank rather than assuming, especially if you invoice a related party such as a US parent.

The export of services is treated as a zero-rated supply under GST, which means you can supply without charging IGST provided you meet the statutory export conditions. Most IT exporters file a Letter of Undertaking (LUT) so they can invoice without IGST, rather than pay the tax and claim a refund later.

The conditions matter. The supplier must be in India, the recipient abroad, the place of supply outside India, and payment received in convertible foreign exchange. Intermediary services need a separate place-of-supply analysis and may not qualify. The full mechanics, including LUT filing, sit in the export of services under GST guide.

Here is a single export receipt from invoice to booked INR, the way it should run:

• Invoice: An ITeS exporter raises a $5,000 invoice to a US client for software implementation work.
• Channel: The client pays; funds route through an AD bank or a PA-CB receiving accounts setup that collects the USD abroad.
• Purpose code: The receipt is tagged P0802 (software consultancy and implementation).
• Documentation: The bank or platform generates an eFIRA carrying the UTR, the FX rate, the INR credited and the purpose code.
• GST: Because the supply is zero-rated and the exporter has filed an LUT, the invoice carries no IGST.
• Booking: At an illustrative USD/INR of ₹95 (illustrative only), the $5,000 books to ₹4,75,000 gross before any platform fee.
• Realisation and record-keeping: The proceeds are realised within nine months, the bank reconciles the receipt in EDPMS, and the exporter retains the invoice, contract and eFIRA for five years.

The exchange rate is where value quietly leaks. Banks typically add a spread to the USD/INR rate on top of any stated fee, so the INR you book can trail the mid-market rate by a noticeable margin. Compare the true landed cost before you pick a channel.

Xflow settles at the mid-market rate and issues an eFIRA automatically on every payment, which can save exporters up to 50% on FX costs versus a traditional bank once the spread is counted. That keeps both the rate and the compliance trail in one place.

Even a clean export receipt can stall when the paperwork does not line up. The usual triggers:

• Missing or wrong purpose code: The receipt is untagged or coded as a personal gift, so the bank holds it for clarification instead of crediting it as export income.
• Invoice-to-remittance mismatch: The amount, invoice number or payer name on the wire does not match your invoice, and the AD bank queries it before releasing the funds.
• Incomplete KYC: Outdated business KYC or an unregistered beneficiary account delays the credit until your records are refreshed.
• No LUT for GST-free export: Without a valid Letter of Undertaking on file, a zero-rated supply can attract IGST questions at reconciliation.

Each item maps to a rule covered above: the purpose code you tag, the documents you retain, and the export-under-GST conditions you meet. Fix them at the invoicing stage, not after the money is already held.