eBRC Self-Certification from Amazon and Payoneer Settlements

What self-certification changed

DGFT Trade Notice 33/2023-24, issued in November 2023, replaced the bank-issued Bank Realisation Certificate with an exporter-self-certified one. The bank no longer produces your certificate. Instead, your AD bank pushes every foreign inward credit into the DGFT system as an Inward Remittance Message (IRM) , and you decide which shipping bills that money paid for, in what proportion, and then self-certify the eBRC.

For a traditional exporter with one buyer, one invoice and one telegraphic transfer, this is administrative. For a marketplace seller it is a structural change. And, once you understand it, a favourable one.

You still need eBRC for the same things you always did: RoDTEP scrip utilisation, final settlement of duty drawback, closure of Advance Authorisation and EPCG export obligations, and Status Holder recognition. If you are new to eBRC as a concept (what it proves, what the DGFT screens look like, and the generic rejection reasons) read the general eBRC filing guide first. This guide assumes you know that and deals only with the marketplace settlement problem.

What is an IRM and what does it contain?

An Inward Remittance Message is the bank's structured record of one foreign currency credit into your account. It is the atom of the whole system: DGFT will not let you certify a rupee of realisation that is not backed by an IRM the bank has reported. Nothing you generate yourself (not an Amazon settlement report, not a Payoneer statement) can substitute for it.

To see what the bank has actually reported for you, go to dgft.gov.in , log in with your IEC-linked credentials, and open the eBRC module. The IRM listing shows every remittance your AD banks have pushed in, with the balance still available for mapping against each one. Two habits pay for themselves:

Working with the IRM list

• Check it fortnightly, not annually. An IRM with a wrong purpose code takes weeks to get corrected. You want to discover that in week one of a 9-month window, not month eight.
• Reconcile against your bank statement. Every foreign credit in the statement should have a matching IRM. A credit with no IRM means the bank either has not uploaded it or booked it as something other than an inward remittance.
• Track the unmapped balance per IRM. Since one IRM can be split across many shipping bills over time, the useful number is not the IRM amount but how much of it is still unallocated.
• Note which AD code reported it. If you bank with more than one AD, the IRM must come from the same AD code branch context as the shipping bill, or the mapping will be rejected.

The Payoneer and Wise money chain

The single most common misunderstanding among marketplace exporters is where realisation happens. Money moves through four or five hands before it becomes rupees in India, and only the last leg counts for eBRC.

Marketplace payout → IRM

1. :

Steps 1 to 4 generate no IRM at all. Only the credit at step 5 does. Two consequences follow, and both cost exporters real money every year:

Why this matters

• Balance parked in Payoneer is unrealised export proceeds. If you leave $40,000 sitting in a USD receiving account for a year, FEMA treats those exports as unrealised, because nothing has been repatriated to India. The 9-month FEMA window runs from the date of export on the shipping bill, and it is the INR credit that stops the clock.
• Your withdrawal pattern becomes your mapping problem. One withdrawal covering two settlements produces one IRM spanning every shipping bill in both. Partial withdrawals produce the reverse: one settlement split across two IRMs, so each shipping bill inside it needs two mappings.
• The remitter will never be Amazon. The IRM shows the payment company as remitter. Your reconciliation file is the only thing connecting that name back to the marketplace orders and the shipping bills.

The purpose code trap

This is the section worth the most money to you. If your Payoneer or Wise remittance never shows up as available for eBRC mapping against a goods shipping bill, the overwhelmingly likely cause is that your bank tagged it with the wrong RBI purpose code.

Every inward remittance has to be classified. The purpose code tells RBI what kind of transaction it was. Goods exports sit in the P0101 series. Realisation of export proceeds against goods that have been shipped. The eBRC module filters on this: a remittance tagged as services income, or as a generic "other current receipt", is not offered for mapping against a goods shipping bill, no matter how obviously it relates to your exports.

Why banks get it wrong on payment-platform credits

It is not carelessness so much as missing information. The bank classifies from what the wire tells it, and a Payoneer or Wise payout tells it very little about the underlying trade:

What the bank sees, and what it concludes

• The remitter is a payment company. The wire comes from Payoneer or Wise, not from an overseas buyer of goods. A processor looks like a services counterparty to a classification desk.
• There is no invoice reference in the narration. A conventional export wire quotes the invoice or the shipping bill. A wallet withdrawal usually carries a withdrawal ID and nothing else.
• The amount matches nothing. Because platform and wallet fees are already deducted, the credit does not equal any invoice or FOB value, so the desk cannot pattern-match it to an open shipping bill.
• The account may not be flagged as an exporter. If your IEC and AD code are not properly recorded against the current account, the bank has no reason to look for a goods export at all.

