A client in Austin clicks "pay" on a USD invoice. You expect the money in two days. On day nine your AD bank emails asking you to "confirm the purpose of the remittance," the sum that finally lands is $47 short of what you invoiced, and your accountant wants a certificate you have never heard of before he'll treat it as export revenue. None of that is bad luck. It is the plumbing working exactly as designed, and once you know the shape of the pipe, most of these stalls stop happening.

Here is what actually moves when a US client pays you.

The wire's journey

Your client's US bank does not have an account at your bank in Pune. Almost no two banks on opposite sides of the corridor do. So the payment travels over SWIFT through one or two correspondent (intermediary) banks that both sides do have relationships with, and finally reaches your Authorised Dealer Category-I bank in India, which converts the USD and credits you in INR (or into a permitted foreign-currency account, if you hold one).

Every one of those inbound service-export payments is governed by the Foreign Exchange Management Act, 1999 and RBI's Master Direction on Export of Goods and Services. That Master Direction is worth knowing exists even if you never read it end to end. It is the document your AD bank is actually following when it asks you questions, and it sets a clock most operators miss: export proceeds must be realized and repatriated within nine months from the date of export (with defined extension provisions your bank can walk you through). Late payment from a slow US client is not just a cash-flow problem. Past nine months it becomes a FEMA compliance item your bank has to track.

Purpose codes: the tag on every rupee

RBI requires your AD bank to report every inbound remittance under a Balance-of-Payments purpose code. This is not optional metadata. It is how the transaction is classified for the central bank, and it drives whether the inflow reconciles cleanly against an export invoice.

Software and IT services sit in the P08xx group on RBI's purpose-code annexure. In practice a dev shop's receipts land under codes like software implementation and consultancy, or data processing charges. You do not usually type the code yourself, but you influence it: the wire's narration, your invoice description, and what you tell the bank when they call all feed the code the bank ends up reporting. When the narration says "consulting" and your invoice says "software development" and the amount matches a services contract nobody has seen, that is when the "please confirm the purpose" email arrives and the credit sits in limbo.

The practical move is to be boring and consistent. Put the intended purpose code on the invoice, describe the service the same way everywhere, and give your bank the underlying document (the SOW or the contract) before they ask.

FIRC: your proof the money was clean

Once the money lands, you want the Foreign Inward Remittance Certificate on file. The FIRC is the AD bank's attestation that foreign currency arrived as a legitimate inbound payment. Physical paper FIRCs were largely phased out around 2016. Today the AD bank reports the remittance into RBI's Export Data Processing and Monitoring System (EDPMS), which generates an Inward Remittance Message that functions as the e-FIRC (background explainer). Only AD Category-I banks issue it.

You want it because it is the single cleanest piece of evidence that a given inflow was a bona fide service-export receipt. Your GST position on exports, your income-tax treatment of the revenue as export earnings, and any future audit all lean on it. A shop that collects e-FIRCs against each invoice, month after month, has a paper trail. A shop that does not is reconstructing history from bank statements the week before an assessment.

SOFTEX and STPI: a rule in transition

Historically, software and ITeS exported over data links were declared on a SOFTEX form, certified by STPI (or the SEZ office), which gave the AD bank the basis to report the export under FEMA (STPI's SOFTEX filing page). Whether it bit depended on registration status and value thresholds, so treat "do I need to file SOFTEX" as a question for your CA against your specific setup, not a blanket yes.

More important: this regime is changing. Under the RBI's new Foreign Exchange Management (Export and Import of Goods and Services) Regulations, 2026, the SOFTEX form is being discontinued and folded into a single Export Declaration Form (EDF) effective 1 October 2026, with an AD bank recognized as a certifying authority on par with STPI (Majmudar & Partners' summary). If you are reading this near that date, confirm the current mechanics with your AD bank before you assume the old SOFTEX workflow still applies. This is not legal advice, and the transition is exactly the kind of thing where last year's blog post is wrong.

GST: export of services is generally zero-rated

Export of services is generally a zero-rated supply under Section 16 of the IGST Act, 2017. "Generally" is load-bearing. It is zero-rated when the supply meets the "export of services" definition, which includes receiving payment in convertible foreign exchange within the prescribed period. That is the same nine-month clock the FEMA side is watching, from a different direction.

Section 16 gives an exporter two routes. Pay IGST and claim a refund, or supply under a Letter of Undertaking (LUT) without paying integrated tax up front. Most shops file the LUT so they can invoice without charging IGST at all. The LUT is filed in Form GST RFD-11 on the GST portal, under Section 16(3) read with Rule 96A of the CGST Rules. It is not permanent. The conditions and timelines are rule-bound, so it gets renewed and the realization requirement still applies.

On the invoice itself, the SAC for custom IT work is 998314, "Information technology (IT) design and development services," under heading 9983 (CBIC GST portal). The domestic rate on that SAC is 18%, but a qualifying export is zero-rated. Putting the right SAC on the invoice is how you keep the classification clean; getting the export treatment is a separate condition on top of it. When your client's counsel starts asking about tax gross-up and who bears withholding, this is the vocabulary that conversation runs in. It is one of the quieter reasons the client's lawyer slows your close: payment and tax terms get read carefully, and vague ones bounce back.

Why wires actually stall

Strip out the exotic cases and inbound wires stall for a short, boring list of reasons:

  • Purpose-code mismatch or a missing purpose. The bank cannot classify the inflow, so it holds and asks.
  • Beneficiary name or account mismatch. "Acme Tech Pvt Ltd" on the wire versus "Acme Technologies Private Limited" in the bank's KYC record is enough to trigger a manual review.
  • Missing KYC or documentation trail. The AD bank needs an underlying document (the invoice or contract) to report the inflow. No document, no clean report.
  • AML, sanctions, or compliance holds. These can fire at the sender's bank, a correspondent bank, or your receiving bank, and you often will not be told which.
  • Intermediary fees quietly shrinking the amount. Each correspondent hop can deduct a flat charge, and the FX conversion carries a margin off the mid-market rate (fee mechanics). This is why the credited amount comes in under the invoice.

That last one has a fix most operators do not know about. The wire carries a fee-allocation field: OUR, BEN, or SHA. Under OUR the sender pays all charges, so you receive close to the full invoiced amount. Under BEN or SHA, the shop absorbs the deductions. Put "remit under OUR / sender bears all bank charges" in your payment terms and the $30-a-hop leakage becomes the client's problem, which is where it belongs.

Invoice hygiene that prevents the stall

Most corridor payment pain is prevented at the invoice, not chased down at the bank. A clean export invoice carries:

  • Your PAN and GSTIN
  • The LUT reference (ARN) if you are exporting without IGST
  • The SAC code (998314 for IT design and development)
  • The intended RBI purpose code for the inflow
  • Correct beneficiary name and account, plus your AD bank's SWIFT/BIC and routing details, matching KYC exactly
  • Currency (USD) and the conversion basis
  • A clear, milestone-linked payment schedule

The last line does more than it looks like. When each payment tranche is tied to a specifically accepted milestone, every inbound remittance maps to one invoice with one purpose code, and reconciliation stops being detective work. It also closes the dispute your client reaches for when a payment is due: whether the deliverable was actually done. If the schedule says payment falls due on documented acceptance of a milestone, "we're not sure this is finished" is answered by the acceptance record, not a call. That is why the payment schedule and the acceptance criteria a client can't argue with are really one instrument written in two places.

The corridor is not hostile. It is procedural. The bank is not trying to hold your money; it is trying to classify it, and every stall is the classification failing on something you could have stated up front. State it up front, keep the certificates, and the wires get boring. Boring is what you want.