countries · sectors · sub-national hubs · trade bodies · FTAs · tools · academy · essays
Compare your duty savings across all active India Free Trade Agreements — side by side. Enter your product category and annual shipment value. See which corridors deliver the largest tariff advantage and how much you save per shipment and per year.
ⓘ Indicative estimates only. FTA duty rates depend on the specific 10-digit HS code and Rules of Origin compliance. Verify against official TARIC, DGFT, and partner-country customs databases before making commercial decisions.
Side-by-side FTA duty comparison across all 6 active India FTAs will appear here.
The most transformative India FTA — eliminates duty on 85-90% of EU tariff lines over 7-10 years. 400+ Indian GIs receive EU legal protection. REX self-certification replaces paper CoO. The largest single FTA opportunity for Indian exporters in the next decade.
Full FTA Guide →90%+ tariff lines at zero duty immediately. JAFZA re-export hub for GCC and Africa. Gold jewellery, pharma, rice, engineering — immediate zero duty. India-GCC full FTA expected 2025-26 to extend benefit to Saudi Arabia, Qatar, Kuwait, Bahrain, Oman.
Full FTA Guide →85%+ tariff lines at zero. TGA pharma pathway significant — ECTA zero duty + TGA registration = full market access. IT services strong growth. Australian market values quality and provenance — Indian GI and premium products well-positioned.
Full FTA Guide →90%+ tariff lines at zero or significantly reduced. Japan is a quality-demanding, long-term relationship market. PMDA pharma approval is the primary access barrier — CEPA removes the tariff once approval is obtained. Auto components for Japanese OEMs in India also benefit.
Full FTA Guide →85%+ tariff lines at zero. Korean conglomerates (Samsung, LG, Hyundai, POSCO) have invested heavily in India — creating reverse supply chain opportunities. K-REACH for chemicals and KC Mark for electronics are the key compliance requirements alongside CEPA.
Full FTA Guide →90%+ tariff lines at zero (Singapore already near-zero MFN). Strategic value: the India-Singapore-EU triangular structure — CECA for India→Singapore leg, EUSFTA for Singapore→EU leg. IT services to Singapore-based MNCs is the largest Mode 1 opportunity.
Full FTA Guide →Totality lens · 32 points to ponder · 16 user POV + 16 developer POV · this FTA pillar
User POV — for the practitioner navigating the Fta Savings Estimator FTA pillar
Eight dimensions
A savings-estimator that lets users plug in their HS code + origin + destination + shipment value and returns the FTA-applicable savings versus MFN-rate baseline replaces the consultancy-quote treadmill with a self-service surface. The possibility is to make FTA economics legible at decision-time rather than at end-of-year-review-time. Small exporters who would never engage a consultancy can now answer "is this shipment worth claiming the FTA preference for" themselves in three minutes.
Plausibility tracks calculator accuracy. Wrong calculations cause downstream operational damage when traders plan around mis-estimated savings. We solve through (a) sourcing duty rates from the underlying agreement-specific hub data (single-source-of-truth), (b) surfacing confidence flags where data has known ambiguity, (c) explicit disclaimer that the calculator is decision-support not legal-advice. The plausibility floor is the data-pipeline integrity.
On a six-month horizon, savings-estimator search is dominated by small-and-medium exporters making per-shipment decisions, customs-brokers running scenarios for client decisions, and the cost-curious sub-group of larger exporters who want to validate consultancy estimates with an independent number. The probability that the calculator becomes a habitual workflow-tool (rather than a one-time visit) is high because per-shipment decisions repeat.
What works is the four-input simple-form pattern: HS code + origin + destination + shipment value. Users get an answer in under 30 seconds. The simplicity is the value — users do not have to know anything more than their basic shipment context. What works less well is forcing users to specify rules-of-origin compliance up-front; we treat that as a separate downstream check after the savings number motivates the deeper investigation.
What does not work is over-precise outputs. Reporting savings as "$1,247.32" implies false precision when the underlying data has 5 percent confidence band. We round to two significant figures and surface the confidence band explicitly so users calibrate trust correctly.
A common pitfall is using the calculator without checking rules-of-origin compliance. The calculator returns the savings the trader could claim if they qualify under rules-of-origin — but the qualification itself is the gate. We surface a "now check rules of origin" call-to-action prominently after every calculation, with a deep-link to the relevant agreement-specific RoO surface.
Counter-intuitively, many "would save money" calculations turn out to not save money once documentation cost is factored in. A 2 percent rate-margin on a $5,000 shipment saves $100; certificate-of-origin documentation cost is $80-150 depending on the agreement and broker. The calculator surfaces a "documentation-cost overlay" toggle so users see the net-saving rather than the gross-saving.
The highest-leverage move is the multi-shipment-projection mode. Single-shipment savings are often small; annualised projections (estimated shipment-frequency × per-shipment savings × certificate-of-origin amortisation) tell a meaningfully different story. Users planning capacity get the annualised view, which is decision-relevant in ways the per-shipment view is not.
Eight user intents
For per-shipment-decision actors — small and medium exporters running their own customs-decision workflow, customs-brokers running scenarios for clients, in-house trade-compliance staff validating consultancy estimates, and the cost-curious sub-group across all sizes who want a quick second-opinion number. The schema serves all four because the inputs and outputs are the same regardless of audience size.
They want a fast, self-service savings number that respects their specific shipment context. Not "FTA saves on average X percent" but "for your HS line + origin + destination + value, FTA saves Y dollars net of documentation cost". The schema delivers exactly that.
When they are about to ship and need to decide whether to pursue FTA documentation. Calculator traffic peaks during business hours in the user's timezone, drops on weekends, peaks again at fiscal-year-end when annualised-projections matter for next-year planning.
Where they read it: 60 percent mobile because per-shipment decisions are often opportunistic. Desktop is for annualised-projection mode. The mobile design optimises for the simple-form pattern with auto-complete on HS-line.
Because per-shipment FTA-savings calculations are too small individually to justify consultancy fees but cumulatively meaningful for small-exporter cash-flow. The calculator captures this audience with self-service tooling that consultancy economics cannot reach.
Which mode dominates per audience: per-shipment for transactional decisions, annualised-projection for planning decisions, multi-agreement-comparison for traders evaluating routing alternatives, what-if for scenario-modeling.
Whose perspective drives the calculation: the trader-side (the entity claiming the FTA preference). Currency conversion uses the trader's home currency by default with USD-equivalent surfaced. The schema labels the perspective per result.
How they engage: enter the four inputs, scan the savings result + documentation-cost overlay + confidence band, decide whether to pursue FTA documentation, drill into the rules-of-origin surface if pursuing. Time-to-decision under three minutes for the binary outcome; 5-7 minutes for the annualised-projection mode.
Developer POV — for the architect, maintainer, future contributor to this FTA pillar
Eight dev dimensions
Data architecture: calculator pulls duty rates from agreement-specific hub data (single-source-of-truth), MFN-rates from country-level tariff schedules, documentation-cost-estimates from the per-agreement docs surface. Calculation is deterministic: (MFN-rate − FTA-rate) × shipment-value − documentation-cost. Confidence band derived from per-data-source confidence flags.
Schema markup: calculator hub emits as SoftwareApplication with applicationCategory "calculator". Result emits as ParcelDelivery (custom) with PriceSpecification children for savings + documentation-cost. JSON-LD identifier "ajg:fta-pillar::fta-savings-estimator".
Internal linking: estimator hub fans out to per-agreement RoO surfaces (the "now check rules of origin" CTA), per-agreement-specific hubs (for deeper context), masterclass (for learners wanting to understand the calculation), guide (for first-time-FTA readers). Cross-content injector surfaces the estimator on per-product + per-corridor pages.
Page-speed posture: calculator UI is server-rendered shell with client-side calculation logic (under 12 KB minified JS). Calculation runs in browser (no API call) for instant feedback. Total hub page weight under 80 KB. PageSpeed-100-v7 layer applies.
Mobile UX: simple-form pattern as full-screen on mobile. HS-line autocomplete via combobox. Origin + destination as country-picker. Shipment-value as numeric input. Result panel scrolls into view on submit. Multi-shipment-projection as separate URL.
Accessibility: form inputs have proper labels + aria-required. HS-line autocomplete is role=combobox with aria-expanded reflecting dropdown state. Result panel is role=region with aria-live so screen-readers announce updates. Documentation-cost overlay toggle is role=switch with aria-checked.
SEO saturation: hub H1 names "FTA savings calculator" + scope. SoftwareApplication schema. FAQPage with the four most-asked calculator questions (accuracy, documentation-cost overlay, multi-agreement comparison, multi-shipment projection). Speakable on the introductory paragraph.
Extensibility: adding a new agreement to the calculator coverage is data-pipeline-driven (when the agreement-specific hub publishes, the calculator absorbs it). Adding new modes (e.g. "what if RoO does not qualify, what is the MFN-only cost") is calculator-logic extension.
Eight dev intents
For the developer maintaining this hub, the data-pipeline integrity is the most operationally-important. The calculator reads from agreement-specific hub data; if that data drifts, the calculator returns wrong numbers. We enforce single-source-of-truth via pre-flight that fails the build if calculator data references duplicate non-canonical sources.
What changes when calculator data updates: the calculator inherits agreement-specific hub updates automatically (no separate calculator-data file for duty rates). Documentation-cost-estimates update editorially when broker-network surveys complete. Confidence-band derivation updates when per-data-source confidence flags change.
When the cron runs: nightly at 09:30 UTC for the calculator-cache rebuild from agreement-specific hubs. Annual at 09:30 UTC on January 1 for the documentation-cost-estimate refresh. Stagger from other crons.
Where files live: data/cache/fta-savings-rates.json (the calculator-rate cache), data/fta-savings-doc-costs.php (documentation-cost estimates), includes/fta-calculator.js (client-side calculation logic). Renderer at fta-savings-estimator.php.
Why client-side calculation: because instant feedback matters for user-experience on a per-shipment decision tool, and the underlying data is small enough (few KB) to ship to client at first paint. Server-side calculation would add round-trip latency that erodes the simple-form value.
Which renderer: fta-savings-estimator.php emits the calculator UI shell + per-agreement-coverage indicator + multi-shipment-projection sub-mode + RoO-now-check CTA. Calculator JS is the client-side worker. Echoes directly. Idempotent.
Whose responsibility: rate-cache regeneration is automated cron from agreement-specific hubs. Documentation-cost curation is editorial-with-broker-network-survey. Calculator JS maintenance is dev. Schema validity enforced by pre-flight.
How to extend calculator coverage to a new agreement: (1) agreement-specific hub must publish its rate data in the canonical schema; (2) calculator-cache cron picks up automatically on next run; (3) documentation-cost estimate added to fta-savings-doc-costs.php; (4) verify calculator UI auto-detects coverage. Total: minimal direct effort if the agreement-specific hub follows canonical schema.
Explore
Every page in the AJG platform cross-links to these primary entities. Click any pill to explore that branch of the knowledge graph.