The SOFTEX Repeal Isn't a Simplification If You Never Filed SOFTEX

Search for what is changing under India's new export rules and you will find the same sentence in a dozen places: the SOFTEX form is going, filing gets simpler. That is true. It is also written entirely for people who were already filing SOFTEX forms. If you export services that are not software — design, consulting, marketing, copywriting, video, research, ops, support — you have never had a structured export declaration obligation. From 1 October 2026 you will, it recurs every month, and almost nobody has written the version of this article that is addressed to you.

This is that version.

What changes on 1 October 2026?

The Reserve Bank of India notified the Foreign Exchange Management (Export and Import of Goods and Services) Regulations, 2026 through Notification No. FEMA 23(R)/2026-RB dated 13 January 2026, operationalised by A.P. (DIR Series) Circular No. 20 dated 16 January 2026. The Regulations supersede the FEMA (Export of Goods & Services) Regulations, 2015. The accompanying Directions, issued through A.P. (DIR Series) Circular No. 20 dated 16 January 2026, supersede the Master Direction on Export of Goods and Services, the Master Direction on Import of Goods and Services, and the 167 circulars listed in their annexure. The notification was published in the Official Gazette on 15 January 2026. Until 30 September 2026 the existing rules still apply, so this is a window to prepare rather than a change that has already landed. That consolidation is the genuinely good news in this reform: one rulebook instead of a decade of accumulated circulars.

Four changes matter for anyone earning from clients abroad. The SOFTEX form — the declaration software exporters file to report software exports — will be retired on 1 October 2026. A single unified Export Declaration Form, the EDF, will cover goods, services and software together. Software is reclassified as a sub-category of "services" (Explanation to Regulation 2(1)), defined as any computer programme, database, drawing, design, audio/video signals, or any information by whatever name called on a non-physical medium (Regulation 2(1)(e)) — the same definition used in the 2015 Regulations. And AD banks — Authorised Dealer banks, meaning the bank licensed to handle your foreign exchange transactions, in practice the bank your client's money lands in — are recognised as a "Specified Authority" on par with STPI (Regulation 2(1)(f)), the Software Technology Parks of India body that currently certifies software exports.

Is STPI certification still required for software exporters after 1 October 2026?

Not mandatorily, and that last change is a real win for software exporters. STPI certification stops being mandatory for software, IT or ITeS exporters in the Domestic Tariff Area — the DTA, meaning anywhere in India outside a Special Economic Zone. From 1 October 2026 an AD bank can certify instead. One caveat worth carrying: the regulations deliberately leave process detail to the banks, and it is not yet fully settled whether an individual AD bank may still insist on STPI or SEZ certification in practice. Ask your bank rather than assuming the option is live.

Why is this a simplification for software exporters but a new burden for everyone else?

The framing problem in every other article about this reform is that it measures the change against SOFTEX. Measured that way, the reform is unambiguously a simplification. But that measurement only works if you were filing SOFTEX in the first place.

Consider who files today. A software company exporting a product to a US client files SOFTEX, frequently per transaction, routed through STPI, with the friction that implies. For that company, the 2026 framework will be a straightforward improvement: one monthly EDF instead of transaction-level SOFTEX filings, and a bank that can certify instead of a separate authority. Less work, fewer parties, one form.

Now consider a marketing consultant in Pune advising a client in Amsterdam on campaign strategy. Under the framework in force until 30 September 2026, there is no SOFTEX obligation, because strategic advice is not software under any reading of Regulation 2(1)(e) — there is no file, no drawing, no design, no audio/video signal changing hands. Foreign exchange arrives, the bank applies a purpose code, and the export declaration layer that governs software exporters does not extend to this work. The obligations that do apply — realisation of proceeds, tax, GST — are real, but a structured, recurring export declaration is not among them.

The unified EDF does not simplify a form for non-software service exporters. It extends a declaration regime to a cohort that was never inside one. Same reform, opposite direction, depending entirely on which side of the software line you sit on before October.

This is why the prevailing framing misleads by omission rather than by error. "SOFTEX is going" is accurate. "Filing gets simpler" is accurate for the people already filing. Neither sentence tells a consultant, a marketing agency or an operations contractor that they are about to acquire a monthly obligation. The reform reduces the number of forms in the system while increasing the number of people who have to file one — and the coverage has almost entirely reported the first half.

Who will have to file an EDF that doesn't today?

If you invoice clients outside India for a service and are paid in foreign exchange, this is you — but the answer to whether you already had an obligation splits the list in two.

Tier 1 — the obligation was always arguable; from October it is unambiguous

The regulatory definition of "software" is broader than the word suggests, and it has not changed. Both the 2015 and 2026 Regulations define it as any computer programme, database, drawing, design, audio/video signals, or any information by whatever name called on a non-physical medium (Regulation 2(1)(e)). If you deliver files, that language has arguably covered you for a decade. In practice almost nobody in this group filed SOFTEX and almost no bank asked. From 1 October 2026 the ambiguity disappears.

• Independent designers and design studios — brand, product, UI, illustration
• Video editors, motion designers, animators and post-production contractors
• Technical writers, copywriters, editors, translators and researchers delivering written deliverables

Tier 2 — genuinely outside the regime until now

Regulation 3(3) of the 2015 Regulations stated in terms that where no prescribed Form applied, services could be exported without furnishing any declaration. For this group the obligation is new, not merely newly enforced.

• Consultants and advisors of every stripe: strategy, management, engineering, finance, HR
• Marketing, performance and creative agencies running campaigns for foreign brands, where the deliverable is the campaign rather than a file
• Customer support, operations, bookkeeping and virtual assistance contractors
• Architects, legal and accounting professionals advising clients abroad

