Rohas Legal AI: Tax

View saved version →

---
name: fema-analyst
description: Analyses a cross-border transaction against India's foreign exchange control framework — transaction classification, residential status under FEMA, applicable route, pricing guideline and reporting requirements — flagging current sectoral caps and form requirements for verification rather than asserting them from memory. Use this whenever a user has a cross-border transaction and needs the FEMA position — including phrasings like "what's our FEMA position on this investment", "is this an automatic route or approval route transaction", "what FEMA filings does this share transfer trigger", "check the FEMA angle on this ECB", or "does this sector have foreign investment restrictions". India-specific. Fires for inbound or outbound investment, external commercial borrowing, trade transactions, and any transaction touching India's exchange control regime.
---

# FEMA Analyst

## What this does

Analyses a cross-border transaction against India's Foreign Exchange Management Act framework: what kind of transaction it is, the residential status of each party under FEMA specifically, whether it falls on the automatic or approval route, what pricing guideline and reporting obligations apply, and any sector-specific restriction. Sectoral caps, pricing parameters, and reporting forms are set by RBI notifications and master directions that change frequently, so this skill treats their current content as something to verify, never something to assert from memory.

## Before you start

**The transaction facts.** The nature of the transaction — inbound investment, outbound investment, external commercial borrowing, a trade transaction, or another capital or current account item — the parties, the amount, and the sector involved. This is blocking; the applicable framework cannot be determined without it.

Not blocking, ask once and proceed on what is available: **whether current RBI Master Directions or FEMA notifications are available this session.** If they are, cite only what is retrieved or supplied, specifically. If they are not, work from the general structure of the FEMA framework and flag every current threshold, cap, and form requirement as a verification point rather than asserting it.

## Method

**1. Classify the transaction precisely** — FDI, ODI, external commercial borrowing, trade credit, or another category under the NDI Rules or the relevant FEMA regulation — since compliance requirements differ substantially by category.

**2. Determine the residential status of each party under FEMA specifically, not under income tax law.** These use different tests, and conflating them is a common and consequential error — flag this distinction explicitly if there is any risk of confusion on the facts given.

**3. Determine whether the transaction is a capital account or current account transaction.** This is the threshold question that determines which regulatory framework governs it.

**4. Determine the applicable route — automatic or government/RBI approval — based on the sector and structure of the transaction, without asserting a specific sectoral cap or approval threshold from memory.** Flag the current sectoral cap and any attached conditions as a verification point against the current FDI Policy or NDI Rules.

**5. Check the pricing guideline requirement.** State that a valuation compliant with the applicable pricing method is required for the transaction type, without asserting which specific method or its current parameters apply — flag that for verification.

**6. Identify the reporting requirements likely triggered** — the category of form involved (such as an FC-GPR- or FC-TRS-type filing, or an ODI-related filing) based on the transaction type, flagged for verification of the current form number and filing timeline, since these are administratively updated.

**7. Flag any sector-specific restriction or conditionality** — defence, media, real estate, and similar sectors carry their own conditions — as requiring verification against the current sectoral policy, since these are amended frequently and vary significantly.

**8. State the overall compliance posture** — compliant on the facts given, requiring a specific approval, or an open question needing verification — with the reasoning tied to the facts rather than a general statement.

## Output

**1. Header.** Transaction summarised, parties and their residential status under FEMA, date.

**2. Classification.** Transaction type and the FEMA framework that applies to it.

**3. Route analysis.** Automatic or approval route, with the sectoral cap and conditions flagged for current verification.

**4. Pricing guideline requirement.** Stated, without specific current parameters asserted.

**5. Reporting requirements.** The category of filing likely applicable, flagged for verification of the current form and timeline.

**6. Sector-specific conditions, if any.** Flagged for verification against current sectoral policy.

**7. Overall compliance posture.**

**8. Points requiring verification.** Current sectoral caps, current RBI Master Directions and notifications, and current form requirements and timelines.

## Do not

Do not assert a specific sectoral cap, pricing guideline parameter, or approval threshold from memory. These are set by RBI notifications that change frequently.

Do not conflate FEMA residential status with income-tax residential status. They use different tests.

Do not assume the automatic route applies without checking sector-specific conditions.

Do not state a specific form number or filing deadline as current without flagging it for verification.

Do not opine on the income-tax consequences of the transaction. That is a separate question; stay within FEMA and exchange control.

Referenced files: 1

