Orthodontic Practice Software: Why Multi-Location Groups Outgrow Dolphin and Ortho2, and What to Build Instead

Why practice software makes or breaks an orthodontic group

Orthodontics is not general dentistry with wires. General dentistry is transactional: procedure, claim, payment, done. Orthodontics is a 24 month contract with a down payment, a monthly autopay schedule, an insurance assignment that pays quarterly on its own calendar, a treatment plan that changes at month 9, and a patient who moves out of state at month 14 with $2,400 of unearned revenue on the books. Your practice management system was built to schedule appointments and file claims. It was never built to be a subscription billing engine with clinical dependencies, which is what an ortho group actually is.

Walk into a six-location group doing 1,800 starts a year and this is the stack. Dolphin Management or Ortho2 Edge or Cloud9 holds the schedule, the imaging and the ledger. Then there is a shared drive with a workbook called Contracts_Master_v4_USE_THIS.xlsx that the regional treatment coordinator maintains, because nobody trusts the aging report in the PMS after the third mid-treatment contract revision. There is a separate tracker for Invisalign cases, because the Invisalign Doctor Site knows a refinement was ordered but the PMS does not, so the front desk finds out a case is in refinement when the patient asks about it. There is a Google Sheet for insurance because the EOBs post quarterly and someone has to manually split the payment across 40 patients. There is a QuickBooks file where a bookkeeper re-keys the month.

It is the 8th of the month, and your regional manager is on a call with the Riverside office TC. A patient started in March at $5,900 over 26 months. In September the doctor extended to 32 months and swapped to aligners for the finishing phase. The TC edited the contract in Dolphin. The autopay in the merchant portal was never changed. The insurance assignment still assumes the original end date. Riverside's production number now disagrees with the ledger by $3,100, and the only way to find out why is for two people to spend 90 minutes reading the treatment card and the payment history side by side. Multiply that by six offices. When we have timed this in discovery, it runs 25 to 40 hours a month of senior staff time, and it is the reason nobody in the group can answer "what is our actual contract balance" without a week of notice.

Problem 1: Mid-treatment contract changes break every downstream system at once

A contract change in orthodontics is not an edit. It is an event with five consequences: the remaining balance changes, the autopay schedule changes, the insurance assignment changes, the revenue recognition changes, and the patient needs a new signed agreement. Dolphin and Edge treat it as a field update. You change the number, the ledger recalculates, and the merchant processor, the insurance record and the signed contract file all go stale without telling anyone.

The specific failure we see: a $5,900 contract extended by 6 months. The office adds the months but leaves the monthly at $195 because that is what the patient budgeted. Now the contract collects $6,240 against a $5,900 agreement, and nobody catches it until the patient's final payment bounces the balance negative. Or the reverse, which is more common: the term extends, the monthly drops, and the group under-collects a few hundred dollars per affected patient. One group pulled their own revision rate for us and it was north of one start in ten, which put roughly 200 contracts a year into drift.

No amount of configuration fixes this, because the PMS ledger and the payment processor are different vendors with a one-way sync. Dolphin pushes a payment plan out. It does not own the schedule after that, and it has no concept of a contract version.

What a custom build does: model the contract as an immutable event log, not a row. Original terms, then amendments, each with an effective date, a reason code, an approving doctor and a delta. Every amendment fires a workflow: recompute the remaining schedule, push the corrected schedule to the processor via API, regenerate the agreement PDF, send it for e-signature, and flag the insurance assignment for review. The TC sees one screen: "Extend treatment 6 months" with a live preview showing the old schedule, the new schedule, the total collected either way, and a hard block if the amended total does not match the amended agreement. The reconciliation stops happening because the drift stops happening.

Problem 2: Aligner cases live in a vendor portal your practice software cannot see

If a meaningful share of your starts are Invisalign or SureSmile, half your clinical operation runs in the Invisalign Doctor Site or the SureSmile portal, and your PMS has no idea. The case is submitted there. The ClinCheck is approved there. Refinements are ordered there. Shipment tracking is there. Your practice software knows only that a patient has an appointment.

The operational cost: a patient shows up for a delivery appointment and the trays are not in. The chairside assistant walks to a computer, logs into the doctor site, checks the shipment, discovers it went to the wrong office because the case was submitted from Riverside while the patient now sees the doctor at Eastvale. That is a dead chair slot, a rescheduled patient, and a doctor standing idle. You already know your production per chair hour. Multiply it by how often this happens, which is a number nobody in the group is currently counting.

