How to Transfer a Duty Credit Scrip on ICEGATE: Both Sides, Step by Step

The short answer

Transferring a RoDTEP or RoSCTL e-scrip on ICEGATE is not one action by one person. It is a two-sided handshake inside the Electronic Duty Credit Ledger, and it has two operators: the transferor, who initiates, and the transferee, who approves. The seller selects the scrip, enters the buyer's ICEGATE ID and IEC, and verifies with an OTP. The scrip then reads Transfer Pending and nothing has moved. The buyer opens the request on their own login and approves it with an OTP of their own, and only at that moment does the status become Transferred. Either side may reject, which produces Transfer Rejected.

The sequence below is taken from sections 3.4 and 3.5 of the ICEGATE advisory to avail benefit of export incentive schemes (RoDTEP and RoSCTL), version 0.11 dated 16 August 2024, which is the operating document for the e-scrip module. Where the advisory is silent, this page says so rather than filling the gap.

Before you start: what both sides need

Three things have to be true before either party touches the portal, and two of them belong to the buyer.

• Both parties need an ICEGATE login with an e-scrip account. The advisory is explicit that the e-scrip facility can be used only after creating an e-scrip account at ICEGATE, and that the user has to be a valid IEC holder registered on ICEGATE with a DSC. The same requirement is repeated for the transferee: the party receiving the scrip must already hold a valid e-scrip account. A buyer who has not done this cannot receive the scrip at any price. The ICEGATE registration guide for scrip holders covers that setup.
• The scrip itself needs no separate registration errand. Under Regulation 5 of the Electronic Duty Credit Ledger Regulations, 2021, registration of an e-scrip is automatic at the customs station of export. There is no form to file to make a scrip registerable and no counter to visit. What you are waiting on is the scrip existing in the ledger, not a registration step you have missed.
• You need two identifiers from the buyer, not one. The transfer is directed using the transferee's ICEGATE ID and IEC together. Collect both in writing before you begin, because the transfer goes to that pair and to nobody else.

What the seller (transferor) does

Six steps, in order, per section 3.4 of the advisory.

• 1. Open the Scrip Transfer tab. From the Schemes page, select the Scrip Transfer tab.
• 2. Select the scrip. Choosing the e-scrip from the list of generated e-scrips is mandatory. The whole scrip moves: Regulation 7(2) of the Electronic Duty Credit Ledger Regulations, 2021 requires the duty credit to be transferred at a time for the entire amount in the e-scrip and does not permit transfer in part. You cannot shave off a slice to match a buyer's duty bill.
• 3. Enter the transferee's ICEGATE ID and IEC. This is the only step on the page that cannot be undone by you alone. The request goes to the ICEGATE ID and IEC you type, so read them back against what the buyer sent you before you go further.
• 4. Choose a verification mode. The transferor has to verify themselves before the request can be accepted. Select Mobile or E-mail for the verification OTP.
• 5. Enter the OTP. ICEGATE sends it to the mobile number or e-mail registered against your login. The OTP is valid for a window of fifteen minutes only, and a wrong OTP returns an error message rather than a silent failure.
• 6. Submit, then read the grid. After submitting you get a success notification, and the request appears in a grid on the same Scrip Transfer tab. The scrip is now Transfer Pending. It is still yours, it is not the buyer's, and it is committed to a request you should not duplicate elsewhere.

Step six is where most private deals go wrong, because the seller reports the transfer as done and asks to be paid. It is not done. Nothing has left your ledger.

What the buyer (transferee) does

The other half, per section 3.5. Until these steps are completed the buyer owns nothing, whatever has been agreed on a call.

• 1. Receive the request. The approval request is sent to the IEC named by the transferor, and that IEC holder must already have a valid e-scrip account on ICEGATE for it to arrive at all.
• 2. Open the Approve Scrip Transfer tab. From the Schemes page, the transferee selects the Approve Scrip Transfer tab, which is where approving and cancelling both happen.
• 3. Read the request before touching either button. The tab lists every e-scrip requested to be transferred to you. Check the scrip and its remaining life here: validity is two years from the scrip's creation in the ledger under Regulation 6(2), and it does not restart on transfer, so you inherit the balance of a clock somebody else started. Check what the credit can actually pay too. An e-scrip pays the duties of customs leviable under the First Schedule to the Customs Tariff Act, 1975, that is basic customs duty and nothing else, never IGST, never GST compensation cess, never social welfare surcharge.
• 4. Reject, or approve. A transferee who does not wish to accept the scrip cancels the request with the Reject button. To take it, click Approve, which triggers verification of the transferee: select Mobile or E-mail for the verification OTP.
• 5. Enter your own OTP. ICEGATE sends it to the mobile number or e-mail registered against the transferee's login. This OTP is also valid for a window of fifteen minutes only, and a wrong entry returns an error message.
• 6. Submit. A success notification confirms the approval. The status moves from Transfer Pending to Transferred, and the credit is now in the buyer's ledger to apply against their own import duty.

Troubleshooting the four things that actually go wrong

