Bill-to-Overseas / Ship-to-India in ERPNext: Getting the GST Classification Right (2026)

We find this misclassification on inherited ERPNext instances, and it was a tracked issue in 2023 (frappe/erpnext#35479). I am Manoj, and I lead ERPNext and Frappe work at MithTech, a team of Frappe specialists in Bengaluru. The code below is from the current India Compliance source (v16).

Try it: is this invoice really an export?

Pick the customer, supply type, and physical destination. The widget names the correct classification and which GST accounts should apply — following the same branching that india_compliance/gst_india/utils/__init__.py uses.

The legal picture: place of supply, not billing address

Is it an export? Export of goods means taking goods out of India to a place outside India (IGST Act s.2(5)). If the goods are delivered in Chennai, they were not exported, so the invoice cannot be zero-rated as an export, whatever the customer master says.

Which state is the place of supply? IGST Act s.10(1)(a) is the general rule: where the movement of goods ends for delivery. Section 10(1)(b) covers bill-to / ship-to: where goods are delivered to a person on the direction of a third person, the third person is deemed to have received them, and the place of supply is the third person's principal place of business. When that third person is overseas, with no place of business in India, how s.10(1)(b) applies is a question to settle with your CA. India Compliance sets the place of supply to the ship-to state, which this post follows.

For services: IGST Act s.13. When the supplier or recipient is outside India, s.13 sets the place of supply: s.13(2) is the general rule, s.13(3) covers services on goods physically made available in India, s.13(5) events, and so on. Export of services also needs every condition in s.2(6), including payment in convertible foreign exchange or in rupees where RBI permits.

Neither section turns on the customer’s billing address. The billing address is master data; the place of supply is a fact about the transaction.

What ERPNext actually does — pinpoint the classification function

Look at india_compliance/gst_india/utils/__init__.py. Two functions carry the whole burden.

get_place_of_supply(party_details, doctype) dispatches on GST Category. For sales, when the customer is Overseas it delegates to a specialised function:

# india_compliance/gst_india/utils/__init__.py (v16.x)
def get_place_of_supply(party_details, doctype):
    if doctype in SALES_DOCTYPES or doctype == "Payment Entry":
        # for exports, Place of Supply is set using GST category in absence of GSTIN
        if party_details.gst_category == "Overseas":
            return get_overseas_place_of_supply(party_details)
        # ... regular POS via GSTIN state / address

get_overseas_place_of_supply(party_details) is where the bill-to / ship-to logic lives. It defaults POS to 96-Other Countries, then — if a Shipping Address is set and its country is India with a valid gst_state_number — overrides POS to the Indian state:

# india_compliance/gst_india/utils/__init__.py (v16.x)
def get_overseas_place_of_supply(party_details):
    """
    As per definition the of Export, material should be shipped to a place outside India.
    Where the material is shipped in India, Place of Supply should be the location where
    the material is shipped to.
    """
    place_of_supply = "96-Other Countries"

    if not party_details.shipping_address_name:
        return place_of_supply

    shipping_address_details = frappe.get_value(
        "Address",
        party_details.shipping_address_name,
        ("country", "gst_state_number", "gst_state"),
        as_dict=True,
    )

    if shipping_address_details.country == "India" and shipping_address_details.gst_state_number:
        place_of_supply = f"{shipping_address_details.gst_state_number}-{shipping_address_details.gst_state}"

    return place_of_supply

Read the guard carefully. Two things must both be true for POS to switch to an Indian state:

1. shipping_address_name must be populated on the Sales Invoice.
2. The Address record must have country = "India" and a non-empty gst_state_number.

If either is missing (no Shipping Address, or an Indian address whose state wasn’t filled), POS stays at 96-Other Countries without a warning and the invoice is treated as an export. That is the trap.

The downstream "is this a foreign transaction?" test in the same file makes the consequence explicit:

def is_foreign_transaction(gst_category, place_of_supply):
    return gst_category == "Overseas" and place_of_supply == "96-Other Countries"

Both conditions must hold. Fix POS to an Indian state and the invoice stops behaving as an export everywhere downstream — GST accounts, GSTR-1 table selection, e-invoice SUPTYP field — because they all funnel through this predicate.

Six real bill-to / ship-to scenarios

Tap through each — the widget shows the exact GST Category, POS, and tax accounts you should set on the Sales Invoice.

The setup that gets it right, field by field

Where the invoice lands in your returns

Once the classification is right, everything downstream falls into place. If it’s wrong, the invoice lands in the wrong return section — which is what your CA sees at filing time.

The line-item breakdown by return section is defined across india_compliance/gst_india/utils/gstr_1/ and gstr3b/. The classification is inherited from the Sales Invoice’s GST Category + POS — not recomputed at filing time. So fixing the classification after the invoice is submitted requires an amendment or a credit note; you cannot just "reclassify" a filed row.

See also: GST on services bought from abroad in ERPNext, the buying side of this: who pays the GST on a foreign vendor's bill, the self-invoice, and where the credit goes.

How do you fix invoices that were classified wrong?

Which path you take depends on whether the invoice is already in a filed return. Agree the route with your CA before you post anything.

Not filed yet, same period: cancel and amend. Open the Sales Invoice, click Amend, fix the GST Category, Shipping Address and POS, and resubmit. The new invoice takes a -1 suffix; the cancelled one stays in the audit trail. If an IRN or e-way bill was generated, they can be cancelled only within 24 hours of generation; after that, the correction goes through a credit note.

Already in a filed return: don't edit the historical invoice in ERPNext. The usual routes are amending the invoice in a later GSTR-1 (Table 9A, within the time the law allows) or a credit note against it with a fresh, correctly classified invoice. Either way the tax that should have been paid is due, with interest. Which route fits, and how it shows in GSTR-3B, is your CA's call.

Automation gate: the lasting fix

Humans forget to set Shipping Address. The gate is a before_save client script that warns whenever Customer country ≠ India but Shipping Address is in India — before the user submits.

// Custom Script → DocType: Sales Invoice
frappe.ui.form.on('Sales Invoice', {
  async before_save(frm) {
    if (!frm.doc.customer) return;

    // Pull the two country fields we need to compare
    const customer_country = await frappe.db.get_value(
      'Address', frm.doc.customer_address, 'country'
    );
    const shipping_country = frm.doc.shipping_address_name
      ? await frappe.db.get_value(
          'Address', frm.doc.shipping_address_name, 'country'
        )
      : { message: { country: null } };

    const bill_c = customer_country.message?.country;
    const ship_c = shipping_country.message?.country;

    // The classic bill-to-overseas / ship-to-India case
    if (bill_c && bill_c !== 'India' && ship_c === 'India') {
      // Confirm GST Category isn't stuck on Overseas + POS 96
      if (
        frm.doc.gst_category === 'Overseas' &&
        (frm.doc.place_of_supply || '').startsWith('96-')
      ) {
        frappe.msgprint({
          title: __('GST classification check'),
          indicator: 'orange',
          message: __(
            'Customer billing country is <b>{0}</b> but Shipping Address is <b>India</b>. ' +
            'This is a domestic supply — Place of Supply should be an Indian state, ' +
            'not 96-Other Countries. Open the Shipping Address and confirm gst_state is set, ' +
            'then trigger a POS recompute before submitting.',
            [bill_c]
          )
        });
      }
    }

    // SEZ sanity — POS must not be 96 for SEZ either
    if (
      frm.doc.gst_category === 'SEZ' &&
      (frm.doc.place_of_supply || '').startsWith('96-')
    ) {
      frappe.throw(__(
        'SEZ supplies are always inter-state IGST — Place of Supply must be an Indian state.'
      ));
    }
  }
});

Run it as a warning (msgprint) for two weeks, watch for false positives, then switch the classification check to frappe.throw once the accounts team has adjusted.

What judgement calls do you need to make?

Two things worth flagging where the source doesn’t answer the question by itself:

• frappe/erpnext#35479 (May 2023) reported that an invoice to an overseas customer with supply in India was treated as an export. The current flow, get_overseas_place_of_supply reading the shipping address country, handles it. On an older install, update India Compliance before relying on this.
• Export of services under s.13 has enough conditions (place of supply, foreign-exchange payment, the distinct-persons rule) that the classifier only flags it as "check with your CA". We don't automate it: the safe default is a taxable domestic supply, and the export treatment is claimed only with evidence.

At a glance

FAQ: what do people ask most?

What should you do next?

The bill-to / ship-to case is a costly classification error and an easy one to prevent. Current India Compliance does the right thing when the Shipping Address is set; the failure is almost always a missing Shipping Address or an Indian address with an empty gst_state.

Fix that habit and add the gate script, and these invoices stop landing in your GSTR-3B as exports.