How to get a wrong purpose code corrected

Purpose codes are amendable. You are asking for a reclassification of an existing reported transaction, which the trade services desk can do. But they will not do it from a phone call. Send a written request with everything they need to justify the change in their own file:

Purpose code amendment request

1. 1 Identify the exact IRM Quote the bank reference number, credit date, foreign currency amount, INR credited and the purpose code currently applied. Vague requests get bounced.
2. 2 Prove the money is against goods Attach the Payoneer or Wise withdrawal advice, the Amazon settlement reports it covers, and the list of shipping bills with LEO dates and FOB values. This is the chain that turns "a credit from a payment company" into "export proceeds against these shipping bills".
3. 3 Give a covering declaration On letterhead: the receipt represents realisation of export proceeds for goods exported under the listed shipping bills, and should be classified under the goods-export purpose code. State your IEC and the AD code.
4. 4 Ask for re-reporting, not just an internal correction An amendment in the bank's own system is useless to you unless the corrected IRM is re-transmitted to DGFT. Say so explicitly and ask for confirmation once it has been pushed.
5. 5 Fix it at source for future credits Ask the branch to record a standing instruction that inward remittances from your Payoneer or Wise account are goods-export proceeds against your IEC. This is the difference between doing this once and doing it every fortnight.

Mapping one IRM across many shipping bills

Once the IRM is visible with the right purpose code, the remaining work is arithmetic and evidence. The method is to work backwards down the money chain, because that is the direction in which the relationships are unambiguous.

The working-backwards method

1. 1 IRM → withdrawal Match the IRM's foreign currency amount and value date to a specific Payoneer or Wise withdrawal. Payment platforms give each withdrawal a transaction ID; record it. This is a one-to-one link and should never be ambiguous.
2. 2 Withdrawal → settlements From the platform's account activity, list which incoming settlement credits that withdrawal drew on. Use first-in-first-out against the balance so the answer is deterministic and repeatable, and write down the rule you used.
3. 3 Settlements → orders Download each Amazon settlement report. It itemises every order ID, the product charges, and every fee deducted. This is the document that ties an opaque net payout to individual sales.
4. 4 Orders → shipping bills Map order IDs to the shipping bills they were exported under, using your courier or CSB-V manifest, or your own dispatch register. Record shipping bill number, port code, LEO date and FOB value.
5. 5 Allocate proportionally by FOB Spread the IRM's INR value across those shipping bills in proportion to their FOB values. Proportional allocation is defensible precisely because it is mechanical. It does not let you flatter one bill at the expense of another.

Worked example

An IRM of INR 8,20,000 lands in your AD bank. It corresponds to a Payoneer withdrawal of $9,800 , which drew on two Amazon settlements. Between them, those settlements cover orders exported under four shipping bills:

The allocation factor for each shipping bill is its FOB divided by the total FOB of 2,000. Apply that factor to both the IRM's foreign currency amount and its INR amount:

Four eBRCs get self-certified against this one IRM, for INR 2,73,333, 2,39,167, 1,70,833 and 1,36,667 respectively. The unrounded values are 2,73,333.33, 2,39,166.67, 1,70,833.33 and 1,36,666.67, so rounding to the rupee happens to close exactly here. It will not always. When it does not, put the one or two rupee difference on the largest shipping bill so the allocation still sums to the IRM to the paisa. An allocation that does not tie back to the IRM total is the first thing a reviewer will notice.

Note that the implied realisation rate here is 8,20,000 / 9,800 = INR 83.67 per dollar, and that each shipping bill has realised only 68.33% of its FOB (8,20,000 against a FOB of 2,000). Section 6 deals with that gap.

The gap between FOB and realised amount

A marketplace exporter never realises 100% of FOB. Money is taken at three separate layers before rupees reach India, and none of those deductions appear anywhere on the shipping bill. Continuing the worked example above:

Self-certify the eBRC for what actually arrived. Partial realisation is permitted by design and the certificate is issued for the realised amount, not the FOB. What you must not do is inflate the certification to match FOB. You signed it, and the IRM behind it is a fixed number the system already holds.

