Payment Compliance in India: A Guide for Services Exporters

When an Indian software or services exporter gets paid by an overseas client, the payment is only half done. The other half is proving it, correctly and on time, so the money counts as legitimate export earnings under Indian law. That proving step is payment compliance, and it is where a smooth export receipt can quietly turn into a problem.

For an Indian services exporter, payment compliance means receiving foreign payments through an authorised banking channel and keeping a clean trail from contract to invoice to inward-remittance proof to reporting closure. In practice that comes down to four things: FEMA, the correct RBI purpose code, bank evidence such as FIRC or eFIRA, and EDPMS closure of the export entry.

• Payment compliance is following the rules that govern how export money is received, documented and reported, so every receipt is legal and traceable.
• The core stack for a services exporter is FEMA, purpose code, FIRC or eFIRA, and EDPMS.
• Global standards like PCI DSS, AML and KYC matter to your provider more than to you directly, but they still shape how you get paid.
• Freelancers below the GST threshold are still covered by FEMA and still need clean realisation proof.

Payment compliance is the practice of following the laws, regulations and technical standards that govern how money moves, so every transaction is legal, traceable and secure. For a domestic business that is mostly about data security and fraud rules. For an exporter receiving foreign money, it is mostly about evidence: proving to your bank and the RBI that a genuine export was paid for through proper channels.

That shift, from security to evidence, is why generic definitions of payment compliance miss what an Indian exporter actually needs.

Get it right and your export earnings are clean, your GST refund flows, and your export incentives stay intact. Get it wrong and you risk penalties under FEMA, a stuck GST refund, or an export entry that never closes. The stakes are practical, not theoretical.

A worked example of the cost of getting it wrong

A consultancy receives $9,000 from an overseas client into a personal account, coded as a personal transfer rather than a services export. When it files for a GST refund months later, it has no FIRC and no matching purpose code, so the refund is rejected and the export entry sits open in EDPMS.

Fixing it means reopening the receipt with the bank, re-coding it, and requesting documentation after the fact. The same $9,000, received through a compliant channel, would have carried its own proof from day one.

Responsibility is shared. The RBI writes the rules. Your Authorised Dealer bank applies them and issues documents. Your payment provider handles KYC, screening and settlement. You keep the contracts, invoices and records that tie it all together. A gap at any point is where a payment gets flagged.

Not every payment regulation you read about is aimed at you. This table separates what governs your provider from what governs your export receipt.

For the screening layer, see AML compliance and KYC for international payments. For the tax side, see cross-border tax compliance.

Every clean export receipt carries the same four elements:

• A purpose code classifying the receipt as a software or services export, commonly P0802 or P0807. See the purpose code reference.
• FIRC or eFIRA proving the inward remittance. A FIRC comes from the bank, and the eFIRA is issued automatically on platforms like Xflow. The related bank realisation certificate proves realisation.
• EDPMS closure so the export entry is marked realised. See the EDPMS guide for exporters.
• Realisation within the FEMA window, tracked from the invoice or export date, and where relevant supported by your SOFTEX filing.

An IT services firm invoices a US client $8,000. The client pays through a regulated receiving account. The provider settles about ₹7,60,000 at a rate near ₹95 into the firm's bank account the next business day, issues an eFIRA, and tags the receipt with a services-export purpose code. The bank records realisation in EDPMS. When the firm files for a GST refund, the eFIRA is the proof of realisation it needs. Nothing about the payment is left to explain later.

Say the same $8,000 arrives but is coded P1099 as a miscellaneous receipt instead of a services-export code. The money is in the account, but the classification does not match the export, so the bank cannot cleanly close the EDPMS entry, and the GST-refund claim is questioned. Correcting a purpose code after the fact means a request letter, supporting invoices, and a wait. Confirming the code at the point of receipt avoids all of it.

Payment compliance is not only about documents, it is also about timing. Export proceeds must be realised within the FEMA window for your export date. As of August 2026, exports made between 5 June and 30 September 2026 carry a 9-month window, and from 1 October 2026 the period is 15 months, or 18 months where the export is settled in INR.

A worked realisation example

