The Place-of-Supply Question a SKU Cannot Answer
The same item can attract a different treatment depending on where it goes, so a tax rate on an invoice line is a record of a decision, not a conclusion. What a line records, what a determination requires, and why NoxOrigin has no place-of-supply engine.
You sell a carton. On Monday it goes to a customer in Maharashtra and on Tuesday an identical carton goes to a customer in Karnataka. Same SKU, same price on your list, same rate printed on the invoice line, and possibly a completely different correct answer. The SKU did not change. The rate still is not, on its own, the whole answer.
This is the failure mode that is not a bug and never will be. It is not a missing feature that a vendor could add next quarter. It is a structural limit on what any system that stores a tax rate on an invoice line can know, and pretending otherwise is how a business ends up believing its billing software has an opinion about a question that requires a human determination.
So this article does something slightly unusual: it takes the limitation seriously instead of listing features around it. It explains what a place-of-supply determination actually requires, what a line item genuinely records, what your records must make possible so that the determination is possible later, and where the software's responsibility ends.
And it says the uncomfortable part up front. NoxOrigin has no place-of-supply engine, and it is not going to grow one, because the thing a place-of-supply engine would need to be is a rule engine over statutory treatment, which is a different category of software. NoxOrigin does not file GST returns, does not generate or submit returns, is not a tax authority, and is not certified.
Why the SKU cannot answer the question
A SKU describes what the thing is. A place-of-supply determination describes where the thing is going, who the recipient is, and what the applicable treatment is in that specific case. Those are different questions, and the second one has more inputs than a product master will ever hold.
The inputs that routinely decide the answer include the destination state or country, the nature of the recipient, whether the recipient holds a registration, whether the supply is made to a place of business or to a different place, whether the movement of goods and the movement of the invoice are the same journey, whether anything is included in the invoice value beyond the price, and whether the supply falls under a specific notification. That last one alone is enough to defeat a product master field, because a notification can change independently of your catalogue.
Two further inputs make it worse at the counter. The first is that the determination is per line, and a single invoice can carry lines that answer differently. The second is that a document can be issued before the determination is settled, because the goods are already moving and the customer wants the invoice now. A system that insists on resolving everything before printing will not be used, and a system that silently picks an answer and prints it will be trusted far more than it deserves.
What an invoice line genuinely records
An invoice line records four things that are within its competence: the item, the quantity, the taxable value, and the rate your team applied. The fourth of those is a record of a decision, not the decision's justification. That distinction is the whole article.
A rate printed on a line means: on this date, this person, on this document, applied this rate to this taxable value. It does not mean: this rate is correct. It does not mean: this rate was arrived at by a rule the system applied. It means: a human made a call, and the document records it.
That is not a weakness. A record that says a human decided is far more useful than a record that says a machine decided, because the first one can be examined. The moment a rate stops being a record of a decision and starts being presented as a conclusion, the record stops being evidence and becomes an assertion that nobody can check.
Illustrative: what an invoice line records versus what a place-of-supply determination requires
| What the line records | What the determination needs | |
|---|---|---|
| Destination | Nothing on the line itself; at most a customer record address | The place of supply for this specific supply, which is not always the customer address |
| Recipient | A customer name and, if it was on the record, a tax identity | The recipient's registration status and nature, which affect the treatment and are not derivable from a name |
| Rate | The rate applied on the date, by a named person | A conclusion from the applicable rules, the supply's facts, and any current notification |
| Goods movement | Not recorded on the line | Where the goods physically went, which may differ from where the invoice went |
| Conclusion | None, and should not be implied | Made by a qualified person, with the inputs that produced it, and revised if the inputs change |
A worked example, constructed so you can check the arithmetic
Every figure in this section is a constructed example. There is no real customer, no real shipment, and no real compliance rate behind it. The 18% rate appears here, and only here in this article, for a single reason: so that each total can be verified by hand. It is a prop for arithmetic, not a claim about any slab, threshold, or classification, and the treatment of any of these supplies is a question for your chartered accountant.
Take one SKU with a taxable value of Rs 10,000 per unit. At 18% the tax on a unit is Rs 1,800, which you can check as 10,000 multiplied by 0.18, and the line total is Rs 11,800. Now suppose a week in which the same SKU is invoiced 40 units to customers in one state, 12 units to customers in a second state, and 4 units to a third.
Tax recorded on the whole week is 1,800 multiplied by 56. Do it in stages so the multiplication is checkable: 1,800 multiplied by 50 is 90,000, and 1,800 multiplied by 6 is 10,800, so 90,000 plus 10,800 is Rs 1,00,800.
The share attached to the 12 units going to the second state is 1,800 multiplied by 12, which is Rs 21,600. Check it as 1,800 multiplied by 10, which is 18,000, plus 1,800 multiplied by 2, which is 3,600, so 18,000 plus 3,600 is 21,600.
If the treatment of any of those 12 units differs from the treatment of the other 44, then Rs 21,600 of recorded tax is attached to a question rather than to an answer. The system cannot identify those 12 by asking the SKU, because the SKU was identical in all 56 cases. The only thing that can distinguish them is data the line does not currently hold.
The obvious next number is 21,600 divided by 1,00,800, and this article again declines to print it. A ratio of that kind invites the reader to treat a constructed arithmetic relationship as a statement about how often this happens, and about what it costs. Neither follows from the arithmetic. What the arithmetic does say is simple and sufficient: a specific, countable quantity of tax in your records is attached to a determination that has not been made, and the only way to find it is a query over the lines, not a recollection.
What the underlying records have to make possible
The system cannot make the determination, but it can make the determination possible later. That is a lower bar and a real one, and most systems fail it in a surprisingly basic way: they discard the inputs at the point of printing.
A record that has thrown away the destination cannot support a retrospective question about a destination. That sounds obvious written down, and it is nonetheless the single most common reason a quarter-end tax query takes a week instead of five minutes. The inputs have to survive the printing of the document, attached to the line rather than to a memory of the shipping note, and they have to be exportable without re-keying.
What your records should let you extract, per invoice line, without re-keying
- The item, quantity, taxable value, and the rate applied, as three separate values rather than one lumped amount.
- The rate as applied on that date, so a later question about a rate is answerable without guessing what the rate was.
- The person who applied the rate, because a question about a determination is a question about a judgement.
- The destination recorded against the line, where your operation already knows it, even if the system makes no use of it for tax.
- The customer record version in force on the invoice date, so the identity on the line is traceable to a dated record.
- The credit notes and returns that relate to the line, so a partial reversal can be read without reconstructing it.
- The day and shift the line was raised, because a determination question very often arrives as a range of dates rather than a single document.
Three cases where you should stop and ask, rather than trust the line
Illustrative: situations where the rate on the line is a decision someone has to make
The same SKU, two destinations
Where the same item goes to different places, the treatment may differ. The system will show you the same rate on both lines. That is a record of what was applied, not a finding.
The recipient's status changed
Where a recipient's registration status or nature is in question for a given supply, the applicable treatment is a determination. The rate field cannot know the recipient's status on the supply date.
A rate on the line that nobody can explain
Where nobody on the team can say why a rate was applied to a particular line, that line is an assertion. The honest response is to ask your chartered accountant, not to accept the field as evidence.
The software that does this, and the software that does not
There is a category of product that resolves statutory treatment automatically: a rule engine over notifications, exemptions, and supply classifications, usually coupled with return preparation, e-invoicing submission, and e-way bill generation. That is a real category and NoxOrigin is not in it. It has no place-of-supply engine, no reverse-charge handling, no e-invoicing submission, no e-way bill generation, no TDS or TCS recording, and no return preparation of any kind.
Nox-Billings is a counter and operations system. It records sales, prices, tax rates as applied, invoices, credit notes, payments, and the day-end picture of a trading business. It links stock to billing so that a sale and a stock movement are the same event. It produces the structured exports an accountant needs to do the work that belongs to them.
The two categories are not competitors and should not be evaluated against each other on a feature checklist. What matters is knowing which question you are asking. If the question is which rate applies to this supply, that is a determination, and it belongs to a chartered accountant or to a treatment engine you have deliberately chosen to buy. If the question is what we sold, to whom, at what taxable value, at which rate, on which date, and who applied it, that is a record, and the system is exactly the right tool.
Our article on what a billing engine actually is goes into the rules layer behind invoices in more depth, and the comparison between billing software and accounting software is useful if you are still working out which side of this boundary you are shopping for. Both are written to keep the same line in place: software records, a qualified person determines.
The one-line version. A SKU cannot answer a place-of-supply question because the answer depends on the supply, not the item. A rate on an invoice line is a dated record of a decision made by a named person, not a conclusion. NoxOrigin records the rate, the value, the date, the destination where it is known, and the customer record version in force. Whether the rate is right is a determination for your chartered accountant, and NoxOrigin has no place-of-supply engine, no reverse-charge handling, and no statutory return preparation of any kind.
Frequently asked questions
Does NoxOrigin have a place-of-supply engine?
No. It has no place-of-supply engine, no reverse-charge handling, and no statutory treatment logic of any kind. A rate on an invoice line is a record of the rate that was applied on that date by that person, and the system does not claim it is a conclusion about the supply.
Then how do I know the rate on an invoice is right?
You do not get that from the system, and you should be suspicious of any product that suggests otherwise. The system records the rate applied, the taxable value, the date, the person, and the destination where your operation knows it. Whether the rate is correct for the supply is a determination, and that question belongs to your chartered accountant.
What does the system need to hold so the question can be answered later?
The inputs to the question, attached to the line rather than discarded at printing: the rate applied on the date, the taxable value, the person who applied it, the destination where known, the customer record version in force, and any credit notes relating to the line. All of that should be exportable without re-keying so an accountant can work from it.
Is a different category of software better at this?
There is a category of product that resolves statutory treatment automatically, usually bundled with return preparation, e-invoicing submission, and e-way bill generation. That is a legitimate purchase if you need it, and it is not NoxOrigin. NoxOrigin is a counter and operations system that records the transaction cleanly so a qualified person can determine the treatment.
If the same SKU is sold to two different states, does the system let me set different rates?
The system records whatever rate is applied on each line, so the two lines can carry different rates, and each line's value, rate, date, and author are stored separately. What it does not do is tell you which of the two rates is correct, because that is a place-of-supply determination and not a property of the item.