The test is not your job title or whether you are registered as a company. It is whether a service left India, a client outside India paid for it, and money came in through banking channels. If those three things are true, the EDF regime will reach you from 1 October 2026.

When is the EDF due, and what happens if you miss it?

The baseline rule for services and software is a consolidated monthly filing: one EDF submitted within 30 days from the end of the month in which the invoice was raised (Regulation 3(2)), and a single consolidated EDF may cover multiple recipients in that month (Regulation 3(2)(a)) — so ten clients in October means one filing, not ten. For services other than software there is also an option to submit the EDF on or before the date you receive payment (Regulation 3(2)(b)), and your AD bank may extend the deadline on request if it is satisfied the reason is reasonable (Regulation 3(2)(c)) — worth confirming with your bank which route it expects, because this is exactly the kind of process detail the regulations leave to individual AD banks.

Where the EDF goes depends on what you export. Goods are declared to the specified authority at the time of export, with EDI filings deemed submitted automatically (Regulation 3(1)). For services and software, the specified authority is defined by export type and location (Regulation 2(1)(f)). For most readers of this post the answer is simply: your bank.

Filings feed EDPMS — the Export Data Processing and Monitoring System, RBI's database that tracks every export declaration against the payment that is supposed to settle it. Your bank has five working days from receiving your EDF to enter it in EDPMS (Regulation 18(1)(b)). Its import counterpart is IDPMS, and FETERS is the separate return through which banks report foreign exchange transactions to RBI (Regulation 18(2)). You do not interact with these systems directly; your bank does. What you experience is the consequence when they do not reconcile.

That consequence is worth stating plainly, without dramatising it. A declaration that is never matched to an inward remittance stays open in EDPMS. Open entries accumulate against your name at your bank, and they are what surface when you later need something routine — a clean record for a loan application, a new banking relationship, an export incentive claim. Separately, the realisation clock runs: export proceeds must be realised and repatriated within fifteen months of the invoice date, extended to eighteen months where the export is invoiced or settled in Indian Rupees, or both (Regulation 5(1)(a) and first proviso). Where proceeds remain unrealised beyond a year past the due date, the exporter must undertake further exports only against receipt of full advance or an irrevocable letter of credit (Regulation 13) — a working-capital problem rather than a penalty, but a serious one if your business depends on invoicing in arrears. Contraventions under FEMA are civil. Section 13 provides for a penalty of up to three times the sum involved where the amount is quantifiable, and a further penalty for each day a contravention continues. The practical cost is rarely the penalty. It is friction that compounds quietly and surfaces at the worst possible moment.

What reliefs does the EDF regime actually offer?

The coverage that oversells the burden is as common as the coverage that undersells it. Four reliefs in the Regulations meaningfully soften the compliance load for a small exporter, and they are missing from most explainers.

• Self-closure up to ₹10 lakh. Under the proviso to Regulation 4(2), where the invoice is up to ₹10 lakh or its foreign-currency equivalent, the EDPMS entry may be closed on the strength of a declaration from the exporter that payment has been realised. That declaration can be submitted quarterly for bulk closure. For most independent exporters this covers the entire invoice book, and it substantially defuses the open-entry problem described above.
• Under-realisation up to ₹10 lakh. Regulation 6 allows the same ₹10 lakh threshold for reduction in export value, including non-realisation, on an exporter's declaration — useful where a client short-pays or a payment gateway deducts at source.
• The deadline is extendable. Regulation 3(2)(c) permits your AD bank to extend the EDF submission window on a request citing reasons, where the bank is satisfied the request is reasonable.
• Your bank must publish its process, and cannot penalise you for it. Regulation 19 requires every AD bank to maintain a documented internal policy and SOP covering documents, timelines, charges, extensions and escalation, and to disclose it on its website (Regulation 19(4)). It also provides that a bank shall not levy any charge or penalty on a customer for regulatory delay, and that charges must be reasonable and proportional to the service rendered.

What should you do before 1 October 2026?

• From 1 October your bank is required to publish its policy and SOP on its own website (Regulation 19(4)) — check there first, then ask in writing for anything it doesn't cover: format, submission channel, whether it wants the monthly consolidated filing or payment-date filing, and who at the bank owns it. The regulations delegate this detail to banks, so the answer is bank-specific and you want it before your first filing is due, not after.
• Get invoice-to-remittance records into one place. Every invoice needs to be matchable to the specific payment that settles it. If this currently lives across email, a spreadsheet and your banking portal, consolidate it now — reconciliation is the actual work behind an EDF, and the filing itself is trivial once records line up.
• Confirm the purpose codes your bank applies to your inward remittances. A wrong code is the most common reason a payment fails to reconcile against a declaration, and it is far cheaper to correct standing instructions than to unwind mismatched entries later.
• Calculate the realisation due date for every open invoice — 15 months from invoice date, or 18 if you invoice or settle in Rupees — and know which ones fall due first.
• If you export software or ITeS and currently route through STPI, ask your bank whether it will certify directly from 1 October 2026, and get that confirmation before assuming you can drop STPI.

None of this requires a compliance department. It requires knowing the obligation is coming, which is the part the current coverage is failing to deliver to the people it will apply to.

A per-transaction, do-it-when-you-remember approach to compliance survives contact with an annual obligation. It does not survive a monthly one. Twelve filings a year, each requiring every invoice matched to the remittance that settled it and every purpose code correct, is not a memory problem — it is a records problem, and records problems get worse the longer they run. That reconciliation trail, from declaration through to realisation, is what Lumeo automates.

This is general information, not legal or tax advice. The 2026 Regulations leave significant process detail to individual AD banks, and positions are fact-specific — confirm yours with your bank and a qualified professional before acting.