A $420 check payment was posted at 2:00 PM. At 2:14 PM it was gone. The patient’s balance went back up, a statement went out two days later, and nobody noticed until the patient called.
Deleted payments are the single most useful thing to watch in a practice ledger, because an honest deletion is almost always followed by a re-post, and a dishonest one is not.
Why do payments get deleted at all?
Ordinary reasons, in roughly the order you will see them:
- Posted to the wrong family member. Deleted and re-posted within minutes.
- Wrong payment type (card entered as check). Same thing.
- A check that bounced. Deleted or reversed days later, usually with a note.
- A duplicate entry from a card terminal that was also posted by hand.
- Training. New staff delete and redo more than experienced staff.
The deletion itself is not the signal. The absence of a re-post, and the distance in time from the original entry, are.
How does each system record a deletion?
Open Dental. The deletion writes a row to securitylog with the permission type for payment edit or delete, the UserNum, LogDateTime, PatNum and CompName (the workstation). The deleted row may also leave a tombstone in deletedobject with the object type and a time stamp, without the user. To see them: Tools, Audit Trail, then filter by permission type and date.
Eaglesoft. Nothing is physically removed. The original payment row in transactions_header stays with status changed from A (live) to D (voided), and the system writes a reversing mirror row with status V. The user_id column is the provider on the transaction, not the person who voided it; the person is in the separate audit utility. To list voided payments, use the Audit utility under Utilities, or ask whoever runs your SQL reports for rows where status is D and type is A or P.
Dentrix. This is the hard one. admin.payment_view has no user column and no modified time. A deleted payment simply stops appearing. The only ways to see it are the Audit Trail Reports in Office Manager (Reports, Ledger, Audit Trail Reports) or a day-over-day comparison of the payment rows. If you run Dentrix, that comparison is the control you need, and it has to be done by something outside the office.
What thresholds are useful?
A rule that alerts on every deletion is a rule nobody reads. Three filters cut most of the noise:
| Filter | Keep if | Why |
|---|---|---|
| Time since posting | more than 24 hours | Same-day deletions are nearly all corrections |
| Re-post | no payment on the same account within 7 days | A re-post closes the question |
| Amount | above $100, or any cash amount | Small card corrections are common; cash is the one that matters |
A worked example with made-up but realistic figures: 38 payment deletions in a month. 29 were deleted within an hour of posting. Of the remaining 9, 7 had a matching re-post within two days. That leaves 2 events worth a conversation, which is the right number for an owner to look at in a month.
What do you do with one?
- Pull the account ledger for 14 days either side of the deletion.
- Check for a re-post, a reversal note, or a bounced check record.
- Check whether an adjustment appeared on the account after the deletion. A deleted payment followed by a courtesy adjustment of the same amount is the pattern that deserves most attention.
- Compare the day sheet for the original posting date to the deposit for that day. If the $420 check was deposited, the money is in the bank and the deletion was a ledger mistake.
- Ask the user who made the change what happened, with the row in front of you. Most answers are ordinary.
The write-off report page covers step 3 in more detail, because adjustments are where a deleted payment usually gets hidden.
What Calibic adds
Protect is LIVE. Calibic reads securitylog and deletedobject in Open Dental, transactions_header status changes in Eaglesoft, and compares admin.payment_view snapshots in Dentrix, all read-only. It applies the filters above and raises an alert like “Completed payment deleted, front desk, WS-03, 2:14 PM, High” with the before and after values kept. On Dentrix the alert says the change is observable but not attributable, because the software does not record who did it. Calibic never writes to the PMS and never deletes anything itself.
Next step: see an alert on the Protect product page.