The Eaglesoft outstanding claims report, read correctly

Where the report lives

Eaglesoft groups its reports by area, and the outstanding claims list sits with the insurance reports rather than with the account or production reports. Instead of hunting for an exact menu label, look for the report that asks you for an insurance company and a date range before it will print anything. That pair of prompts is the reliable way to know you have the right report. Labels and groupings differ across versions, so the name somebody wrote on a training handout may not be the name on the machine in your office today, and the report is still there under a different heading.

Before you print anything, look at what the report is asking you for. Every parameter on that screen changes the total, and three of the four change it in ways that are easy to miss later.

• Date range. Decides which claims are eligible. It is worth knowing whether your version applies the range to the date of service or to the date the claim was submitted, because the same window produces two different lists. If nobody in the office knows, run the same range twice on a quiet afternoon and compare what comes back.
• Insurance company. Narrows the list to one payer. Leave it open when you want the whole picture, then narrow it when you start making calls, because the call itself is per payer.
• Provider. Filters to one dentist or hygienist. Useful for a conversation with that provider, misleading as a practice total, because a provider filter quietly removes claims rather than telling you it did.
• Preauthorizations. Whether to include the requests your office sent to ask what a plan would cover, as opposed to claims sent to ask for payment.

What each column counts

The columns look self explanatory, and two of them are not. Here is what an office is actually looking at, line by line.

Patient and account

Who the treatment was for, and which account carries the balance. These are different in a family, and the account is what a statement goes to.

Date of service

When the treatment happened. This is the date that matters for age, because it is the date a filing limit runs from and it does not move when a claim is corrected and sent again.

Date submitted

When the claim last left your office. Useful for judging whether a payer has had enough time to respond, and dangerous as a measure of age, because a resubmission makes an old claim look new.

Insurance company

The payer the claim went to. Worth reading as the grouping for your work rather than as a detail on a row, because payers behave as payers, not as individual claims.

Submitted total

The amount that was sent to the payer for that claim. This is the billed figure, and it is what the total at the bottom of the report is adding up.

Estimated amount

What your system expects the payer to pay on that claim, based on the coverage table and fee schedule in place when the estimate was made. It is a prediction your office made, not a commitment the payer made.

Claim status

The short code that says where the claim stands. It is also the field the report filters on, which makes it the single most consequential column on the page.

Submitted total and estimated amount are two different numbers about the same claim, and treating them as interchangeable is the reconciliation failure to rule out next. One is what you asked for. The other is what you guessed you would get. A meeting where one person quotes the billed column and another quotes the estimate will never reach agreement, because both people are reading correctly from different columns. The full treatment of that difference has its own page.

There is one more case worth naming because it looks like a data error and is not. Sometimes a claim shows a header total of zero while plainly carrying procedures. When that happens, the real billed amount for that claim is the sum of the fees on the procedures attached to it. Any report or export that reads only the header will understate that claim, and if there are enough of them it will understate the whole page. If you see a zero on a claim that clearly had work done, open the claim and add up the lines before you conclude anything.

The status codes that decide what appears

This is the part nobody writes down, and it is the reason two offices running the same report on the same version get lists that behave differently.

Eaglesoft stores a claim status as a short code rather than as a sentence, and the report filters on it. What each code means in practice is a configuration decision inside your database, shaped by how your office was set up, what was migrated in from an earlier system, and what habits your team formed since. It is not a universal standard you can look up and rely on.

The consequence is specific and it is nasty. A filter built on a code someone copied from a forum post, a vendor of a reporting add on, or an old handout can silently read no rows at all, or silently read the wrong rows. Neither failure announces itself. The report still runs, still formats, and still prints a total at the bottom that looks exactly as authoritative as a correct one. An office can work a wrong list for months and the only symptom is a nagging sense that the numbers do not tie out.

How to confirm your own codes

The fix is one sitting, once, and it is the most valuable sitting available anywhere in this subject.

1. 1Pick claims whose real outcome you already know. Five or six is enough. One that is genuinely open and waiting on a payer. One that was denied. One that was paid and closed out properly. One that was corrected and sent again. One preauthorization.
2. 2Open each one and note the exact status it carries. Not what you think it should say. What it says.
3. 3Build your filter from those observed values, not from anything you were told. If a value surprises you, that surprise is the finding.
4. 4Write the list down where the whole team can see it. A printed card by the insurance desk beats a note in one person's head, because the person who knows the codes is the person who eventually goes on holiday.
5. 5Confirm again after any upgrade or any conversion, and after anyone changes how claims are worked. Codes drift when workflows drift.

Four reasons the total looks wrong

When the number at the bottom is bigger than anyone believes, it usually is, and it is usually one of these. Each has a different tell on screen and a different fix, which is why a total on its own never tells you what you are looking at.

1. 1Preauthorizations were included in the run. Spot it by scanning for rows with no expectation of payment attached, or by rerunning the report with preauthorizations excluded and watching the total drop. The fix is to run them separately, always. A preauthorization list is a scheduling tool and belongs in a different conversation than a collections list.
2. 2Claims were paid but never closed. Spot it by picking three old rows and checking the account for a posted payment against that treatment. If the money is there, the claim is stale, not outstanding. The fix is to close them out, and to make closing part of posting rather than a separate task somebody does later.
3. 3Duplicates were created by resubmission. Spot it by sorting by patient and looking for the same date of service twice with different submission dates. One piece of treatment, two claim records, both counted. The fix is to resolve the record that is no longer in play, and to standardise on whether your office corrects and resends an existing claim or creates a new one.
4. 4Secondary claims were never sent. These sit in a state that reads as outstanding even though nothing has ever reached the secondary payer. Spot it by checking whether the row has a submission date at all, or whether the primary payment was posted long ago and nothing followed. The fix is to send them, and then to look at why they stopped: almost always it is that sending the secondary is a manual step nobody owns after the primary payment posts.

How to work the list

Once the list is honest, the work is mechanical. The order matters more than the effort.

1. 1Run it oldest first. Age is the only thing on this report that gets strictly worse while you ignore it, and the oldest rows are the ones closest to a deadline no appeal recovers.
2. 2Group by insurance company, not by patient. The phone call is per payer. One call that covers a payer's whole stack is one call. A call per claim is a morning gone, and you will read the same script to a different representative all day.
3. 3Set aside anything past the filing limit as its own pile. The action there is different: it is a decision about writing off, appealing on documented grounds, or billing the patient where the contract allows it, not another status call to a payer.
4. 4Record the outcome of every call against the claim itself. Not in a side spreadsheet, not in a notebook, not in one person's memory. The next person to open that claim needs to see what the payer said and when, or the whole call happens again.
5. 5Never adjust a balance to clear a line off the report. A row that disappears because someone wrote it down to zero looks identical to a row that was collected, and the report loses the ability to tell you anything. If the money is not coming, write it off deliberately and record why.

None of this needs software you do not already own. What it needs is that the list be run with the right parameters, filtered on codes somebody confirmed, and read in an order that puts the deadlines first. The reason offices stop doing it is not difficulty. It is that the whole exercise takes an afternoon, and the answer is stale again by the following week.