• The OTP expired. The window is fifteen minutes, on both sides of the transfer. If it lapses, or if a wrong code was entered and the error message came back, the fix is to re-initiate the verification and enter a fresh OTP inside the window. Have the registered mobile or mailbox in front of you before you start, not in another room.
• The buyer says they cannot see the request. While a request is pending it is visible to the transferee on their own Approve Scrip Transfer tab, and it reaches only the ICEGATE ID and IEC that were entered. If the buyer's tab is empty, the first thing to check is the pair you typed, not the portal. A request sent against a mistyped ICEGATE ID and IEC is not sitting where either of you is looking.
• The status reads Transfer Rejected. The advisory attributes rejection to either side: it covers an e-scrip rejected by the transferor who initiated the request, or by the transferee to whom it was sent. Rejection is not a loss. The credit stays with the transferor, and the route forward is a fresh request with the details corrected and the commercial point settled first, because a second rejection costs the same two OTPs as the first.
• You are not sure what state the scrip is in. Read the Scrip Status field rather than trusting a message from the other side. It offers six values: Active, Utilize (the transaction view labels the same thing Utilized), Transferred, Transfer Pending, Expired and Transfer Rejected, with All as the default grid view. Active means the scrip is live and yours. Transfer Pending means a request is out and the credit has not moved. Transferred means the transferee approved and it is gone. The balance and status guide covers reading the rest of the ledger.

What the exchange changes

Look at where the two flows meet. Between the seller's submit and the buyer's approval the scrip sits in Transfer Pending, and the portal holds no money and offers no guarantee. In a privately negotiated deal that gap is the whole problem: somebody has to move first, and whoever moves first is exposed. A seller who initiates before being paid is trusting a stranger to approve and then pay. A buyer who pays before approving is trusting a stranger not to leave the request sitting or to reject it. That pending window, not the paperwork, is where counterparty risk in a private scrip sale actually lives. The seller's view of the same problem is set out in how scrips are sold today, and the buyer's in how scrips are bought today.

Scriphouse closes the window rather than negotiating inside it. Settlement is atomic delivery versus payment: buyer funds are secured before the scrip moves, and the seller's payout releases against confirmation of the transfer, on the same business day, carrying a bank UTR. If any leg fails, the trade unwinds and refunds in full, so a failure returns both sides to where they started rather than leaving one of them holding a pending request. Every scrip is provenance-screened before it can be listed, quotes are firm for sixty seconds, and every settled trade ships a GST invoice and a net-realisation statement. The first trade on an IEC is free; after that the self-serve fee is 0.40% of the value that settles plus 18% GST on the sell side, and the buy side is a spread with the ask capped at face value. Same-day T+0 settlement sets out the sequence step by step.

Where to go from here

If you hold a scrip and want it turned into cash without running either flow yourself, the shortest path is a single Sell Now offer. To confirm what you hold before you initiate anything, read how to check your scrip balance on ICEGATE, and when does a scrip expire for why the remaining life is part of the price rather than a detail. If you buy as well as sell, the same credit covers basic customs duty on an import, and the ledger explainer covers the system all of this runs inside. See how Scriphouse works for exporters.

Frequently asked questions

How do I transfer a duty credit scrip on ICEGATE?

From the Schemes page, open the Scrip Transfer tab, select the e-scrip, enter the transferee's ICEGATE ID and IEC, verify yourself by an OTP sent to your registered mobile or e-mail, and submit. The scrip then reads Transfer Pending. The transferee opens the Approve Scrip Transfer tab on their own login, approves, and enters an OTP of their own, and only then does the status become Transferred. On Scriphouse the transfer runs under a signed, revocable mandate after you accept a firm offer, so you do not run either flow.

What do I need from the buyer before I can initiate a transfer?

Two identifiers, not one: the transferee's ICEGATE ID and their IEC. The buyer also has to hold a valid e-scrip account on ICEGATE, which per the advisory requires a valid IEC holder registered on ICEGATE with a DSC. A buyer without that account cannot receive the scrip, however the price was agreed.

What if I enter the wrong ICEGATE ID or IEC?

The request goes to the pair you typed and appears on nobody else's Approve Scrip Transfer tab, which is why an empty tab at the buyer's end is a prompt to check what was entered. If it reaches a real party who approves it, the scrip has moved to an unintended holder and recovery depends on that party. On Scriphouse the counterparty comes from a screened, settled trade, so the identifiers are never typed by you.

What happens if the OTP expires?

The OTP is valid for a window of fifteen minutes only, on both the initiation and the approval side, and a wrong code returns an error message. If the window lapses, re-initiate the verification and enter a fresh OTP within fifteen minutes. Each party receives their own OTP at their own registered mobile or e-mail, and neither can complete the other's step.

The scrip reads Transfer Pending. Has it moved?

No. Transfer Pending means the transferor has submitted the request and the transferee has not yet approved it. The credit is still in the transferor's ledger and the transferee cannot use it. This is the window where counterparty risk in a private deal sits, and it closes only when the transferee approves with their own OTP.

What does Transfer Rejected mean, and what should I do next?

Transfer Rejected covers an e-scrip rejected either by the transferor who initiated the request or by the transferee to whom it was sent. The credit remains with the transferor and nothing is lost. The next step is to settle the disagreement or correct the details and initiate a fresh request, since each attempt costs both parties a verification.

Can a duty credit scrip be transferred more than once?

Regulation 7 of the Electronic Duty Credit Ledger Regulations, 2021 sets no limit on how many times a credit may move, and the ICEGATE advisory does not address it. What Regulation 7(2) does require is that the whole scrip moves at a time, never part of it. Anyone writing with more certainty than that on the count is going beyond the published sources.

Do I get paid when the transfer confirms?

On Scriphouse, yes. Buyer funds are secured before the scrip moves, and your payout is released against confirmation of the transfer and carries a bank UTR, on the same business day. A failed transfer unwinds and refunds in full the same day, and every settled trade ships a GST invoice and a net-realisation statement.