A firm invoices $5,000 on 1 August 2026. Because that date sits in the 9-month window, the proceeds must be realised and repatriated by around 1 May 2027. If the client is slow, the firm should apply to its AD bank for an extension before that date rather than let the entry breach. Compliance here is a calendar task as much as a paperwork one.

• Wrong purpose code, which can misclassify a business receipt as a personal transfer and complicate reporting.
• Missing FIRC or eFIRA, which blocks GST refunds and leaves realisation unproven.
• Late realisation, which breaches the FEMA window and risks penalties.
• Mismatched documents, where the invoice, contract and remittance advice do not agree.

• Receive through an authorised, regulated channel, never an informal one, ideally one built for cross-border payments for service exporters.
• Confirm the purpose code on every receipt. Freelancers can start with the purpose code for freelancers guide.
• Keep the eFIRA or FIRC for each payment, filed against its invoice.
• Track realisation from the export date and know your FEMA window.
• Reconcile contract, invoice and remittance details so they match.

A purpose code is the label that tells the RBI why foreign money entered India. For a services exporter it is the single field that decides whether a receipt reads as export earning or as something else entirely, so it deserves more attention than it usually gets.

Two codes cover most software and services work. P0802 generally applies to software consultancy, implementation and related computer services, while P0807 generally covers other business and professional services. The right one depends on what you actually delivered, not on which is convenient. Where a single invoice mixes categories, the receipt may need splitting, which is where handling multiple purpose codes cleanly matters.

A worked purpose-code example

A firm delivers a software build for $6,000 and a separate advisory retainer for $2,000 to the same client, billed on one invoice. Booked under a single code, the receipt misrepresents half the work. Split correctly, the $6,000 sits under the software-services code and the $2,000 under the business-services code, so each part reads accurately and closes cleanly in EDPMS. The classification is not cosmetic, because it flows straight into your reporting and your GST position.

This is the fear that stops many exporters moving off a slow bank wire: the assumption that dropping SWIFT will break the FIRC, EDPMS and GST-refund workflow they rely on. It does not, and understanding why removes the main objection to a cheaper, faster rail.

When you receive through a regulated provider, the compliance evidence simply changes form rather than disappearing. The bank-issued FIRC is replaced by an automatically issued eFIRA that carries the same weight as proof of inward remittance, as set out in FIRC vs FIRA. EDPMS closure still happens through an AD bank, and your GST-refund claim still rests on the same realisation proof. Nothing downstream of the receipt changes.

A worked switching example

An exporter moves a recurring $7,000 monthly retainer off a bank wire and onto a receiving account. In the first month, the eFIRA arrives automatically, the purpose code is applied, and the AD bank closes the entry in EDPMS exactly as before. The finance team files the same GST-refund paperwork it always did, using the eFIRA in place of the old FIRC. The only visible difference is that the money arrives faster and costs less to convert. The compliance trail is intact throughout.

Xflow is built so the compliance stack comes with the payment, not after it. As of February 2026, Xflow holds final Payment Aggregator – Cross Border (PA-CB) authorisation from the RBI for both exports and imports.

• Receive from 140+ countries and 25+ currencies into one account.
• Get the eFIRA issued automatically for realisation and EDPMS closure.
• Settle to your Indian bank account the next business day at the live mid-market rate.
• Rely on payment security with ISO 27001 and SOC 2 certification.

For the GST side specifically, see FIRC for GST refund. This guide explains the rules, not personalised advice. For a specific tax or regulatory position, consult a chartered accountant.

The core duties are the same, because FEMA covers anyone exporting services from India. What changes is the paperwork burden around them.

A registered company usually files SOFTEX where applicable, maintains GST records, and reconciles receipts against invoices at scale. The reporting load is generally heavier here, and the reviews are typically more frequent. A freelancer below the GST threshold has a lighter load, but still needs each foreign receipt to arrive through a proper channel, carry a services-export purpose code, and produce inward-remittance proof.

A worked freelancer example

A designer earning $2,500 a month from overseas clients receives each payment into a receiving account rather than a personal wallet. Every receipt lands with an eFIRA and the right purpose code, so the designer has a clean record for income tax and can prove the money is legitimate export earning, without a GST registration. The compliance is lighter, but it is not optional, and doing it at the point of receipt saves reconstructing a year of payments at filing time.