One payout, forty shipping bills: how do you reconcile that?

Why isn't a payout just an invoice payment?

In a traditional B2B export, one buyer pays one invoice against one shipment, and the inward remittance carries the invoice reference. The bank can see the link. Marketplace and platform selling breaks every part of that sentence. The buyer is not the remitter. The marketplace or the payment service provider is. The payment is not per order. It is per settlement window. The amount is not the invoice value. It is what is left after the platform has taken what it is contractually entitled to take. And the remittance advice carries an internal settlement reference, never a shipping bill number.

So you end up with two ledgers built by two systems that were never designed to speak to each other. Customs generates one row per consignment, keyed to a shipping bill number and a date of export, valued gross. The platform generates one row per settlement, keyed to a payout reference and a window, valued net. EDPMS sits on top of the first ledger and waits for entries from the second. It does not know the two are related.

This is worth being blunt about, because a lot of exporters lose months to the assumption that the mismatch is a data problem somebody else will fix. It is not. It is structural. The only thing that resolves it is a reconciliation you construct yourself and hand to your Authorised Dealer bank with the working shown.

What is deducted before the money reaches you?

The single most useful mental model is that the payout is the bottom of a waterfall, and the shipping bill value is the top. In between sit deductions that are contractual, disclosed in the platform's own fee schedule, and applied automatically before remittance. Every one of them is legitimate. Every one of them also widens the gap that EDPMS reads as unrealised value.

The exact fee lines and rates differ by platform and by payment service provider, and they change. Do not model them from memory and do not carry last year's percentages into this year's reconciliation. Read them off the settlement statement for the window you are reconciling. What is stable is the shape of the waterfall.

The compliance consequence of the waterfall is simple and uncomfortable: even a perfect reconciliation leaves the total realised value below the total declared value. That difference is real, it is permanent, and it has to be dealt with explicitly rather than left as an open balance in EDPMS. Section 7 covers the routes.

Why is subset matching the only method that works?

Because the problem is not "which bill does this payout close?" It is "which set of bills does this payout close, and in what proportion?" Once you accept that, the method falls out. You take the payout as fixed and known, you propose a candidate set of shipping bills, you run the deduction chain over that set, and you compare. A tie means the set is right. A miss tells you the set is wrong. Not that the money is missing.

Treat the payout as the known quantity and the set of shipping bills as the unknown. Every failed match is information about the set, not evidence of non-realisation. </> } />

A related trap: the same logic applies in reverse. One shipping bill can be realised through two or three payouts, which is normal for a consignment containing orders that settled either side of a window boundary or where part of the value sat in reserve. The bill is closed only when the apportioned amounts across all the payouts add up, which is why per-bill tracking matters more than per-payout tracking. The same pattern shows up in Amazon settlement reconciliation and in Etsy payouts routed through Payoneer .

What does a real reconciliation look like?

Below is the whole method on one page: a payout, a candidate set, the deduction chain read off the statement, and the apportionment back down to individual shipping bills. The numbers are illustrative (your fee lines will be different) but the arithmetic is the arithmetic your AD bank will want to re-perform.

A garment exporter selling on an overseas marketplace receives one settlement credit of USD 70,956.60 for the window ending 12 May. Forty shipping bills were filed between 30 April and 10 May. No shipping bill number appears anywhere in the credit advice. The exporter builds the reconciliation from the settlement statement for that window. </> } result= >

Step 1. Total the candidate set. Five of the forty bills are shown; the remaining thirty-five are aggregated on the last line.

Step 2. Run the deduction chain off the statement. Each figure below is a statement total for exactly the 196 orders above, not a modelled percentage.

The set ties: 78,540.00 &minus; 6,676.90 &minus; 785.40 &minus; 119.10 &minus; 2.00 = 70,956.60. Total deductions are USD 7,583.40, which is 9.66 per cent of gross. The number to quote to the bank, because it is derived rather than assumed.

Step 3. Apportion the realised value per bill. Apply the derived realisation ratio of 70,956.60 &divide; 78,540.00 = 0.903446 to each bill's gross value. SB-1234567: 2,400.00 &times; 0.903446 = USD 2,168.27 realised, USD 231.73 fee-attributable. SB-1235004: 3,120.00 &times; 0.903446 = USD 2,818.75 realised, USD 301.25 fee-attributable. SB-1235330: 990.00 &times; 0.903446 = USD 894.41 realised, USD 95.59 fee-attributable.

