Does ERPNext with the Hospitality app fit a hotel or restaurant back office?
The Frappe Hospitality app covers restaurant and hotel workflows that create invoices in ERPNext. On the restaurant side it handles restaurants, menus, tables, reservations, order entry and billing. On the hotel side it handles rooms and room reservations, and those reservations can create invoices. That makes it a fit for an operator who wants front-of-house activity and room billing to end up in the same accounting system as purchasing, stock and the general ledger. It is not a standalone property management system with its own accounts. Before committing, confirm with the project which hotel functions the app covers today, such as rate plans, room status, housekeeping, check-in and check-out, and group bookings, because the public description is short and does not list them.
Since version 14, Hospitality is no longer part of ERPNext. The ERPNext version 14 migration guide states that it moved out of ERPNext into a separate app. This changes three things for you. It is installed as its own app alongside ERPNext rather than as a core module, so your deployment plan must list it explicitly. It is versioned on its own track, so the Hospitality release you run must be checked against the ERPNext release you run. And any site that used the older built-in features needs a documented migration step before upgrading. Ask for the compatibility matrix for your target ERPNext version, and test the installation on a copy of your site before you schedule any upgrade.
The decision comes down to whether your operation needs more than the app documents. Restaurant groups with standard menus, table service and reservations are the simpler case. Hotels with channel managers, property management systems, payment terminals or loyalty programs will need integration design, and those integrations are not covered by the app's public description. Confirm the point-of-sale and payment connectors, the data each one syncs into ERPNext, and who maintains them. A short written scope covering menus, rooms, invoicing, accounts and each external system will show whether the app fits or whether a custom build is the better path.
Which hospitality requirements the build must meet
This table maps the core operator requirements for a hotel or restaurant to the researched source fact that supports each one and to what it means for the build. Read the Status column first: rows marked as needing confirmation are capabilities the supplied facts do not establish, so verify them in the Hospitality app documentation before scoping.
| Requirement | Supported by the supplied facts | What it means for the build |
|---|---|---|
| Restaurant menus and order entry | The Hospitality app covers restaurants, menus, tables, reservations, order entry and billing (frappe/hospitality README). | Confirm menu item structure, modifiers and course handling with the app documentation, then design item and price lists in ERPNext to match. |
| Table management | Tables are listed among the restaurant workflows the app handles (frappe/hospitality README). | Confirm how table status, seating and order transfer work before writing floor layout requirements. |
| Restaurant reservations | Reservations for restaurants are listed in the app README (frappe/hospitality README). | Confirm whether restaurant reservations are a standard feature or need custom work, and who owns no-show handling. |
| Hotel room reservations | Hotel rooms and room reservations are listed in the app README (frappe/hospitality README). | Map room types, rates and availability rules to your property before the build, since these drive every invoice. |
| Invoicing from room and restaurant sales | Room reservations can create invoices (frappe/hospitality README). | Decide which charges post as sales invoices and which post at checkout, and test the invoice output with your accounting team. |
| Accounting and stock | ERPNext covers accounting and inventory management (frappe/erpnext GitHub repository), and Hospitality moved out of ERPNext into a separate app in version 14 (ERPNext version 14 migration guide). | Install Hospitality as its own app on a supported version, then map its income, tax and stock items to ERPNext accounts and warehouses. |
| Payment terminals, channel managers and property management integrations | Not confirmed by the supplied facts. | Verify with the Hospitality app documentation and its repository whether these connectors exist. If not, budget for custom integration work and scope it in writing. |
Why Hospitality is a separate app from ERPNext version 14
The ERPNext version 14 migration guide states that Hospitality moved out of ERPNext into a separate app, so the restaurant, table, reservation and room workflows no longer ship inside the ERPNext codebase. For a team upgrading an older hospitality install, this changes the upgrade plan. Before touching the ERPNext version, list every Hospitality doctype, page and report in use, confirm which of them lived in ERPNext and which now come from the Hospitality app, and check the migration guide for any steps that apply to your site. Treat the two codebases as separate dependencies with their own version numbers.
Version pinning follows from that split. Record the ERPNext version and the Hospitality app version together in your build or deployment manifest, and pin both. The supplied facts show ERPNext version 14 reached end of life on January 31, 2026, while version 15 and version 16 are the supported lines, with version 15 planned for support until the end of 2027 and version 16 until the end of 2029. Compatibility between the Hospitality app and each ERPNext version must be confirmed with the Hospitality repository and its release notes before you choose a target, because a supported ERPNext line does not by itself guarantee a matching Hospitality release. Ask the vendor or your partner to write the tested pairing into the scope.
Ownership of the release cycle also sits with the Hospitality app. Its maintainers decide when it changes, so your upgrade calendar now has two tracks that must be aligned. Decide who in your organization or partner watches the frappe/hospitality repository for releases, who tests a new pairing in staging, and who signs off a production change. Confirm the support terms for any Hospitality issue you raise, since Frappe's supported versions policy ties warranty coverage to listed versions and matching support plans, and ask specifically whether that coverage extends to the separate app.
Which modules and apps must be configured for restaurants and hotels
The frappe/hospitality repository describes restaurant workflows for menus, tables, reservations, order entry and billing. These records depend on item and price data held in ERPNext, so restaurant configuration starts with how each menu entry becomes a sellable item. Confirm in the README and in the release you target which restaurant screens, fields and options the app provides.
- Menu items as ERPNext items: Decide which menu entries are stock items, which are non-stock items, and how portions, variants and add-ons are represented. Confirm how the app handles modifiers before you build the item list.
- Price lists and tax: Plan price lists per outlet and per channel, such as dine-in and takeaway, and tax templates for each rate that applies. Test that a order priced in one list bills with the right tax.
- Tables and floor layout: Define tables, sections and seating per outlet before order entry testing starts. Confirm whether the app supports table status, order transfers and split bills.
- Reservation to bill flow: Test the full path from reservation to order to invoice, including changes, cancellations and no-shows, with staff who use the floor.
Before go-live, run the full service flow on a staging site with a test menu and check that the printed bill, tax lines and daily totals match your requirements.
The Hospitality app also covers hotel rooms and room reservations, and it can create invoices from them. The hotel configuration therefore depends on how room types, rates and guest accounts map to ERPNext customers, items and invoices. The supplied facts confirm that room reservations can create invoices, but they do not describe the folio, night audit or check-out process, so these need confirmation with the app's current documentation.
- Room types and rates: Model room types and their rates as items and price lists, and decide which charges appear as separate invoice lines, such as room nights, extra beds and minibar.
- Reservation to invoice timing: Define when the app creates invoices: at booking, at check-in, at check-out or in batches. Test each case with a sample stay that includes a change of dates and an early departure.
- Guest and customer records: Decide whether each guest, company or travel agent is an ERPNext customer, and how duplicates are prevented during import of existing guest lists.
- Tax and currency on room charges: Confirm the tax treatment of room, food and service charges for each jurisdiction and currency, because these rules often differ within one stay.
- Posting dates: Confirm how the app assigns posting dates to charges made late in the day or after midnight, since this affects period-end reports.
Before go-live, reconcile a set of test stays against the invoices and the accounts receivable balance in ERPNext.
Restaurant and hotel sales post into the same accounting, stock and user model that ERPNext uses for the rest of the business. The ERPNext version 14 migration guide states that Hospitality moved out of ERPNext into a separate app, so the app must be installed and versioned alongside ERPNext. Frappe's supported versions page lists version 14 as end of life from January 31, 2026, so confirm the Hospitality release that matches your ERPNext version before you start.
- Accounting structure: Set income accounts per outlet, room type and service, and decide how cost centers or accounting dimensions separate restaurant, rooms and events for management reporting.
- Kitchen and bar stock: Create warehouses for the kitchen, bar and store. Confirm whether a sale depletes stock through recipes or bills of materials, and how units of measure are handled for ingredients bought in bulk.
- Users and roles: Map front desk, waiter, cashier, manager and accountant roles per outlet. Connect directory groups through LDAP if your organization uses Active Directory or OpenLDAP, and consider Social Login for other sign-in options.
- Custom posting logic: Server Scripts are disabled by default from version 15 and must be enabled with
server_script_enabled. Frappe Cloud public shared benches do not allow them, so custom rules need a deployment that permits this setting. - Support coverage: Frappe's policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan, so check this before choosing a hosting model.
Before go-live, confirm the Hospitality app version, the ERPNext version and the support status of both in writing.
Where the system runs and how staff sign in
The hosting choice decides where guest records, folios and payment references sit, so settle it before any Hospitality configuration. ERPNext can run on Frappe Cloud, through Docker Compose, or manually with the bench command line tool. Frappe Cloud is the least operational work, but the hotel group then depends on the vendor's hosting for guest and billing data. Docker Compose or bench keeps the database, backups and network paths inside infrastructure the group controls, at the cost of its own team patching, backing up and sizing the stack. The frappe_docker project provides production images and Compose files with MariaDB, Redis, workers, the scheduler and Nginx, but its single-file demo setup is meant only for short evaluations. Ask the implementation partner which of these the Hospitality app is tested against on your chosen version, and confirm where the payment provider's tokens and card references are stored.
Staff sign-in is a separate decision from hosting. ERPNext supports LDAP login against Active Directory or OpenLDAP, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login, so front desk, restaurant and night audit staff can be granted roles centrally when they join or leave. Social Login Key is the alternative for providers such as Google, Microsoft or a custom OpenID Connect endpoint, but it is a weaker fit for shift staff who share terminals, and it does not replace role mapping. Confirm which identity source holds your staff records, how terminal and shared-device logins are handled, and whether a leaver's access is removed the same day.
Server Scripts deserve a check early. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them at all. If your room rate rules, menu surcharges or folio logic depend on custom Python run on document events, you need a self-hosted bench or Docker deployment with that setting enabled, or a custom app. Put this to the partner as a written requirement, because it changes the hosting decision above and the effort needed to build and test those rules.
How a hospitality rollout moves from pilot to go-live
The sequence starts by confirming that the Hospitality app matches your ERPNext version, then builds outlet and room master data in small batches, proves the setup in one pilot location, and only then extends it across the property or group with monitoring in place.
Confirm version and app compatibility
Before any configuration, check which ERPNext version you run and which Hospitality app release matches it. ERPNext moved Hospitality out of the core in version 14, so the app is a separate install that must be paired with a supported ERPNext line. Check the Frappe supported versions page for the lifecycle of your ERPNext version, and confirm with the Hospitality maintainers which release works with it. The output is a written compatibility record naming both versions, plus a test bench where the app installs cleanly. Your team or the partner owns this check, and the step is done when the install succeeds on a non-production site.
Model outlets, menus, tables, rooms and rates
Design the data model with the operations team before loading anything. For restaurants, define outlets, menu categories, items, tables, and the stations that print or route orders. For hotels, define room types, individual rooms, rate plans, taxes and the rules for charges posted to a folio. Decide which items and rooms map to ERPNext accounts and tax templates, because these links drive the invoices. The output is a signed-off workbook that lists every field, value and account, reviewed by finance and front-of-house staff. Done when each menu item and room type has an owner and a revenue account.
Load master data in small batches
Use the ERPNext Data Import tool with the downloadable templates to load items, customers, price lists and room or table records. The documentation advises importing only a few thousand records at a time, so split large menus or room inventories into batches and keep each file's row count in a log. Import parent records before dependent ones, and check child table rows such as menu variants or rate lines. The output is a load log per batch showing created and updated counts and rejected rows. Done when a second import of the same file updates records without creating duplicates.
Configure order entry and billing rules
Set up how orders become invoices in the pilot configuration: order entry flow, kitchen or station routing, payment methods, and the point where a room charge or table bill posts to accounting. Test each path with sample transactions, including voids, split bills, discounts and corrections. Where you plan custom logic, weigh whether a Server Script is needed. Server Scripts are disabled by default from version 15 and must be enabled, and Frappe Cloud public shared benches do not allow them, so confirm your hosting option first. The output is a test script with expected ledger entries. Done when finance reconciles the test invoices to the expected accounts.
Run a pilot in one outlet or one property
Choose a single restaurant outlet or a single hotel property with real but manageable volume. Run live transactions alongside the existing process for an agreed period, and compare totals, tax and room charges each day. Involve front-of-house staff in the sessions and record every workaround they need, because those gaps usually point to missing configuration. The output is a pilot report listing defects, open decisions and reconciliation differences. Done when the sponsor accepts the report and every critical defect has a fix or a documented exception.
Fix findings and freeze the configuration
Resolve pilot findings in the test environment first, retest the affected paths, and then freeze the configuration with a change record. Capture the Hospitality app version, ERPNext version, custom fields and any scripts in version control so they can be redeployed. This step matters because the rest of the rollout copies this baseline. The output is a tagged configuration baseline and an updated runbook. Done when a clean install from that baseline reproduces the pilot results.
Roll out with monitoring and support in place
Extend the frozen configuration to the remaining outlets or properties in waves, loading each location's master data with the same batch process. Set up monitoring for background jobs, failed scheduled tasks, error logs and invoice posting, and assign a named owner for the first weeks after each wave. The output is a go-live record per location and a support handover. Done when every wave closes its reconciliation checks and the ongoing support model is agreed in writing with the vendor or partner.
What do buyers ask before hiring a partner for a hotel or restaurant ERPNext build?
What drives the cost of a hotel or restaurant ERPNext build?
The main drivers are the number of outlets and properties, the number of rooms and tables, how many integrations the build needs, and how much historical data must be migrated. Each outlet adds its own menus, tables, price lists and staff roles, and each property adds room types, rate plans and reservation rules. Ask for a quote built from a written scope that lists these counts, the integrations (payment terminals, booking channels, accounting exports) and the data sets to move. Fixed-scope engagements are agreed in writing before work starts, so the quote should name every deliverable.
Which costs are one-time and which recur after go-live?
One-time costs cover discovery, configuration, customization, integration work, data migration and training. Recurring costs cover hosting, a support plan, upgrades, backups monitoring and testing after each release. Self-hosting ERPNext is free according to the ERPNext pricing page, so your recurring spend is infrastructure and people. If you use Frappe Cloud instead, the same pricing page lists shared site hosting from 5 US dollars per month and shared servers from 20 US dollars per month, with dedicated servers from 125 US dollars per month. Confirm current plans on that page before budgeting, since prices can change.
How long does a hotel or restaurant ERPNext build take?
Duration depends on scope, mainly the number of outlets and properties, the integrations and the state of your source data. A single restaurant with a standard menu and accounting export is a much smaller job than a multi-property hotel with reservations, room billing and channel integrations. No duration can be stated responsibly without a scoped plan, so ask for a timeline tied to named milestones such as configuration sign-off, test billing runs, data load rehearsal and go-live. Ask how many rounds of testing are included and who signs off each stage.
What must the operator provide before the build starts?
The operator must supply the menus with items, modifiers and prices, the room types and rate plans, the chart of accounts, and the staff roles and their permissions. You also need tax rules for each outlet and property, the payment methods you accept, and the reports your accountants and managers expect. Access to existing systems, sample invoices and a named decision-maker for each area shortens discovery. Ask the partner for a written list of required inputs with owners and due dates before signing.
Can an in-house team build this without a partner?
Yes, if your team has Frappe and ERPNext experience, Python for server logic and the time to run testing and cutover. ERPNext is open source under GPL-3.0 and can be installed with Docker Compose or the bench command line tool, according to the frappe/erpnext README. Hospitality is a separate app, so your team must plan its installation and its version compatibility on its own. Be realistic about the testing burden: billing, tax and night audit flows must be verified before go-live. A partner is most useful where your team lacks these skills or capacity.
Which Hospitality app version should we plan around?
Plan around the version that matches your ERPNext release, because the ERPNext version 14 migration guide states that Hospitality moved out of ERPNext into a separate app. Frappe's supported versions page lists ERPNext and Frappe Framework version 14 as end of life on January 31, 2026, and version 15 and 16 as supported. Confirm the Hospitality app's compatibility with your target ERPNext version in its repository before selecting a version. Ask the partner how upgrades will be tested, since an app split can change where features and data live.
What security and access questions should we settle early?
Settle who can see room folios, payment details and guest records, and which roles can change rates, void bills or close a shift. ERPNext supports role-based permissions, and LDAP login or Social Login Key sign-in can connect staff accounts to your directory, according to the ERPNext LDAP integration documentation and the Frappe Framework documentation. Server Scripts are disabled by default from version 15 and must be enabled deliberately, and Frappe Cloud public shared benches do not allow them. Ask the partner how access reviews, backups and staff offboarding will be handled.
Which compliance and data questions a hospitality deployment must answer
A hotel or restaurant group running ERPNext with the Hospitality app holds guest data, staff records, invoices and card-related flows in one system. The cards below cover the questions to settle before go-live, and they connect because each answer shapes the hosting, roles and logs the others depend on.
Guest and staff personal data
Reservations, guest profiles and room folios hold names, contact details and stay history, while staff records hold payroll and identity data. Map which DocTypes hold personal data, who may view each field, and how long reservation and folio records are kept. Confirm with your legal team which deletion or access requests you must honor and whether the retention rules are written down before data loads. Ask DeployOpen to document the data map as evidence for your privacy program.
Role separation for cashiers and managers
Front desk staff, waiters, cashiers and managers need different rights to create, edit, discount and cancel invoices. Design roles and permissions so a cashier cannot void a closed bill or change a room rate without an approver. Test each role with a real login before go-live, and review who holds the System Manager role, since it bypasses most restrictions.
Audit trails for invoices and accounting
Auditors will ask who created, changed or cancelled an invoice and when. Confirm that ERPNext version tracking is enabled on sales invoices, payments and room charges, and that cancelled documents remain visible rather than deleted. Decide who reviews the logs and how often, and export a sample trail for your own control testing. DeployOpen prepares this evidence, and independent auditors decide whether the controls are sufficient.
Data residency through self-hosting
Self-hosting ERPNext keeps the database, file storage and backups in infrastructure you choose, which matters when guest data must stay in a specific country or region. Frappe Cloud hosting places the data with that provider, so confirm its locations before choosing it. Document where backups, logs and email relay sit, since each can carry personal data.
Payment card scope and gateways
If a restaurant or hotel takes card payments through a gateway, the scope of your cardholder data environment depends on whether card numbers ever reach ERPNext, its logs or its exports. Prefer hosted payment pages that return only tokens, keep card data out of notes and print formats, and ask your assessor to confirm the scope boundary. Treat this as a design decision before integration work starts.
What to ask a partner before committing to the Hospitality app
Start with the versions. Ask the partner which ERPNext release and which Hospitality release they will pin, and whether both will be on a branch that receives minor releases. The Hospitality app is a separate app from ERPNext, so it has its own compatibility matrix and its own release cadence. Ask who checks that pairing before each upgrade, how the pinned versions are recorded in your bench or container images, and whether the partner will tell you in writing when a version you depend on reaches end of life. Confirm the Frappe support version you are on, since the supported versions page lists the dates that matter for planning.
Next, ask how room and table workflows are tested. Ask for the test cases in writing: a room reservation that converts to a folio and invoice, a table moved mid-service, an order split across two checks, a no-show, a refund after the day is closed. Ask who holds the test data, whether the tests run in a staging site built from a copy of your configuration, and who signs off each scenario. For existing installs moving off ERPNext 13 or earlier, ask how the separation of Hospitality into its own app is handled: which documents and settings move, what is re-linked, and what the partner will not migrate. Ask for the migration guide version they are working from, and for a backup and rollback step before any change.
Finally, ask what a fixed-scope quote contains and what a retainer covers. A fixed-scope quote should list the modules and apps in scope, the menu, room type and tax configuration to be built, integrations such as payment terminals or booking channels, data migration, testing, training and go-live support, along with the exclusions. For upgrades and support, ask whether the retainer covers patching, upgrade testing on staging, and out-of-hours response, and whether upgrades to a new major version are priced separately from routine minor releases. Ask which costs recur each month and which are one-time, and what changes the price if your property count or order volume grows.
How DeployOpen scopes and delivers hospitality implementations
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ERPNext with the Hospitality app, we start from your outlets, rooms and accounting rules, then agree the written scope before any build work begins.
How we scope
- We map which outlets, restaurant tables, room types and rate plans the written scope covers.
- We confirm which invoices the Hospitality app must create in ERPNext and which accounts, taxes and cost centers they post to.
- We list the integrations, payment handling and user roles in scope, and name anything left for your own team or a later phase.
How we build
- We configure menus, tables, reservations and room reservations on a non-production site that mirrors your ERPNext version.
- We build any custom fields, print formats or scripts needed for billing, and check them against the version's rules for server scripts.
- We test end-to-end sales flows, from a reservation or table order through to a posted invoice and payment, before go-live.
How we hand over
- We deliver configuration records, test scripts, and a record of every customization with its purpose and owner.
- We document the deployment, the upgrade path for ERPNext and the Hospitality app, and the backup and restore steps.
- We train the staff who will run front desk, restaurant service and accounting, using your own sample data where possible.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- We plan version upgrades of ERPNext and the Hospitality app together, since the two are maintained as separate apps.
- Ask any partner to confirm which ERPNext versions and Frappe Cloud support plans apply to your site and warranty position.
