The 7 FEMA compliance screens no Indian payment rail cross-rails

If you search for EDPMS India, e-BRC freelancer, or EDF filing 2026, Skydo's blog is in the top three. Their posts explain the acronyms, the realization windows, the penalty structure, the ICEGATE handoff. It is, honestly, excellent content — a better education than most CAs will give you.

Here's what nobody says out loud: the product that hosts those blog posts is a single-rail payment pipe. The FEMA ops layer across every rail you actually use? Still assembled by hand.

Skydo is a payment rail. It moves USD from your foreign client into your Indian bank account, and it auto-generates a FIRA for every payment that flows through its own pipe. That's the whole product. If your money arrived through Payoneer, or Wise, or a direct SWIFT wire, or Stripe Atlas payouts — Skydo never sees it, and their compliance suite can't help you.

If your real question is which stack to use for a SaaS product selling globally, we mapped the tradeoffs separately in the Indian SaaS international payments guide: Indian Stripe, Stripe Atlas, Merchant of Record platforms, Indian gateways, and bank-transfer rails all create different proof trails.

Dodo Payments and other Merchant of Record platforms create another version of the same proof problem. They can simplify checkout, but an Indian SaaS founder still needs to know what the bank statement, payout document, and FIRA/FIRC trail look like. That narrower question is covered in the Dodo/MoR payout-proof guide.

If Stripe is one of your rails, the bank-proof trail has its own moving parts: SCB payment advice, FIRC request, purpose code, and downstream e-BRC / EDPMS matching. We wrote a separate Stripe FIRC guide for Indian exporters because that workflow is not the same as a normal payment receipt.

Starting October 1, 2026, the RBI's new FEMA rules (Notification 23(R)/2026-RB) retire the SOFTEX regime. Every service export has to be declared on an Export Declaration Form and closed on EDPMS — public summaries of the notified framework suggest services and software exports can be rolled up into a consolidated monthly EDF rather than one per invoice, but the closure discipline is still per invoice on EDPMS. The penalty for getting this wrong is up to 3× the transaction value. A $50K consulting gig that doesn't close on EDPMS = $150K exposure if the RBI picks you up in audit.

We read every Skydo blog post, every product page, every features doc, every competitor review, every G2 summary. Then we did the audit their marketing team hopes you don't do: separated the product surface from the content surface. Here are the seven screens that exist in the blog but not in the product.

01 · Cross-rail reconciliation

What the screen should be: one timeline. Every inward USD you received this quarter — from Skydo, Karbon, Winvesta, Wise, Payoneer, PayPal, direct SWIFT, Stripe Atlas — reconciled against the invoices you sent. Purpose code per payment. EDPMS-ready status per invoice. One view.

What Skydo actually does: it reconciles payments that came through Skydo. Their Zoho integration blog is explicit: an invoice in Zoho gets marked paid only when the payment lands on the Skydo rail. PayPal money to your Chennai account? Not in the view. Stripe Atlas quarterly distribution? Not in the view. The money that doesn't touch Skydo's pipe is invisible to Skydo's dashboard.

Why it matters:EDPMS doesn't care which rail the money came through. It cares that every outgoing invoice has a matching inward remittance, closed within the realization window, with the right purpose code. If your payment stack is two-or-more rails, reconciliation is a spreadsheet job — or it breaks silently and you find out during an audit.

02 · EDPMS closure tracking

What the screen should be: a per-invoice view of EDPMS status. Open / closed / pending write-off. Timeline bar per invoice with the realization clock running. One-click PDF export of the closure trail, for your CA.

What Skydo actually does: Skydo's EDPMS explainer post is well-written. At the end, it tells you to go to ICEGATE and use the RBI-SB-EDPMS Enquiry tool. The CTA button says "Get started!" — and takes you to the Skydo signup page, which has no EDPMS screen on the other side.

Why it matters: EDPMS closure is the single most important FEMA artifact after Oct 1, 2026. Without it, every outgoing invoice sits as an unclosed export — theoretically exposing you to the 3× penalty multiplier even if the money landed on time. A CA can chase this for you, quarterly, by hand. Nobody should be doing this by hand.

03 · e-BRC helper

