SOFTEX to EDF on 1 October: The Real Change for SaaS Exporters Is Monthly Reconciliation

On 1 October 2026 the FEMA export and import regulations issued by the RBI take effect, and the SOFTEX to EDF switch is the part that lands on every Indian SaaS company selling to foreign customers. The SOFTEX form, filed for software exports for over two decades, is replaced by a single Export Declaration Form that covers goods, services and software. Most coverage focuses on the form. The more useful reading is that the unit of compliance moves from the invoice to the month.

This piece is for the finance lead or founder at an Indian SaaS company invoicing in dollars, euros or pounds, who has been treating export paperwork as something the bank and a chartered accountant handle. The rules below are drawn from law-firm and advisory summaries, so treat them as a map and confirm specifics with your Authorised Dealer (AD) bank.

What the SOFTEX to EDF switch changes

Under the old routine, software exporters filed SOFTEX per invoice or per batch and had it certified, typically by STPI. Under the new regime, summaries from Majmudar & Partners and others describe software as a form of service, reported through one Export Declaration Form. The EDF is furnished within 30 days from the end of the month in which the invoices were raised, and the AD bank then has five working days to upload it into EDPMS, the RBI's export data processing and monitoring system.

The bank step matters more than it looks. EDPMS entries determine when a foreign inward remittance certificate (FIRC) or an electronic Bank Realisation Certificate (eBRC) can be issued. An entry that does not match a real receipt stays open, and an open entry is where trouble starts.

Why the 15-month window is less generous than it sounds

The realisation period, the time you have to bring the money home, moves from nine months to 15 for services, and to 18 where the invoice is in rupees. Payment terms for enterprise SaaS rarely run past 90 days, so few companies will need the full runway. The window is a safety margin for the disputed invoice, the customer whose finance team reorganised, or the annual contract billed in arrears.

There is a wrinkle worth knowing. According to Xflow's summary, the RBI first lengthened the period from nine to 15 months in November 2025, then a technical amendment on 5 June 2026 reset it to nine months for the June to September window so two regimes would not overlap. If you have invoices from that window still unpaid, do not assume the longer clock applies to them. Ask your bank which date governs.

The monthly EDF is a reconciliation problem

Per-invoice filing let a small team stay loose about matching money to invoices, because each SOFTEX was a discrete task. A monthly EDF bundles many invoices into one declaration that must tie to actual realisations. If a customer pays two invoices in one wire, or a payment gateway deducts fees and converts to rupees before the money reaches your account, the receipt no longer maps one-to-one to an invoice.

That mapping is the work. Hiwi Pay's explainer makes the same point: a late or mismatched inward remittance complicates filings and delays cash flow. The fix is boring and mechanical, which is why it is worth doing before the first filing is due rather than during it.

-- Invoices raised last month that have no matched inward remittance yet
SELECT i.invoice_no, i.customer, i.currency, i.amount_foreign, i.invoice_date,
       (CURRENT_DATE - i.invoice_date) AS days_outstanding
FROM export_invoices i
LEFT JOIN remittance_allocations a ON a.invoice_id = i.id
WHERE i.invoice_date >= date_trunc('month', CURRENT_DATE - interval '1 month')
  AND i.invoice_date <  date_trunc('month', CURRENT_DATE)
GROUP BY i.id
HAVING COALESCE(SUM(a.amount_foreign), 0) < i.amount_foreign
ORDER BY days_outstanding DESC;

The point of the table behind that query is the allocation step. Every rupee credited by the bank gets allocated to one or more invoices, with the bank reference (FIRC or eBRC number) stored beside it. One remittance can settle several invoices, and one invoice can be settled by several remittances. If your ledger cannot express both, the EDF will be painful.

The GST refund is tied to the same paper

SaaS delivered to a foreign customer is generally treated as an export of services and zero-rated for GST. Companies either export under a Letter of Undertaking without paying IGST, or pay IGST and claim a refund. Advisory write-ups from Xflow and InCorpX note that refund claims depend on proof of foreign exchange realisation, and that a refund officer can reject a claim where the payment arrived in rupees without an eBRC.

So the chain runs from invoice to EDF to EDPMS to eBRC to GST refund. A mismatch at the second link surfaces as a rejected claim at the fifth, months later. That delay is the real cost of sloppy reconciliation, more than any penalty.

A short checklist before your first EDF

• Ask your AD bank how it will certify software exports and what it needs from you each month.
• List every invoice from June onward that is unpaid, and confirm which realisation window applies to each.
• Add an allocation table that maps each inward remittance to invoices, with the bank reference alongside.
• Set a calendar reminder for the 30-day filing cut-off, and a second one internally at day 20.
• Check that every rupee-converted receipt from a payment gateway has an eBRC or FIRC on file.
• Decide who owns the process. Finance, not engineering, should hold the deadline; engineering supplies the export.

What to watch after 1 October

The first cycle will show how banks interpret the rules in practice. Turnaround on EDPMS uploads, whether banks ask for supporting contracts, and how they treat pre-October invoices are all things the regulations leave to operating detail. Companies that have their receipts allocated by the end of October will find the first filing routine. Those that do not will find out at the worst possible moment: when a refund is due.