Dental Clinic Management for Business Central

Key Features

Chair and provider scheduling built on Business Central `Resource` records with capacity calendars, so utilisation reporting reuses standard resource capacity entries

Day/week appointment board page with conflict validation in a scheduling codeunit — double-booked chairs, provider overlaps and out-of-hours slots are blocked at validation, not discovered at the front desk

Patient modelled as a table extension of `Customer` plus a dedicated Patient Card, keeping every clinical record on the customer ledger you already reconcile

Versioned treatment plan documents (header/line) with per-line accept or decline, revision history, and a plan status flow from Draft through Accepted to Completed

Procedure code master mapped to `Item` or `Resource` records with posting groups and default durations, so an accepted procedure prices, posts and schedules consistently

Patient-share and insurer-share split on every plan line, with the insurer portion posted to a separate bill-to customer or a dedicated receivable account

Procedure-linked invoicing posted through the standard `Sales Header` / `Sales Line` path — full VAT/GST/sales tax, dimensions and posting-group behaviour, with no shadow ledger

Lab case documents carrying lab vendor, send and due dates, shade and material, case status, and optional Purchase Order creation so lab cost lands against the case

Treatment plan margin view combining procedure revenue, consumable item cost and posted lab case cost

Consumable consumption per procedure via item journal posting, so implants, composites and single-use kits deplete inventory when the procedure is completed

Recall engine driven by a Job Queue Entry that scans due recall dates and queues reminders by email, SMS gateway or Power Automate flow

API pages on REST API v2.0 / OData v4 exposing appointments, patients, treatment plans and lab cases for portals, imaging software and Power Apps front-ends

Role-scoped permission sets separating reception (book and reschedule), clinical (plan and complete) and finance (post and credit) duties

Upgrade-safe construction: table and page extensions with event subscribers only, a reserved object ID range and prefix, targeting current Business Central release waves on SaaS and on-premises

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

A dental practice runs on three clocks that Dynamics 365 Business Central has no native concept of: the chair, the treatment plan, and the lab bench. Business Central gives you a solid customer ledger, sales invoices, VAT/tax posting, inventory for consumables and a Service Management module that was designed for field service on serialised equipment — not for a hygienist's 30-minute recall slot or a five-visit crown sequence with an insurance pre-authorisation attached. Practices end up running the clinical side in a standalone dental app and the money side in Business Central, keying the same procedure twice, reconciling patient balances by hand, and discovering a lab case is late only when the patient is already in the chair.

What we build is an AL extension for Business Central that closes that gap without forking your finance setup. Patients extend Customer through a table extension plus a Patient Card page, so every clinical record still posts to the customer ledger you already reconcile. A chair and provider model reuses Business Central Resource records with capacity calendars, and the Appointment table carries chair, provider, duration, procedure codes and status, surfaced on a day/week board page with reassignment actions and conflict validation in a scheduling codeunit. Treatment plans are versioned header/line documents: each line references a procedure code (mapped to an Item or Resource and a posting group), carries an estimate, a patient share and an insurer share, and can be accepted line by line. On completion, a posting codeunit turns accepted, delivered plan lines into a Sales Invoice through the standard Sales Header / Sales Line posting path — never a custom ledger — so tax, dimensions and posting groups behave exactly as your accountant expects.

Lab work is a first-class document: lab vendor, send and due dates, case status, shade and material fields, and an optional Purchase Order raised to the lab so cost lands against the case and the treatment plan margin is real rather than assumed. Recalls are driven by a Job Queue Entry that scans due recall dates and queues reminders through email, an SMS gateway or a Power Automate flow. Technically it is built to stay upgrade-safe: table and page extensions rather than base-object modification, event subscribers instead of hooks into Microsoft code, a reserved object ID range and prefix registered to your tenant, and dedicated permission sets so reception can book, clinicians can plan and only finance can post. API pages published on the Business Central REST API v2.0 / OData v4 surface expose appointments, patients, treatment plans and lab cases so a patient portal, imaging software or a Power Apps front-end can read and write them; Dataverse virtual tables and Power BI reporting are wired on request. The extension targets current Business Central release waves and runs on SaaS (per-tenant extension or AppSource-packaged app) as well as on-premises.

This is build-to-order, not a download. After a scoping call we produce a written functional specification covering your procedure code set, insurance and claim handling, chair and provider layout, lab vendors and recall rules, and confirm the price against that scope. Typical delivery is 2-4 weeks from confirmed scope. We build against your Business Central version, deploy to your sandbox for UAT with your own patient and procedure data, then install into production during an agreed window with a documented rollback. You receive the AL source, the git repository, technical and user documentation, a live training session, and a post-go-live support window for fixes and adjustments.

What you get

Installable AL source code and a packaged `.app` built for your exact Business Central version (SaaS per-tenant extension or on-premises deployment)

Installation and configuration on your environment, including procedure codes, chair and provider resources, posting group mapping and recall rules

Technical documentation: object model, event subscribers, API page endpoints, permission sets and configuration reference

User guide plus a live training session for reception, clinical and finance roles, recorded for future staff

UAT deployment to your sandbox with your own data, an agreed acceptance checklist, and a documented rollback plan for the production install

Post-go-live support window for defect fixes and configuration adjustments against the confirmed scope

Handover of the private git repository with full commit history, build configuration and versioned releases

The written functional specification produced during scoping, which the delivery is measured against

Who this is for

Practice owner or principal dentist

