How a 70-franchise beverage brand cut ERP costs ~80% moving off Odoo

At a glance

The Odoo renewal quote is usually what starts this search: you chose open-source ERP, then watched per-user, per-app pricing compound until it cost like a proprietary system. Mr Goli Soda, a beverage brand running 70 franchises and 45 factories, made exactly that jump from Odoo to ERPNext and cut total ERP spend by roughly 80% without giving up multi-company accounting, manufacturing, or inventory control. This is a first-hand account of how they did it, what was genuinely hard, and what the same pattern looks like for a US multi-entity business.

The setup: 70 franchises, 45 factories, and an Odoo bill that scaled the wrong way

Mr Goli Soda is an Indian beverage brand built around a nostalgic product: goli soda, the traditional marble-stoppered drink, sold in returnable glass bottles. The operation is a franchise model at serious scale, 70 franchises and 45 factories across India, where franchisees invest their own capital in local production units and the franchisor supplies the brand, the recipes, the commercial framework, and the operating system that holds it all together.

That operating system was Odoo. To be clear up front: Odoo is capable software. The problem was not quality. It was that the pricing model and the business model pulled in opposite directions. Full disclosure before we go further: Mr Goli Soda is our client, and the implementation described here was delivered by VGTS, ERPNova's parent delivery organization. This is a first-hand account, not a story we found online.

Why per-user, per-module economics punish franchise models

A franchise network is, structurally, a user-count multiplier. Every new franchise adds operators, supervisors, and accounts users who all need system access. Every operational capability, from manufacturing to inventory to accounting to approvals, is another module on the bill. Odoo publishes its pricing openly, which is to Odoo's credit, but the published model is per-user subscription, with the Custom plan required for multi-company, Studio, and external API access. Seventy franchises' worth of users, each needing the multi-company tier, meant the bill grew in lockstep with the thing the business most wanted to grow: the franchise count.

That is the trap for any multi-entity business on per-user pricing. Your license cost scales with expansion itself. Growth becomes a line item. We have written a full comparison at Odoo vs ERPNext, including where Odoo remains the better fit.

Why did they move from Odoo to ERPNext?

Cost structure, primarily. Odoo's per-user and per-module pricing compounded across 70 franchises and 45 factories. ERPNext has no per-user license fee, so costs are hosting and implementation, and the brand cut total ERP spend by roughly 80% while keeping multi-company accounting, manufacturing, and inventory capability.

Three specific pressures drove the decision, and they will sound familiar to anyone running Odoo at scale. ERPNext answered all three: it is GPL-licensed open source with unlimited users, unlimited companies, and zero license fees, so the cost structure is hosting plus implementation and support, none of which scales per head. And because VGTS took over as the implementing partner with direct accountability, support stopped being the bottleneck.

• Per-user cost. Every added franchise user raised the subscription. There was no version of expansion that did not raise the ERP bill proportionally.
• Hosting economics. The hosting arrangement added its own recurring layer on top of licensing.
• Slow partner support. When issues surfaced, resolution cycles through their implementation partner were slower than an operation shipping perishable-adjacent product across India could tolerate.

How do you run 70 franchises in one ERP?

Each franchise is a separate Company in ERPNext with its own books, chart of accounts, and P&L, under one shared instance and item master. Intercompany transactions link franchisor and franchisee entities, and head office gets consolidated visibility. New franchises are onboarded from a templated company setup.

This is the architectural decision everything else rests on. Because each Mr Goli Soda franchise is franchisee-invested, a separate business with its own owner and its own capital at risk, each one is modeled as a separate Company in ERPNext, not a cost center or a warehouse under one entity. Separate books. Separate chart of accounts. Separate P&L the franchisee can stand behind.

ERPNext makes this economically possible in a way per-user-priced systems do not: companies are unlimited and free. One instance hosts all 70-plus entities, shared masters span the network, and head office rolls up visibility across the tree. If you are running multiple legal entities on any ERP, this is the pattern to study, and we go deeper at /solutions/multi-entity. One honesty note that matters for finance readers: ERPNext's consolidated reporting aggregates across companies; intercompany elimination entries are manual journals at close, not an automated engine.

Minimum Guarantee and crate rotation, encoded in the system

Mr Goli Soda's commercial framework includes a Minimum Guarantee model, a defined commitment structure between franchisor and franchisee. The point worth taking away is not the specific commercial terms; it is that the model is encoded in the ERP rather than tracked in side spreadsheets. Franchise commercial logic lives where the transactions live, so compliance with the model is visible in the same system that books the invoices.

