Every few months someone asks whether Acumatica can "run a dental practice." The honest answer is no — not the clinical side — and the useful answer is what it can do instead, which is more relevant to most multi-location dental groups than the clinical scheduling question anyway.
Say the quiet part first
Acumatica has no patient chart, no odontogram, no clinical scheduling calendar, and no HL7/dental-imaging integration built in. It is a general-purpose ERP with strong financials, inventory, and multi-entity consolidation. A dental practice's clinical workflow — charting, treatment planning, imaging, patient scheduling — lives in dedicated practice management software built for that job. If a vendor pitches Acumatica as replacing that layer, that pitch is wrong, and I would tell a client that directly rather than let them find out during implementation.
Where Acumatica genuinely fits: multi-location back office
The real use case is a dental service organization (DSO) running ten, thirty, or a hundred locations that has outgrown QuickBooks per-location and needs consolidated financials, centralized AP, intercompany billing between the management company and each practice entity, and standardized chart of accounts across locations. That is squarely an ERP problem, and it is where Acumatica's multi-company/multi-branch structure earns its cost.
The realistic architecture: two systems, one integration
The pattern I have built (in this shape, for a services group, not specifically dental) is: practice management software owns patient records, scheduling, and clinical billing; Acumatica owns the general ledger, AP, fixed assets, and consolidated reporting. A nightly or near-real-time integration pushes summarized production and collections data — not clinical detail — from the practice system into Acumatica as journal entries or AR summary documents.
POST /entity/Default/24.200.001/JournalTransaction HTTP/1.1
Content-Type: application/json
{
"BatchNbr": { },
"Description": { "value": "Location 04 — Daily Production Summary" },
"Details": [
{ "Account": { "value": "4100-PROD" }, "Branch": { "value": "LOC04" },
"CreditAmount": { "value": 8420.00 } },
{ "Account": { "value": "1200-AR" }, "Branch": { "value": "LOC04" },
"DebitAmount": { "value": 8420.00 } }
]
}No patient names, no procedure codes tied to identity — the summary crosses the boundary, the PHI does not. That is the design principle worth repeating to a client who wants "everything in one system": keep clinical/patient data in the system built and (where applicable) certified for it, and let Acumatica consume financial summaries.
The tempting shortcut is to sync patient-level AR aging into Acumatica so collections staff can work from one screen. That reintroduces protected health information (patient name plus treatment-linked charges) into a system that was not designed or configured as a covered system for that data. If patient-level AR detail is a real requirement, treat it as a deliberate compliance decision — encrypted fields, restricted roles, a signed business associate arrangement with whoever hosts the instance — not a convenience default.
Wrapping up
Acumatica does not run the clinical or scheduling side of a dental practice, and no amount of customization makes that a good idea. What it does well is multi-location financial consolidation for a growing DSO, fed by summarized, de-identified data from the practice management system that owns the patient relationship. Keep that boundary explicit and the two-system architecture works cleanly.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.