What the screen should be: surface the IRMs your bank has transmitted to DGFT (across every rail you use), pre-fill the self-certification form with matched invoice references, flag clubbing opportunities (multiple IRMs → one e-BRC, or one IRM → several invoices), validate the match before you generate, and track any later bank / agency flag with the specific field that tripped.

What Skydo actually does: writes useful content about it, and has public support pages covering e-BRC flows for Skydo-received remittances. Their e-BRC Update post describes the DGFT handshake cleanly. What it doesn't do is span non-Skydo rails — if your USD came in via Payoneer, Wise, PayPal, or direct SWIFT, you're still manually picking IRMs in DGFT and self-certifying one invoice at a time.

Why it matters: e-BRC is how you claim your GST export refunds. Every stuck or unutilized e-BRC is working capital idle in the DGFT system. Agencies with 20+ invoices a quarter lose 2-4 weeks of finance-team time chasing these across bank trade-services desks and the DGFT portal. A cross-rail screen that surfaces IRMs, pre-fills self-certification, and alerts on utilization collapses that to an afternoon. We wrote a deep-dive on e-BRC →

04 · Realization timeline alerts

What the screen should be: a countdown per invoice. 15 months for foreign-currency realization, 18 months for INR. Warning at T-60 days, escalation at T-30, compounding penalty notice at T-0. Push / email / WhatsApp your choice.

What Skydo actually does: explains the timelines in a blog post. The product has no countdown, no alert, no invoice-level realization view. You are expected to track this yourself — or more realistically, not track it and hope you don't get audited.

Why it matters:the realization window is the silent FEMA trap. Missing it doesn't send an email. It sits in the file until an auditor or a tax scrutiny pulls your records. By then, you're defending three years of missed windows. An alert system is the single cheapest piece of insurance a service exporter can buy.

05 · Export Declaration Form (EDF) filing assistant

What the screen should be: the Oct 2026 EDF is structured data. An assistant that reads your invoices, auto-fills the EDF fields, flags missing data (purpose code, HS code where applicable, client country, banker details), submits through the portal integration, returns the acknowledgment to your ledger.

What Skydo actually does: publishes an EDF Filing Guide. The CTA at the end says "Explore Skydo" and links to the homepage. There is no EDF filing screen in the product, no pre-fill, no submission flow. The post was published well before the Oct 1, 2026 deadline — the product hasn't caught up.

Why it matters: EDF is the new default. From Oct 1, 2026, it replaces SOFTEX. Each service export has to be represented in an EDF — or in an EDF ledger entry where services are consolidated into a monthly EDF — and the ledger discipline per invoice (purpose code, client country, banker details, realization tracking) is yours to keep clean either way. A freelancer handling 40 invoices a year through the RBI portal by hand is a recipe for error and missed closure events. This is the highest-volume, highest-repetition screen on this list.

06 · GST LUT renewal + IGST refund workflow

What the screen should be: a reminder, every April, to renew your LUT. A one-click start for the IGST refund workflow that pulls your export invoices, matches them to inward remittances, auto-generates the GST RFD-01, and tracks it to credit.

What Skydo actually does: blogs about LUT for tech service exports. The product has no reminder, no renewal flow, no IGST refund workflow. LUT expiry is the moment a service exporter silently starts owing 18% IGST on invoices they thought were zero-rated.

Why it matters: an expired LUT costs you 18% of export revenue for every month it stays expired. IGST refunds stuck in RFD-01 limbo are working capital your accountant forgot to chase. These are the unglamorous, unsexy, high-dollar screens.

07 · Audit-ready CA handoff package

What the screen should be: one button. Export a zipped bundle: FIRA PDFs, invoices, inward remittance statements, EDPMS closure trail, e-BRC receipts, LUT copy, realization timeline per invoice. Dated, signed-off, CA-usable without a follow-up call.

What Skydo actually does:hosts the FIRA documents in the dashboard. That's it. You assemble the rest. If your CA is chasing the handoff, it's because Skydo — the rail — only owns the slice of the handoff that Skydo processed.

Why it matters:the CA's time is the most expensive time in the export ops seam. Every quarter, they email you and ask for the same eleven files. Every quarter, you assemble the eleven files. Multiply across three years of records. This is the screen that turns a CA-review subscription into a two-email conversation.