Step 4. Convert and lodge. The credit of USD 70,956.60 was converted at 87.20, giving INR 61,87,415.52 credited. That single inward remittance is lodged once in EDPMS and marked off against forty shipping bills in the apportioned amounts, with the working paper above attached.

Which document actually evidences the realisation?

A settlement statement is your record. It is not a bank realisation document. What your AD bank needs in order to lodge the inward remittance in EDPMS is a remittance certificate or advice showing the foreign currency amount, the sender, the purpose code and the INR credited. And how that document is generated differs sharply between providers, which changes how much apportionment work lands on you.

Payoneer is explicit on the division of labour: the digital FIRA it supplies is not the regulatory e-FIRA, and where your own bank differs from Payoneer's processing partner, your bank must lodge the IRM to EDPMS, generate the e-FIRA and issue the e-BRC after realisation of the export bill. Read that as an instruction rather than a disclaimer. Nobody upstream is going to apportion the payout across your shipping bills. Detail on each provider sits in the PayPal weekly FIRA guide and the Payoneer e-FIRA eligibility guide .

One more structural point worth knowing before you argue with your bank: where the provider credits you in rupees over a domestic rail, your AD bank has no SWIFT inward message to raise an IRM from automatically. The remittance advice is what evidences the foreign origin of the money. That case is common enough to have its own guide. when the payout arrives in INR rather than foreign currency .

How do you apportion one remittance across many bills?

Once the set ties, the remaining job is arithmetic and record keeping. There are two defensible ways to split a payout across the bills inside it, and you should pick one and use it consistently rather than switching per window.

The pro-rata method applies the derived realisation ratio uniformly, as in the worked example above. It is fast, it always sums exactly to the payout, and it is easy for a bank officer to re-perform. Its weakness is that it spreads a fee that was actually charged on one order across every bill in the set.

The order-level method attributes each fee line to the order it was charged on, sums the net per order, and rolls those up to the shipping bill. It is more accurate and it is what you want when one bill has an unusual fee profile. A large refund, a promotional discount, an oversized shipping charge. It is also considerably more work and needs the per-order fee detail rather than statement totals.

Whichever method you use, record it per shipping bill rather than per payout. The realisation obligation attaches to the bill: nine months from the date of export, for all exporters including SEZ units, Status Holder exporters, EOUs, EHTPs, STPs and BTPs, under para A.2(i) of the Master Direction and Regulation 9 of FEMA Notification 23(R)/2015-RB. The one longer period in the current framework is fifteen months, and it applies to goods exported to a warehouse established outside India, reckoned from the date of shipment. Aggregated settlement does not extend that clock, and a bill sitting half-realised across two payouts is still one bill with one deadline. If you are unsure when the clock actually started, see when the nine-month clock starts .

Note also that a further change is already notified: the Foreign Exchange Management (Export and Import of Goods and Services) Regulations, 2026 come into force on 1 October 2026 in supersession of the 2015 Regulations, and set the period at fifteen months from the date of shipment for goods, with eighteen months where the export is invoiced or settled in Indian Rupees. Until that date the nine-month rule above governs. Confirm the applicable period for any specific bill with your AD bank.

What happens to the residual gap that never closes?

In the worked example, USD 7,583.40 of declared value was never going to arrive. It was consumed by fees before the remittance was even generated. That amount does not vanish from EDPMS because you have explained it. The entry stays open until it is closed through one of the published routes. Choosing the right route early is the difference between routine housekeeping and a file your bank escalates.

For a marketplace seller with many small consignments, the small-value declaration route under para C.31 is usually the proportionate one, and the quarterly consolidated declaration was designed for precisely this shape of business. From 1 October 2026 the same relaxation moves into the Regulations themselves. The mechanics are covered in the small-value EDPMS closure guide , alongside the wider process in EDPMS reporting and e-BRC for e-commerce settlements .

Separately, where proceeds remain unrealised beyond one year from the due date or extended period, further exports may only be made against receipt of full advance or an irrevocable letter of credit. That restriction bites on your ability to trade, not just on your paperwork, which is the strongest practical argument for clearing residues in the quarter they arise.

Many-to-many reconciliation checklist

Run this per payout window. It takes far less time than reconstructing a quarter under a bank query.

