- Home
- Apps
- SaaS Tools
- Cloud Kitchen / Multi-Brand Ops for ERPNext
Illustrative previewA build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen,
with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability.
ECOSIRE builds, installs, and supports it to your confirmed scope.
What is Cloud Kitchen / Multi-Brand Ops for ERPNext?
A build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen, with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability. ECOSIRE builds, installs, and supports it to your confirmed scope. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Key Features
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your ERPNext.
- 3
Go live + support
You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Technical Specifications
- ERPNext Compatibility
- —
- License
- Licence confirmation required
- Python Requirement
- Python 3.10+
- Database
- MariaDB 10.6+
About this Product
Cloud-kitchen operators typically run four, six, or a dozen virtual brands out of one back-of-house — and stock ERPNext has no concept of a "brand" that owns its own menu, pricing, tax profile, and P&L. You end up modelling each brand as a separate Company (which fragments your one shared inventory) or crushing everything into a single price list and item group, at which point you can no longer answer the only question that matters: which brand actually makes money after aggregator commission and food cost? Sales Orders arriving from Talabat, Deliveroo, Careem, Uber Eats or your own web checkout all land in the same Sales Order list with nothing that routes, tags, or reconciles them by brand and channel. That is exactly where ERPNext core runs out of road for this business model.
We build a proper Frappe app (its own module, git repo, and hooks.py) that adds first-class multi-brand structure on top of ERPNext instead of fighting it. A Virtual Brand DocType owns each brand's menu (linked ERPNext Items via a child table), its own Price List and Item Tax Template, its logo/branding, and its target margin. A Kitchen Channel DocType maps each delivery aggregator or direct channel to its commission percentage, prep-station, and default warehouse. Incoming orders — whether pushed via the Frappe REST API / a whitelisted ingest method or entered at POS — are stamped with virtual_brand and channel custom fields, and a doc_events hook on Sales Order before_save/on_submit applies the brand's price list and tax template, injects the channel commission as a deduction line, and routes the ticket to the correct prep station via a Kitchen Display screen (a Frappe Page / Portal view backed by realtime frappe.publish_realtime).
Under the hood the shared pantry stays shared: all brands deduct from the same ERPNext Warehouse and Stock Ledger, so a kilo of chicken consumed by three different brand menus draws down one real inventory balance and triggers one reorder — no double-counting, no per-company silos. Server Scripts and scheduled jobs (scheduler_events — hourly/daily) roll up a per-brand P&L: revenue, aggregator commission, theoretical food cost from linked BOMs/recipes, and contribution margin, surfaced through a Query Report and dashboard chart filtered by virtual_brand. Client Scripts add brand-aware validation and one-click brand switching on the order form, and a Role Profile ("Brand Manager") plus User Permissions scope each operator to only their own brands' orders and reports.
This is build-to-order, not a marketplace download — there is no instant install. After a short scoping call we confirm which aggregators, brands, tax jurisdictions and reporting cuts you need, then build and hand over an installable Frappe app tested against ERPNext v15/v16. Typical delivery is one working week from confirmed scope. You receive the source, a UAT pass on a staging bench with a rollback plan, training, and a post-go-live support window — installed and maintained by ECOSIRE.
What you get
- Installable Frappe app (full source) for your confirmed scope, versioned in a git repository
- Installation and configuration on your bench: brands, channels, price lists, tax templates and role profiles wired up
- Technical documentation: DocType schemas, hooks, whitelisted methods, scheduler events and REST ingest contract
- End-user guide plus a live training session for brand managers and kitchen staff
- UAT on a staging bench with a signed-off test plan and a documented rollback procedure
- Post-go-live support window for defect fixes and configuration adjustments
- Git repository handover with commit history, README and upgrade notes for v15/v16
- Data mapping / seed for your existing menu items, brands and aggregator channels
Who this is for
Cloud-Kitchen Operator (Multi-Brand)
Runs 4–12 delivery-only brands from one kitchen and needs each brand's menu, pricing, tax and P&L cleanly separated while stock stays pooled — without spinning up a Company per brand in ERPNext.
Finance / Operations Controller
Wants trustworthy per-brand contribution margin after aggregator commission and food cost, reconciled against the shared Stock Ledger, delivered as ERPNext Query Reports and dashboards rather than exported spreadsheets.
Kitchen / Station Manager
Needs incoming aggregator and direct orders routed to the right prep station in real time on a Kitchen Display, with tickets clearly tagged by brand and channel so the line never mixes up which brand an order belongs to.
IT / ERPNext Administrator
Maintains the bench and wants a clean, migratable Frappe app with proper DocTypes, hooks and fixtures — not scattered manual customisations — that survives `bench migrate` across v15/v16 upgrades.
How Cloud Kitchen / Multi-Brand Ops for ERPNext Compares
| Criterion | ECOSIRE | Custom Build | Competitor | ERPNext Native |
|---|---|---|---|---|
| Multiple virtual brands | First-class `Virtual Brand` DocType in one Company | Possible, but you design the data model from scratch | Usually assumes one brand per site | No brand concept; forced into Company-per-brand |
| Shared inventory across brands | One Warehouse + Stock Ledger, deducted by all brands | Achievable with careful modelling | Often silos stock per brand/company | Company-per-brand fragments inventory |
| Aggregator/channel routing | `Kitchen Channel` + whitelisted REST ingest + doc-event routing | Build ingest and routing yourself | Limited or single-channel | Manual Sales Order entry only |
| Per-brand P&L with food cost | Scheduled roll-up: revenue, commission, BOM cost, margin | Custom reports to build and maintain | Basic sales report, no margin | No per-brand cut of profitability |
| Channel commission handling | Auto-injected as deduction via `hooks.py` doc event | Hand-coded per channel | Rarely modelled | Manual adjustment each order |
| Kitchen display routing | Realtime Page via `frappe.publish_realtime` per station | Build the realtime layer yourself | May need a separate KDS product | None |
| Upgrade safety (v15/v16) | Versioned app, fixtures, `bench migrate` safe | Depends on discipline of the build | Varies; may lag versions | N/A — no such feature to upgrade |
| Support & source ownership | Full git handover + post-go-live support window | You own it and all its maintenance | Vendor-locked, generic support | Community/self-service only |
Frequently Asked Questions about Cloud Kitchen / Multi-Brand Ops
How long until it is live? Can I download it now?
No — this is build-to-order, not a marketplace download. After a short scoping call to confirm your brands, aggregators, tax jurisdictions and reporting needs, typical delivery is one working week from confirmed scope. You get a UAT pass on a staging bench before anything touches production.
How are updates and support handled after go-live?
Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full source in a git repository, you're never locked in. We keep the app compatible with ERPNext/Frappe v15 and v16, and can quote ongoing maintenance or feature extensions separately.
Do I need a separate ERPNext Company for each brand?
No — that's exactly the pattern we avoid. Brands are modelled as a `Virtual Brand` DocType inside one Company, so they share a single Warehouse and Stock Ledger. Each brand still gets its own menu, Price List, Item Tax Template and P&L; you get separation of reporting without fragmenting inventory.
How do orders from delivery aggregators get in?
Through a whitelisted Frappe REST method that accepts aggregator payloads and creates Sales Orders stamped with the correct `virtual_brand` and `channel`. If you use a middleware or the aggregator's webhook, we map it to that ingest contract. Orders can also be entered at POS. Commission per channel is applied automatically via a `hooks.py` doc event.
Will per-brand profit actually reflect food cost, or just revenue?
Both. When your menu items are linked to recipes/BOMs, scheduled jobs compute theoretical food cost per item and roll it into a per-brand P&L alongside revenue and aggregator commission, giving you real contribution margin — not just top-line sales — in a filterable Query Report.
Which ERPNext versions is this built for?
Frappe/ERPNext v15 and v16. It's packaged as a proper versioned app with fixtures and migrations, so it's `bench migrate` safe. If you're on an older version, we'll flag any upgrade needs during scoping.
Can operators be restricted to only their own brands?
Yes. We ship a `Brand Manager` Role Profile plus User Permissions so each operator only sees the orders, reports and dashboards for the brands they're assigned — enforced at the ERPNext permission layer, not just hidden in the UI.
Related Modules

