A $310 patient payment was on the ledger on Tuesday. Today the account shows a balance again and nobody remembers why. Eaglesoft keeps a record of that change. Finding it, and reading it correctly, takes a little knowledge of how Eaglesoft stores a void.
Where is the audit trail in Eaglesoft?
The audit tools sit under the Utilities menu, as an Audit option. It asks for a login, and the security level attached to that login decides what you can see. Some offices know it as the audit trail app or the audit trail login because of that prompt.
Once open, you can filter by date range, by the kind of change (ledger, appointment, patient) and by user where Eaglesoft recorded one.
How does Eaglesoft record a deleted payment?
This is the part worth understanding, because it changes what “deleted” means on a report.
Every ledger entry is a row in a table called transactions_header. A service is type S. A patient payment is type A. An insurance payment is type P. A credit adjustment is type C and a debit adjustment is type D. Each row has a status.
When someone voids a payment, the original row does not disappear. Its status changes from A (live) to D (voided). Eaglesoft then posts a second row, with status V, that reverses the first. So a void leaves two rows behind, both dated, both with the amount. Nothing is physically removed.
That is good news for an audit. A voided $310 payment is still in the table with the amount and the date. The question is who voided it.
What does it not record?
Here is the honest part. The user_id column on transactions_header points at a provider, not at the person who typed the entry. When our team verified the Eaglesoft schema across six practices (Eaglesoft 17 through 25, September 2026), that was consistent on every one. So the ledger row tells you which provider the payment was credited to, and does not tell you which staff member voided it.
The audit screen under Utilities may show a user, because Eaglesoft’s program writes its own audit records with the login. Run it for that reason. But over the database itself, attribution of a ledger change to a person is not available, and anyone who tells you otherwise is guessing.
Appointments are similar. The appointment table records arrival, in-chair and walk-out times, which is how a visit’s status is known, but it carries no column for who moved or broke the appointment.
How do I run a weekly audit?
- Open the audit under Utilities for the last seven days, ledger changes only.
- Print the Day Sheet from End of Day for each of those days.
- For every void, find the original row and the reversing row. Check whether the same amount was re-entered the same day. If it was, it is a correction. If it was not, the deposit for that day should be short by exactly that amount.
A worked example. The week shows 9 voids. 6 are a payment voided and re-entered within minutes with the same amount, a wrong patient or wrong payment type corrected. 2 are insurance payments voided when the EOB was re-read. 1 is a $310 check payment voided on Wednesday, never re-entered, and Wednesday’s Deposit Slip is $310 lighter than the Day Sheet. That is the entry to ask about, with the date and the patient in hand. The audit will not hand you the name, so the conversation starts with “who closed Wednesday?”
Do this on the same day each week and write down that you did.
What Calibic adds
Protect is LIVE, and Eaglesoft coverage is partial. Calibic reads transactions_header, appointment, patient and provider over a read-only connection every few minutes. A row whose status changes from A to D becomes an alert with the amount, the date and the mirror row kept as evidence, even though Eaglesoft does not record the person. Alerts that need an actor to be meaningful are listed on the Coverage page as limited on Eaglesoft rather than shown with a guessed name.
Calibic never writes to transactions_header and cannot void or restore a row.
See how evidence is kept on the Protect product page. The sibling guide on the Open Dental security log shows what a log that names the user looks like, for comparison. What Calibic reads from Eaglesoft, and the checks that cannot run on it yet, are on the Eaglesoft integration page.