• Download the settlement statement for the window, not just the order report. The statement is what the money followed.
• Strip out anything that is not sale proceeds: reserve releases, fee refunds, promotional credits, and any credit whose purpose code is not an export code.
• Map every remaining order number to a shipping bill number, and flag orders whose consignment shipped outside the window.
• Total the gross declared value of the candidate set of shipping bills from the shipping bills themselves, not from the order values.
• Apply the fee lines from the same statement, one line at a time, and show the running balance so the arithmetic is re-performable.
• Test the net against the credit received. If it does not tie, adjust the set (a held order, a boundary bill, a netted refund) before concluding anything about realisation.
• Record the derived realisation ratio for the window and compare it against your recent windows.
• Apportion the realised value to each shipping bill, pro-rata by default and order-level where a bill needs precision.
• Obtain the provider remittance advice or FIRA for the credit and submit it to your AD bank with the working paper and the underlying export documents so the IRM is lodged in EDPMS.
• Track each shipping bill against its own nine-month realisation deadline (fifteen months only where the goods were exported to a warehouse established outside India) and diarise a review at month six, not month eight.
• Route every residue to a closure path in the same quarter: small-value declaration, reduction in invoice value, or write-off, with the supporting evidence assembled.
• Keep the payout reference, order numbers, shipping bill numbers, fee lines, arithmetic and remittance advice together as one file per window.

Frequently asked questions

Why does one marketplace payout cover many shipping bills?

Because a payout is a settlement event and a shipping bill is a customs event. The platform sweeps every order that reached settlement inside the window, nets the fees it is entitled to deduct, converts the balance and remits one figure. Customs, meanwhile, recorded one row per consignment on the day it left. A single payout therefore spans dozens of bills, and a single bill can be split across two payouts when its orders settle either side of a window boundary. Nothing in the credit carries a shipping bill number, so the link has to be built.

Should I match a payout to a shipping bill one to one?

No. The two populations are different sizes and the amounts sit on different bases, so one-to-one matching fails by construction. Subset matching works: total the gross value of a candidate set of bills, apply the deductions evidenced on the settlement statement for exactly those orders, and test the net against the payout. A gap tells you the set is wrong, not that the money is missing.

How long do I have to realise export proceeds from a marketplace payout?

Nine months from the date of export, for all exporters including SEZ units, Status Holder exporters, EOUs, EHTPs, STPs and BTPs, under para A.2(i) of RBI Master Direction No. 16/2015-16 and Regulation 9 of FEMA Notification 23(R)/2015-RB. Fifteen months applies only to goods exported to a warehouse established outside India, reckoned from the date of shipment. The clock runs per shipping bill, so aggregated settlement extends nothing.

The payout is smaller than the shipping bill value. Is that short realisation?

Usually not. The bill declares gross; the payout is what survives commission, processing, conversion and any refunds applied inside the window. The gap is arithmetic until the documented deduction chain has been applied and it still will not close. Your AD bank needs the statement showing those deductions for the same orders, not an assertion that fees exist. Only the residue that survives the evidenced chain is a genuine shortfall.

Does one FIRA document cover one shipping bill?

That depends on the provider. PayPal India generates a free automated weekly Foreign Inward Remittance Advise and clubs all withdrawals in a week into a single document, so one free FIRA routinely spans many bills; a per-transaction Custom FIRA is offered at INR 100 plus 18% GST per transaction for requests up to 20 transactions, and INR 2,000 plus 18% GST for bulk issuance beyond that. Payoneer issues a free digital FIRA per transaction but states it is not the regulatory e-FIRA and that your own AD bank must lodge the IRM in EDPMS and issue the e-FIRA and e-BRC.

What do I do with the residual gap that never realises?

Pick a published route rather than letting it age. For entries of value equivalent to Rs 10 lakh per bill or less, para C.31 of the Master Direction allows reconciliation and closure on the exporter's own declaration, including a reduction in declared value, with quarterly consolidated declarations permitted. Above that, a reduction in invoice value under para C.17 may be approved up to 25% of invoice value, with no ceiling for exporters in the business more than three years who meet the track record test. Write-off under para C.23 is a separate route with cumulative limits of 5% for a self write-off, 10% for a Status Holder self write-off and 10% for an AD bank write-off, against total export proceeds realised in the preceding calendar year.

Sources

Seasaw for Exporters

Stop subset-matching payouts by hand

Seasaw reads your settlement statements, builds the subset match against your shipping bills, apportions each remittance down to bill level and tracks every open bill against its own realisation deadline. With the arithmetic laid out for your AD bank.

Learn more about Seasaw

Update history

• 2026-08-25 First published.