1. India–New Zealand FTA: New Customs Declarations from 20 October 2026

The India–New Zealand Free Trade Agreement is intended to improve bilateral market access and strengthen commercial opportunities. Preferential treatment, however, depends on the relevant product and rules of origin. Goods do not qualify merely because they are shipped to New Zealand.

According to the ICEGATE implementation advisory dated 19 October 2026, customs EDI implementation began on 20 October 2026. The agreement identifier is FTANZD.

Required declaration fields

For an eligible export item claiming preferential treatment, the Shipping Bill Single Window information table uses the following values:

Why item-wise treatment matters

Imagine an exporter dispatching three product lines to one customer in New Zealand. Two lines meet the applicable origin requirements and the third does not. The three lines share a consignee and shipment, but they cannot automatically share the same preferential-origin declaration.

Each Shipping Bill item should be evaluated separately. Export software should allow the user to choose “preferential benefit claimed” or “not claimed” for each item, with rules that catch missing mandatory declarations before the filing file is created.

Certificate of Origin and import-side documentation

Businesses should capture and retain the applicable origin criterion, Certificate of Origin (CoO) reference, date, relevant product classification and supporting documents. The advisory also introduces e-SANCHIT document code 861021 for relevant import-side Certificate-of-Origin submissions.

Not every internally captured field is necessarily a mandatory field in every customs message. Review the technical specification and legal requirements separately, and preserve the supporting records for verification.

Exporter action checklist

• Check whether each item qualifies for the agreement under the applicable origin rules.
• Confirm the agreement code and item-level EDI mappings with the customs broker.
• Validate CoO information and maintain supporting origin records.
• Test shipments containing a combination of qualifying and non-qualifying items.
• Prevent generation of a customs export file when the required declaration is incomplete.

2. GST RCM: Recipient-Generated E-Invoices Enter Sandbox Testing

Under the Reverse Charge Mechanism (RCM), GST payment responsibility shifts to the recipient for specified taxable transactions. These can include prescribed domestic supplies and certain imported services, depending on the applicable legal provisions.

A GSTN advisory dated 16 October 2026 describes a new electronic self-invoicing capability in the sandbox/testing environment for eligible taxpayers, introducing two supply types.

The facility is described as intended for taxpayers meeting the relevant aggregate turnover threshold of ₹5 crore, subject to the official legal framework and rollout guidance.

Example: overseas software subscription

An Indian export company subscribes to an overseas SaaS platform and receives a US-dollar invoice. If the transaction qualifies as a taxable import of services liable under RCM, the finance team may need to account for GST and generate the appropriate internal documentation. For future electronic self-invoicing, software may need to map supplier country, currency, exchange rate, service classification, place of supply, tax amounts and payment-voucher reference.

What to test in software

• Separate series for recipient-generated self-invoices and normal sales invoices.
• Validation of mandatory supplier, transaction and tax fields.
• IRN creation and handling of failed or duplicate submissions in the IRP sandbox.
• Cancellation and eligible debit/credit note scenarios according to supported specifications.
• Complete audit histories and reconciliation with accounting records.

Finance teams should also identify foreign service expenses and prescribed domestic RCM transactions. Importantly, a purchase from an unregistered supplier does not automatically mean that reverse charge applies.

3. SCMTR: Preparing for the 31 October 2026 Transition Date

The Sea Cargo Manifest and Transshipment Regulations (SCMTR), 2018 govern electronic cargo and transshipment reporting by relevant participants in sea-cargo logistics. These participants may include carriers, agents, custodians and transhippers.

CBIC Notification 73/2026-Customs (N.T.), dated 1 September 2026, substituted 31 October 2026 as the date for a particular entry in the SCMTR framework's table following Form XII.

Example: Morbi ceramics exported through Mundra

A ceramic manufacturer in Morbi dispatches boxed wall tiles to Mundra Port. The shipment may pass through transporters, customs-broker processes, stuffing activities, a container freight station or port facilities, and a shipping line. Accurate records are essential across these handoffs.

Common references include the export order, invoice, packing list, Shipping Bill, container and seal numbers, package count, gross weight, transport records, stuffing details and relevant cargo-manifest acknowledgements.

A mismatch in a package count or container identifier can trigger investigation and correction even when the goods and invoice are otherwise accurate.

Before 31 October

• Ask regular brokers, forwarders, custodians and transhippers for written readiness confirmation where relevant.
• Check location-specific registration and operational responsibilities, not only corporate registration.
• Reconcile package quantity, weight and container details against actual stuffing and customs records.
• Investigate shipments that show Let Export Order (LEO) but no expected subsequent logistics or manifest update.
• Do not rely on informal claims that the transition date will be extended.

Missing status information is not, by itself, proof of a regulatory breach; it is a prompt for follow-up with the responsible logistics partner.

4. CERT-In's AI-Agent Security Warning: Protecting Business Systems

