Your Invoice Says One Thing. Your Bank Told the RBI Something Else.

Every time foreign money lands in your account, two different arms of the Indian government get told what it was for — and they don't talk to each other.

Your invoice carries a SAC code. That's what you told GST you did.

Your bank attaches an RBI purpose code to the remittance. That's what the RBI was told the money was for.

They're supposed to describe the same work. Very often they don't, because you chose the first one and somebody else chose the second one — usually a bank clerk, a platform default, or a dropdown your client's bank picked in another country.

If you export services, this matters more than it sounds. The purpose code is stamped on your e-FIRA, and the e-FIRA is the document that proves your money came in as export earnings. If it says something else, your export proof has a hole in it.

General information, not tax advice. The RBI's FETERS purpose code schedule and the CBIC's SAC schedule are both revised periodically, and published copies of the purpose code list circulating online disagree with each other in places. Confirm your specific codes with your AD bank and your CA.

The part most freelancers get wrong

You probably never picked your purpose code.

Most people assume it's automatic and correct. In practice it gets set one of three ways:

• Your bank asks you — sometimes a phone call, sometimes an email with a form, sometimes buried in the inward remittance advice you never opened.
• Your bank guesses — based on your account type or whatever the last one was.
• A default fires — and this is where it goes wrong.

The default is the dangerous case. If your money lands in a savings account rather than a current account, or if nobody supplied a code, it can get tagged as personal income rather than business income. Two codes in particular do real damage:

• P1301 — inward remittance from Indian non-residents towards family maintenance and savings
• P1499 — other income receipts

The first one means this is money from an NRI relative. Neither means this is an export of services. Your CA cannot use a P1301 remittance to support a zero-rated export, because on paper it isn't one.

If you've been receiving client payments into a savings account, stop reading and go check. This is the single most common version of the problem.

The crosswalk: SAC code to RBI purpose code

Here's the mapping between what goes on your invoice and what should be on your remittance. Codes starting with 99 are SAC codes under GST. Codes starting with P are RBI purpose codes for inward remittance.

What those P-codes actually say, in the RBI's own words: P0802 is software implementation and consultancy other than that covered by a SOFTEX form. P0803 is database and data processing charges. P0804 is repair and maintenance of computer and software. P1002 is trade-related services, commission on exports and imports. P1004 legal, P1005 accounting and auditing, P1006 business and management consultancy and public relations, P1007 advertising, trade fair, market research and public opinion polling, P1009 architectural, engineering and other technical services. P1019 is the catch-all: other services not included elsewhere.

The SAC schedule is maintained by the CBIC under GST; the purpose code schedule sits in the RBI's FETERS reporting annexure, and your AD bank publishes its own copy of it. Both are revised periodically, so treat the table as a starting point and confirm edge cases against those references or with your bank.

If you're unsure which SAC applies to your work in the first place, start with the SAC codes guide for freelancers — that's the code you have direct control over.

Three places the two lists genuinely don't line up

P0802 is one code doing four jobs. Development, consulting, hosting and support all collapse into it. That isn't sloppiness on your bank's part; the RBI's list simply isn't as granular as GST's. Where GST gives you 998313, 998314 and 998315, the RBI gives you one line.

There is a second software code, and most freelancers should not use it. P0807 covers off-site software exports — the ones reported through a SOFTEX form. SOFTEX filing is the world of STPI registration and SEZ units, not solo freelancers invoicing a US client from a laptop. P0802 exists precisely for software work outside the SOFTEX net, which is where nearly every freelancer sits. If your bank proposes P0807, ask why, and be ready for the SOFTEX obligation that comes attached.

Designers and writers have no line of their own. This is the gap the crosswalk can't close cleanly. GST has 998391 for specialty design and 998399 for other professional services; the RBI's Group 10 has no design entry and no writing entry, so the honest answer is P1019 — other services not included elsewhere. Two exceptions worth knowing: creative work produced for a campaign sits comfortably under P1007 (advertising), and design that ships as part of a software deliverable follows the software into P0802. Be aware that several payment-platform guides recommend P0806 for design and content work. In the RBI's own schedule P0806 is "other information services — subscription to newspapers, periodicals," which is not what a freelance designer does. Some bank lists also print the Group 10 catch-all as P1099 rather than P1019. Use whichever code appears on your own AD bank's list, and don't be surprised when two guides contradict each other.

How to check yours in five minutes

1. 1.Find your last inward remittance advice or e-FIRA. Your bank emails it, or it's in net banking under foreign inward remittance. If you use a cross-border payments platform, it's in your dashboard.
2. 2.Look for a five-character code starting with P. It's usually near the amount or in a field labelled purpose or purpose code.
3. 3.Compare it to the table above against the SAC on the invoice that payment was for.
4. 4.Check the account it landed in. A savings account is a warning sign on its own.

If they match, you're done — and you now know something most freelancers don't.

If the purpose code on your inward remittance is wrong

For payments already received: contact your bank's trade or forex desk, not the branch counter. Tell them the purpose code on a specific remittance is incorrect and ask what they need to amend it — typically the invoice, the contract or SOW, and a short declaration of the actual nature of the service.

Be realistic: banks can amend recent transactions fairly readily. Older ones are harder, because the FETERS reporting has already gone to the RBI. If a bank says no, don't leave it there — keep the invoice, the contract and the payment trail together in one place. A wrong code is much easier to explain when the underlying documents are consistent and available.

Going forward, this is a five-minute fix. Write to your bank once, in writing, telling them the standing purpose code for your inward remittances and what your business does. Most banks will note it against the account. If you use a payments platform, set it in your profile so it applies to every future payment rather than transaction by transaction.

And receive client money in a current account, not a savings account. Nearly every default-code problem traces back to this.

Why this is worth ten minutes of your time

Your export position rests on documents agreeing with each other. The invoice says you exported a service. The LUT says you're entitled to do it without charging IGST. The e-FIRA says the money came in from abroad, in foreign currency, for that service.

Break the chain at the last link and the first two are weaker than they look. It matters twice over: once when your CA is assembling a refund claim, and again if a payment goes missing entirely and you need to show what did and didn't arrive within the Rule 96A year.

This isn't usually a crisis. It's the kind of thing that surfaces at the worst possible moment, when someone asks for proof and the paperwork tells two different stories. If this is your first foreign payment, the inward remittance walkthrough covers the rest of the paper trail around it.

The good news is that it's genuinely a five-minute check, and once fixed, it stays fixed.

Keeping the two ends consistent

The reason this drifts is that the SAC lives on your invoice and the purpose code lives at your bank, and for most freelancers those are two completely separate systems with nothing joining them.

Mavoin keeps the SAC on the client and the service, so the same code comes out on every invoice for that work rather than being retyped each time — which at least means the invoice side of the chain is consistent when you go to compare it against your e-FIRA. It handles the rest of the export invoice too: USD billing with INR books, place of supply outside India, and the LUT declaration.

Start a 30-day trial — no card required.

Mavoin is not a Chartered Accountant service. General information, current as of August 2026. RBI purpose code schedules are revised periodically — confirm any specific code with your AD bank or CA before relying on it.