View saved version →

---
name: gst-compliance-analyst
description: Analyses a supply for its GST treatment — classification as goods or services, place and time of supply, applicable rate, reverse charge, input tax credit eligibility, and registration and compliance obligations — flagging current rate notifications and thresholds for verification rather than asserting them from memory. Use this whenever a user needs the GST position on a transaction — including phrasings like "what's the GST treatment of this supply", "does reverse charge apply here", "can we claim input tax credit on this", "do we need to register for GST because of this transaction", or "check the place of supply on this cross-state contract". India-specific. Fires for any supply of goods or services, or a composite or mixed supply, under India's GST regime.
---

# GST Compliance Analyst

## What this does

Analyses a supply of goods or services for its GST treatment: classification, place and time of supply, applicable rate and reverse charge position, input tax credit eligibility, and any registration or compliance obligation the transaction triggers. GST rates, HSN and SAC classifications, reverse charge coverage, and registration thresholds are all set by notifications that change periodically and can vary by state or category, so this skill treats their current content as a verification point rather than something to assert from memory.

## Before you start

**The supply facts.** What is being supplied, by whom, to whom, where, and the consideration involved. This is blocking; the analysis cannot proceed without it.

Not blocking, ask once and proceed on what is available: **whether current GST rate notifications or rulings are available this session.** If they are, cite only what is retrieved or supplied, specifically. If they are not, work through the applicable rule structure and flag every current rate, threshold, and notification-dependent point for verification.

## Method

**1. Classify the supply** — goods, services, or a composite or mixed supply, which carries its own specific tax treatment rule — since this classification drives the rate and place-of-supply analysis that follows.

**2. Determine the place of supply**, working through the specific rule structure for the transaction type (which differs for goods versus services, and for intra-state, inter-state, and export or import transactions). Where the facts are genuinely borderline, say so rather than resolving the question with false confidence, and flag it for verification.

**3. Determine the time of supply** — the trigger, whether invoice, payment, or completion of performance, that fixes when the liability to pay tax arises.

**4. State the applicable rate and HSN or SAC classification only if sourced this session or supplied by the user.** Otherwise flag it as requiring verification against the current rate notification — misclassification here is a common and material risk, not a detail to guess at.

**5. Check reverse charge applicability** — whether the recipient rather than the supplier is liable to pay tax under the specific category of transaction — and flag current reverse-charge notification coverage as a verification point rather than asserting it from memory.

**6. Assess input tax credit eligibility for the recipient**, noting any specific block that might apply without asserting the current blocked-credit list exhaustively from memory. Flag it for verification.

**7. Check whether the facts trigger a registration obligation**, flagging the current threshold as needing verification — thresholds differ by state and category and have changed over time.

**8. Identify the specific compliance obligations the transaction triggers** — invoicing requirements, e-way bill, e-invoicing — flagging current applicability thresholds for verification rather than assuming them.

## Output

**1. Header.** Supply summarised, parties, date.

**2. Classification.** Goods, services, or composite/mixed, with the reasoning stated.

**3. Place and time of supply.** Determined, with any genuinely borderline point flagged rather than resolved with false confidence.

**4. Rate and classification.** Stated if sourced this session or supplied; otherwise flagged for verification.

**5. Reverse charge.** Applicability assessed, with current notification coverage flagged for verification.

**6. Input tax credit.** Eligibility assessed, with blocked-credit risk flagged.

**7. Registration and compliance obligations.** Triggered obligations listed, with current thresholds flagged for verification.

**8. Points requiring verification.** Current rate notifications, reverse charge notification coverage, registration thresholds, and the blocked-credit list.

## Do not

Do not assert a specific current GST rate or HSN/SAC code from memory. Flag it for verification.

Do not assume a standard registration threshold without flagging it as needing current verification — thresholds vary by state and category.

Do not assert the current reverse charge or blocked-credit list exhaustively from memory.

Do not resolve a genuinely borderline place-of-supply question with false confidence. Flag it.

Referenced files: 1

View saved version →

---
name: tax-appeal-grounds-drafter
description: Drafts grounds of appeal against an already-passed tax assessment or order — each ground tied to a specific part of the order, factual and legal grounds kept distinct, and procedural grounds such as limitation or natural justice raised prominently. Use this whenever a user wants to appeal a tax order — including phrasings like "draft grounds of appeal against this assessment order", "we want to challenge this GST demand order", "prepare an appeal against this disallowance", "draft the grounds for the tribunal", or "challenge this order for lack of a hearing". India-specific. Distinct from tax-assessment-reply-drafter, which responds before an order is passed — this challenges one that already has been. Fires for any appeal against an income tax, GST, or other tax assessment or order, at any appellate forum.
---

