Every foreign payment that enters India carries a four character code attached to it. Most Indian exporters have never chosen one, could not name the one on their last remittance, and will not think about it until a bank or a GST officer raises a question that turns out to trace back to it.
The code is small and consequential. It determines how the Reserve Bank sees your transaction, whether your remittance reconciles cleanly against your export declaration, and whether the story your paperwork tells matches the story your business tells.
Here is what purpose codes are, who assigns yours, what happens when the wrong one is applied, and why the answer connects to how you chose to get paid in the first place.
What a purpose code is
India reports its external transactions as part of balance of payments statistics, and every cross border payment has to be classified by what it was for. The RBI maintains a list of purpose codes for this, and every authorised dealer bank applies one to every transaction it handles.
The codes are split by direction. Inward remittances, money coming into India, carry P codes. Outward remittances, money leaving India, carry S codes. As an exporter receiving payment for services or goods, you are dealing with P codes.
Within that, codes are grouped by the nature of the transaction. There are families covering travel, transportation, financial services, software and information technology services, professional and business services, and merchandise trade, among others. Software consultancy and implementation services fall under P0802, which is the single code most frequently relevant to Indian technology exporters.
The full list is published by the RBI and is longer than most people expect, with distinctions that are meaningful in reporting terms and invisible in commercial ones. Confirm the specific code for your revenue type against the current RBI list or with your AD bank rather than working from what someone posted on a forum, since the list is revised and the differences between adjacent codes are exactly the sort of thing that gets summarised inaccurately.
Who actually assigns it
This is the part that surprises exporters. In many cases, nobody who understands your business chose the code on your remittance.
On a SWIFT wire, the purpose is derived from what the remitter or their bank wrote in the payment message, then interpreted by the receiving bank. Your US client, filling in a wire form, is not classifying your revenue under an Indian regulatory taxonomy. They are typing a description into a field. What arrives at your AD bank is that description, and the code assigned is somebody at the bank matching free text to a list.
Through a card gateway, the classification follows the merchant category and the platform reporting, which may or may not reflect what your business actually supplies.
Through a cross border collection platform authorised under the RBI Payment Aggregator Cross Border framework, the code is set as part of onboarding and applied per transaction, which is a materially different situation because it is set once by someone looking at your actual business. skydo applies the purpose code automatically to every payment and issues the FIRA carrying it, which means the classification is deliberate rather than inferred from a free text field filled in by your client eight thousand kilometres away.
What goes wrong when the code is off
Four consequences, roughly in order of how often they surface.
EDPMS entries that will not close
The Export Data Processing and Monitoring System matches export declarations against realised remittances. A remittance classified inconsistently with the declaration is harder to match, and unmatched entries stay open against the exporter. Open entries accumulate, and a poor record can eventually restrict your ability to transact export business through the banking system.
GST refund friction
Export of services is zero rated, and claiming the benefit requires demonstrating that foreign currency came into India against your invoices. A remittance whose stated purpose does not align with the services on the invoice invites a question, and questions add months to refund cycles that are already slow.
Queries from your AD bank
Banks review whether the reported purpose fits the customer profile. A company registered for software development receiving a stream of payments coded as something unrelated will get asked about it, and the credit can sit pending while the query is answered.
A record that contradicts itself
The slowest burning consequence. Over years, remittances coded inconsistently create a transaction history that does not describe a coherent business. That history is what an auditor reads, what a bank reads during a credit assessment, and what an acquirer reads during diligence. Nobody flags it at the time and everybody reads it later.
Matching the code to what you supply
| What you actually supply | Code family to look at | Supporting evidence | Common misclassification |
| Software consultancy and implementation | P08 software and IT services | Statement of work, invoice describing the service | Tagged as general business consultancy |
| Hosted software subscription | P08 software and IT services | Subscription agreement, recurring invoice | Tagged as a royalty or licence fee |
| Management or business consulting | P10 professional and business services | Engagement letter, deliverable record | Tagged as software services |
| Design, marketing or content services | P10 professional and business services | Contract, dated deliverables | Tagged under a generic services code |
| Goods exported physically | Merchandise export codes | Shipping bill, invoice, AD code registration | Treated as a services remittance |
The last column is where most errors actually sit, and the pattern is instructive: the misclassifications are almost always between adjacent plausible categories rather than wild mistakes. That is precisely why they are not caught at the time.
How to find out what code you are currently on
Most exporters reading this do not know their own code, so start there. It takes one afternoon.
Pull the FIRA or remittance advice for your last five inbound payments. The purpose code should be a field on each. If your documents do not show one, that is itself the finding, and the issuer is the person to ask.
Check whether the same code appears across all five. Variation across payments for the same kind of work from the same client means the classification is being inferred per transaction rather than set, which is the signature of a wire based route.
Then compare the code against what your invoices actually describe. Read the service description on the invoice and the code family side by side and ask whether a stranger would connect them. If the answer is no, that gap is what a bank query eventually asks about.
Finally, ask your AD bank for your outstanding EDPMS entry position. Unmatched entries are the most direct evidence that something upstream is not reconciling, and the position is a single request rather than a project.
How this connects to SOFTEX and export declarations
For software exporters there is an additional layer worth understanding, because the purpose code sits inside a wider reporting chain.
Software exports from India are declared and tracked through EDPMS, and the SOFTEX form is the declaration mechanism for software exported other than in physical form. The system then expects a realised inward remittance to match against each declaration.
Lower value software export invoices have carried exemptions from full SOFTEX filing, and the applicable threshold has been revised over time. Confirm the current position for your invoice values with your AD bank rather than working from an older summary, since this is precisely the sort of detail that circulates in outdated form.
What does not change is the matching logic. A declaration exists, a realisation is expected against it, and the purpose code on the realisation is one of the fields that determines how cleanly those two things reconcile. A code that misdescribes the service makes the matching harder for a system that has no judgement and simply leaves the entry open.
This is the practical reason purpose codes matter more for software and IT exporters than for most other businesses. The reporting chain is longer, there are more places for a mismatch to surface, and the entries that stay open belong to you.
Correcting a wrongly coded remittance
It is possible and it is slow, which is the argument for getting it right at source.
Raise it with your AD bank, in writing, with the transaction reference, the corrected code, and the invoice and contract supporting the classification. The bank processes an amendment and, where relevant, corrects the EDPMS reporting.
Two practical notes. The further back the transaction, the more work it becomes, since staff change and older transactions require retrieval. And a pattern of amendments looks worse than a single correction, so if you discover the code has been wrong on every payment for two years, fix the process first and then approach the bank with a consolidated correction and an explanation of what changed.
Where cost and classification meet
Cheapest way to receive international payments in India is a search that ranks routes by headline fee and ignores what the fee buys. Purpose code handling is one of the things it buys, and it is worth pricing.
Consider what a wrongly coded payment actually costs. Your CA spends hours reconstructing and explaining it. A GST refund sits an extra quarter, which is working capital parked with the department. An EDPMS entry stays open and eventually generates correspondence. In a bad case, a credit sits pending while a bank query is resolved.
Set against that, the difference between the cheapest available rail and one that applies the code automatically is usually a few thousand rupees a year for a mid-sized exporter. The arithmetic is not close, and it runs the opposite way to how the decision is usually made.
This is the general shape of cost in Indian cross border collections. The visible price is the transfer fee. The real price includes the professional hours, the working capital timing, and the risk of a payment stopping. Optimising only the visible component reliably increases the total.
Frequently asked questions
Can I choose my own purpose code?
You can and should specify what your business supplies so the correct code is applied. What you cannot do is select a code for convenience. It has to reflect the actual nature of the transaction, and a mismatch between the code and your invoices is exactly what creates the problems above.
What code applies to SaaS subscription revenue?
Software and IT services codes are the relevant family, and the specific code depends on whether you are supplying a hosted subscription, an implementation service, or a licence. These are treated differently and the distinction matters. Confirm yours with your AD bank or your payment platform against the current RBI list.
Do I need a different code for each client?
The code follows the nature of the service rather than the client. A business supplying one type of service uses one code across clients. A business with genuinely different revenue lines may legitimately use more than one.
Does the purpose code appear on my FIRA?
It should. A remittance document without a purpose code is missing the field that makes it useful for reconciliation. If yours does not show one, ask the issuer.
What if my client writes something odd in the wire description?
On a wire, that description drives the classification, which is the structural weakness of the rail. Give clients standard wording to use, or move to a collection method where the code is set on your side.
Do purpose codes affect my tax liability?
The code is a reporting classification rather than a tax determination. It affects your ability to evidence a position, particularly on zero rated exports, which is a different thing and matters just as much in practice.
The short version
A purpose code is four characters that tell the RBI what your money was for. On a wire it is inferred from what your client typed. On a properly configured collection platform it is set deliberately and applied automatically. The wrong code produces unmatched EDPMS entries, slower GST refunds, bank queries and a transaction history that misdescribes your business, and every one of those costs more than the fee difference that usually drives the decision.