That leaves a permanent shortfall on each shipping bill. 31.67% in this example. You have three routes, in this order of preference:

Closing the residual gap

• Check whether more money is still coming. If part of the settlement is still sitting in the Payoneer balance, withdraw it. A later IRM mapped to the same shipping bills reduces the gap without any regulatory process at all. Do this before treating anything as a shortfall.
• Use the small-value simplified closure route where it applies. RBI Circular 12 dated 1 October 2025 provides a simplified closure path for low-value export shipping bills below INR 10 lakh, which is precisely the size band nearly every marketplace consignment falls into. Ask your AD bank which documentation set they operate for it. Typically a declaration plus the settlement evidence showing the deductions were commercial fees, not non-payment.
• Apply for a write-off through your AD bank for the rest. For shipping bills outside the small-value route, the AD bank can write off short realisation within its delegated limits on a self-write-off basis, against documentary proof of the fees and refunds that caused the gap.

Records to keep for audit

Under self-certification, the burden of proof moved to you. Nobody checks the allocation at the point of certification. Which means it gets checked later, by a DGFT scrutiny of an Advance Authorisation or EPCG closure, by your AD bank when it reviews outstanding export bills, or by your statutory auditor. The reconciliation file is the deliverable.

Structure the reconciliation as one flat file where a single row is one shipping bill's share of one IRM. That grain lets the same file answer both questions a reviewer asks ("where did this IRM go?" and "what paid for this shipping bill?") by filtering on one column:

Reconciliation row structure

• bank_ref_no · irm_date · purpose_code · irm_fc_amount · irm_inr_amount
• withdrawal_id · withdrawal_date · withdrawal_fc · wallet_fees
• settlement_id · settlement_period · settlement_gross · platform_fees · settlement_net
• order_ids · sb_no · port_code · leo_date · sb_fob_fc
• allocation_pct · allocated_fc · allocated_inr · ebrc_no · ebrc_date
• sb_cumulative_realised · sb_residual_gap · gap_treatment

Two control totals make the file self-checking: for every bank_ref_no , the sum of allocated_inr must equal irm_inr_amount ; and for every sb_no , the sum of allocated_fc across all IRMs must never exceed sb_fob_fc . Run both checks before you certify anything, not after.

On retention: keep the full chain for at least five years from the date of the eBRC, and longer where the shipping bill supports an Advance Authorisation or EPCG obligation. In that case keep it until the licence is formally redeemed plus five years, because scrutiny of an EPCG closure can reach back the full eight-year obligation period. Store the marketplace settlement reports as downloaded files: platforms purge older reports from the seller console, and you cannot reconstruct them later.

Marketplace seller checklist

Set up once

• Confirm your IEC and the correct AD code are recorded against the current account that receives Payoneer or Wise withdrawals
• Tell the branch in writing that inward remittances from your payment platform are goods-export proceeds, and ask for a standing purpose code instruction
• Run one small test withdrawal and verify the purpose code that appears on the resulting IRM in the DGFT eBRC module
• Decide and write down your withdrawal policy. Ideally one full withdrawal per settlement cycle
• Set up the reconciliation file with the row structure in section 7 and both control totals

Every settlement cycle

• Download the itemised marketplace settlement report and archive it
• Withdraw to the AD bank and save the withdrawal advice with its transaction ID
• Save the bank credit advice, FIRA and charge advice for the resulting INR credit
• Map order IDs in the settlement to shipping bill numbers, port codes, LEO dates and FOB values

Fortnightly on the DGFT portal

• Open the eBRC module and reconcile the IRM list against every foreign credit in your bank statement
• Check the purpose code on each new IRM; raise an amendment request the same week if it is not a goods-export code
• Allocate each available IRM across its shipping bills pro rata to FOB, verifying the allocation sums exactly to the IRM
• Confirm no shipping bill's cumulative realisation exceeds its FOB, then self-certify
• Download each eBRC PDF and record its number against the shipping bill in the reconciliation file

Monthly review

• List every shipping bill approaching 6 months from LEO. Three months of headroom before the 9-month FEMA window closes
• For each, check whether the balance is still sitting in the wallet, still unmapped in an IRM, or genuinely a fee shortfall
• Route genuine shortfalls to the small-value simplified closure route or an AD bank write-off, with the three-layer fee evidence attached
• Reconcile eBRC coverage against your open RoDTEP, Advance Authorisation and EPCG obligations

Update history

• 2026-08-13 First published.