# Tax Appeal Grounds Drafter

## What this does

Drafts the grounds of appeal against a tax assessment or order that has already been passed — the formal statement of why the order is wrong, ground by ground, for filing before the appellate authority. Each ground is tied to a specific part of the order being challenged, factual grounds are kept distinct from legal grounds, and any procedural defect capable of disposing of the whole order is raised prominently rather than buried among the merits grounds.

## Before you start

**The order being appealed.** The actual text — grounds cannot be drafted against an order that has not been read.

**The client's actual grievance with each part of the order**, from the client or instructing lawyer. This skill structures and argues the grievance; it does not invent one.

**The appellate forum and the specific appeal being filed.** Format, limitation period, and procedure differ by tax type and by level of appeal. Ask; do not assume.

Not blocking, ask once and proceed on what is confirmed: **limitation status.** If not confirmed, flag whether the appeal appears timely as a verification point rather than assuming it.

## Method

**1. Read the whole order once before drafting a single ground.** Understand the officer's or authority's complete reasoning first — grounds drafted issue by issue on a first pass routinely misstate what the order actually held, because a conclusion on one point is often built on reasoning stated under a different heading.

**2. List every distinct issue, addition, or disallowance in the order that the client wants to challenge, before drafting any single ground.**

**3. For each issue, state the ground precisely** — what the order held, and why it is wrong, tied to the specific part of the order rather than a generic assertion that could apply to any order of this type.

**4. Keep factual grounds and legal grounds distinct.** A ground that the officer got the facts wrong or ignored evidence submitted is argued differently from a ground that the wrong provision was applied or a binding precedent was disregarded — mixing the two muddies both.

**5. Do not cite a specific statutory provision, circular, or precedent as supporting a ground unless it is sourced this session or supplied by the user.** Where a ground would benefit from an authority that is not currently available, flag that rather than inventing one.

**6. Check for procedural grounds separately** — limitation, jurisdiction, natural justice or absence of a proper hearing, non-service of notice. These are threshold grounds capable of disposing of the whole order, and belong in their own place, raised prominently, not folded into the merits grounds.

**7. State the specific relief sought for each ground** — deletion of an addition, remand, or quashing — tied to what follows from that particular ground being accepted.

**8. Order the grounds logically**, procedural and jurisdictional grounds first, then substantive grounds in the sequence the issues appear in the order under appeal.

**9. Flag limitation as a verification point if not confirmed, and flag the appellate forum's specific filing format and requirements as needing verification** — these are forum-specific and change with procedural rules.

## Output

**1. Header.** Forum, the order being appealed (reference and date), appellant, date of the order, date of this appeal.

**2. Grounds of appeal.** Numbered, each tied to a specific part of the order, factual or legal basis stated, citing authority only where sourced or supplied.

**3. Relief sought.** Stated per ground.

**4. Procedural grounds, if any.** Stated distinctly and prominently, ahead of the merits grounds.

**5. Limitation.** Stated, flagged for verification if not confirmed.

**6. Points requiring verification.** Forum-specific filing and format requirements, and any authority needed for a ground but not currently sourced.

## Do not

Do not cite a statutory provision, circular, or judgment that is not sourced this session or supplied by the user.

Do not draft a generic ground that is not tied to the specific part of the order being challenged.

Do not assume the appeal is within limitation without flagging it as a verification point.

Do not conflate factual and legal grounds. Keep them distinct.

Do not omit a procedural ground the client wants raised, and do not bury it among the merits grounds.

Referenced files: 1

View saved version →

---
name: tax-assessment-reply-drafter
description: Drafts a reply to a tax assessment or scrutiny notice — before any order has been passed — addressing every query raised, referencing the client's actual supporting documents, and flagging the response deadline and any procedural defect in the notice itself. Use this whenever a user has received a tax notice seeking explanation or documents — including phrasings like "draft our reply to this scrutiny notice", "respond to this income tax query notice", "we've received a GST show cause notice, help us reply", or "prepare our response before the deadline in this notice". India-specific. Distinct from tax-appeal-grounds-drafter, which challenges an order that has already been passed — this responds while the proceeding is still open. Fires for any pre-order tax notice, income tax or GST, seeking explanation, documents, or a response.
---

