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

This is one of the most common misclassifications we clean up on inherited ERPNext instances in Bengaluru — and it was a real, tracked bug in v14 (frappe/erpnext#35479). I am Manoj, ERPNext and Frappe implementation lead at MithTech — this post grounds every claim against the current india_compliance source in 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

Two provisions do all the work.

For goods — IGST Act §10(1)(a) and (b). §10(1)(a) is the general rule: place of supply is where the movement of goods terminates for delivery. §10(1)(b) is the bill-to / ship-to override: "where the goods are delivered by the supplier to a recipient or any other person on the direction of a third person… it shall be deemed that the said third person has received the goods and the place of supply of such goods shall be the principal place of business of such third person." Read plainly: if the billing customer directs delivery to a different location, POS = that location.

For services — IGST Act §13. When the supplier or recipient is outside India, §13 sets POS through a cascade — §13(2) general rule, §13(3) services in relation to goods physically performed in India, §13(5) events, and so on. Export of services additionally requires payment in convertible foreign exchange under §2(6) of the IGST Act.

Neither section mentions the customer’s billing address. The billing address is a masterdata property; 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 field wasn’t filled — POS silently stays at 96-Other Countries and the invoice ships 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

GSTR reporting downstream — where the invoice lands

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.

Fixing invoices that were classified wrong

Two paths, and which one you pick depends on whether the invoice has flowed into a filed return yet.

Not filed yet, same period: Cancel and amend. Open the Sales Invoice, hit Amend, fix the GST Category / Shipping Address / POS, and re-submit. The new invoice takes a -1 suffix; the cancelled one shows in your audit trail as Cancelled.

Already in a filed GSTR-3B: Do not touch the historical invoice. Raise a Credit Note against the wrong-classification invoice in the current period, then raise a fresh Sales Invoice with the correct classification. Both will land in the current return; the credit note offsets the earlier overstatement of exports (which was an understatement of taxable supply), and the fresh invoice books the taxable supply where it should have gone.

Automation gate — the permanent 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.'
      ));
    }
  }
});

Deploy it as a warning (msgprint) for two weeks, watch the false-positive rate, then flip the classification failure to frappe.throw once the accounts team has adjusted. Same soft-launch pattern we recommend on every gate.

Judgement calls

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

• The v14 bug in frappe/erpnext#35479 was that ERPNext core (before india_compliance split out into its own app) didn’t always route bill-to-India / ship-to-India cases through the shipping-address override. The current v16 flow — get_overseas_place_of_supply reading shipping_address_name.country — is the fix. If you’re on v13 or v14, upgrade india_compliance before relying on this behaviour.
• Export of services under §13 has enough moving pieces (POS, forex-payment, distinct-persons rule) that the classifier above only flags it as "verify with your CA". We deliberately do not automate the classification because the safe default is a taxable domestic supply — the export benefit is opt-in and evidenced.

FAQ

Closing

The bill-to / ship-to case is one of the highest-impact classification errors we see on inherited ERPNext instances — and one of the easiest to prevent. Current india_compliance does the right thing when the Shipping Address is set correctly; the failure mode is almost always a missing Shipping Address or an Indian address with an empty gst_state.

Fix that one habit, drop the gate script into your instance, and this class of misclassification stops appearing in your GSTR-3B forever.