Custom ERP for an Indian SMB is one of those phrases that means three different things depending on who is saying it. To a SAP partner it means a heavily configured SAP Business One implementation. To an ERPNext studio it means a Frappe app on top of the open-source core. To a SaaS founder it means buying Zoho One and calling the integration layer "the ERP". To a buyer who has just outgrown Tally, it usually means "something that finally connects the parts of our business that currently live in five spreadsheets and a WhatsApp group".
This guide is for that last buyer. The Indian SMB in the INR 20 to 300 crore revenue band, almost always already running Tally or a small packaged ERP, where one or two workflows have quietly broken under growth and the question on the table is whether to migrate to a bigger packaged product, configure the existing one harder, or build a thin custom layer on top of what is already there.
The honest answer in 2026 is almost always the third, and most of this piece is an argument for why.
What an ERP is actually for at the SMB scale
It is worth being concrete. An ERP at an Indian SMB is doing five jobs, not one.
It is the statutory book of record — every invoice, every payment, every journal entry, every adjustment, audit-ready and reconciled to bank. This is the job Tally was built for and still does at the lower end.
It is the single source of truth for inventory and orders — what is in stock, what is on order from suppliers, what is committed to customers, what is in transit. This is where most SMBs first feel pain as they cross the second warehouse or the third sales channel.
It is the operational system for production or service delivery — work orders, job cards, dispatch, service tickets, project milestones. This is the most workflow-specific layer and the layer most likely to demand custom work.
It is the financial cockpit — multi-entity consolidation, cost-of-goods analysis, margin reporting per SKU or per project, cash flow forecasting. This is what a CFO wants and what no SMB in the early Tally era ever actually got.
It is the integration spine — how the website talks to the books, how the POS talks to the warehouse, how payroll talks to the GL, how the channel partner portal pushes leads into sales. This is the layer that absorbs most of the engineering effort in any real implementation.
Most SMB conversations about ERP collapse these into one and then argue about which product wins. That is not how the decision actually works.
Where packaged ERP earns its place
Three categories of packaged ERP are credible for Indian SMBs in 2026.
The Indian-built open-source layer. ERPNext is the strongest choice in this category and has matured significantly. The product treats GST, TDS, e-invoicing, and e-way bills as first-class concerns rather than third-party afterthoughts. The data model is genuinely extensible — you can add a custom doctype without forking the core — and the implementation cost on the lower end (INR 6 to 15 lakh for a careful single-entity rollout) is several times cheaper than the multinational alternatives. Odoo is the other player here, technically strong but with weaker out-of-the-box Indian compliance.
The SMB tier from the multinationals. SAP Business One, Microsoft Dynamics 365 Business Central, Oracle NetSuite (rare below INR 200 crore in India), Acumatica. These earn their place when there is a real reason to be on that graph — a parent company on the same product, an enterprise customer mandating it, or a complex multi-entity manufacturing footprint where the depth of the product genuinely matters. Implementation costs typically run INR 25 lakh to INR 1.5 crore plus annual licensing, and the implementation partner often matters more than the product itself.
The SaaS suite. Zoho One is the dominant player at the lower SMB end in India. It is not technically an ERP but for many INR 20-60 crore companies the combination of Zoho Books, Zoho Inventory, Zoho CRM, and Zoho People does enough of the job that calling it one is fair. The ceiling is real — Zoho's data model does not gracefully handle complex manufacturing or multi-entity consolidation — but the time-to-value is the best in the market.
If none of the three obviously fits, the answer is usually that the buyer is asking the wrong question. Almost no SMB needs a wholly bespoke ERP. The right question is which packaged core is the best primitive to build a thin custom layer on top of.
When the packaged tool quietly bends under you
This is the part most buyers discover six to eighteen months after the implementation goes live.
Parallel spreadsheets. The first symptom is always the same. The packaged ERP is producing reports, and the operations head is producing a different set of reports from a spreadsheet that lives on a shared drive. The spreadsheet is what gets used in the Monday meeting. The ERP report is what gets shown to the auditor. When the spreadsheet and the ERP diverge by more than 5 percent on any meaningful number, the ERP has stopped being the source of truth.
Structured data stuffed into notes fields. The second symptom is more subtle. Sales is putting project codes into the customer notes field. Production is using the work order description field to encode batch numbers. Finance is putting GST treatment categories into the invoice narration. Every one of these is a workflow asking for a first-class data field that the packaged product does not give it. Each one is a small bend; together they make the data unreportable.
Workaround documentation. When the onboarding document for a new operations executive includes the phrase "and then you have to" more than three times in a single workflow, the workflow is broken. The phrase is a marker for an unsupported case that the team has built a verbal manual around.
Integration tax growing faster than headcount. The bill for middleware tools — Zapier, Make, Pabbly, custom scripts — quietly creeps up every quarter. Each integration was justified individually. Together they become a fragile graph that one person on the team understands.
The annual upgrade dread. When the operations team starts dreading the annual ERP upgrade because of how many of those workarounds will break, the build of accumulated debt has crossed a threshold.
Any one of these signals individually is normal. Three or four of them together is the signal that a thin custom layer earns its cost.
What a thin custom layer actually looks like
The shape we recommend most often for SMBs in this band is unromantic. Keep the packaged ERP as the system of record for statutory books, inventory primitives, payroll, and standard reporting. Build a small focused custom layer for one or two workflows where the differentiation lives.
Three patterns recur.
The production or service delivery cockpit. For manufacturers, distributors, and service businesses, this is where the leverage usually sits. A custom work order screen that knows your specific routing, your specific QC steps, your specific subcontractor handoffs. It reads from the packaged ERP for the master data (customers, SKUs, BoMs) and writes back the cost postings and inventory movements that the books need. Build cost INR 10 to 25 lakh on the first module. This is the kind of work our internal tools service is built around — small focused operational surfaces that own one workflow well.
The multi-entity finance cockpit. For SMBs that have grown into three or four legal entities — most do, eventually — the consolidated view across Tally companies or ERPNext sites is almost never adequate from the packaged product alone. A small custom dashboard that reads from each entity's books and produces a single P&L, balance sheet, and cash flow view with drill-down — including inter-company eliminations — is usually a sub-INR 10 lakh build that pays back in the first board meeting that uses it.
The integration spine. When the integration sprawl described above has crossed the threshold of one-person-understands-it, replacing it with a small focused middleware layer is the right move. Not a full iPaaS, not a homegrown Zapier — a focused service that knows your specific data flows, owns the failure modes, and produces an audit trail. This is the work our process automation service handles, and the most common shape is a 6 to 10 week build at INR 8 to 18 lakh.
In every case the rule is the same: do not replace what the packaged ERP does well. Build only where the packaged data model bends, where the workflow is genuinely differentiated, or where the financial cost of not automating is concretely measurable.
A worked example: a 4-entity Pune manufacturer at INR 90 crore revenue
To make this concrete. A specialty chemicals manufacturer with one production unit in Pune, one in Vadodara, a trading entity in Mumbai for imports, and a service entity for plant maintenance contracts. Tally Prime across all four companies. Total revenue around INR 90 crore. About 90 employees.
The presenting pain points after a discovery week typically look like this. Production scheduling lives in a single operations head's spreadsheet. Inter-company sales between the trading entity and the production entities involve a finance executive doing manual reconciliation every month. Service contract billing is being done in a separate spreadsheet because Tally's recurring billing does not handle the slab-based pricing model. The CFO cannot see consolidated working capital without three days of analyst work.
A wholesale migration to SAP Business One would be quoted at INR 60 to 90 lakh plus INR 12 to 18 lakh per year in licensing, take 9 to 14 months, and replace a Tally that works fine for what it is doing. A wholesale custom ERP is a non-starter.
The honest scope is a thin layer.
Phase 1, 10 to 14 weeks, INR 18 to 26 lakh. A production scheduling cockpit that reads BoM and inventory data from Tally via TallyConnector, owns the schedule, dispatch, and QC workflow, and writes back stock movements and cost postings. A service contract module that handles slab-based recurring billing and produces Tally-compatible invoices. Master data cleanup of the SKU catalogue and customer ledger across the four companies — usually quoted separately at INR 3 to 5 lakh because it is grim, important, and not negotiable.
Phase 2, 6 to 10 weeks after Phase 1 stabilises, INR 8 to 14 lakh. The multi-entity finance cockpit. Reads from all four Tally companies, handles inter-company eliminations, produces consolidated P&L, BS, and cash flow with drill-down to the source entity. Also produces a working capital view (debtor days, creditor days, inventory days) per entity and consolidated.
Phase 3, ongoing, INR 60,000 to INR 90,000 per month retainer. Small enhancement requests, regulator-driven changes (Tally version bumps, GST schema changes), bug fixes against the documented build scope, named-human reachability for finance and operations.
Total year-one outlay around INR 32 to 45 lakh, no licence costs, Tally remains the statutory book of record. By month four the operations head has stopped maintaining the production spreadsheet. By month seven the CFO has the consolidated view at month-end without an analyst. By month twelve the team has lived through one full audit cycle on the new setup.
This is roughly the shape of work we have delivered for finance-heavy and operations-heavy SMBs — the Iyer & Joshi engagement followed a similar architecture for a CA firm's internal cockpit, and the Halverson Chambers build for a multi-partner law firm took a comparable phased approach. The pattern transfers across verticals because the underlying decision is the same: keep the packaged primitives, build the layer that is actually doing the work, write down the seam.
When to actually go fully custom
For completeness. There are SMBs for whom a wholly custom ERP is the right answer. Three situations.
The business is a vertical SaaS in disguise — a service company whose differentiation is genuinely the way they run, and whose growth plan involves productising the operating system itself. In that case the ERP is not overhead, it is part of the product. The economics change.
The business has a multi-entity, multi-currency, multi-jurisdictional structure where the consolidation logic is itself the moat — a holding company structure with international operations, complex revenue recognition, group treasury. At that point the packaged products start losing more than they save, and a custom build with a strong finance partner can earn its cost. Typically these are INR 200 crore plus businesses.
The business has tried two packaged ERPs in five years and abandoned both. This is rarer than it sounds. When it happens, the cause is almost always organisational rather than technical — the implementation kept failing because the buyer kept changing what they wanted. A custom build with a partner who runs proper discovery and writes scope before code can be the right answer here, but only after the underlying organisational issue is named honestly.
In all three cases the project is INR 1 crore plus, runs 9 to 18 months, and needs a partner with both engineering depth and finance domain depth. It is not the typical SMB ERP project.
The buying conversation, in five questions
If you are an Indian SMB owner or CFO sitting with an ERP vendor next week, the conversation that gets you a useful answer is short.
- Which of the five jobs above is actually broken — books, inventory, production, finance cockpit, integration?
- What is the smallest workflow change that would unblock the next 18 months?
- Of our existing tools, what is genuinely working and not worth replacing?
- If we build something custom, what is the named workflow it owns and what is the named workflow it leaves alone?
- Who at our company will own this six months after go-live, and what is the retainer that keeps them able to?
A vendor whose answer to all five is "buy our full suite" is selling a product. A vendor whose answer is "let us do a two-week paid discovery and write the actual scope down" is selling work. The second is what an SMB at this scale almost always needs.
If you are at that stage and want a second read on the shape of the work — what is genuinely custom, what is packaged, what is the budget that lands honestly — start a conversation. We do paid discovery before we propose, and we are happy to tell you that the answer is to configure your existing tool harder if that is what the work says.
Sources we read while writing this — useful if you want the broader category context: ERPNext product docs, GSTN portal for the Indian compliance surface, and MCA guidance on related-party and multi-entity reporting for the consolidation work.