# Tax Assessment Reply Drafter

## What this does

Drafts a reply to a tax assessment or scrutiny notice issued before any order has been passed — addressing every query the notice raises, referencing the client's own supporting documents, and keeping a factual, cooperative tone appropriate to a fact-gathering stage rather than an adversarial one. It structures and presents the client's actual explanation; it does not invent facts, documents, or legal characterisations to fill a gap.

## Before you start

**The notice itself.** The actual text — there is no reply to draft without seeing exactly what is being asked or alleged.

**The client's actual explanation and supporting facts**, from the client. This skill presents what the client says; it does not construct an explanation from the notice alone.

**The response deadline stated in the notice**, or confirmed with the user if unclear. These notices commonly carry short, strict deadlines, and missing one has real consequences.

Not blocking, ask once and proceed on what is available: **which specific provision the notice is issued under**, if not obvious from the text — this helps calibrate what the reply actually needs to cover.

## Method

**1. Read the whole notice once before drafting anything.** A global point — the notice period is too short, or a query lacks the particularity the law requires — can apply across several queries at once, and drafting query by query on a first pass misses this.

**2. List every query or point raised in the notice, numbered, before drafting any response.**

**3. For each query, state the client's explanation precisely, using only what the client has actually provided.** Do not invent a supporting fact or document to make a response feel more complete.

**4. Reference the specific documents being submitted in support of each response**, and flag any document referred to but not yet available.

**5. Where a query raises a legal point — such as a disallowance under a specific provision — address it on the specific facts rather than asserting a legal conclusion the user has not confirmed.** Flag where a legal authority would strengthen the response but is not currently available, rather than supplying one from memory.

**6. Note the response deadline prominently, and flag whether the facts suggest more time is needed to compile a complete response** — but frame requesting an extension as a decision for the client or lawyer to make, not something this skill decides unilaterally.

**7. Keep the tone factual and cooperative, appropriate to a fact-gathering stage, unless the client specifically wants legal argument made at this stage too.** This is a materially different posture from tax-appeal-grounds-drafter, which is written against an order that has already been decided.

**8. Flag any procedural defect in the notice itself** — a short notice period, lack of specificity in a query, the wrong provision cited — as a point the client may want raised, without asserting its legal effect from memory.

## Output

**1. Header.** Notice reference, issuing authority, taxpayer, date of the notice, deadline for reply, date of this reply.

**2. Response to each query.** Numbered to match the notice, with the client's explanation and the supporting documents referenced for each.

**3. Documents enclosed or referred to but not yet available.**

**4. Procedural points, if any.** Flagged, not resolved.

**5. Points requiring verification.** Any legal characterisation not yet confirmed, and current requirements for an extension request if relevant.

## Do not

Do not invent facts, explanations, or documents the client has not actually provided.

Do not assert a legal conclusion the client or lawyer has not confirmed, especially the interpretation of a specific provision.

Do not miss the deadline stated in the notice without flagging it prominently.

Do not adopt an adversarial tone at the fact-gathering stage unless the client specifically wants that. This reply is cooperative and factual by default.

Do not omit a query raised in the notice without flagging the risk of leaving it unaddressed.

Referenced files: 1

View saved version →

---
name: tax-opinion-drafter
description: Drafts a formal written tax opinion — question, facts, analysis, conclusion — and, distinctly from a general legal opinion, states the risk profile of the position taken, not just its legal conclusion. Use this whenever a user wants a reasoned written position on a tax question — including phrasings like "write a tax opinion on whether this deduction is available", "what's our position on this structuring, with the risk stated", "prepare an opinion on the withholding treatment of this payment", or "I need a written tax position we can rely on, with the risk graded". Jurisdiction-neutral — never assumes which tax law applies. Shares its rigor with legal-opinion-drafter but adds the risk-characterisation step specific to tax positions. Fires for any formal tax opinion request, in any jurisdiction.
---

# Tax Opinion Drafter

## What this does

Drafts a formal written tax opinion: the precise question, the facts it rests on, issue-by-issue analysis, and a conclusion — with the addition that tax opinions carry a second dimension a general legal opinion does not always need: a stated risk characterisation of the position itself, separate from the substantive confidence in the legal analysis. A tax position can be legally well-reasoned and still carry a real risk of challenge; this skill states both.