Align does not owe your PMS vendor an integration, and your PMS vendor has no commercial reason to build one deeply, so what exists is thin and will stay thin.

What a custom build does: an aligner case object that lives in your system and syncs case state from the vendor, either through available APIs or, where no API exists, a scheduled headless job that pulls the case list and status per doctor account. Every case has a stage, an expected ship date, a destination office, a tray count, and a refinement count. Two things fall out of that immediately. First, the scheduler refuses to book a delivery appointment for a case whose trays are not marked received at that office. Second, refinement count becomes a number your clinical director can see: in one group we built this for, the refinement rate roughly doubled between two doctors on a comparable case mix, and until it was in a report nobody managed it.

One place AI does real work here: ClinCheck approval notes, lab prescriptions and doctor scan notes are unstructured text and PDFs. A document extraction pass reads them on ingest and populates structured fields: planned tray count, IPR requirements, attachment stages, planned finish date. You get a case record you can query instead of a PDF someone has to open.

Problem 3: Insurance pays on a schedule your PMS does not model

Ortho insurance is its own animal. A $1,500 lifetime max, paid as $375 down and $46.88 monthly for 24 months, assigned to the practice, posted quarterly, subject to the patient staying eligible. When the patient's employer changes carriers at month 11, the remaining benefit evaporates and the patient owes the difference. Your PMS records the claim. It does not model the benefit as a receivable that decays.

The scene: your insurance coordinator has a spreadsheet of expected quarterly payments per carrier. A $9,200 check arrives from Delta Dental covering 38 patients. She spends most of a day splitting it. Two patients on that EOB terminated coverage in the prior quarter, so the practice is now carrying $1,100 of patient responsibility that nobody told the patient about, and the first the patient hears of it is a balance letter 90 days later. That conversation costs you a referral.

PMS vendors implemented the claim, not the benefit lifecycle, because ortho insurance modeling is a small enough market to skip. There is no eligibility re-verification loop tied to contract balance in any of them.

What a custom build does: model the insurance benefit as a distinct receivable with its own schedule, its own carrier, its own eligibility status. Run automated eligibility re-checks against clearinghouse APIs on a cadence, monthly for active contracts. When eligibility changes, the system computes the patient responsibility delta immediately, drafts the patient communication, and routes it to the TC for approval, at month 11 rather than month 14. Bulk EOB posting becomes a document extraction job: the ERA or scanned EOB gets parsed into patient-level line items, auto-matched against expected amounts, and only the exceptions land in a human queue. Your coordinator reviews 6 exceptions instead of splitting 38 lines.

Problem 4: You cannot see the group, only six copies of one office

Multi-location ortho groups run a database per location, or a location filter that most reports ignore. Ask "what is our contract receivable across the group, aged, by office, net of insurance" and the honest answer is that someone exports six reports and pivots them. Ask "which office has the most starts stalling before down payment" and there is no answer at all.

This gets worse the moment you acquire. Acquire a two-office practice on Cloud9 while you run Dolphin, and now you have two clinical systems, two ledgers, and a 9 month migration project that nobody has time for. Most groups just run both and reconcile in Excel forever.

The PMS is licensed and architected per practice, so group reporting is an add-on that reports what the PMS knows, and the PMS does not know about the contract amendments and aligner states that explain the variance.

What a custom build does: your contract and case layer sits above the PMS instances, not inside them. Each PMS is a source: patient demographics, appointments and clinical data flow in through the vendor API or a nightly extract. Contracts, aligner cases, insurance benefits and payments live in your system, keyed to a group-level patient ID that survives a patient transferring between offices. The acquisition problem inverts: you do not migrate the new practice's PMS, you connect it as another source and the group layer covers both from week one. Forecasting on top of that data is worth the line item, because a contract portfolio is a predictable cash stream: model expected collections per office per month from scheduled contract payments, insurance schedules and historical delinquency by cohort, and you get a 90 day cash forecast accurate enough to plan hiring and equipment against.

Problem 5: The gap between the consult and the start is where money dies

A patient sits for an exam, gets a treatment plan, and does not sign that day. In most groups that patient enters a pending list, gets a call attempt or two, and then disappears. Nobody knows the group's true consult-to-start conversion because the denominator lives in one place and the numerator in another.

Your PMS gives you a recall list. It does not give you a pipeline, because it models appointments, not opportunities.