Returnable glass bottles create an inventory problem most ERPs never see: the packaging is an asset that cycles. Crates and trays of glass bottles go out full and must come back empty, across 70 franchises. The ERPNext implementation tracks crate and tray rotation, what went out, what came back, what is outstanding where, turning a chronic leakage problem into a reconcilable ledger. It is a good example of why an open-schema system matters: this is not a standard module you tick, it is a workflow built on the platform.

The results

Total ERP spend across licensing, hosting, and support dropped by approximately 80% versus the prior Odoo arrangement. We publish the relative figure only; the absolute numbers are the client's business. The structural reason is simple: the single biggest cost line, per-user licensing, went to zero, and what remained was hosting plus a support relationship. Want to run your own numbers against your current Odoo bill? The ROI calculator takes your user count and modules and does the math ungated.

Onboarding a new franchise, covering entity setup, books, masters, and training, used to take about 60 days. After the move it runs about 35 days, driven by templated company setup in ERPNext. For a franchisor, onboarding time is expansion throughput; cutting it nearly in half changes how fast the network can grow.

Field sales reps across the network run on YoloWorks, a field-sales application that pushes hourly rep KPIs into ERPNext and includes controls like a sales-exit approval gate, where a rep cannot close out a visit without the gate clearing. Plain disclosure: YoloWorks is VGTS's own product. We built it, we sell it, and you should weigh this accordingly. The relevant point for evaluation is integration depth: field activity lands in the same database as inventory and accounting, not in a disconnected CRM.

The MD's own summary of the engagement: "VGTS made Frappe ERP easy to adopt, giving us better control over inventory, production, and operations." Chandru, MD, Mr Goli Soda.

What the migration involved (and what was hard)

Any vendor who tells you an Odoo-to-ERPNext migration is painless is selling you something. None of these friction points changed the outcome; all of them belong in your plan.

• Retraining. Odoo and ERPNext are conceptual cousins but different products. Dozens of franchise teams had to relearn daily transactions, including screens, terminology, and workflows. Budget real training time per role, not a single all-hands demo.
• Report rebuilds. Custom Odoo reports do not convert. Every report the business actually used had to be identified (many were not used), prioritized, and rebuilt in ERPNext. Treat your report inventory as a migration workstream of its own.
• Custom module parity. Customizations built on Odoo's framework had to be re-implemented on Frappe. Some mapped to native ERPNext features; some, like crate rotation, were rebuilt as custom apps. The parity audit, what you have, what is actually used, and what the ERPNext equivalent is, is the most important pre-migration document you will produce.

Is ERPNext actually cheaper than Odoo?

For multi-user, multi-entity deployments, usually yes: ERPNext is GPL-licensed with zero per-user fees, so cost is hosting plus implementation. Odoo's published per-user, per-app pricing grows linearly with headcount. In this case the move cut ERP costs roughly 80%; your delta depends on user count and modules.

The honest nuance: at low user counts, the gap narrows. Odoo's published entry pricing for a handful of users is modest, and ERPNext still carries implementation and hosting costs regardless of size. Our implementations start at $4,000 (published pricing), with support plans starting in the low hundreds of dollars a month. The crossover is user count and entity count: the more of either you have, the more a zero-license model dominates. Seventy franchises is deep on the ERPNext side of that line. Five users in one entity may not be.

Would this work for a US multi-entity business?

The architecture, one instance, one Company per legal entity, unlimited users, and templated entity onboarding, transfers directly, and it is the pattern we implement for US multi-entity clients (/solutions/multi-entity). Two US-specific honesty notes before you extrapolate from an India deployment follow below.

If those constraints are acceptable, and for most $2-20M US groups they are once seen plainly, the Goli Soda pattern is proof the model scales far past what most multi-entity businesses will ever need. Bring your Odoo invoice and your entity list to a free expert audit and we will show you the comparison line by line.

• Consolidation eliminations are manual journals. ERPNext's Consolidated Financial Statement report aggregates balances across companies; intercompany eliminations are journal entries you book as a defined month-end close step. With templates, that is routine for a 2-15 entity group, but it is not an automated elimination engine, and we will not pretend otherwise.
• No turnkey US bank feeds. Bank reconciliation defaults to statement imports (OFX/CSV); live feeds via Plaid are scoped per client as integration work. US payroll also stays with Gusto or ADP, with summaries posted to ERPNext.