Bill From ≠ Ship From: How Multi-Warehouse Brands Stop Losing Quick-Commerce POs to GSTIN Mismatches
Blinkit and Zepto raise purchase orders against a specific state GSTIN. If your stock happens to sit in a warehouse registered under a different GSTIN, most brands short-ship the PO and eat the fill-rate damage. They don't have to. GST's Bill From – Dispatch From structure lets you invoice from the GSTIN the PO demands while the goods leave from whichever warehouse actually has the stock — provided your billing software gets the invoice, the e-way bill, and the tax treatment exactly right.
⚡ Key Takeaways
- Quick-commerce POs are raised against one of your state GSTINs. A PO on the Karnataka registration cannot be invoiced from your Haryana registration.
- GST supports Bill From – Dispatch From: the e-way bill carries the invoicing GSTIN under Bill From and the actual warehouse address under Dispatch From, and the e-invoice schema has a dispatch-details block for exactly this case.
- IGST vs CGST/SGST is decided by the Bill From and Bill To states — not by the route the truck takes.
- When the dispatching warehouse belongs to a different GSTIN of your own company, a stock-transfer invoice papers the inter-GSTIN leg — but the goods make one journey on one e-way bill.
- Done right, any PO can be served from any warehouse — no short-shipping, no panic stock transfers, no duplicated safety stock in every GSTIN state.
Short Answer
The invoice and the truck don't have to start from the same place. GST's documentation was built for this: the e-way bill's FROM section takes a Bill From GSTIN and a separate Dispatch From address, the e-invoice (IRN) payload takes dispatch details distinct from seller details, and the tax type follows the billing axis, not the physical one.
So when Blinkit raises a PO on your Karnataka GSTIN and your stock is sitting in Haryana, you can invoice from Karnataka, dispatch from Haryana, and deliver the PO in full — instead of short-shipping and taking the fill-rate hit. The catch is operational: the invoice series, the e-way bill fields, the tax split, and the inter-GSTIN paper trail all have to be right on every single order. That's a software problem, and it's the one this post walks through.
Why a Quick-Commerce PO Is Pinned to a State GSTIN
A Blinkit or Zepto purchase order is not raised on your brand. It's raised on one of your GST registrations. GST registration is per state, so a brand with warehouses in Haryana, Maharashtra, and Karnataka is — for invoicing purposes — three sellers, each with its own GSTIN, its own invoice series, and its own tax identity. When a quick-commerce platform onboards you as a vendor for a city, the buying entity on their side is also a state-registered entity, and the PO they cut names your GSTIN for that state as the supplier.
This is not pedantry on the platform's side. Their GRN, their input tax credit, and their books all key off the supplier GSTIN on the PO. Invoice from a different GSTIN and you have a document that doesn't match the PO — which at best bounces at the gate and at worst gets received, mismatched at reconciliation, and disputed at payment.
So the constraint every multi-warehouse brand runs into is this: the PO tells you which GSTIN must raise the invoice, but it says nothing about which warehouse has the stock. On a good day the two line up. On a bad day — a demand spike in Bengaluru, a delayed production run, a batch stuck in QC — the PO lands on your Karnataka GSTIN while the sellable inventory sits in Gurugram. What you do next decides whether the week's fill rate survives.
The Three Bad Options Brands Default To
Talk to the ops team at any brand selling into quick commerce from multiple warehouses and you'll find some mix of three coping strategies. Each one costs real money.
1. Short-ship the PO
Invoice whatever the local warehouse has, cut the rest with an "Out of Stock" reason, and hope next week's PO is kinder. The immediate cost is the sales loss — short-shipped units valued at the PO rate. The compounding cost is worse: platforms track vendor fill rate closely, and sustained short-shipping invites fill-rate penalties, shrinking POs, and eventually delisting from that dark-store cluster. Once a platform's system learns you can't fill, it stops asking.
2. Fire an emergency stock transfer
Move the stock from Gurugram to the Bengaluru warehouse first, then invoice locally. Compliant, but now you're running a two-leg movement: a branch-transfer invoice and e-way bill for the inter-state leg, receiving and putaway at the destination, then a fresh picklist, invoice, and e-way bill for the delivery leg — days of lead time and double handling against a PO that carries an appointment date and an expiry date. A transfer that lands after the PO expires converts a fill-rate problem into a dead-stock problem in the wrong city.
3. Duplicate safety stock in every state
The structural fix most brands land on: hold a full safety buffer of every fast SKU in every GSTIN state you sell from. But safety stock scales with the number of nodes — every additional warehouse is another buffer of the same SKUs, another pool of working capital sitting still, another set of batches ageing toward expiry in a market that might not need them. For food and beverage brands, duplicated buffers don't just cost capital; they generate write-offs.
All three options treat the GSTIN-warehouse mismatch as a physical problem. It isn't. It's a documentation problem — and GST already ships the solution.
The Mechanism: Bill From – Dispatch From on the E-Way Bill and E-Invoice
The e-way bill was designed around the fact that the entity raising the invoice and the premises the goods leave from are often different. Part A of the e-way bill splits its FROM section into two parts: Bill From — the GSTIN and trade name of the registration raising the invoice — and Dispatch From — the address the goods physically depart from. The TO section mirrors it: Bill To (the buyer's GSTIN) and Ship To (where the goods actually land — a dark store, a feeder warehouse, a distribution centre). Four fields, two axes: a billing axis and a physical axis, deliberately decoupled.
The e-invoice system matches this. The IRN payload has a dispatch-details block, separate from seller details, that is filled only when the dispatch address differs from the seller's registered address — the schema's own way of saying "this is a Bill From – Dispatch From transaction." So the compliant documents for shipping from a different premises aren't a workaround; they're first-class fields on both the invoice registration and the transport document.
Two consequences follow, and they're the ones that surprise operators the first time:
- The tax type follows the billing axis, not the truck. Per the NIC e-way bill guidance, when the Bill From state differs from the dispatch state, tax components are entered as per the Bill From state relative to the Bill To state: inter-state on the billing axis means IGST, intra-state means CGST plus SGST — irrespective of where the goods physically moved from. A Karnataka GSTIN billing a Karnataka buyer charges CGST+SGST even when the carton starts its journey in Haryana.
- The e-way bill follows the physical axis. Distance — and with it, EWB validity — is computed from the actual dispatch PIN code to the delivery PIN code. And CBIC has clarified for bill-to/ship-to movements that one physical journey needs exactly one e-way bill, generated by either party to the transaction, not one per invoice.
One honest complication remains. If the dispatching warehouse operates under a different GSTIN of your own company, GST treats that registration as a distinct person (Section 25 of the CGST Act), and Schedule I makes supplies between distinct persons taxable even without consideration. So the Haryana registration doesn't just quietly hand goods to the Karnataka registration — there's a documentary stock-transfer supply between the two, with its own tax invoice, IGST, and input tax credit flowing to the receiving registration. Valuation follows Rule 28, under which the invoice value is deemed to be the open market value where the recipient can take full ITC. The net cash cost of this leg is typically neutral because the credit offsets the tax, but the sequencing and valuation deserve a one-time sign-off from your CA before you make it a standard operating motion. Describe your exact structure to them; don't improvise it order by order.
A Worked Example: PO on Karnataka, Stock in Haryana
Say Blinkit raises a PO on your Karnataka GSTIN for its Bengaluru dark stores. The SKU is stocked out in your Bengaluru warehouse, but your Gurugram warehouse — registered under your Haryana GSTIN — has plenty. Serving the PO in full looks like this:
Blinkit PO ingested against your Karnataka GSTIN. The buyer entity is Blinkit's Karnataka registration; the ship-to is a Bengaluru dark store or feeder warehouse. Nothing about the PO cares where your stock is.
Stock allocated from the Gurugram warehouse — the physical node with inventory — while the order remains attached to the Karnataka billing entity.
Raised from the Karnataka GSTIN, on the Karnataka invoice series. Bill From and Bill To are both Karnataka, so the tax is CGST + SGST — even though the goods will travel Haryana to Karnataka. The IRN payload carries the Gurugram warehouse in its dispatch-details block.
A back-to-back stock-transfer tax invoice from the Haryana GSTIN to the Karnataka GSTIN papers the inter-registration supply (IGST; ITC to the Karnataka registration; Rule 28 valuation).
Bill From: Karnataka GSTIN. Dispatch From: Gurugram warehouse address. Bill To: Blinkit's Karnataka GSTIN. Ship To: the Bengaluru dark store. Distance and validity computed from the Gurugram PIN to the Bengaluru PIN — a multi-day validity window that needs watching.
The dark store receives against the original PO and the Karnataka invoice. Fill rate: 100%. The platform never needed to know which warehouse the truck left from.
Compare that to an emergency transfer: the same truck journey plus a receiving-and-reshipping cycle at the Bengaluru warehouse that the PO's appointment window probably can't absorb. Bill-from/ship-from is the same physics with less lag — the goods move once, directly to the buyer.
Serving Q-Commerce POs From Multiple Warehouses?
Book a 30-minute demo and watch a PO get invoiced on one GSTIN, dispatched from another state's warehouse, and closed at 100% fill — invoice, IRN, and e-way bill included.
What the Billing Software Must Get Right
The GST mechanics are settled; the failure mode is execution. A single mismatched field turns a clean movement into a detention risk or a GRN dispute. Here's the checklist:
The invoice: right GSTIN, right series
The customer invoice must be raised from the GSTIN the PO names, on that GSTIN's own invoice series for the financial year — not the dispatching warehouse's series. This is exactly backwards from the default in most billing systems, which key the invoice profile off the ship-from warehouse. If your software can't decouple "who bills" from "who ships," bill-from/ship-from is dead on arrival.
The e-invoice: dispatch details that tell the truth
The IRN payload must carry the actual warehouse in the dispatch-details block whenever it differs from the seller's registered address. Registering the invoice with the seller address as the implied dispatch point, then trucking from somewhere else, creates a document-versus-reality gap that an intercepting officer can read off the schema.
The e-way bill: four parties, real distance, live validity
Bill From and Dispatch From filled distinctly; Bill To and Ship To filled distinctly; transporter, vehicle number, and documents attached; and — critically — distance computed from the dispatch PIN code, because that drives validity. A Gurugram-to-Bengaluru movement runs on a multi-day validity clock, and an EWB that expires mid-route is a detention risk on a truck carrying a time-boxed PO. You need validity countdowns you can see, not a portal login someone checks on Fridays.
The tax split: billing axis, always
IGST versus CGST/SGST must be computed from the Bill From and Bill To state codes, never from the warehouse route. Software that infers tax type from the dispatching warehouse's state will charge IGST on what is legally an intra-state supply — a wrong invoice the platform's reconciliation will bounce.
Inventory and GRN: physical truth, commercial truth
Stock must decrement at the warehouse that actually shipped — batch, rack, and FIFO order intact — while the GRN and the fill-rate math stay attached to the original PO and the billing GSTIN. The platform GRNs against the PO it raised; your system has to reconcile that GRN even though the goods came from a node the PO never mentioned. If those two truths live in different spreadsheets, month-end reconciliation becomes archaeology.
How FilFlo Runs Bill-From/Ship-From
FilFlo was built for brands selling into quick commerce from multi-warehouse, multi-GSTIN footprints, so this flow is native rather than configured.
It starts with master data. Every GSTIN runs as an invoicing profile — legal name, address, state code, signature, and its own invoice series per financial year — and every channel delivery location maps to the correct GST-registered buyer entity, so "which GSTIN bills this PO" is answered by data, not by whoever is on shift. POs arrive through channel ingestion (Blinkit ASN, CSV parsers for Zepto and Swiggy Instamart), already attached to the right buyer entity, and inventory is visible across every warehouse node — batch, rack, and expiry included — so ops can see in one screen that the Karnataka PO is coverable from Haryana stock.
At invoicing, FilFlo raises the invoice from the GSTIN the PO demands, on that profile's series, and generates the IRN through its Whitebooks IRP integration as part of the order flow — with dispatch details reflecting the warehouse that's actually shipping. On dispatch, the e-way bill carries distinct Bill From and Dispatch From details, distance computed from the dispatch pincode via FilFlo's internal pincode directory, with the transporter and vehicle details recorded at dispatch flowing straight in. The E-Way Bills screen then tracks every active bill with a live validity countdown and one-click NIC reconciliation — which matters more here, because cross-country dispatch legs run longer validity windows than local ones.
Downstream, the GRN is entered against the original PO and the delta feeds the Fill-Rate Funnel — Ordered → Approved → Fulfilled → GRN Received, with per-stage loss attribution — and the Sales Loss report, which values every short-shipped unit at the PO rate. That report is where this capability proves itself: the "Out of Stock" losses that used to appear whenever a PO landed on the wrong state simply stop appearing, because the stock was never out — it was elsewhere.
This is the operating pattern brands like Jimmy's Cocktails run on FilFlo — state warehouses under separate GST registrations, quick-commerce and modern-trade POs each pinned to a specific registered entity, and delivery-location-to-entity mapping doing the routing work that used to live in someone's head. Across its customers, FilFlo's combination of multi-warehouse visibility and PO-level fulfilment discipline has reduced stockouts by 87% and freed 28% of working capital — the second number being exactly the duplicated-safety-stock problem that bill-from/ship-from attacks: when any warehouse can serve any PO, you stop needing a full buffer in every state.
Frequently Asked Questions
Can I invoice from one state's GSTIN while shipping from a warehouse in another state?
Yes. GST explicitly supports the 'Bill From – Dispatch From' structure. The e-way bill's FROM section has two parts — Bill From (the GSTIN raising the invoice) and Dispatch From (the address the goods physically leave from) — and the e-invoice (IRN) schema has a dispatch-details block filled only when the dispatch address differs from the seller's address. One caveat: if the dispatching warehouse sits under a different GSTIN of your own company, that registration is a distinct person under GST, so the inter-GSTIN leg needs its own stock-transfer tax invoice. Have a CA confirm the documentation sequencing for your structure.
Is it IGST or CGST/SGST when goods ship from a different state than the invoicing GSTIN?
Tax type on the customer invoice is decided by the Bill From state versus the Bill To state — not by the truck's route. Per the NIC e-way bill guidance, when the Bill From state differs from the dispatch state, tax components are entered as per the Bill From state: if billing is inter-state (Bill From and Bill To in different states) it is IGST; if intra-state, CGST plus SGST — irrespective of whether the goods physically moved within or across state lines. So a Karnataka GSTIN billing a Karnataka buyer charges CGST+SGST even if the goods dispatch from Haryana.
How does the e-way bill handle a dispatch address different from the registered address?
Part A of the e-way bill carries a Dispatch From address distinct from the Bill From GSTIN. You enter the invoicing registration's GSTIN and trade name under Bill From, and the actual warehouse address under Dispatch From. Distance — and therefore e-way bill validity — is computed from the actual dispatch PIN code to the delivery PIN code. Only one e-way bill is required for one physical movement, a point CBIC has clarified for bill-to/ship-to scenarios: either party can generate it, but the goods travel on a single EWB.
What happens between my own two GSTINs when one bills the customer and the other's warehouse ships the goods?
Under Section 25 of the CGST Act, each state registration of the same PAN is a distinct person, and Schedule I treats supplies between distinct persons as taxable even without consideration. So there is a documentary stock-transfer supply from the Haryana registration to the Karnataka registration — its own tax invoice, IGST charged, input tax credit to the receiving registration, valuation per Rule 28 (invoice value deemed open market value where the recipient gets full ITC). The physical goods still make one journey on one e-way bill. The valuation and sequencing details are worth a one-time sign-off from your CA.
How does FilFlo handle bill-from/ship-from for quick-commerce POs?
FilFlo runs one invoicing profile per GSTIN — legal name, address, state code, and invoice series per financial year — and maps every channel delivery location to the correct GST-registered buyer entity. At invoicing, FilFlo selects the GSTIN the PO was raised against, pulls the next number in that profile's series, and generates the IRN through its Whitebooks IRP integration with dispatch details reflecting the actual warehouse. On dispatch, the e-way bill carries distinct Bill From and Dispatch From details, with distance computed from the dispatch pincode. The GRN still reconciles against the original PO, and the Fill-Rate Funnel and Sales Loss report show the loss you stopped taking.
Stop Short-Shipping POs Your Other Warehouse Could Fill
See how FilFlo serves any quick-commerce PO from any warehouse — right GSTIN on the invoice, right dispatch address on the e-way bill, right tax split, and a fill-rate funnel that shows the loss you stopped taking.