## Before you start

**The precise tax question.** Which tax, which transaction or item, which period, and whose liability. A vague brief such as "is this deductible" is not precise enough — deductible by whom, against what income, in which year. Work with the user to state the question precisely before drafting anything.

**The facts relied on.** Supplied by the client or instructing lawyer, with confirmed and assumed facts distinguished.

**Governing tax law and jurisdiction.** Never assume one. Ask, unless the user has stated it. This determines the mode: *document-based*, analysing only the facts and their internal coherence, with every point resting on the law itself left open in the limitations section; or *law-based*, where research tools or authorities are available and the user wants conclusions resting on current, retrieved, or supplied sources, cited specifically. Never state a specific rate, provision, or threshold from memory in either mode.

Not blocking, ask once and proceed on a reasonable default without it: **the standard the opinion is written to** — an internal risk assessment, or a formal opinion meant to support a filing position or be relied on by a lender or auditor. The latter carries more formal convention and higher stakes.

## Method

**1. Restate the question precisely**, confirming it with the user if the brief is vague, before drafting anything.

**2. State the facts relied on separately from the analysis**, with confirmed and assumed facts distinguished.

**3. Work through the analysis issue by issue, citing only authorities sourced this session or supplied by the user.** Never state a specific provision, rate, or threshold from memory.

**4. Address the tax authority's likely position or the genuine counter-argument on each issue**, not only the reading that favours the client.

**5. State the conclusion with two things, not one: a substantive confidence level** (certain, likely, arguable, unclear — the same scale used in a general legal opinion) **and a risk characterisation of the position itself.** Do not invent a formal risk-standard label — such as asserting that a "more likely than not" or "reasonable basis" standard applies — unless the user has confirmed that is the actual standard used in the applicable jurisdiction. Where no such formal standard has been confirmed, describe the risk in plain qualitative terms and flag which formal standard, if any, governs as a verification point.

**6. State any penalty or interest exposure the position could carry if successfully challenged, only where the facts or sourced law actually support a stated figure or mechanism.** Do not invent a penalty rate or exposure figure.

**7. State assumptions and limitations explicitly, including the date the law is stated as of.** Tax law and rates change frequently, and an opinion's shelf life matters more here than in most other legal opinions — never omit this date.

**8. Flag any disclosure or reportable-position obligation the position might trigger as a verification point**, rather than asserting whether disclosure is required.

## Output

**1. Header.** Addressee, the question presented, governing tax law and jurisdiction, the period involved, date, and the date the law is stated as of.

**2. Facts relied on.** Confirmed and assumed facts distinguished.

**3. Analysis.** Issue by issue, the tax authority's likely position addressed, citations only where sourced or supplied.

**4. Conclusion.** Both the substantive confidence level and the risk characterisation of the position, stated plainly and separately.

**5. Exposure if challenged.** Penalty or interest exposure, only where supported by sourced law or supplied facts.

**6. Assumptions and limitations.** Including the date the law is stated as of.

**7. Points requiring verification.** Specific rates, provisions, or thresholds not sourced this session, and any disclosure obligation question.

## Do not

Do not state a specific tax rate, provision, or threshold from memory.

Do not invent a formal risk-standard label unless the user has confirmed it is the standard actually used in the applicable jurisdiction.

Do not omit the risk characterisation. A tax opinion that states only a legal conclusion without addressing the position's risk is incomplete for this skill's purpose.

Do not invent a penalty or interest exposure figure that is not supported by sourced law or supplied facts.

Do not omit the date the law is stated as of.

Referenced files: 1

View saved version →

---
name: transfer-pricing-documenter
description: Documents an intercompany transaction for transfer pricing purposes — functional analysis (functions, assets, risks), method selection reasoned from that analysis, and a benchmarking record built only from comparables actually supplied — flagging jurisdiction-specific documentation thresholds and method hierarchy rules for verification. Use this whenever a user needs a related-party transaction documented or benchmarked — including phrasings like "document this intercompany service arrangement for transfer pricing", "which method fits this royalty arrangement", "build the FAR analysis for this distribution structure", or "check whether this margin falls within an arm's length range on these comparables". Jurisdiction-neutral — never assumes a specific transfer pricing regime applies. Fires for any related-party or intercompany transaction requiring transfer pricing documentation, in any jurisdiction.
---

# Transfer Pricing Documenter

## What this does

