Operational software built for the Indian market handles three things imported SaaS rarely does well: GST returns, e-way bill APIs, and WhatsApp as the actual operational comms layer. The compliance trifecta.
By Mohammad Jamnagarwala · Simply Five Studio
A founder evaluating ERPs for his distribution business in early 2025 narrowed the list to two products. One was a global SaaS ERP with strong workflow features and a clean interface. The other was a domestic product that looked older but quoted lower. He asked us to weigh in. The question that resolved the comparison was not features. It was three line items that the global product did not handle natively. GSTR reconciliation. E-way bill API integration. WhatsApp as the operational channel.
These three are the Indian operational reality. A piece of software running an Indian mid-market business has to handle all three competently, or it leaks effort somewhere else (the CA's office, the dispatch team, the customer-service queue). Imported SaaS products handle them at best as add-ons, at worst not at all. The domestic products handle GST natively, e-way bills usually, and WhatsApp inconsistently. A custom-built system handles all three because the system is built to fit the country it runs in.
This essay is the compliance trifecta. What each one is, why imported software handles it badly, and what a fitted system looks like.
GST as a statutory obligation is well understood. GSTR-1 (outward supplies). GSTR-3B (summary return and tax payment). GSTR-2B (the auto-generated input-credit statement). The challenge is not the filing. The challenge is the reconciliation between what the firm recorded and what the GSTN's system says the firm should have recorded.
The 2B reconciliation is where most firms quietly lose money. A vendor's invoice does not appear in the firm's 2B because the vendor filed late, or filed wrong, or did not file. The firm cannot claim the input tax credit. The amount, on any individual line, is small. The annual total is consistently in the lakhs for firms above twenty crore in revenue. Recovering it requires chasing vendors, which requires knowing which vendors specifically have which missing entries.
Imported SaaS ERPs treat GST as a localisation module. The module handles the basics. The 2B reconciliation, in the form an Indian firm needs it, is rarely native. The firm ends up exporting the data to a separate reconciliation tool, or to the CA's office, and the round trip loses the operational context that would let the firm pursue the missing entries.
A fitted system holds the GST data alongside the operational data. The vendor record, the purchase invoice, the goods receipt, and the 2B match status all live together. The chasing happens from inside the system. The recovery rate is higher because the friction is lower.
At AKSD, the GST reconciliation flow sits inside the ERP that runs the firm's offline distribution business. The team sees, in one screen, which vendor invoices are in 2B and which are not, and can act on the gaps the same week they appear.
The e-way bill requirement, for inter-state movement above fifty thousand rupees and increasingly for intra-state movement of certain goods, is operational, not statutory in the usual sense. The bill has to be generated before the goods move. If the dispatch team generates it on a separate portal, the data has to be re-entered from the sales invoice, the part number has to match, the HSN code has to be right, and the vehicle number has to be added. Any mismatch is a problem at the checkpoint.
The integration that should exist, and frequently does not in imported software, is direct API connection to the GSTN e-way bill endpoint. The sales invoice produces the e-way bill in one click, with the data already present. The vehicle number is added on dispatch. The bill prints with the dispatch documentation. The process takes thirty seconds instead of five minutes, and the mismatch surface is zero because the data is the same data.
For an industrial firm moving goods across states regularly, the e-way bill integration belongs in the original build, not as a later add-on. The dispatch team generates the bill from inside the ERP, against the sales invoice that produced the dispatch. The dispatch team does not maintain a separate login to the GSTN portal. The integration is invisible until you compare it to the alternative. The ES Haji industrial ERP and similar engagements treat compliance plumbing as part of the operational layer rather than a separate workstream.
The third leg is the one global SaaS products handle worst, because it is the one furthest from how those products were designed. In India, WhatsApp is the operational comms layer. Customers send orders on WhatsApp. Vendors send proformas on WhatsApp. The dispatch team sends acknowledgements on WhatsApp. The salesperson confirms a quote revision on WhatsApp. Treating WhatsApp as a "notification channel" misunderstands the operational reality.
A fitted system uses WhatsApp Cloud API as a structured channel into and out of the operational core. Inbound: the order from a customer on WhatsApp lands as a structured enquiry in the system, attached to the customer record. Outbound: the proforma, the dispatch update, the payment reminder go out as templated messages the customer can act on. Both directions feed the same record. The chat history is searchable from inside the customer view.
The longer treatment of the channel question, including when to use WhatsApp Cloud API directly and when a BSP makes sense, is in the WhatsApp Cloud vs BSP essay. The broader question of when WhatsApp is the right order channel in the first place is in this essay.
What imported SaaS gets wrong is treating WhatsApp as a one-way broadcast tool. The platforms send messages out. The replies do not come back into the operational system. The customer's response sits in a chat window the team has to monitor separately. The data layer is broken.
A fitted system closes the loop. Every WhatsApp interaction with a customer or vendor is part of the same record as the order, the invoice, and the dispatch. The team works from one screen. The founder sees customer-relationship history that spans every channel in one place.
Each of the three (GST, e-way, WhatsApp) is solvable in isolation. The firms that get it right do not treat them as three separate problems. They treat them as a single property of the operational system: the system handles the Indian operational reality end-to-end, without forcing the team to step outside it to complete any of the three.
The pattern produces material time savings, in the range of two to four hours per day across a twenty-person firm, that the team previously spent on context-switching between the ERP, the GSTN portal, the e-way bill portal, and WhatsApp. The pattern also reduces the error surface, because data does not get re-keyed between systems that do not talk to each other.
The work we do under the internal systems practice treats the trifecta as baseline, not as a feature list to negotiate. Indian operational software that does not handle these three competently is, in our view, not Indian operational software. It is software adapted for India, with the friction of the adaptation absorbed by the team.
A founder evaluating any operational software, imported or domestic, can run a three-question diagnostic on the trifecta. Does the system reconcile against GSTR-2B without an export, and can my team chase missing vendor entries from inside it. Does the system generate e-way bills directly against the GSTN API, or does my dispatch team maintain a separate portal login. Does the system treat WhatsApp as a bidirectional channel that feeds the customer record, or as a notification broadcast that disappears after sending.
If any of the three answers is the wrong one, the system is going to leak effort the firm cannot see in the demo. The leak shows up in month three, when the team is doing the workaround daily.
If you are within sixty days of choosing operational software and want a working assessment of how the candidates handle the trifecta, Start a Conversation.
Every Indian B2B founder running customer messaging on WhatsApp eventually asks the same question. The honest answer is technical, not a sales pitch, and it depends on a few specific factors most BSP comparison pages skip.
For a five-to-fifty-crore Indian business running custom software, the hosting choice is overdone. When a 1500-rupee VPS wins. When AWS wins. When Vercel wins.
Seventy percent of AI-in-ERP marketing is window dressing. The thirty percent that pays back lives in unstructured-input parsing, anomaly detection, and drafting outbound responses.
The contact form takes about two minutes. The reply comes from the founder within two working days.
