A patient says she paid $200 cash in March. The ledger shows nothing. The front desk person who was there in March has left. The only thing that can settle it is the audit trail, if it recorded enough.
This page is about what “enough” means, and what each practice system actually records.
What should be included in an audit trail?
Six things, every row:
| Field | Why it matters | Open Dental | Dentrix | Eaglesoft |
|---|---|---|---|---|
| Who | Which user account made the change | securitylog.UserNum, joined to userod |
admin.appthist.userid for appointments; none on payments or adjustments |
transactions_header.user_id is the provider, not the person typing |
| When | Date and time, not just date | LogDateTime |
modifieddate plus modifiedtime (milliseconds since midnight) |
tran_date, plus the Utilities audit |
| Where | Workstation | CompName |
not in the SQL views | not in the ledger |
| Which record | Patient and the row touched | PatNum, FKey |
patid, apptid |
resp_party_id, tran_num |
| Before and after | The old value and the new one | log text for some permission types | snapshot comparison only | voided row kept with status D, mirror row V |
| A stable ID | So you can cite the row later | SecurityLogNum |
automodifiedtimestamp as a cursor |
tran_num |
If your system is missing a column, that is not a reason to panic. It is a reason to know which questions it cannot answer and to add a control outside the software for those.
How do the three systems differ?
Open Dental has the most complete native log. securitylog writes a row for permission-gated actions with a PermType code (the integer map shifts between major versions, so check it on your own install with SELECT DISTINCT PermType FROM securitylog). Deleted rows also leave a tombstone in deletedobject with the object type and time, though without the actor. The user list lives in userod.
Dentrix exposes no general audit table over SQL. Appointment changes are in admin.appthist with a user ID and a time. Payments (admin.payment_view) and adjustments (admin.adjustment_view) carry no user and no change time, so a deleted payment can only be seen by comparing one day’s rows with the next. The Audit Trail Reports in Office Manager are the human-readable view.
Eaglesoft keeps the ledger in transactions_header. A deleted transaction is not removed: its status changes from A to D and the system writes a reversing mirror row with status V. The user_id column names the provider on the transaction, which is often not the person who entered it. The audit utility under the Utilities menu records user activity separately.
How long should you keep it?
The HIPAA Security Rule requires that documentation of required policies and actions be retained for six years from creation or last effective date (45 CFR 164.316(b)(2)). Many practices treat six years as the floor for audit logs too. Your state may set a longer period for clinical records; follow the longer one. Keep the log somewhere a front desk user cannot purge it, and keep a copy off the server.
How do you read one?
Take one row at a time and answer four questions before forming an opinion.
- What exactly changed? A payment deleted is different from a payment moved to the right family member.
- How long after the original entry? A deletion two minutes after posting is usually a typo fix. A deletion three weeks later, after a statement went out, deserves a second look.
- What happened to the same account next? Look at the ledger for the following seven days. A re-posted payment closes the question. A courtesy adjustment opens one.
- Does the pattern repeat for the same user? One event is noise. The same shape five times in a month is a pattern.
A worked example. Row 48,211 in securitylog: PermType for payment delete, user 7, 2:14 PM, workstation WS-03, patient 10,442. The ledger shows a $420 check payment posted at 2:00 PM the same day and nothing after. Statement history shows a statement sent two days later with the $420 still owing. That is one event with a clear shape. It is not proof of anything; the check may have bounced. It is a question for the person who was logged in as user 7, asked calmly, with the row in front of you.
What a log cannot tell you
A log records what the software saw. It does not see cash that was never entered at all. That gap is closed by the daily reconciliation of the day sheet against the deposit, not by any report.
What Calibic adds
Protect is LIVE. Calibic reads these tables read-only (it never writes to the PMS) and keeps its own time-stamped record of payment and adjustment changes with before and after values, outside the practice. It knows which system can name the actor and which cannot, and labels each event accordingly. It raises alerts only for a small set of patterns; in our audit of about 1.4 million change events across three practices (anonymised example, internal audit, October 2026) the calibrated rules raised 15 alerts where the old rules raised 5,959.
The deleted payments page is the sibling to read next. Then see the Protect product page for what the record looks like on screen.