Runs a single or multi-chair clinic and wants one system for clinical scheduling and money. Needs chair utilisation, treatment plan acceptance rates and true per-procedure margin after lab and consumable cost, without exporting two systems into a spreadsheet every month.

Practice manager

Owns the diary, the recall list and the debtor ledger. Needs conflict-free chair and provider booking, visibility of which treatment plans were presented but never accepted, and patient balances that agree to Business Central without manual reconciliation.

Finance manager or group accountant

Responsible for statutory posting, tax treatment and multi-location consolidation. Needs clinical activity to post through standard Business Central sales documents with correct dimensions and posting groups, and insurer receivables kept separate from patient receivables.

IT lead or Business Central partner consultant

Maintains the tenant and its extensions. Needs upgrade-safe AL that survives release waves, no base-object modification, documented API pages for the patient portal and imaging integration, and a git repository they can build and support themselves.

How Dental Clinic Management for Business Central Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your clinic's workflow	Built to your written spec — your procedure codes, chair layout, insurers and recall rules	Fully bespoke, but the result is only as good as the spec the developer was given	Fits the vendor's assumed dental workflow; you adapt the practice to the product	No dental concepts at all — Service Management was built for field service on equipment
Chair and provider scheduling	Resource-backed chair and provider board with conflict validation in a scheduling codeunit	Achievable, but capacity and conflict logic is the part most DIY builds under-scope	Usually present, often with limited control over provider capacity calendars	Resource capacity exists, but there is no appointment entity and no diary view
Treatment plans and estimates	Versioned plans with line-level accept or decline and a patient vs insurer share	Buildable; versioning and partial acceptance are commonly deferred then missed	Typically a flat quote document with no revision history	Sales Quotes only — no clinical sequencing, partial acceptance or revisions
How revenue posts	Through standard Sales Header and Line posting, so tax, dimensions and posting groups behave normally	Depends on the builder; a shadow ledger is the classic DIY mistake here	Often posts through its own journal, which complicates audit and tax review	Posting is correct, but nothing links an invoice line to a procedure or a plan
Lab case tracking	Lab case document with vendor, dates and status, plus optional PO so lab cost hits the case	Rarely scoped into a first build; usually added later at additional cost	Sometimes a status field only, with lab cost left outside the margin	Not modelled — practices track lab work in a spreadsheet or on a whiteboard
Upgrade safety across release waves	Extensions and event subscribers only, reserved object range, tested against current waves	Varies widely; base-object modification and unreserved IDs are common failure modes	Vendor maintains it, but you wait for their release cadence and their priorities	Always upgrade-safe, because there is nothing dental in it to break
Integration surface	Documented API pages on REST API v2.0 / OData v4 plus Dataverse and Power Automate wiring	Only what you specify; API pages are often the first thing cut for budget	A published API if the vendor offers one, on their schema and their roadmap	Standard Business Central APIs only — no appointment, plan or lab case endpoints
Ownership and lock-in	You receive the AL source, the git repository and the build configuration at handover	You own it, subject to whatever your contract with the developer actually says	Licensed per user or per tenant; the source is never yours	Included in your Business Central licence, with nothing dental to own

Frequently Asked Questions about Dental Clinic Management for Business Central

How long does delivery take?

This is a build-to-order extension, not an AppSource download. Typical delivery is 2-4 weeks from confirmed scope. The clock starts when you sign off the written functional specification produced from the scoping call — before that we are still agreeing procedure codes, insurance handling, chair layout and recall rules. Larger scopes such as multi-location rollout, insurer claim file generation or imaging integration are quoted with their own timeline.

Will this survive Business Central upgrades and release waves?

Yes, by construction. We build with table and page extensions and event subscribers only — no base-object modification — inside a reserved object ID range and prefix registered to your tenant. We target current release waves and test against the next preview environment when one is available. Your support window covers fixes needed because of a Microsoft release wave during that period.

What happens to support and updates after go-live?

You get a post-go-live support window for defect fixes and configuration adjustments against the confirmed scope. Beyond that we offer an optional annual support and maintenance agreement covering release-wave compatibility, bug fixes and a bank of change hours. Because you receive the AL source and the git repository, you or your own Business Central partner can maintain and extend it independently — there is no lock-in.

Does it replace our clinical charting or imaging software?

No, and it deliberately should not. Charting, radiographs and clinical notes belong in your dental clinical system. This extension owns scheduling, treatment plan estimates, billing and lab logistics inside Business Central, and exposes API pages on REST API v2.0 / OData v4 so your charting or imaging software can push completed procedures in and read appointments out. Where a specific integration is in scope we build and document the mapping as part of delivery.

How does insurance billing work?

Every treatment plan line carries a patient share and an insurer share. The insurer portion can post to a separate bill-to customer or a dedicated receivable account, so patient debtors and insurer debtors are never mixed in your aged receivables. Pre-authorisation reference, claim number and claim status fields sit on the plan. Generating a particular payer's electronic claim file format is scoped and quoted separately, because every payer's schema differs.

Does it run on Business Central SaaS, on-premises, or both?

Both. For SaaS we deliver a per-tenant extension installed to your production environment, or an AppSource-packaged app where you need that distribution route. For on-premises we deliver the `.app` for your build and assist with deployment. The same AL codebase covers both; the difference is packaging and how the job queue and outbound messaging are configured.

What do we need ready before the scoping call?

Your Business Central version and whether you are on SaaS or on-premises, your current procedure code list and fee schedule, how many chairs and providers per location, which labs you use and how they invoice you, your recall intervals, and any insurer or payer you bill directly. Sandbox access helps but is not required for the first call.