Executive summary
Every OIDAR obligation starts with one determination: where is the customer located, for tax purposes? Get this wrong in either direction and the consequences compound — undercharging creates liability, overcharging creates friction and disputes. This guide assumes you already know OIDAR applies to your business — if you haven't confirmed that yet, our Complete Guide is the place to start.
- Place of supply for OIDAR is governed by Section 13(12) of the IGST Act — the recipient's location, not the supplier's.
- A customer is deemed to be in India if any two of seven listed indicators point to India and don't contradict each other.
- Major payment processors, including Stripe, have built-in support for collecting OIDAR IGST in India — this is a solved problem at the infrastructure level, not something you need to build from scratch.
- Since 31 December 2024, a CBIC circular requires the recipient's state, not just country, to be recorded on invoices.
- The strength of your evidence trail matters most when something is disputed — not at the point of the transaction itself.
The legal rule: Section 13(12)
The statute doesn't ask where your servers are, where your company is incorporated, or where your team sits. It asks one question: where is the recipient.
This is a deliberately practical rule. India's regulators recognised that a foreign supplier usually cannot verify a customer's physical location the way a domestic supplier could — so the law substitutes a set of observable, largely automatic data points instead of requiring proof of physical presence.
The seven indicators, explained
You need any two that agree. Here is what each one actually means in practice, and where it typically comes from in a modern billing stack.
| # | Indicator | Where this typically comes from |
|---|---|---|
| 1 | Address given over the internet | Billing/shipping address field at checkout |
| 2 | Payment card issuance country | Card BIN (bank identification number) — captured automatically by most payment processors |
| 3 | Billing address | Address associated with the payment method |
| 4 | Device IP address | Server-side request logging at time of transaction |
| 5 | Bank location | Bank identifier from the payment processor |
| 6 | SIM card country code | Relevant for mobile-billed transactions specifically |
| 7 | Fixed landline location | Relevant only where service is delivered via a fixed line — rare for most digital products |
Capturing evidence in practice
Most of the seven indicators are already flowing through your systems somewhere — the practical task is making sure they're captured and retained, not generating them from scratch.
Capture billing address at checkout
A standard field, but worth confirming it's a required field, not optional, and that it's actually stored against the transaction record rather than only used transiently for payment processing.
Log IP address at time of transaction
Server-side, at the moment of purchase — not a general analytics IP that might reflect a different session.
Retain card BIN data from your payment processor
Most processors expose this without requiring you to handle full card details directly.
Capture GSTIN where offered
Not one of the seven place-of-supply indicators directly, but essential for the separate B2B/B2C determination that runs alongside it.
Store all of it against the transaction, not just the two you rely on
If a classification is ever questioned, having the fuller picture — even indicators you didn't strictly need at the time — is what makes the file defensible rather than merely adequate.
What payment gateways already do for you
This is worth knowing plainly: you likely don't need to build this evidence capture from nothing. Major payment infrastructure providers have already solved parts of this.
This doesn't remove your obligation to classify correctly, capture the right evidence, and file GSTR-5A — but it does mean the heaviest technical lifting (calculating the right amount, applying it at checkout) is available off the shelf for many businesses, rather than something to engineer independently.
Edge cases
The straightforward cases rarely cause disputes. These are the ones worth thinking through in advance.
A customer travelling abroad at the moment of purchase
If their billing address and card issuance both point to India, the place of supply is India — the two-indicator test looks at these specific data points, not the customer's physical location at the instant of the transaction. A temporarily-travelling Indian customer doesn't change the outcome.
Indicators that genuinely conflict
An Indian billing address paired with a non-Indian card and non-Indian IP is not a clean two-indicator match — this is exactly the kind of case where the honest answer is "not clearly determined by the standard indicators," and where documenting your reasoning at the time, rather than after the fact, matters most.
VPN usage
A VPN can mask IP address, but rarely changes billing address or card issuance country simultaneously. In practice, this is one of the reasons the rule requires two indicators rather than relying on IP alone.
Corporate cards issued outside the employee's country
Common in multinational teams — an Indian-based employee might hold a card issued by a foreign parent entity. Here, billing address and other indicators become more important than card issuance alone.
Invoicing: the December 2024 rule
A procedural change with real system-design implications.
For a foreign OIDAR provider, this means your billing system needs a state-level field for Indian customers specifically, feeding directly into invoice generation — not just a country-level "India" flag.
Building an audit-ready file
The goal isn't perfection at the point of every transaction — it's being able to explain your reasoning clearly, months or years later, if asked.
- Retain more than the minimum. Storing all available indicators, not just the two you relied on, costs little and adds real defensive depth.
- Keep your classification logic documented, not just the transaction data itself — a written note of how your system decides B2B vs B2C and how it applies the two-indicator test is worth having on file.
- Revisit genuinely mixed cases specifically, rather than assuming your general logic covers every transaction equally well.
- Update your documentation when the rules change — the December 2024 invoicing circular is a good example of a procedural shift that's easy to miss if nobody owns tracking it.
How other countries compare
India's approach sits within a broader, fairly consistent international pattern for taxing cross-border digital services.
| Jurisdiction | Approach |
|---|---|
| European Union | Electronically supplied services taxed under the VAT Directive; reverse charge for B2B cross-border transactions |
| United Kingdom | 20% VAT on digital services, reverse charge for B2B imports |
| Singapore | 9% GST via Overseas Vendor Registration regime; reverse charge for B2B |
| Japan | 10% consumption tax on electronic services; reverse charge for B2B imports; platform taxation regime for designated digital platforms since April 2025 |
The common thread across jurisdictions, India included, is destination-based taxation with a reverse-charge mechanism for B2B transactions — the details of evidence and place-of-supply determination differ, but the underlying structure is broadly consistent internationally.
India's seven-indicator, two-match test is one implementation of a globally familiar principle: tax digital services where they're consumed. If you already handle EU VAT MOSS/OSS or UK VAT for digital services, the underlying logic will feel familiar — the specific evidence requirements are what differ.
Glossary
Want a second opinion on a specific case?
If your evidence is mixed or you're planning a launch into the Indian market, a short conversation can tell you whether it's worth a formal written opinion — no pressure either way.