Use the invoice-month rule and identify the exception
For service exports governed by the FEMA export-import regulations effective 1 October 2026, regulation 3(2) requires an EDF declaring full export value within thirty days after the invoice month ends. It permits one EDF for a month’s exports to one or more recipients. Services other than software have a separate option to submit on or before payment receipt. An authorised dealer may extend filing time on a reasoned request after satisfying itself about the request.
This guide was checked on 22 October 2026 against the 2026 regulations consolidated through the amendment of 22 September 2026 and A.P. (DIR Series) Circular 20 dated 16 January 2026. It addresses the new framework’s service-invoice filing calendar, rather than reproducing an older SOFTEX checklist. The circular’s supersession and the regulations’ savings require separate treatment of earlier acts or omissions; do not erase historical compliance obligations.
Classify the service and identify the receiving authority
Regulation 2 gives software a broad definition, extending beyond a narrowly described packaged program. Examine the actual deliverable and medium before classifying a design, database or other electronically supplied output as a non-software service. The specified authority also differs: in DTA, non-software services go to an authorised dealer, while software can go to an authorised dealer or STPI; in SEZ, the Development Commissioner is specified. Obtain the receiving authority’s current submission requirements without inventing a universal portal workflow.
The Annex supplies the prescribed EDF. Use the current official form obtained from the authority or bank and preserve its acknowledgment. This article makes no claim about an application’s ability to file it or any particular portal’s operational status. A file prepared internally is not evidence that the declaration reached the specified authority, and a bank credit alone is not the same document as an EDF acknowledgment.
Build the calendar from invoices, not collection reminders
Maintain invoice number, date, export classification, recipient, full declared export value, submission authority, filing basis, due date and acknowledgment. Attach the underlying contract and invoice. Where a monthly EDF is used, retain its invoice-level reconciliation so that several recipients and later receipts can be traced without treating the declaration as one merged commercial invoice. Do not move invoices between months just to make a bank reconciliation easier.
Calculate thirty days after the last day of the invoice month. Thirty days is not interchangeable with “the last day of the following month”. Keep calendar-day calculations visible and do not presume a weekend, bank holiday or internal office closure automatically grants an extension. Future dates in the examples are illustrative calculations from the rule checked above, not announcements of a later regulatory change.
Record the non-software filing choice expressly
For a genuine non-software export, the receipt-based proviso may produce a different filing date from the ordinary month-based calendar. Retain the classification, receipt date and chosen legal basis in the working. For software, do not borrow that option merely because the customer will pay later. If classifications are mixed, segregate the eligible non-software items rather than using one late receipt to defer the software invoices.
Keep declaration timing separate from proceeds realisation. A submission option does not change the contractual receivable or itself extend a separate FEMA realisation period. Conversely, a receipt or a small-value EDPMS closure process is not automatically an exemption from the EDF requirement. This article deliberately does not recompute those separate realisation and closure rules. Use distinct evidence and conclusions for each obligation.
Escalate an actual filing delay to the authorised dealer
Regulation 3(2)(c) allows the authorised dealer to extend time after assessing the stated reasons. Preserve the request, reason, invoice list and written decision; sending an email request alone is not proof of an extension. If submission is already late, document the original due date and actual date rather than silently overwriting the calendar with a revised internal target. This provision does not prescribe the invented flat per-day late fee sometimes inserted into generic compliance spreadsheets.
Worked illustrations
These illustrations use fictional facts and expressly stated assumptions. Amounts are Indian rupees unless a different currency or unit is specified. They are independent examples, not findings about any actual client.
Illustrative example 1: October invoices share one ordinary deadline
A software exporter raises invoices on 10 October and 31 October 2026. For each, the invoice month ends 31 October; thirty days later is 30 November 2026. The earlier invoice does not get a thirty-day-from-invoice deadline, and the later invoice does not move into the November invoice batch. Assume no authorised extension.
Illustrative example 2: November is not a 31 December deadline
For a software invoice dated 1 November 2026, month-end is 30 November. Adding thirty calendar days gives 30 December 2026, not 31 December. The same ordinary result applies to an invoice dated 30 November. An internal “next month-end” formula would be one day late in this example.
Illustrative example 3: a February calculation crosses into March
Assume a software invoice on 15 February 2027 and no later change in the applicable rule. February ends on 28 February 2027. Thirty days later is 30 March 2027. An automatic 31 March target would be one day later than the calculated ordinary deadline.
Illustrative example 4: one monthly EDF retains three invoice allocations
Assume three qualifying October 2026 service-export invoices of USD 12,000, USD 8,000 and USD 5,000 to three recipients, consistently denominated and requiring no adjustment. Their full export values total USD 25,000. The monthly option permits one EDF instead of three, reducing the declaration count by two; the ordinary filing deadline remains 30 November. Retain all three invoice and recipient allocations.
Illustrative example 5: non-software receipt-based option
Assume an export is correctly classified as non-software, invoiced on 12 October 2026, with actual payment received on 15 December 2026. The ordinary invoice-month date is 30 November; regulation 3(2)(b) separately permits EDF submission on or before the receipt date, 15 December. Record the reliance on that proviso and receipt evidence. Do not apply this option to software or infer an extension of separate proceeds-realisation obligations.
Illustrative example 6: two-day delay requires an explicit extension assessment
Assume an October software EDF has an ordinary deadline of 30 November 2026 and is submitted on 2 December. The elapsed delay is two calendar days. Prepare the reasoned request and obtain the authorised dealer’s decision under regulation 3(2)(c). No automatic extension or fixed two-day penalty amount is inferred from this calculation.
Ten-step verification table
| Step | Verification | Evidence to retain |
|---|---|---|
| 1 | Identify whether the invoice falls under the effective framework. | Invoice date, transaction history and transition assessment. |
| 2 | Confirm the FEMA service-export facts. | Contract, parties and delivery evidence. |
| 3 | Classify software or other services accurately. | Deliverable and medium analysis under regulation 2. |
| 4 | Identify DTA/SEZ and specified authority. | Unit status and authority confirmation. |
| 5 | Capture every invoice’s full export value. | Invoice register and supporting contract. |
| 6 | Choose individual or permitted monthly declaration. | Invoice-to-EDF reconciliation. |
| 7 | Compute the ordinary month-end-plus-thirty date. | Reproducible calendar working. |
| 8 | Record any non-software receipt-based reliance. | Classification, receipt evidence and filing basis. |
| 9 | Resolve late cases through a reasoned AD request. | Request and written extension decision. |
| 10 | Retain acknowledgment and reconcile separately to receipts. | Accepted EDF, bank trail and receivables register. |
Sixteen practitioner FAQs
1. When did the new regulations become effective?
1 October 2026; use the amended official text and assess transitional matters separately.
2. Is the ordinary clock thirty days from the invoice date?
No. It runs from the end of the month in which the service invoice is raised.
3. Is the ordinary deadline always next month-end?
No. Adding thirty days can produce a date before that month-end.
4. Can one EDF include several recipients for the month?
Yes. Regulation 3(2)(a) expressly permits the monthly option for one or more recipients.
5. Does that merge the underlying invoices?
No. Keep each invoice, value and recipient traceable.
6. Can software use the non-software receipt option?
No. Do not extend the stated proviso to software.
7. Is software limited to a packaged application?
No. Read regulation 2’s broader definition against the actual deliverable.
8. Who is specified for non-software services in DTA?
An authorised dealer under regulation 2(1)(f).
9. Who is specified for software in DTA?
An authorised dealer or STPI under that definition.
10. Who is specified in SEZ?
The Development Commissioner of the SEZ for the service categories addressed here.
11. Does a draft EDF prove submission?
No. Retain evidence of receipt or acknowledgment from the specified authority.
12. Is the prescribed form replaced by a spreadsheet?
No. A spreadsheet can support reconciliation; obtain and use the current prescribed EDF and receiving process.
13. Can a holiday be assumed to extend the date?
Do not assume an automatic extension; verify the applicable rule or obtain the required decision.
14. Who may extend submission time under regulation 3(2)(c)?
The authorised dealer, on a reasoned exporter request it considers reasonable.
15. Does a request email itself prove the extension?
No. Keep the dealer’s decision as evidence.
16. Does EDF filing settle GST export status and all realisation obligations?
No. Those are separate legal and reconciliation questions; filing the declaration does not decide them.
Working-paper organisation
Keep the source documents, calculation and final conclusion together for the same entity and period. If using assurePractice or other assureOffice tools, use only confirmed available functions and retain this evidence with the output.
Conclusion
Build the EDF calendar from the invoice month, preserve monthly invoice allocations and document the correct authority and filing basis. Treat a non-software receipt option or an authorised extension as an evidenced legal conclusion, separately from collections and other export obligations.