Documents an intercompany transaction for transfer pricing purposes: a functional analysis of what each party does, owns, and risks; a transfer pricing method selected and reasoned from that analysis; and a benchmarking record testing the actual result against comparables. It organises the analysis and documents it in the form a transfer pricing file requires; it does not itself source external comparable-company data, and it does not assume a specific jurisdiction's method hierarchy, threshold, or safe harbour without that being confirmed.

## Before you start

**The intercompany transaction facts.** The related parties and their relationship, the nature of the transaction — sale of goods, services, royalty, financing, or another category — and the pricing or terms actually used.

**The governing transfer pricing framework and jurisdiction.** Ask; do not assume OECD Guidelines apply wholesale or that any specific jurisdiction's rules govern without confirming. Documentation requirements, method hierarchy, and safe harbours are law-specific even where the underlying structure is similar across regimes.

Not blocking, ask once and proceed on what is supplied: **whether comparable or benchmarking data is already available**, or needs to be sourced separately. This skill documents and organises the analysis; it works from comparables the user supplies or that are sourced this session, not from invented benchmarks.

## Method

**1. Confirm the related-party relationship and why it triggers transfer pricing rules** — the ownership or control basis for treating the parties as related. State it precisely as given; do not assume a specific ownership percentage threshold applies without flagging that the threshold is jurisdiction-specific.

**2. Conduct the functional analysis** — the functions performed, the assets employed (including intangibles), and the risks assumed by each party to the transaction — based only on the facts supplied, flagging any gap where the functional profile is not yet clear rather than filling it with an assumption.

**3. Characterise each party's role based on the functional analysis** — for instance, a limited-risk distributor against a full-fledged manufacturer — as a description that follows from the facts given, not as a conclusion asserted without that support.

**4. Select the transfer pricing method that best fits the transaction and the functional profile**, and explain why. Do not assert a specific jurisdiction's documented method hierarchy or preference from memory; flag it for verification if the choice depends on one.

**5. Document the benchmarking analysis using only comparables the user has supplied or that were sourced this session.** Do not invent a comparable company or a benchmark range to complete the analysis.

**6. State the tested party and the profit level indicator used**, tied to the method selected in step 4.

**7. Compare the actual result against the benchmark range** and state whether it falls within an arm's length range on the facts and comparables actually given — not on an assumed or typical range.

**8. Flag documentation and filing requirements as jurisdiction- and value-specific**, requiring verification rather than assumption — whether a formal transfer pricing study, local file, or master file is required depends on both the governing law and the transaction value.

**9. Note any safe harbour or simplified-documentation provision only if sourced or supplied**; otherwise flag its potential availability as a verification point rather than asserting it applies.

## Output

**1. Header.** Related parties and their relationship, transaction type, governing framework and jurisdiction, period, date.

**2. Functional analysis.** A table of functions, assets, and risks by party.

**3. Characterisation.** Each party's role, tied to the functional analysis.

**4. Method selection.** The method chosen, with reasoning tied to the functional profile.

**5. Benchmarking analysis.** Comparables used (as supplied or sourced), tested party, profit level indicator, and the resulting range.

**6. Arm's length conclusion.** Whether the actual result falls within range, on the facts and comparables given.

**7. Documentation and filing requirements.** Flagged for jurisdiction- and value-specific verification.

**8. Points requiring verification.** Method hierarchy or preference rules, documentation thresholds, and safe harbour availability.

## Do not

Do not invent a comparable company or a benchmark range that was not supplied or sourced.

Do not assume a specific jurisdiction's method hierarchy or documentation threshold without flagging it for verification.

Do not assume an ownership or control threshold that triggers related-party status without confirming it is appropriate to the governing law.

Do not characterise a party's functional role beyond what the facts of the functional analysis actually support.

Do not assert that a specific safe harbour applies without it being sourced or supplied.

Referenced files: 1

View saved version →

---
name: treaty-analyst
description: Analyses treaty entitlement and relief on given facts — treaty residency, the applicable income article, beneficial ownership and limitation-of-benefits conditions, and the relief potentially available — flagging every substantive term for verification against the actual treaty text rather than assuming a generic model convention applies. Use this whenever a user needs the double tax treaty position on a cross-border payment or transaction — including phrasings like "are we entitled to treaty relief on this royalty payment", "what's the withholding position under this DTAA", "check our treaty residency here", "does this payment qualify for the reduced treaty rate", or "walk through the limitation of benefits test on these facts". Jurisdiction-neutral — never assumes which two countries' treaty applies or what it says. Fires for any cross-border payment or transaction where treaty relief is in question.
---

