Most EDFs that come back from the bank fail for boring, preventable reasons: the AD code belongs to a different branch, the Part 2B rows do not add up to the total in field 1.22, an invoice from the month is missing, or nobody signed Part 4. A five-minute self-check against your invoice register before you submit catches nearly all of them. This article walks through each mistake, why the bank cares, and how to fix it.
Key takeaways
- The bank has to enter your EDF into EDPMS within 5 working days, so it returns anything it cannot key in cleanly.
- AD code, totals, invoice coverage and signature are the four big rejection triggers.
- Every invoice dated in the month belongs on that month's EDF as its own row in Part 2B.
- Build a pre-submission checklist once and reuse it every month.
Why banks are strict about small errors
Under Regulation 18 of the 2026 export regulations, your AD bank must enter the EDF into EDPMS within five working days. EDPMS is the system that tracks each export until the money arrives. If the AD code is wrong, the entry lands against the wrong branch. If totals do not reconcile, later matching against your inward remittances breaks.
So a returned form is usually not fussiness. It is the bank avoiding an entry that will cause problems for months.
The mistakes, ranked by how often they cause trouble
| Mistake | Where on the form | What it causes | Quick fix |
|---|---|---|---|
| Wrong or missing AD code | Field 1.6 | Entry against wrong branch, or not accepted | Get the code in writing from your branch |
| Total does not match rows | Field 1.22 vs Part 2B | Bank cannot reconcile | Recalculate with one consistent rate |
| Invoice missing from the month | Part 2B | Gaps in EDPMS, later realisation mismatch | Tick off against invoice register |
| Unsigned or wrongly signed | Part 4 | Form not valid | Authorised signatory signs and dates |
| Both declaration options left in | Part 4 | Ambiguous declaration | Strike out the unused option |
| Goods fields filled for services | Part 2A, 1.3, 1.14, 1.18, 1.20 | Confusion about export type | Mark N/A, leave Part 2A blank |
| Amount in words differs from figures | Field 1.22 | Form returned | Regenerate words from the final figure |
1. The AD code is wrong
The AD code identifies the bank branch handling your export transactions. It is not your IFSC and not your SWIFT code, though people often paste one of those by mistake. If your company banks with two branches, the code must be for the branch that receives the export proceeds and handles your EDF.
Fix: ask your branch or relationship manager for the AD code and keep their reply on file. If you need a formal request, our AD code request letter takes two minutes.
2. Field 1.22 does not equal the sum of the rows
Field 1.22 is the total value in INR, in figures and words. Part 2B lists each invoice in its own currency. The mismatch usually comes from converting each row at a different rate, or from rounding each row and then rounding the total again.
Example: Kestrel Analytics Pvt Ltd lists three October 2026 invoices: USD 4,200, USD 3,750 and USD 1,050. At an assumed rate of ₹84.20, the total is USD 9,000 × 84.20 = ₹7,57,800. If someone converts each row separately and rounds each to the nearest hundred, the total drifts. Pick one documented rate approach, apply it the same way to every row, and let the total come from the rows.
3. An invoice is missing
One EDF per month can cover all your service exports of that month, to one or more clients, with each invoice as its own row. The trap is the invoice raised on the last day of the month, or one raised by a colleague and never shared with accounts.
Fix: pull your invoice register for the month, filtered by export invoices, and tick each one off against Part 2B. If you keep an EDF register, this becomes a single comparison.
4. Nobody signed, or the wrong person signed
An unsigned Part 4 is not a declaration. Equally, a form signed by a staff member who is not on the bank's list of authorised signatories may be returned. If your signatories changed recently, update the bank first; otherwise the signature will not match its records.
5. Declaration alternatives left standing
Part 4 asks you to strike out options that do not apply: I/We, buyer/third party, will be received/has been received, foreign exchange/Indian Rupees, goods/services. Leaving both words visible makes the declaration ambiguous. Our walkthrough of the Part 4 declaration shows which words service exporters usually keep.
6. Goods fields filled in for a services export
Shipping bill number, port of loading, port of discharge and LEO date are goods concepts. For services, mark them not applicable and leave Part 2A blank. Field 1.4 (mode of delivery) is usually "Internet" for work delivered online.
Errors that slip past the bank but hurt you later
Wrong currency or amount in a row. If an invoice says EUR but Part 2B says USD, the bank may not notice. When the payment arrives in EUR, matching in EDPMS fails, and the entry stays open.
Net realisable value left equal to gross when you know charges will be deducted. Fill NRV thoughtfully. Bank charges deducted abroad reduce what reaches you, and your records should explain the gap.
Unrealistic realisation date. Declaring payment by a date beyond nine months from the invoice date (12 months for rupee invoices) is an error on its face. Use a date that fits the earliest invoice in the month.
Wrong client country. The country column in Part 2B should be where the service recipient is located, not where its bank is.
A pre-submission checklist you can reuse
- Invoice register for the month printed or exported; every export invoice ticked against Part 2B.
- AD code matches the code your branch gave you in writing.
- Every row has invoice number, date, currency, amount, NRV, description, SAC code.
- One exchange rate method applied to all rows; total in 1.22 recalculated from rows.
- Amount in words generated from the final figure.
- Goods-only fields marked N/A; Part 2A blank.
- Part 4 alternatives struck out; realisation date within the permitted window.
- Authorised signatory has signed and dated.
- Copy saved with the submission date and any acknowledgement from the bank.
You can do steps 3 to 7 automatically by preparing the form with our free EDF generator, which totals the rows and writes the amount in words for you. For the wider process, our EDF guide is the place to start. This is general information, not legal or tax advice; your bank's published EDF policy governs what it will accept.
Frequently asked questions
What is the most common reason a bank rejects an EDF?
In practice the usual culprits are a wrong AD code and a total in field 1.22 that does not equal the sum of the Part 2B rows. Both make it impossible for the bank to key the form into EDPMS correctly, so they are returned rather than corrected by the bank.
Can the bank correct small errors on my EDF itself?
Do not count on it. The EDF is your declaration, so most banks will ask you to correct and re-sign rather than alter the form themselves. Fixing errors before submission saves a round trip.
Do I need a separate EDF for each client?
No. One EDF per month can cover all service exports of that month to one or more recipients, with each invoice as its own row in Part 2B. Splitting by client is allowed only if your bank asks for it, so confirm with your branch.
What should I do if I find a mistake after the bank has accepted the EDF?
Write to your AD bank promptly, explain the error, and submit a corrected form if it asks for one. Mention any acknowledgement or reference number you received so the bank can locate the original entry in EDPMS.
Is using an IFSC instead of the AD code a serious problem?
Yes, because the IFSC identifies a branch for domestic payments, while the AD code is used for export reporting. The bank cannot use an IFSC in place of the AD code, so the form will usually be returned.
Bottom line
Rejections are almost always caused by a handful of predictable slips, and a short checklist eliminates them. Prepare your next form with the EDF form generator, compare it against your invoice register, and submit once.
This guide is general information for Indian businesses, not legal or tax advice. Rules and bank processes change — confirm specifics with your AD bank or chartered accountant.