More than $200 million has gone into AI-native ERPs in the last two years. The products that money built are, by most accounts, good. They close books faster, they answer questions in plain language, they automate work that used to consume a team.
Almost all of it was spent building for a country where tax is something you report at the end of the period.
India does not work that way, and the gap between those two facts is not a list of missing features. It is a different architecture. This piece is about what that difference actually is, because if you are evaluating an AI ERP this year, it is the thing most likely to be invisible in the demo and expensive after the signature.
Everywhere else, tax is what you report. Here, it is what you ask permission for.
Consider what an invoice is in most of the world. You raise it. It exists. It is a legal document from the moment you issue it, and at some later point you will summarise a lot of invoices into a return and send that to the tax authority, who will read it.
Now consider what an invoice is here.
You raise it, and it is not yet a valid tax invoice. It becomes one when a government server accepts it and returns an Invoice Reference Number. Until that IRN comes back, you are holding a document with no legal standing. Your customer cannot claim input tax credit against it. If the invoice is more than thirty days old and still unreported, it cannot be reported at all, and the credit is simply gone.
The same is true of physical movement. Goods do not move on your authority. They move on an e-Way Bill, generated against that IRN, validated against the same infrastructure, and if that infrastructure says no, a loaded truck sits in your yard.
This is the difference, stated plainly. In most markets the tax authority is an audience. It reads what you send it. In India the tax authority is a dependency. It is inside the transaction, in real time, and it can refuse.
An ERP built on the first assumption treats statutory data as a reporting concern. It is populated late, validated at filing, and stored for the auditor. An ERP built on the second has to treat statutory validation as a precondition of the transaction existing at all. Those are not the same system with different field labels. They fail in different places, they retry differently, and one of them has no concept of a rejection that stops a business process in its tracks.
Your tax position is not decided by your books
Here is the second structural difference, and it is the one that most surprises finance leaders arriving from other markets.
In a conventional accounting model, your input tax position is a function of what you did. You bought things, you have the invoices, you claim the credit. Your books are the source of truth about your own tax.
Under GST, they are not. Your input tax credit is determined by GSTR-2B, a statement the government assembles from what your suppliers filed. If a vendor in another state filed late, filed wrong, or did not file, the credit you were entitled to does not appear, regardless of how perfectly you kept your own records.
Sit with the implication. Your tax outcome is downstream of other companies’ internal discipline. A careless supplier is not a procurement inconvenience, it is a direct financial loss, and you will typically discover it during a reconciliation weeks after the money has already gone out the door.
That makes vendor filing behaviour a live financial exposure that has to be monitored continuously. Almost every ERP in existence, AI-native or otherwise, models a vendor as a static master record: a name, a bank account, a tax identifier captured once at onboarding. That model is adequate in a market where a vendor’s tax behaviour is their own problem. It is inadequate here, because here it is your problem, and a snapshot taken eighteen months ago tells you nothing about whether it is a problem today.
An ERP that is serious about India has to treat the vendor master as a monitored object rather than a stored record. That is a data architecture decision, not a feature.
Compliance attaches to the line, not to the period
The third difference is granularity, and it is the one that quietly defeats bolt-on tax modules.
TDS does not attach to your month. It attaches to the line. The section that applies, the rate, the threshold, whether the deduction is due at invoice or at payment, all of it is a property of the individual transaction and of the counterparty’s status at that moment. Section 195 on a foreign vendor behaves differently again. The MSME rules under 43Bh mean the payment due date for a supplier depends on their Udyam classification, and paying them late does not just annoy them, it changes your allowable deduction.
The HSN code on a line item is validated by the GSTN at filing, and a wrong one turns into an auto-populated mismatch in your GSTR-1. The place of supply on a line determines whether you charge IGST or CGST plus SGST, and getting it wrong produces a return that reconciles to the correct total while being wrong in every way that matters.
None of this can be computed at period end from summarised data, because by then the information required to compute it correctly has been aggregated away. It has to be resolved at the moment the line is created, which means the tax engine cannot be a module that reads from the ledger. It has to be part of how the ledger writes.
This is an architecture problem, not a localisation problem
The instinct of a global platform arriving here is to localise. Add a tax module. Build the GST reports. Map the fields. Appoint an implementation partner who knows the local rules.
It is worth being fair about this: for some companies, some of the time, that is genuinely enough. If your transaction volume is modest and your structure is simple, a competent partner and a bolted-on tax layer will get you through the year. Pretending otherwise would be dishonest.
But it does not scale, and the reason is structural rather than a matter of effort. You cannot bolt real-time validation onto a system whose core assumes tax is an end-of-period output, for the same reason you cannot make a batch process interactive by running it more frequently. The failure modes are in the wrong place. There is no retry logic, because the original system had nothing to retry against. There is no workflow for a rejection, because in the market it was designed for, nothing ever rejects you.
If you want the evidence rather than the argument, the tax authority has already provided it.
The GSTN scheduled a change to the e-invoice and e-Way Bill APIs, making Ship-to GSTIN mandatory. It was set to go live on 15 June this year. It was deferred to 1 August, and the reason the GSTN gave was the readiness of the APIs and the ERPs.
Read that again. A country of 1.4 billion people moved a compliance deadline because the enterprise software could not keep up. Not because taxpayers did not understand the rule. Because the ERPs were not ready.
That is the clearest possible statement of the gap, and no vendor said it.
What an ERP built here does differently
If you accept that framing, a handful of design decisions stop being optional.
The statutory identifier has to be a key, not a label. A GSTIN is not decoration on a vendor record. It has to be verified, matched against a state code, checked against a PIN, and re-checked over time, because the government is going to check exactly that and reject you when it disagrees.
The system has to have an opinion about being told no. A rejected IRN at six in the evening on a dispatch day is not an error message. It is an operational event that needs a retry path, a hold decision, a person who is told, and a record of what was decided. That is workflow, and it has to exist before you need it.
Reconciliation has to be continuous, because 2B is continuous. Discovering on the nineteenth that a vendor never filed is not a process. It is a hope with a deadline attached.
The statutory interface has to be tracked as a living dependency. When an advisory lands in June saying that a field becomes mandatory in August, that is a release note for a system you are integrated with, and it needs to reach the people who own the integration rather than sitting in a tax newsletter.
Where the AI actually belongs
One more thing, because it is the part the category most often gets backwards.
The intelligence does not go in the ledger. It goes on top of it.
An ERP whose numbers are produced by a language model is not an ERP, it is a very confident guess. Every figure in your books has to be pulled from the ledger by deterministic code, computed the same way every time, reproducible for an auditor who asks in three years. That is not a limitation on the AI. It is the precondition for anyone being allowed to use it.
What the intelligence is for is the work around those numbers: reading the invoice, catching the duplicate, matching the three documents, spotting that a vendor’s filing has gone irregular, preparing the return, noticing that a deadline is approaching and that nothing has been done about it. That work is enormous, it is where finance teams actually spend their days, and it is a genuinely good target for a machine.
The numbers stay deterministic. The work gets done by agents. A person still approves anything that moves money.
How OneFinOps fits in
OneFinOps is an AI-native ERP built in India, for Indian statutory reality, from the ledger up.
That means the tax engine is not a module reading from the books, it is part of how the books are written. It means e-invoicing and e-Way Bills are transaction primitives with rejection handling attached, rather than an export you run afterwards. It means the vendor master is monitored against GSTIN, PAN, MSME, Udyam and MCA continuously, because your input tax credit depends on it. It means GSTR-2B reconciliation runs against the ledger rather than against a spreadsheet exported from it.
And it means that when the Ship-to GSTIN field became mandatory on 1 August, we were not scrambling, because being ready for that class of change is the entire reason the product exists.
Eight digital workers run on that ledger, covering payables, receivables, procurement, accounting and close, GST, e-invoicing, reconciliation and the office of the CFO. They do the work. Every figure they touch comes from deterministic code. Every action they take is logged, attributable and reversible, and anything that moves money waits for a person.
The takeaway
If you are evaluating an AI-native ERP this year, the demo will be impressive. They all are. The category has real money and real engineering behind it, and the products are good at what they were built for.
The question that separates them is narrower than the demo suggests. Ask what happens when the IRN comes back rejected on a dispatch evening. Ask how the system knows that a vendor stopped filing four months ago. Ask what changed in the e-invoice API this year and how they found out.
The answers will tell you which country the software was built for. That matters more than anything on the feature list, because you are not going to be filing in that country. You are going to be filing here.
OneFinOps is an AI-native ERP built for India: one ledger, eight digital workers, and a tax engine that is part of the books rather than a report about them. See how it works.
Tags
- ERP
- GST
- E-Invoicing
- GSTR-2B
- TDS
- CFO