Why One Payout Never Matches One Shipping Bill

Why does the bank see a different number than my invoice?

EDPMS is built on a simple assumption: a shipping bill has a value, a remittance arrives, and the two are compared. Every exporter who has tried to close a month knows the assumption does not survive contact with how money actually moves.

Between the invoice you raised and the credit in your account, four things happen, and each one changes the number:

• Aggregation. A marketplace or gateway pays on its own cycle. One credit can carry fifty orders across three weeks and two shipping bills, or half of one.
• Deduction. Platform commission, payment processing, FX margin and sometimes shipping are netted off before the transfer leaves. What lands is proceeds after costs, not invoice value.
• Conversion. The invoice is in USD or EUR, the credit is in INR at the rate your AD bank applied on its value date, which is not the rate on the shipping bill date.
• Timing. The goods left in one month, the platform settled in the next, and the bank credited on a third. Nothing about the three dates agrees.

What has to be proved: gross or net?

This is the question everything turns on. The shipping bill declares FOB value. The bank credits net proceeds. Reporting is against the shipping bill, so the difference has to be explained rather than ignored.

If your workings only ever touch the bank statement, the deductions are invisible and every bill looks short. If they only touch the platform report, you have no proof of realisation. Both halves are needed, and they come from different places in different formats.

Why is this a many-to-many problem?

A courier export month is rarely one bill to one credit. In practice you get all four of these in the same period:

• One credit covering many shipping bills, which is the common case for marketplace payouts.
• One shipping bill covered by many credits, when a buyer pays in instalments or a platform splits a settlement.
• Credits that cover no shipping bill at all: refunds reversed, service income, or a payment for a domestic sale that landed in the same account.
• Shipping bills that will never see a credit, because the order was returned after export.

Any tool that offers to match your file line by line has already failed on the first two. The unit of work is a set of bills against a set of credits, not a row against a row.

How do you match a set without guessing?

The order in which you attempt matches decides how much is left over. Working remittance first, and taking the most constrained evidence before the least, resolves the bulk of a month before judgement is needed anywhere.

1. Anchor on the credit, not the bill Start from a remittance whose amount and value date are certain, and ask which shipments it could be paying for. The reverse direction invites you to invent a payment that does not exist.
2. Filter by window before amount Only shipments that shipped before the credit, and within the realisation period, are candidates. This usually cuts the search space by an order of magnitude and costs nothing.
3. Reconstruct the gross, then compare Add the platform deductions back to the net credit before comparing against FOB. Comparing net to FOB is what manufactures a phantom shortfall.
4. Solve the subset, then fix the tolerance Find the set of bills whose value the reconstructed credit covers. Set one explicit rounding tolerance for FX and bank charges, write it down, and apply it identically every month.
5. Leave the residue alone Whatever does not resolve is the real work: short realisation, an unmatched credit, or a bill that will need a write-off. It should be a short list, and it should be looked at by a person.

What do you do with what is left?

The leftovers fall into three buckets, and they need different actions:

• Short realised. The credit is genuinely less than the bill after fees are accounted for. Either another remittance is still to come, or the balance needs a documented write-off through your AD bank.
• Unmatched credit. Money arrived that no shipment explains. Check whether it is a service receipt, a refund reversal or a domestic payment, because reporting it as export realisation is worse than leaving it unallocated.
• Unrealised bill. The goods left and nothing came back. This is the entry that eventually reaches the RBI caution list if nobody acts on it.

The repatriation clock is the pressure behind all three. Export proceeds have to be realised and repatriated within the period set under FEMA, and the nine month deadline is measured from the date of export, not from when you noticed.

Which part of this should a machine do?

The mechanical parts are the ones a machine does better and never gets tired of: pulling shipping bills, normalising settlement reports into one shape, reconstructing gross from net, and searching for the subset that fits within a stated tolerance.

The judgement parts should stay human, and they are smaller than people expect: deciding that a bill is genuinely short, choosing to write off, and deciding what an unexplained credit actually was. A system that quietly resolves those is not saving you work, it is filing your assumptions with your bank.

If you want the full closure chain around this, the AWB to eBRC playbook covers what happens either side of the matching step, and EDPMS errors covers what the system says when a match is rejected.

Sources & citations

• RBI Master Direction on Export of Goods and Services. Sets the realisation and repatriation framework that EDPMS enforces, including the period within which proceeds must be brought in.
• EDPMS, Reserve Bank of India. The system AD banks report shipping bills and their realisation into, and the source of caution list action when entries stay open.

Update history

• 2026-08-19 First published.