Checkout.com Gateway for ERPNext
A Checkout.com Flow integration built into ERPNext so you can accept global cards, mada, Apple Pay, Tamara and Tabby through one API. ECOSIRE scopes, builds, installs and supports it — this is a build-to-order engagement, not an instant download.

Check Run & Printed Cheque Manager
A build-to-order ERPNext app that aggregates approved payments into check runs, bulk-prints MICR-formatted cheques on your bank stock, and tracks the full void/reissue and post-dated cheque (PDC) lifecycle. ECOSIRE scopes, builds, installs, and supports it for you.

Contract Payment & Milestone Billing
A build-to-order ERPNext app that links contracts to Sales Invoices and tracks milestone-based billing, retention held and released, and payment progress against total contract value. ECOSIRE scopes, builds, installs, and supports it for your team.

Cost Center & Project Profitability for ERPNext
A build-to-order ERPNext app that turns your General Ledger dimensions into true per-project, per-job, and per-cost-center profitability — committed costs, overhead allocation, WIP, and dashboards included. ECOSIRE scopes, builds, installs, and supports it.
Cloud Kitchen / Multi-Brand Ops
A build-to-order ERPNext application that runs several delivery-only brands from one physical kitchen, with brand-level menus and tax, aggregator order routing, shared inventory deduction, and true per-brand profitability. ECOSIRE builds, installs, and supports it to your confirmed scope.
- `Virtual Brand` DocType owning each brand's menu, Price List, Item Tax Template, branding and target margin
- `Kitchen Channel` DocType mapping each aggregator/direct channel to its commission %, prep-station and default warehouse
- `hooks.py` `doc_events` on Sales Order (`validate`/`before_save`/`on_submit`) that applies the brand's price list + tax template and injects channel commission as a deduction
- Whitelisted REST ingest method (`@frappe.whitelist()`) for pushing aggregator orders into ERPNext, stamped with `virtual_brand` and `channel`