RBI Purpose Codes for Amazon, Payoneer and Marketplace Receipts

What does a purpose code actually control?

Every foreign currency credit into an Indian bank account is reported to RBI under the FETERS framework. Foreign Exchange Transactions Electronic Reporting System. Receipt purpose codes run from P0001 to P1590 across sixteen groups, and the code your AD bank attaches is the only machine-readable statement of what the money was for. Nothing else on the credit carries that meaning: not the amount, not the remitter name, not your invoice.

That one field does three jobs at once, and only the first is obvious.

Three things the purpose code decides

• National statistics. FETERS data rolls up into India's balance of payments. A goods export coded as a service receipt is counted as services trade, not merchandise exports.
• EDPMS matching. EDPMS reconciles inward remittances against shipping bills. A remittance carrying a services purpose code is generally not available to the bank to close a goods shipping bill entry, because the system does not treat it as an export realisation for goods.
• eBRC availability. Under the revamped self-certification system (DGFT Trade Notice 33/2023-24) you map bank-reported Inward Remittance Messages to shipping bills. A mis-coded IRM may simply not appear in the pool of remittances you can map against a goods shipping bill.

The reason this is so damaging for marketplace sellers is the shape of the failure. The money is in your account. The bank statement is correct. Your books balance. Your accountant sees nothing. GST returns file normally. The only symptom is an EDPMS entry that stays open. And most sellers do not look at EDPMS until a bank sends a pending list, which can be six to twelve months after the shipment.

This guide is about marketplace and platform receipts specifically. For the general FETERS code structure and the full reference of receipt codes across all sixteen groups, see RBI purpose codes explained .

Which code applies to which marketplace flow?

The rule that resolves almost every marketplace case is this: the purpose code describes the underlying transaction, not the payment rail. Payoneer, Wise, Stripe and Amazon Payments are conduits. If goods physically left India under a shipping bill, the receipt is a goods export realisation regardless of how many intermediaries the money passed through on the way.

The second rule handles the rest: timing decides P0101 versus P0102. Money that arrives after shipment is a realisation of an export bill. Money that arrives before shipment is an advance against export of goods and has to be reported as such, then adjusted against the shipping bill when it is filed.

Why do banks and platforms get it wrong?

Purpose code errors on marketplace receipts are not carelessness. They are the predictable output of a system where the person choosing the code has almost no information about the transaction. Four structural problems produce nearly all of them.

The four failure sources

1. 1 The remitter is not the buyer On a normal export the remitter name is the overseas buyer and the bank can see a commercial counterparty. On a marketplace payout the remitter is Payoneer, Wise, Amazon Payments, Stripe or PayPal. To the bank's systems that looks like a transfer from a financial institution, which is exactly the profile that does not read as a goods export.
2. 2 The narration carries no export information Payoneer and Wise withdrawals typically arrive with a generic transfer or settlement narration and an internal reference. There is no invoice number, no shipping bill, no description of goods. Nothing in the message tells the bank a container of textiles left Nhava Sheva six weeks ago.
3. 3 Payouts bundle goods and services together A single fortnightly payout can contain physical product sales, digital download sales and platform reimbursements. One credit, one purpose code, several genuinely different underlying transactions. Whatever code is chosen is wrong for part of the money.
4. 4 The bank defaults when your declaration is missing The AD bank enters the code based on the declaration the beneficiary provides. When no declaration arrives (and for small recurring credits, one usually does not) the branch or the central processing unit picks something plausible from the remitter profile. Plausible, given a financial-institution remitter and a bare narration, is usually a services or miscellaneous code.

Notice where the responsibility actually sits. The bank enters the code, but the code is supposed to reflect your declaration of the purpose. If you never declare, you have delegated a compliance decision about your own exports to someone who has never seen your shipping bills. Amazon, Payoneer and Wise publish nothing on this. Their documentation covers how to receive the money, not how India requires it to be reported.

What if I earn from both goods and services?

A large share of Indian marketplace sellers earn more than one kind of foreign income. A handicraft exporter also sells digital patterns. A product seller also takes design freelance work. A brand sells physical goods on Amazon and a subscription app on the side. If all of it lands in one Payoneer or Wise account and withdraws to one Indian bank account, you have built a structure that guarantees mis-coding.

The reason is simple. A standing declaration works because it lets the bank apply one code by default to a predictable stream. The moment a stream is not predictable, the default is wrong roughly in proportion to how mixed it is. And the bank has no way to tell which withdrawal is which.

The structural recommendation: route goods export proceeds to a dedicated bank account under your IEC-linked entity, and route service, SaaS and freelance income somewhere else. Give the goods account a standing declaration that says every credit to it is a realisation of an export bill for goods under P0101 unless specifically flagged as an advance. That single move converts your highest-volume, highest-risk stream from a per-credit judgment call into a rule.

Where a single payout genuinely bundles goods and digital sales (common on Etsy and on Amazon accounts selling both physical and Kindle-type products) you cannot restructure your way out. Here the answer is a split declaration: submit the platform settlement report with the payout, show the goods total and the digital total, and ask the bank to report the credit as two components under their respective codes. Banks do this routinely for aggregated e-commerce settlements when the breakup is documented; they will not do it if you hand them one number.

What breaks when the code is wrong?

The damage from a wrong purpose code is sequential. Each stage looks like an unrelated problem, which is why sellers usually treat five separate symptoms instead of one root cause.

The failure chain

1. :

Because each stage surfaces separately, the symptom you see rarely points at the code. Use this table to work backwards.

How do I file a standing declaration?

This is the single highest-leverage action in this guide. Because the AD bank applies the code based on the beneficiary's declaration, a standing declaration converts every future credit from a guess into an instruction. It costs one letter and one meeting.