Businesses increasingly use AI to answer customer enquiries, interpret documents, summarise production activity and automate routine notifications. These capabilities also raise risk if an agent is granted excessive access to business records or infrastructure.

CERT-In Advisory CIAD-2026-0049, issued 15 October 2026, draws attention to unauthorised access and abuse involving agentic tools, exposed credentials, insecure APIs, excessive permissions and reachable administration interfaces.

AI assistance is not unlimited authority

A voice assistant that reads an authorised order status should not automatically be able to change financial details, remove orders or execute arbitrary database queries. Reading a specific status and making a permanent change are very different security actions.

Five protective controls

1. Least privilege: assign a dedicated, narrowly scoped service identity to an AI workflow; prefer short-lived credentials.
2. Approved application APIs: do not give AI workflows unrestricted direct MySQL connections. Authorise and validate every sensitive operation.
3. Separate environments: keep production secrets out of test tools, prompts, repositories and example data.
4. Audit logging: capture initiating identities, the action, affected record, outcome, and approved changes where appropriate. Follow applicable retention requirements; the advisory references at least 180 days of logs.
5. Network and secret controls: restrict outbound destinations and scan source repositories, configuration and history for leaked credentials.

These precautions are particularly relevant to automated order notifications, customer self-service, AI-assisted production imports and voice agents connected to ERP systems.

5. ICEGATE and e-SANCHIT: Handling Portal Errors and Uncertain Acknowledgements

Correct source data is only part of a successful customs workflow. Export teams also depend on the reliability of external customs services, electronic document-upload facilities and payment integrations.

The IndusInd Bank transaction warning and digitally signed e-SANCHIT upload issue were reported during the review period. Businesses should check the official ICEGATE portal for the current live status; these should not be presented as permanently unresolved.

Recommended error-handling approach

• Record the date, time, transaction reference and complete validation or portal error response.
• Distinguish a rejected submission from an unacknowledged or delayed submission.
• Check whether the first request succeeded before submitting it again.
• Keep copies of successfully submitted documentation and acknowledgement identifiers.
• Use controlled retries that minimise accidental duplicate processing.

A useful export-management workflow distinguishes business-data validation errors, portal availability problems and pending external acknowledgements, so users know which next step is appropriate.

6. The Bigger Picture: Building a Connected Export Workflow

Regulatory changes reveal the limitations of disconnected spreadsheets, duplicated data entry and isolated departments. A shipment quantity updated in one location should not silently remain outdated in its packing list, invoice or customs preparation records.

What integrated export software should provide

• Shared records: consistent customer, product, order and shipment details across documents.
• Configurable compliance data: agreement masters and fields that can be updated under controlled release procedures.
• Pre-submission checks: validation of missing or inconsistent declarations before a file is released.
• Traceable operations: links between orders, packing, container records, Shipping Bill numbers and shipment milestones.
• Secure permissions: restricted access and reviewable actions for people, system accounts and automated agents.

Not every export application has a live government or shipping-line integration. Businesses should distinguish data preparation and internal workflow capability from a confirmed direct external API connection.

7. Practical Readiness Checklist for Export Businesses

Questions to ask internally

• Can our team identify which specific goods qualify for an FTA preference?
• Do our export documents share the same quantities, weights and references?
• Are foreign service purchases assessed for possible RCM implications?
• Can we follow up a container from dispatch through customs and loading milestones?
• Could an AI or automation service change information it only needs to read?

8. How Zuku Export Fits into Modern Export Management

At Zuku, the focus is on organising export-related information into structured workflows that support commercial documentation, orders and operational coordination.

The October 2026 developments illustrate why exporters and their software providers need to plan for changing customs data, validation requirements, document consistency, traceability and secure integrations.

Businesses evaluating an export-management solution should ask which functions are available today, which external integrations are supported, and how changes to customs or tax specifications are tested and released. No software should be assumed to have automatic live filing capability unless that integration has been specifically confirmed.

9. Frequently Asked Questions

10. Official Sources and Further Reading

1. ICEGATE — India–New Zealand FTA implementation advisory, 19 October 2026.
2. Ministry of Commerce & Industry — India–New Zealand trade agreement information.
3. GST Portal — GSTN advisory on recipient-generated RCM e-invoices, 16 October 2026.
4. CBIC Tax Information Portal — Notification 73/2026-Customs (N.T.), 1 September 2026.
5. CERT-In — Advisory CIAD-2026-0049, 15 October 2026.
6. ICEGATE Service Notices — Current electronic-filing and e-SANCHIT updates.

Disclaimer: This article provides general information as of 26 October 2026 and is not legal, tax or customs-filing advice. Technical specifications, effective dates and government advisories can change. Confirm the latest official guidance and consult qualified customs or tax advisers before acting. The exact non-preferential India–New Zealand FTA declaration code requires verification against the official current EDI specification.