A build-to-order ERPNext application that runs a funeral home end to end — case file intake, arrangement conferences, service and merchandise selection, facility and staff scheduling, regulatory documentation, and itemised family billing. ECOSIRE builds, installs and supports it on your Frappe bench after a scoping call. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $499.00 USD; request a quote for a scoped proposal.
Illustrative previewA build-to-order ERPNext application that runs a funeral home end to end
— case file intake, arrangement conferences, service and merchandise selection, facility and staff scheduling, regulatory documentation, and itemised family billing.
ECOSIRE builds, installs and supports it on your Frappe bench after a scoping call.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your ERPNext.
You go live in about 2–4 weeks, with a post-launch support window.
A funeral home does not run on a sales pipeline. A case begins with a first call at 02:00, and within hours it has a decedent record, a next-of-kin who is often the payer but frequently not the legal authorising party, a removal already in motion, a chapel and a cremator to book, a coroner or medical examiner release to wait on, a death certificate and burial-transit permit to file, a casket or urn drawn from inventory, and a statement of goods and services that must be itemised in the exact form your jurisdiction demands. ERPNext core has real strength underneath all of this — Item, Stock Entry, Sales Invoice, Payment Entry, Employee, ledger and cost centres — but it has no notion of a decedent, no authorising party distinct from a bill-to party, no permit whose expiry blocks a disposition, and no way to stop a chapel being double-booked against a cremation retort. Homes end up running the actual work on a whiteboard, a shared calendar and a spreadsheet of case numbers, then re-keying into ERPNext days later so the accounting reconciles. The re-keying is where names get misspelled on a memorial folder and where a service is billed to the wrong family.
ECOSIRE builds you a proper Frappe application — its own app directory, its own module, installed on your bench alongside erpnext — rather than a pile of custom fields on Sales Order. The spine is a Funeral Case DocType with a naming series, a workflow (Intake → Arrangement → Scheduled → Service Held → Disposition Complete → Closed), and child tables for service selections, merchandise, cash advances and disbursements, and the documents a case must produce. Decedent, Authorising Party and Case Contact are separate DocTypes with Link fields into Customer and Contact, so the person who signs the authorisation, the person who pays, and the person who receives correspondence can be three different people without a workaround. Services and merchandise are ordinary ERPNext Item records — a Funeral Service Item extension carries the disclosure category, whether the line is a cash advance handled on behalf of the family, and whether it is a package component — so caskets, urns and register books move through real Stock Entry and Serial No records and your inventory valuation is the one ERPNext already computes.
Technically it is deliberately conventional Frappe. Scheduling is a Facility Booking DocType against Facility records (chapel, viewing room, preparation room, retort, hearse, fleet vehicle) with an overlap check in a validate hook that raises before save, plus a staff assignment child table that checks a director's or embalmer's existing bookings and their Leave Application records. Document control lives in Case Document, each row carrying a type, an issuing authority, an issued and expiry date, and an attached file; hooks.py doc_events on Funeral Case prevent a transition into Disposition Complete while a required document type is missing or expired, so the block is enforced server-side and not merely hidden in the UI. scheduler_events run a daily pass that flags permits approaching expiry, chases outstanding death-certificate copies, and produces the day's service run sheet. Billing is generated by a whitelisted method (@frappe.whitelist()) that assembles the case into a Sales Invoice in your jurisdiction's disclosure order, keeps cash advances in their own group so they are visibly not marked up, and posts through standard ERPNext accounting — nothing about the general ledger is re-implemented. Client scripts drive the arrangement conference screen, with package selection auto-expanding into component lines and a live running total as a family adds or removes items. Permissions ship as role profiles — Funeral Director, Arranger, Preparation Staff, Office Manager, Accounts — with field-level rules so preparation notes are not visible to front-office roles, and the whole surface is reachable over the Frappe REST API for a website enquiry form, a monument supplier, or an obituary feed.
Everything is scoped to your jurisdiction and your paperwork. Cremation authorisation requirements, coroner release workflow, disclosure-statement formats, permit types and retention rules vary by country, state and county, and we build to yours rather than shipping a generic template. Print formats — statement of goods and services, authorisation forms, service programmes, register book inserts, chain-of-custody sheets — are built as Jinja print formats on your letterhead so the family-facing paper looks like your firm's, not like an ERP.
This is a build-to-order application: it is not a Frappe Cloud Marketplace download and there is no instant install. Delivery is typically 2–4 weeks from confirmed scope. We start with a scoping call, walk through a real case from first call to closed file, write the specification, then build and demonstrate on a staging bench where your directors run their own cases as user acceptance testing before anything touches production. You receive the complete source of the app, a git repository handover, installation and configuration on your bench, technical and user documentation, a training session, and a post-go-live support window. The app targets Frappe/ERPNext v15 and v16, and we build against the version you are actually running.
Runs one or several locations and is tired of a whiteboard, a shared calendar and a spreadsheet of case numbers being the real system of record while ERPNext only sees the invoice days later. Wants one case file per family, accurate merchandise stock, and revenue by location and by director without a monthly reconciliation exercise.
Sits with a family for two hours and needs the arrangement conference on one screen — services, packages, casket or urn selection, a running total the family can see, and the authorisation printed on letterhead at the end of it. Needs confidence that the chapel time just promised is genuinely free.
Owns the paperwork: death certificates, burial-transit permits, cremation authorisations, coroner releases, retention. Needs a register showing exactly which documents each case is missing or has expiring, and a hard server-side block that stops a disposition being closed out with a gap in the file.
Needs itemised statements in the jurisdiction's required disclosure format, cash advances and third-party disbursements clearly separated from marked-up goods, instalment and insurance-assignment payments tracked against the case, and all of it posting through standard ERPNext accounting into the ledger they already use.
| Criterion | ECOSIRE | Custom Build | Competitor | ERPNext Native |
|---|---|---|---|---|
| Time to a working system | 2–4 weeks from confirmed scope, built on a staging bench and demonstrated before cutover | Typically 3–6 months once you have hired or briefed a Frappe developer and iterated on requirements | Installs in minutes, then weeks of workarounds where its assumptions do not match your process | Immediate, but funeral case management is absent — the real work happens outside ERPNext |
| Case, decedent and authorising-party model | Dedicated `Funeral Case`, `Decedent` and `Authorising Party` DocTypes, so signer, payer and correspondent stay distinct | Whatever your developer models — usually correct, at the cost of designing it from nothing | A generic case object, commonly assuming payer and next-of-kin are the same record | `Customer` and `Contact` only; a decedent has to be forced into a contact record |
| Facility and staff scheduling | `Facility Booking` with server-side overlap validation across chapel, retort and fleet, plus staff and leave checks | Buildable, but overlap and leave-collision edge cases are where DIY projects usually leak | Often a calendar view without a hard booking-conflict guard | No facility resource concept; teams fall back to a shared Google or Outlook calendar |
| Regulatory document control | `Case Document` register with expiry dates and `hooks.py` rules blocking disposition on missing or expired paperwork | Achievable, but compliance rules are the first thing dropped when a DIY build runs over time | Typically a file attachment list with no enforcement | File attachments on a document — no document types, expiry tracking or blocking |
| Merchandise inventory | Caskets and urns as native `Item` records with real `Stock Entry`, optional `Serial No` and standard valuation | Depends whether the developer wires into ERPNext stock or invents a parallel table | Varies; some apps keep a separate merchandise list that never reconciles to stock | Full inventory available, but with no link from a family's selection to a case |
| Family billing and disclosure statement | Whitelisted method builds a `Sales Invoice` in your jurisdiction's disclosure order with cash advances grouped separately | Custom print-format work, usually revisited after the first compliance review | A generic invoice layout that rarely matches a mandated regional disclosure format | Standard `Sales Invoice` and print format — no disclosure ordering or cash-advance grouping |
| Source code and lock-in | Full source plus git repository handover with commit history to your organisation | You own it outright, and you also own every future fix and upgrade | Frequently licensed per site, sometimes with obfuscated code or a licence check | Open source, but nothing funeral-specific exists to own |
| Upgrade path to a future ERPNext version | Standard bench app — `bench get-app`, `bench migrate` — built and tested against v15/v16 | Depends entirely on whether the original build followed Frappe conventions | Tied to the vendor's release cadence; you wait for their v16 build | Upgrades cleanly, since there is no funeral layer to carry forward |
No — this is a build-to-order application, not a Frappe Cloud Marketplace download, so there is nothing to install instantly. Typical delivery is 2–4 weeks from confirmed scope. The clock starts once we have agreed the specification after the scoping call, not at first enquiry. Jurisdiction-specific paperwork, an unusual disposition workflow, or migrating a large history of legacy case records can extend that, and we will tell you before you commit rather than after.
We build and test against Frappe/ERPNext v15 and v16, targeting the version you are actually running rather than the newest release. Because it is a proper Frappe app with its own DocTypes and hooks — not a mesh of custom fields and property setters — it upgrades the way any bench app does: `bench get-app`, `bench migrate`, then your regression pass. During the post-go-live support window we handle defect fixes and configuration changes. Version uplifts to a future ERPNext major release after that window are quoted as separate work, and you hold the source and the git repository either way, so you are never locked to us.
You receive the complete source and the git repository is handed to your organisation with full commit history. You can read it, fork it, host it, and have another engineer extend it. There is no obfuscated code, no phone-home licence check, and no runtime dependency on ECOSIRE infrastructure.
That is precisely why it is built to order. Cremation authorisation requirements, coroner or medical examiner release workflow, permit types, retention periods and the mandated format of a statement of goods and services differ by country, state and county. We capture yours during scoping and build the `Case Document` types, the required-document rules enforced in `hooks.py`, and the Jinja print formats to match. We are engineers rather than your legal counsel — we implement the rules as your compliance officer states them, and the UAT pass on staging is where they confirm the output is correct.
It sits on top and delegates. Services and merchandise are native `Item` records, stock movements are real `Stock Entry` documents, and billing produces a standard `Sales Invoice` posted through the ordinary ERPNext general ledger. Nothing about accounting is re-implemented, so your chart of accounts, cost centres, tax templates and existing financial reports keep working exactly as they do now. The app adds the funeral-specific layer above that — cases, decedents, facilities, documents and the disclosure-ordered statement.
Yes. The app exposes its DocTypes over the standard Frappe REST API and adds whitelisted methods for the specific flows — creating a first-call case from an external form, publishing service times to an obituary feed, pushing a case summary to a monument supplier. Authentication uses ordinary Frappe API keys or OAuth with a scoped role, so an integration user can create a first-call record without seeing preparation notes or financials.
About 30 minutes. We walk one real case with you from the first call through to a closed file, note where your process differs from the default model, list your required documents and permits, look at your current statement format, confirm your Frappe/ERPNext version and hosting, and identify any data you need migrated. That gives us enough to write a specification with a fixed scope and a delivery date rather than an open-ended estimate.

A finite-capacity, constraint-aware production scheduler for ERPNext that turns Work Orders and Job Cards into a live, drag-and-drop Gantt plan respecting machine, labor, and material availability. Built to order, installed, and supported by ECOSIRE.

A build-to-order ERPNext app for commercial farms and agribusiness that turns crop cycles, land plots, input usage, and harvest yields into structured DocTypes and traceable records. ECOSIRE scopes, builds, installs, and supports it — it is not an instant download.

A build-to-order Frappe app that captures supplier invoices, receipts, and POs via AI/OCR and turns them into draft ERPNext Purchase Invoices and Expense Claims — with line-item, tax, supplier, and item auto-matching. ECOSIRE scopes, builds, installs, and supports it for you.

A build-to-order AI layer for ERPNext manufacturing that predicts asset failures, recommends optimal production schedules, and surfaces quality anomalies from your Work Order, Job Card, and machine sensor data. ECOSIRE builds, installs, and supports it on your v15/v16 bench.
A build-to-order ERPNext application that runs a funeral home end to end — case file intake, arrangement conferences, service and merchandise selection, facility and staff scheduling, regulatory documentation, and itemised family billing. ECOSIRE builds, installs and supports it on your Frappe bench after a scoping call.