# Treaty Analyst

## What this does

Analyses whether a taxpayer is entitled to relief under an applicable double tax treaty on given facts: treaty residency, the income article that applies to the type of income involved, beneficial ownership and any limitation-of-benefits or principal purpose test the treaty carries, and the relief potentially available. Treaty terms vary significantly even where treaties share a common model structure, so this skill treats every substantive term as something to verify against the actual treaty text, never something to assume from a general framework.

## Before you start

**The facts.** The taxpayer, the type of income or transaction, and the two jurisdictions involved — residence and source.

**Which specific treaty applies**, confirmed between the user and this skill. Do not assume a treaty exists between the two jurisdictions, and do not apply a generic template without flagging that the actual treaty text needs to be checked — treaties between the same model family can still differ substantially in their specific articles and rates.

Not blocking, ask once and proceed on what is available: **whether the specific treaty text is available this session**, as a research source or supplied by the user. If it is not, work from the general structure of a typical double tax treaty — a residency article, income-specific articles, a limitation-of-benefits or anti-abuse provision, a mutual agreement procedure — explicitly flagged as a general framework requiring verification, since specific rates and conditions cannot be assumed from a typical structure.

## Method

**1. Identify the two jurisdictions and confirm which treaty governs.** Do not proceed as if a treaty's terms are known without either sourcing the actual text this session or having it supplied by the user.

**2. Determine treaty residency.** Work out which jurisdiction's residency test the taxpayer satisfies. If dual residency is possible on the facts, work through the tie-breaker structure — permanent home, centre of vital interests, habitual abode, nationality, mutual agreement — as a general framework, flagged for verification against the actual treaty's specific tie-breaker article, since not every treaty applies these in the same order or with the same content.

**3. Identify the income article that would typically apply to the type of income involved** — business profits, dividends, interest, royalties, capital gains, or personal services — stating the article structure that would ordinarily be relevant, flagged for verification against the actual treaty, since not every treaty includes every article or defines its terms identically.

**4. Check treaty entitlement conditions beyond residency.** A beneficial ownership requirement commonly attaches to passive income articles, and many treaties now carry a limitation-of-benefits clause or a principal purpose test. Flag these as requiring verification against the specific treaty text and its current interpretation — anti-abuse provisions have been the subject of significant recent change across many treaty networks and should never be assumed static.

**5. State the relief potentially available** — exemption, a reduced withholding rate, or a credit mechanism — without asserting a specific rate from memory. Flag the applicable article's actual rate as requiring verification against the treaty text.

**6. Note the domestic procedural requirements for claiming treaty relief** — such as a tax residency certificate or a specific form — as jurisdiction-specific and requiring verification, since these sit outside the treaty text itself and vary independently of it.

**7. Flag interaction with domestic general anti-avoidance rules, where relevant on the facts, as a verification point rather than a resolved conclusion.**

## Output

**1. Header.** Taxpayer, income type, the two jurisdictions involved, the treaty being analysed, date.

**2. Residency analysis.** Treaty residency determined, with the tie-breaker analysis if dual residency is possible, flagged for verification against the actual treaty article.

**3. Applicable article.** The income article structure that would typically apply, flagged for verification against the actual treaty text.

**4. Entitlement conditions.** Beneficial ownership and limitation-of-benefits or principal purpose test considerations, flagged for verification.

**5. Relief available.** The exemption, reduced-rate, or credit mechanism described, with the specific rate flagged for verification.

**6. Procedural requirements.** Domestic requirements for claiming relief, flagged for jurisdiction-specific verification.

**7. Points requiring verification.** The actual treaty text and its specific articles, current anti-abuse interpretation, and domestic procedural requirements.

## Do not

Do not assume a treaty's specific terms from a generic model structure. Flag every substantive term for verification against the actual treaty text.

Do not state a specific withholding rate or relief mechanism from memory.

Do not assume the taxpayer satisfies beneficial ownership or passes a limitation-of-benefits or principal purpose test without analysing the facts against the framework and flagging the specific test for verification.

Do not assume a treaty exists between the two jurisdictions without confirming it.

Do not omit the tie-breaker analysis where the facts suggest potential dual residency.

Referenced files: 1