At a glance
- Industry
- Food and beverage — roasting, retail and café operations
- Integrations
- Posist POS and Shopify, both posting into Inventory and Books
- Footprint
- India and the UAE — two legal entities, two tax regimes, two Zoho data centres
- Zoho products
- Zoho Books Elite (India and Dubai), Zoho Inventory, Zoho Flow and custom functions
- Custom work
- Recipe and composite-item costing automation, wastage capture, maker-checker approval workflows, legacy automations re-analysed and rebuilt, API sync with fallback logic
- Timeline
- India 14 weeks across 8 phases, Dubai 7 weeks across 6 phases, with 45 days of hypercare after each go-live
Stock numbers you don't trust, in more than one country? See what a clean rebuild looks like. Get a free automation audit
The Challenge
Two problems at once. One inherited, one structural.
- The data had drifted past the point of patching. SKUs had grown without a taxonomy, vendors existed under several names, and costing had stopped reflecting reality. Nothing dramatic breaks when this happens. Reports just quietly become wrong, people stop trusting them, and the business goes back to running on spreadsheets and instinct.
- Recipes weren't costed, so COGS was fiction. A roasted bag and a café drink are both composite items — green coffee, packaging, milk, labour, wastage. Without automated recipe costing, nobody can say what a product costs to make, which means menu pricing is guesswork and wastage is invisible.
- Sales lived in the POS and the storefront, not the ledger. Posist ran the outlets and Shopify ran online. Getting either into the accounts meant manual work, and stock levels lagged behind what had actually been sold.
- A second country with entirely different rules. The UAE business needed VAT, its own chart of accounts and its own data centre. India needed GST, TDS and a migration of live books mid-year. Same operating model, two sets of compliance, and a fixed go-live date on each.
What We Built
Two separate builds on the same operating model, on Zoho Books and Inventory. India was a reset of a system already in use. Dubai was a clean build in the UAE data centre. Both ended up with the same way of counting stock, costing a recipe and posting a sale.
A rebuilt foundation, not a patch
- New Zoho Inventory setup with fresh master data — SKU taxonomy rebuilt, vendors normalised, customers cleaned.
- Books data migrated from April 2025 to the cut-over date, with opening balances uploaded and reconciled against the client's own finance sign-off.
- Warehouse structure redesigned to match how stock actually moves, including a returns workflow from outlets back to warehouse and kitchen.
Recipe costing that updates itself
- Recipes and composite items rebuilt with automated cost recalculation, so a change in an input cost flows through to the finished product without anyone rebuilding a spreadsheet.
- Wastage capture built into the production flow, which is the number most F&B businesses estimate and then wonder why their margin doesn't match their books.
- Inventory valuation, COGS and production tracking reporting on top of it.
POS and storefront posting straight into the books
- Posist POS integrated for real-time sales posting and stock updates into Inventory and Books.
- Shopify integrated for catalog, orders, stock updates and sales posting, with reconciliation into the accounts.
- Where the POS API couldn't support true real-time, scheduled syncs and buffer logic were built as fallback rather than pretending the limitation didn't exist.
Controls, because this is money
- Maker-checker controls and approval workflows across procurement, production, inventory and accounting.
- Role-based access aligned to the actual business hierarchy, with governed inventory movement from procurement through to sale.
Two countries, two compliance regimes
- India: chart of accounts, GST and TDS configuration, approval workflows, and financial reporting for compliance.
- Dubai: a fresh Zoho Books Elite org in the UAE data centre with multi-warehouse configuration, VAT setup and compliance reporting.
- Reporting packs for finance and operations on both sides — P&L, balance sheet, inventory valuation, COGS, GST returns and VAT.
The unglamorous part
- Legacy custom functions, webhooks and schedulers from the old setup could not be lifted across. Each one was documented, re-analysed, rebuilt and redeployed in the new environment.
- Training, SOP documentation and on-site consultation sessions with the operations, finance and procurement leads, because a rebuilt system that nobody adopts is a failed project regardless of how it tests.
Results
- Numbers people trust again. Clean master data, reconciled opening balances, and stock that reflects what the outlets actually sold.
- Recipe-level costing. COGS, wastage and production tracking calculated rather than estimated.
- Sales reach the ledger on their own. POS and Shopify both post into Inventory and Books.
- Both countries live on their fixed dates, each with 45 days of hypercare behind it.
- Controls that survive an audit. Maker-checker approvals and role-based access across procurement, production, inventory and accounts.
Why It Worked
We argued for a reset instead of a repair, and that was the right call even though it was the harder sell.
Patching a broken item master feels cheaper. It isn't. When SKUs, vendors and costing are wrong at the root, every report built on them is wrong, and you spend the next year fixing symptoms one at a time while the client slowly stops believing the system. Rebuilding the foundation is unglamorous, it is most of the work, and it is the only version of this project that ends with anyone trusting the numbers.
The second decision was sequencing. Dubai went live first, a month before India. Dubai was the clean build with no legacy and no migration, so it proved the operating model — the recipe structure, the POS integration, the approval flows — on a smaller, simpler footprint before we attempted the messy India cut-over. Doing the hard one first would have put the entire programme at risk of the same problem twice. Keeping each country in its own Zoho data centre is the same pattern behind our India–Canada trading build.
And we told the client up front that the old custom functions and schedulers could not be copied across. They had to be documented, rebuilt and redeployed. That is a conversation nobody enjoys during a proposal, and it is the thing that would otherwise have been discovered in week ten with a fixed deadline approaching. Saying what's out of scope before it bites kept a manufacturer's Books customisation to four weeks too.
Frequently asked questions
Can Zoho Inventory handle recipe or composite-item costing for F&B?
Yes, and with automation so the cost recalculates when an input price changes. For a roastery or kitchen this is the whole ballgame — if the recipe isn't modelled properly, your COGS is an estimate and your menu pricing is built on it.
Can Zoho connect to a restaurant POS like Posist?
It can, through the POS vendor's API, so sales post into Inventory and Books and stock updates in near real time. One caveat worth asking any partner about: POS APIs vary in what they support. Where true real-time isn't available, you build scheduled syncs with buffer logic. A vendor who promises real-time without checking the API hasn't checked the API.
We run India and Dubai. Can that be one Zoho org?
It shouldn't be. Different tax regimes and different data centres mean separate orgs — one for GST, one for VAT — each compliant in its own right. You get consolidation at the reporting layer, not the transaction layer. Trying to force two countries into a single org is how businesses create a compliance problem to solve a convenience problem.
Our existing Zoho data is a mess. Do we clean it or start over?
Depends where the damage is. If transactions are broadly right and the problem is cosmetic, clean it. If the item master, vendor records or costing are wrong at the root, reset — because everything downstream inherits the error. We'll tell you which one you're looking at after an audit, and the honest answer is sometimes the more expensive one.
Can custom functions and workflows be moved from an old Zoho setup to a new one?
No, not directly. Custom functions, webhooks and schedulers have to be re-analysed, rebuilt and redeployed in the new environment. Budget for it, and document what exists before you start — a migration that discovers undocumented automations halfway through is the one that misses its date.
Does Shopify work with Zoho Books and Inventory?
Yes — catalog, orders, stock and sales posting, with reconciliation into the accounts. Your storefront stays where it is.
How long does a multi-country Books and Inventory implementation take?
Here it was roughly 14 weeks for the India reset across 8 phases, and 7 weeks for the fresh Dubai build across 6, with 45 days of hypercare after each. The difference is migration. A clean build is fast; moving live books mid-year with reconciled opening balances is what takes the time.
Facing the same challenge?
If your stock numbers have stopped matching reality, or you're running more than one country on systems that don't agree, we'll tell you whether it needs a clean-up or a reset. Start with a free automation audit. Get a free automation audit