What a custom build does: treat every treatment plan presentation as an opportunity object with a value, an owner, a stage and an age. Not signed in 48 hours triggers a sequence: a text with the treatment plan summary and the monthly, a financing pre-qualification link, a follow-up at day 4 and day 11. Where AI earns the line item: after-hours inbound. Pull your own call log for last month and count how many rang after five or during a Friday huddle. A voice agent that answers "how much are braces", quotes the actual starting monthly from your fee schedule, and books a real consult into a real open slot in the PMS scheduler recovers appointments that currently go to whoever answers first. The same engine drafts the follow-up from the treatment plan and the conversation history for the TC to approve and send. Three points of conversion at 1,800 starts and a $5,900 average contract is roughly $320k of contract value a year. That is arithmetic on your own numbers, not a projection.

What this costs and how long it takes

Across 2,000-plus projects, the Digital Heroes pattern for this category is consistent. A focused first release, meaning contract lifecycle with amendment handling, payment schedule sync to your processor, and a group-level receivable dashboard reading from one PMS, runs $60k to $130k and ships in 12 to 16 weeks. A full platform, adding aligner case sync, insurance benefit modeling with eligibility loops, EOB extraction, the opportunity pipeline, the AI intake agent and multi-PMS consolidation, runs $150k to $400k phased over 6 to 12 months. We ship the first release before we scope the rest, because what your TCs actually do in month one always differs from what the ops manual says.

What drives the price up in orthodontics specifically. First, PMS integration depth: Dolphin's API surface is usable, Ortho2 Edge varies by hosting, and Cloud9 access depends on your contract. If a vendor will not give you API access, we are into database-level reads or scheduled extracts, and that is real engineering. Second, payment processor migration: if you are on a processor without a schedule-management API, the amendment workflow either stays partly manual or you change processors, and that is a decision with its own cost. Third, HIPAA scope: a BAA-covered build with audit logging, per-office role separation, encrypted PHI at rest and access review is not optional and is not free. In our builds it is typically 10 to 15 percent of the cost. Fourth, number of live PMS instances at go-live: two is fine, five doubles the data reconciliation work. Fifth, aligner vendor coverage: Invisalign only is one integration, Invisalign plus SureSmile plus an in-house lab is three.

What does not drive price up as much as people expect: number of locations. Six offices and sixteen offices are close to the same build. The cost is in the number of distinct systems, not the number of chairs.

Build or buy: take the honest position

Stay on off-the-shelf if you have one to three locations, one PMS, a single doctor setting fees, and under about 400 starts a year. At that scale Dolphin plus a disciplined TC plus a decent spreadsheet is cheaper and lower risk than anything we would build, and a consultant who tells you otherwise is selling. The reconciliation pain is real at that size but it is one person, part-time.

Build when three of these are true. You have four or more locations or more than one PMS in production. Your contract receivable is above roughly $4M and you cannot state it accurately in an afternoon. More than 30 percent of starts are aligner cases whose status lives outside your PMS. You are acquiring, and the thought of migrating each acquisition onto your PMS is why you have not moved faster. A named person, usually a regional TC or ops manager, spends more than 20 hours a month reconciling numbers between systems, and that person's real job is something else.

The signal that matters most: when your growth plan requires standardizing how contracts work across offices, and the PMS cannot enforce that standard, the software is now the constraint on the business. That is the moment to build. On scope, we almost never replace the clinical PMS. Imaging, cephalometrics, the treatment card: leave those alone. Build the contract, case and money layer. That is where the leak is.

How to choose a developer for orthodontic practice software

Ask them to model an ortho contract on a whiteboard, before any proposal. If they draw a table with a balance column, they have built dental software and not ortho software. You want to hear the words amendment, effective date, and revenue recognition unprompted, and you want them to ask whether your insurance is assigned or patient-paid before they draw anything.

Make them tell you specifically how they will read from your PMS. Not "we integrate with Dolphin." Which endpoints, or which extract, at what frequency, and what happens when the vendor changes it. If they have not seen the Dolphin, Edge or Cloud9 data model before, they will spend six weeks of your money learning it, and you should decide knowingly whether to fund that.

Check that HIPAA is architecture and not a checkbox. Ask who signs the BAA, where PHI lives, how access is logged, and how a terminated employee's access is revoked across offices. Ask what happens to PHI in their development environments. A team that answers "we use synthetic data below production" has done this before. A team that says "we're HIPAA compliant" has not.

Settle ownership and exit in the contract, not the conversation. You own the repository, the infrastructure accounts and the data, from day one, not on final payment. Ask what handover looks like if you take it in-house in year two: if the answer is not "here is the repo, the runbook and two weeks of your engineer pairing with ours," keep looking. Software this central to your revenue should never be somewhere you cannot reach it.