What the declaration must contain

• Identification. Legal entity name, IEC, PAN, GSTIN, the specific account number(s) the declaration applies to, and the branch.
• Nature of business. One plain sentence stating that you export physical goods from India under shipping bills / CSB-V courier bills of export, with a short description of the product category.
• Named remitters. The exact remitter names that will appear on your credits: Payoneer, Wise, Amazon Payments, Stripe, PayPal, and the entity names each of them actually remits under. Say explicitly that these are payment intermediaries, not the buyers.
• Default code per stream. State the code to apply by default to each stream: post-shipment goods realisations under P0101, advances received before shipment under P0102, and any services stream under its own P08 or P10 code.
• The exception rule. A line saying you will notify the bank in writing before any credit that departs from the default (an advance, a merchanting receipt, a platform reimbursement), and that absent such notice the default applies.
• Undertaking. That you will furnish the platform settlement report, export invoices and shipping bill particulars on request, and that you remain responsible for the correctness of the declared purpose.
• Validity and refresh. A stated validity (12 months is a sensible default) and your commitment to refresh on any change of platform, revenue stream or account.

Structure it in this order. Letterhead and date. Addressee: the Head of Trade Finance / Forex at your branch. Subject line naming it as a standing declaration of purpose of inward remittances for FETERS reporting, with your IEC. Paragraph one: who you are and what you export. Paragraph two: the account this applies to. A table listing remitter name, stream description, and the purpose code to apply. Paragraph three: the exception rule. Paragraph four: the undertaking and validity. Signature of an authorised signatory with company seal. Two copies, one acknowledged and stamped for your file.

Who to give it to, and how to make it stick

1. 1 Address it to trade finance, not the retail counter Purpose codes are entered by the forex / trade finance function or a centralised trade processing unit. A letter left at a retail branch counter will be filed and never reach the people who code your credits.
2. 2 Get an acknowledged copy with a stamp and date This is your evidence later that you declared correctly and the bank coded against your instruction. Without it, an amendment request becomes your word against the branch's record.
3. 3 Ask them to flag the account in their system A letter in a file does not change behaviour. Ask specifically whether the declaration can be tagged against the account or customer ID so the processing unit sees it, and note down who confirmed it.
4. 4 Verify on the next three credits Pull the purpose code on the next three inward remittances and confirm the declaration is being applied. Fixing a drift after three credits is trivial; after three hundred it is a project.
5. 5 Refresh it on every trigger event Refresh annually, and immediately on: adding a platform or payment provider, adding a digital or service revenue stream, changing branch, changing relationship manager, or opening a new account. Relationship manager changes are the most common cause of a declaration quietly ceasing to be applied.

Can a wrong code be fixed later?

A wrong code on a past remittance is correctable. The AD bank can amend the purpose code and re-report the corrected FETERS data on a written request supported by documentation of the underlying transaction. Banks vary in willingness, and some insist the request comes within a limited window of the credit date, so the practical rule is to raise it the moment you spot it.

The full amendment process (the request format, escalation path, timelines and what to do when a bank refuses) is covered in how to change a purpose code at your bank . What follows here is only the part that is specific to marketplace receipts: the evidence pack.

A normal exporter proves the underlying transaction with an invoice and a shipping bill. You cannot, because one payout covers many orders and the amount received never equals the invoice value. Your job is to hand the bank an unbroken chain from the credit amount back to specific shipping bills.

The marketplace evidence pack

• Platform settlement report for the exact payout period, showing the gross sales, the fee deductions, the refunds and the net disbursed amount that ties to the credit in your bank statement.
• Payout statement from the intermediary. The Payoneer or Wise transaction showing that this specific withdrawal corresponds to that platform settlement, including the reference that appears in your bank narration.
• Order-level detail mapping each order in the settlement to its export invoice number and destination country.
• Order-to-shipping-bill trail. The mapping from those invoices to shipping bill or CSB-V numbers with LEO dates. This is the document banks actually need and the one sellers almost never have ready.
• Reconciliation summary on one page: credit amount, gross order value, fees and refunds deducted, the shipping bills covered and the FOB value against each. The arithmetic must close exactly.
• Amendment request letter naming the credit date, amount, currency, bank reference, the code currently reported, the code it should be, and the reason.

Purpose code checklist for marketplace sellers

Set up once

• Separate goods export proceeds into a dedicated bank account under the IEC-linked entity
• Move freelance, SaaS and digital product income out of that account
• File a standing declaration with the trade finance desk naming every remitter and its default code
• Keep an acknowledged, stamped copy of the declaration in your compliance file
• Confirm the declaration is tagged against the account or customer ID in the bank's system, and note who confirmed it
• Build a standing order-to-shipping-bill mapping process, not a one-off spreadsheet you rebuild under pressure

Check every month

• Pull the purpose code on every inward remittance for the month from your bank
• Confirm every goods payout is in the P01 group and every services receipt is not
• Confirm nothing received after shipment was coded P0102 as an advance
• Reconcile total P01-coded receipts against total FOB shipped for the period
• Check your EDPMS pending list for shipping bills you know were paid
• Check the DGFT eBRC screen for IRMs that should be available for mapping but are not
• Raise an amendment request the same month for anything mis-coded. Never batch these to year end

Trigger events that require action

• Adding a new marketplace, gateway or payment intermediary. Refresh the declaration before the first payout
• Launching a digital product or service alongside physical goods. Decide the account split first
• Receiving money before shipment for the first time. Notify the bank in writing so it is coded P0102
• Starting merchanting or intermediary trade. This needs P0103 and must never touch your goods stream
• Change of branch, relationship manager or account. Re-file the declaration

Update history

• 2026-08-13 First published.