Can ACH work without replacing Dentrix?
The practice needed a bridge around the existing system, not a migration project disguised as savings.
Case study
Dental payment integration
The operating question
How can a practice move recurring payments to lower-cost ACH without manually reconciling every payment?
What the team needed to solve
The fee was visible. The operating constraint was not.
Moving recurring payments to ACH was the easy part. The harder problem was preserving the practice’s existing ledger workflow without creating a second administrative system.
How does each payment reach the right patient account?
Patient matching and posting had to happen safely on the clinic workstation.
How does the system stop safely?
Ambiguous matches and reversals enter an exception state. A posting completes only after Dentrix read-back confirms the expected ledger state.
Before · manual loop
Every cleared payment created another front-desk task.
- Watch the processor
- Find the patient and ledger
- Re-key the payment details
- Reconcile outside the posting action
Designed path · controlled posting
The common path is automated. Uncertain states stop for review.
- Retrieve an opaque payment event
- Match the local account or stop
- Post into Dentrix
- Read back and record proof or failure
The system boundary
Move the payment event. Keep patient identity inside the clinic.
The cloud service carries opaque payment information. Patient linkage, posting logic, exception detail, and Dentrix interaction remain on the clinic workstation.
Cloud boundary · No patient identity
Clinic boundary · Patient identity remains local
Stripe
Records a cleared ACH payment.
Cloud service
Holds only the payment information needed for retrieval.
Clinic-side service
Runs on the clinic’s Windows computer.
Patient match
Resolves the local account or stops for staff.
Dentrix post
Enters the payment through the existing interface.
Read-back
Confirms the ledger or records failure.
What crosses: opaque payment information needed to retrieve work.
What stays: patient linkage, account context, posting detail, and exception evidence.
Human control
The important decisions are the ones the system refuses to make.
The normal path can move quickly because ambiguous or high-risk states stop, remain visible, and return to staff.
Patient linkage remains in the clinic environment.
An uncertain patient match enters an exception state.
Idempotency and deduplication controls protect the ledger.
The system reads the ledger back and records confirmation or a structured failure.
Actual built interface
The clinic-local posting queue. Shown with synthetic test data. Visible counts and records are demonstration fixtures, not client outcomes.
What this record establishes
The payment path, local patient-matching boundary, exception handling, posting controls, and ledger read-back were built, and the system is deployed and running in production at the clinic. Realized savings and other business outcomes are not quantified here.
See the product
CHOMP is designed around this payment path.
Explore the product built around lower-cost ACH and clinic-side payment posting.