What ERPNext looks like when one retail sale touches everything

This article is part of our Frappeverse Mumbai 2026 coverage, including all nine keynotes and selected community stories.

A sale at Royal Wiseborn Retailers can begin at a Philippine grocery counter, consume ingredients in a kitchen, trigger local tax rules, update finance and end up in management reporting. At Quest Retail, a sale could fail at the invoice, claim that products on the shelf did not exist and leave finance making inventory adjustments of ₹10 lakh to ₹15 lakh every month.

At Frappeverse Mumbai, three people from Indictrans used those businesses to explain two very different kinds of ERPNext work. Sudhanshu Badole, a senior software developer, and Taranneet Kaur, an implementation engineer, showed how they adapted ERPNext around Royal's operation. Sales director Abhishek Dakhole followed with a 900-hour recovery project that helped Quest Retail trust its existing ERPNext system again.

A checkout is one transaction to the shopper. Inside the business, it is where POS, inventory, manufacturing, compliance, customer policy and accounting have to agree.

One sale crossed three environments

Royal combined a grocery store, restaurant and in-house food production inside one company. Its two locations served more than 100 users, carried more than 13,000 SKUs and processed over 1,200 transactions a day. Inventory moved continuously through purchasing, manufacturing, kitchens, restaurants and retail shelves.

The first problem was keeping one sale consistent across a POS machine, local ERPNext and cloud ERPNext. The team connected the POS to the local system, synchronized that record to the cloud and created a central Sales Invoice.

The mechanism matters because all three environments could previously describe the same checkout differently. The integration gave the business one sales record that inventory, finance and managers could follow.

The kitchen could not wait for the ledger

Food production introduced a less tidy problem. A chef takes ingredients and prepares a meal. The kitchen cannot pause while someone confirms that ERPNext has already booked every unit of consumption.

For this operation, the team implemented controlled negative stock. The sale could proceed even if the stock ledger had not caught up. Nightly reconciliation hooks then created the necessary manufacturing Stock Entries and corrected the negative balance.

This was a project-specific operating decision, not a newly announced standard ERPNext feature. It accepted a temporary ledger state to keep the store moving, then made the correction an explicit and automated part of the workflow.

Compliance belonged inside the same transaction

The checkout also had to satisfy Philippine tax and invoicing requirements. The team added logic for VAT, Expanded Withholding Tax and Bureau of Internal Revenue invoicing.

Customer classification added another layer. Senior citizens and persons with disabilities could receive a 20% discount and VAT exemption, while diplomats and concessionaires followed different tax and third-party rules. Selecting the customer type had to produce the right discount, exemption and invoice without breaking the stock and finance flow around it.

Kaur said the team initially saw four problems: POS, inventory, compliance and customer type. Once the operation was traced end to end, they were four parts of the same sale.

That is a better test of implementation success than go-live alone. The cashier should be able to serve the customer, the stock team should see what moved, finance should receive the right entry and management should be able to rely on the record.

A live ERPNext system had lost the business

Dakhole's second case began after go-live. Quest Retail operated more than 250 stores across more than four countries, worked with 12 brands and employed more than 1,500 people. ERPNext was already running, but staff no longer treated it as the source of truth.

The symptoms appeared in every department. Stores faced billing failures and queues. Products visible on shelves appeared as zero stock in ERPNext, which caused automatic replenishment to create fresh requisitions. Delivery teams could not consistently identify which batch should move first for products with different expiry dates. Payments reached the bank, while finance still spent hours reconciling them manually.

The monthly inventory adjustments reached ₹10 lakh to ₹15 lakh. People responded by creating spreadsheets, WhatsApp groups and manual workarounds. ERPNext had become another application to check rather than the record that ran the business.

The recovery started outside the code

The tempting response would have been to fix each visible failure: patch an invoice, add a field, change a DocType, correct a valuation. The Indictrans team instead treated missing invoices, inventory mismatches and reconciliation work as symptoms.

It traced how inventory moved between stores and warehouses, how finance closed the books and how an order passed through the company. Historical transactions showed how errors entered the system. The team sat with users to compare documented processes with the way work happened, introduced changes carefully, monitored deployments and measured each improvement.

Quest remained part of the recovery throughout. That kept the project focused on the transactions people needed to trust, not a technically neat description of how the business was supposed to work.

Nine hundred hours to make the records believable again

The recovery took 900 consulting hours. The team restored more than 149 missing transactions, recalculated more than 36,000 historical Stock Ledger Entries, synchronized inventory and corrected valuation.

The business began trusting ERPNext again.

Dakhole connected that result back to discovery. Estimates made before an implementation team understands the client's operation create gaps. Those gaps create schedule pressure, shortcuts and a system that may be live without being dependable.

Royal and Quest reached the same conclusion from opposite directions. Royal's implementation succeeded by following one sale through every system and rule it touched. Quest recovered when the team stopped treating each failure as an isolated ticket and reconstructed the business flow behind it. ERPNext worked when the transaction made sense from the counter to the ledger.

Watch the Day 1 Track 2 livestream from the start of the enterprise retail talk