Nothing Was Sold, Nobody Was Paid, and You Owe a Tax Invoice
Nothing is sold, nobody is paid, and the goods never leave your ownership. Under GST that is still a supply, and it comes with an invoice, a movement document, very likely an invoice reference number, and a quantity of input tax credit that has just changed states.
In most of the markets we write about, moving your own goods between your own warehouses is a logistics event. Somebody loads a truck, somebody else unloads it, and the only question anybody asks afterwards is whether the quantity was right. It is not a transaction. It generates no document that a tax authority will ever look at.
India is different in a way that reshapes what a warehouse network costs to operate, and the difference is easy to state: registrations in two different states are treated as distinct persons, and a supply between distinct persons is taxable even when nobody pays anybody anything.
That single rule turns an internal replenishment into a documented transaction. It is not an exotic edge case — it is what happens every time a distributor tops up a depot across a state line, which for a national business is a routine event happening dozens of times a week and generated entirely by people whose job title contains the word "stores".
This piece is written for operators rather than for tax advisers, and it is a summary rather than advice. The treatment turns on your specific registration structure, and the valuation rules have reliefs that materially change how painful this is. Get your own position from your chartered accountant.
The four things one [pallet](/glossary/pallet) produces
Follow an ordinary movement from a warehouse in one state to a warehouse in another, both belonging to you, both stocked with your goods.
| What is required | Who actually triggers it | What happens if it is late or missing |
|---|---|---|
| A tax invoice | The dispatching location, when the goods leave | A movement with no invoice behind it is a supply you have not documented, and it surfaces during a reconciliation rather than at the time |
| An e-way bill | Whoever arranges the transport, before movement | The consignment is travelling without a valid document — a detention risk at the roadside, not a filing problem next month |
| An invoice reference number | Your systems, if your turnover puts you in scope | Above the higher threshold the portal refuses a document presented too late, and a refused document is not a valid tax invoice at all |
| A credit movement between states | Nobody, which is the problem | Credit accumulates where it cannot be used while cash is paid where it was needed |
The people who trigger all four of these are storekeepers. The people who find out when one of them went wrong are accountants, several weeks later.
Why this is an operations problem rather than a tax one
Here is the part that gets missed, and it is the reason a compliance system on its own does not solve this.
Every one of those four obligations is generated by a physical event: goods left a place. The compliance stack can only act on that event once somebody has told it the event happened. If the dispatch is recorded three days late, everything downstream is three days late, and no amount of portal integration recovers the time.
What a compliance tool does
- Registers the invoice and returns the reference number.
- Generates the movement document from the invoice.
- Files the returns from the documents.
- Reconciles what suppliers reported against what you claimed.
- All of it excellent, and all of it downstream.
What decides whether that works
- Whether the dispatch was recorded on the day it happened.
- Whether the arrival was confirmed or assumed.
- Whether the quantity at the far end matched the quantity on the document.
- Whether anybody noticed when it did not.
- All of it upstream, and none of it in a tax system.
A useful diagnostic: ask how many transfers between states your business made last month. If that number comes from a report, the operational layer is doing its job. If it comes from somebody thinking about it for a moment, every obligation above is being met from memory.
The valuation question, and the relief that makes it survivable
Because a transfer between distinct persons is a supply without a price, something has to be written on the invoice. The rules for supplies between related parties apply — open market value, or the value of like goods, or a cost-based formula — which sounds like a valuation exercise on every pallet.
In practice it usually is not, because of one specific relief: where the receiving unit is entitled to full input tax credit, the value declared on the invoice is generally accepted as the open market value. For an ordinary business whose branches all claim full credit, that means the number you put on the transfer is the number, and the exercise collapses to a consistency question rather than a valuation one.
Where the relief stops helping
Two situations, and both are worth knowing before somebody discovers them for you. First, where the receiving unit cannot claim full credit — because of exempt supplies, or a scheme that restricts it — the value actually matters and the relief does not apply. Second, where transfers across a network are being valued inconsistently, so the same product moves at three different values depending on which branch sent it. Neither is a filing failure. Both distort the cost base every branch prices against, and the second one is entirely self-inflicted.
How credit gets stranded
This is the consequence that costs real money and appears in no operations report anywhere.
When a transfer happens, the sending registration charges tax and the receiving registration claims it. In a balanced network that nets out over time. In an unbalanced one — a manufacturing state that supplies six consuming states, say — the flow runs consistently in one direction, and the receiving registrations accumulate credit faster than their own output tax can absorb it.
-
Stock moves in one direction, consistently
A plant or a central warehouse supplies branches. That is not a mistake, it is the design of most distribution networks, and it means the tax flows in one direction too.
-
The receiving state builds a credit balance
It has more input credit than output tax. The balance sits there. It is real money the business has paid, and it is on the balance sheet as an asset that cannot be converted into anything.
-
The sending state pays cash
Meanwhile the state doing the supplying has output tax to settle and pays it in cash, because its own credit is being consumed. The group is simultaneously overpaid in one place and paying in another.
-
Nobody notices, because nobody owns it
The operations team does not see tax balances. The finance team sees them as a tax position rather than as a consequence of how the network is shaped. It gets raised at year end, described as a working capital issue, and carried forward.
-
And the amount is a function of transfer documentation
Which is the point of this article. Volumes, values and directions of transfer are decided by operations. The credit position is an arithmetic consequence of them.
None of this argues that you should reshape your distribution network for a tax reason — usually you should not, and the logistics case is stronger than the credit case. It argues that somebody should be able to see the number, and that in most businesses nobody can.
The thirty-day clock, and why it is an operational deadline
Two thresholds are routinely confused and they are worth keeping apart. Invoice registration itself applies above one turnover level. The rule that a document must be reported to the portal within thirty days of its date applies at a higher one.
If you are in the second group, a document presented late is not accepted late. It is refused, which means it never becomes a valid tax invoice, which means the supply it described has no document. Recovering from that is considerably more work than raising it on time.
And here is the thing worth noticing: almost nobody misses that window for a tax reason. They miss it because the paperwork on a movement that physically happened five weeks ago was never closed. The site had not confirmed. The receiving branch had not counted. The transfer sat open, and open transfers do not raise invoices.
Five things to check, none of which requires software
- Count last month's interstate transfers from a report rather than from a person. If there is no report, that is the finding.
- Pick four at random and find the documented arrival — the receipt against the dispatch, with the quantity that actually turned up.
- Ask your accountant which state registrations are accumulating credit faster than they can use it.
- Check whether the same product moves at the same declared value regardless of which branch sent it.
- Ask how many invoices last quarter were raised more than a week after the movement they describe. If nobody knows, the thirty-day clock is running on hope.
What AWRA OpsHub does today
- Every warehouse, depot and site store as a distinct stock position
- Transfers that stay open until the receiving location confirms the quantity
- In-transit stock as an owned, dated, visible position
- Blind counts with valued variance, and a full audit trail
- Landed cost allocated to the consignment it belongs to
- Procurement approvals that refuse rather than warn
What it does not do
- Any connection to an invoice registration portal, and no IRN generation
- E-way bill creation, cancellation or vehicle updates
- GST return preparation, GSTR-2B reconciliation or Invoice Management System actions
- Transfer valuation under the related-party rules
- Indian statutory payroll of any kind
What is not built for India today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in India. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an IRP connection, e-way bills, an Indian payroll engine, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
IRP registration, IRNs and e-way bills
Invoice registration against the IRP with the IRN and signed QR returned onto the document, e-way bill generation and cancellation for goods in movement, and the thirty-day reporting clock watched rather than discovered. Read the honest version first: this is the single most crowded build on this list. Tally, Zoho, Busy and a dozen others already do it, at a price we cannot approach, with a chartered accountant who already knows your ledger. We would build it to sit under an operations layer you had already chosen us for, not to win a GST comparison.
UPI, NEFT and bank feeds
UPI collection with automatic settlement against the invoice, NEFT and RTGS payment files, and bank statement feeds wired into the Payments Register so money in and out reconciles without re-keying.
Payroll and statutory returns
Provident fund, ESI, professional tax by state and TDS on salary, computed on live records and produced in the return layouts each body expects. This is a serious statutory build with per-state variation, and it is a genuine reason to keep an Indian payroll provider rather than move payroll to us.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur take
The compliance half of this is well served in India and you almost certainly already have it. The half nobody sells is the operational record underneath — the movement, the arrival, the confirmed quantity — and it is what decides whether the compliance half is working on facts or on reconstructions. If you take one thing from this piece, make it the four-transfers test: pick four interstate movements from last month and look for the documented arrival. It costs an afternoon and it tells you which of the two halves your business is actually short of.
The upstream half
We do not register invoices or generate e-way bills — your existing stack does that better than we would. What we hold is the movement, the arrival and the confirmed quantity that all four obligations are generated from.
Talk to us about IndiaFrequently asked questions
Is every stock transfer between our warehouses taxable?
No — the state line is what matters. Where the two locations sit under separate registrations in different states, they are distinct persons and a movement between them is a supply even without consideration. Where they sit under the same registration in the same state, generally they are not, though a delivery challan is still the right document for the movement. Businesses with multiple registrations within one state, or with an input service distributor in the structure, have a more complicated position. Confirm yours with your chartered accountant rather than with this article.
What value goes on the transfer invoice?
The rules for supplies between distinct persons apply, which in principle means open market value or a prescribed alternative. In practice there is a significant relief: where the receiving unit is eligible for full input tax credit, the value declared on the invoice is generally accepted as the open market value. For most ordinary businesses that turns a valuation exercise into a consistency exercise. It stops applying where the recipient cannot claim full credit, and that is the case worth identifying in advance.
Do we need an e-way bill for our own goods?
The e-way bill requirement attaches to the movement of goods above the threshold value, not to whether a sale occurred, so movements of your own stock are generally included. The details that catch people out are practical rather than conceptual: the validity is calculated from distance rather than chosen, transport details need updating if the vehicle changes mid-route, and an expired document on a travelling consignment is a roadside problem rather than a monthly one. Intrastate thresholds vary by state.
How does credit end up stranded in the wrong state?
Through the ordinary shape of a distribution network. If one state consistently supplies several others, the receiving registrations accumulate more input credit than their output tax can absorb, while the supplying state settles its own liability in cash. The business is simultaneously overpaid in one place and paying in another. It is not a compliance error and nothing goes wrong on any return — it is working capital tied up as a consequence of transfer volumes, directions and values, all of which are operational decisions.
Does AWRA generate the invoice or the e-way bill?
No to both, and we would rather say so early than have it emerge in a demonstration. We have no connection to any invoice registration portal, we do not generate invoice reference numbers, and we do not create, cancel or update e-way bills. India has a deep and inexpensive market for exactly that and you should buy it there. What we build is the operational record the documents are made from: the dispatch, the confirmed arrival, the quantity actually received, and in-transit stock as an owned position rather than a gap.
What is the single most useful thing to check this week?
Take four interstate transfers from last month and look for the documented arrival at the far end — the receipt against the dispatch, with the quantity that genuinely turned up, recorded by the receiving location. Not the stock simply appearing in a count. If three of the four are assumptions rather than records, then every obligation described in this article is being met from memory, and the reason invoices are late has nothing to do with your tax software.
