How old is that claim, really
Every claim carries at least three dates: the date of service, the date it was first submitted, and the date it was most recently submitted. An aging report has to pick one to count from, and different reports pick differently. That is why the same claim can appear as ninety days old on one screen and six days old on another, in the same office, on the same afternoon. Neither report is broken. They are measuring from different starting lines. For a worklist, age from the date of service, because it is the only one a resubmission cannot reset.
Three dates a claim carries
Open a single claim and several dates are looking back at you. They get confused constantly, because reports label them loosely, the labels differ between systems, and two of them are often shown in adjacent columns with almost the same heading. Here is what each one actually is, and the one job each is good for.
- Date of service
- When the treatment was done. It never changes, it is the date the patient remembers, and it is the date most payers run their filing limit from. Because nothing anyone does later can move it, it is the only date that gives a stable answer to the question of how long this money has been outstanding.
- Date first submitted
- When the claim first left your office. Useful for exactly one measurement: how long a payer takes to respond. It says nothing about how old the underlying treatment is, because a claim can sit unbilled in the office for weeks before anybody sends it, and that delay is invisible on this basis.
- Date last submitted
- When the claim was most recently sent. It moves every time anyone resends, corrects, or refiles. It is the right answer to did we send this again after we called them, and the wrong answer to almost everything else.
- Date the record was last touched
- Most systems also stamp the claim record whenever anything about it changes, which can include somebody simply opening it or an overnight process rewriting a field. It is a housekeeping timestamp, never a measure of age. If a claim quietly changes age columns on a day nobody worked it, this is usually the reason.
Notice what splits those four. The first two are facts about the treatment and the payer. The last two are facts about your own activity. An aging report built on the second kind is measuring how busy the office has been, not how long the money has been waiting, and those are very different questions to hand a team on a Monday morning.
What resubmission does to the clock
Picture one ordinary claim. It goes out the week of the appointment. A month passes with nothing. Somebody notices it on the report, calls the payer, and is told there is no record of it, so the claim is sent again. A few more weeks pass, it comes back needing a radiograph, the attachment goes on, and it is sent a third time. Nothing in that story is unusual. That is a claim being worked properly by people doing their jobs.
Now age that claim. Measured from the date of service, it is old and getting older, which matches what everyone in the building believes about it. Measured from the last submission, it was a few days old after the first resend, a few days old again after the second, and it will be a few days old again after the third. On that report the claim never ages at all. It is rejuvenated by exactly the activity that was supposed to resolve it.
Follow that through and the consequence is precisely backwards. The claims that get chased hardest look the youngest, so they sort to the bottom of a list read oldest first. A diligent team makes its worst claims invisible. The oldest column looks clean, the office concludes it does not have an aged claims problem, and the same handful of claims keeps circulating until one of them passes the point where anybody will pay it. Nobody made a mistake. The report was answering a different question from the one being asked of it.
There is a quieter version of the same failure. When a corrected claim is created as a new claim rather than a replacement, one piece of treatment ends up with two open records: the abandoned original ageing in the far column and the replacement looking fresh. On a last submission basis the pair looks like one old mystery and one healthy new claim, when in truth it is a single claim that has been outstanding since the appointment.
Which basis your reports are using
No page can tell you which basis your reports use. It varies by software, by version, and sometimes between two reports in the same system that share a name. You can find out yourself in about two minutes, and it is worth doing once rather than guessing forever. What the report counts in the first place is a separate question, covered in the guide on reading an insurance aging report.
- Pick one claim you know has been resubmitted. Open it and write down two things: its date of service, and the most recent date it was sent. Any claim will do as long as those two dates are far apart, because the whole test depends on the gap.
- Find that same claim on each report that shows an age. The aging report, the claims list, any saved view somebody built, and whatever the front desk actually reads in the morning.
- Read which gap the age matches. If it matches the time since the date of service, that report ages from service. If it matches the time since the last send, it ages from the last submission. If it matches neither, it is using the first submission or a housekeeping timestamp, and a second claim will tell you which.
- Repeat for every export. Exports frequently use a different basis from the on screen report of the same name, because whoever wrote the export chose a column and nobody has ever had reason to check that the two agree. The same goes for any analytics or reporting layer sitting on top of the software.
- Write the answer down where the team can see it. Next to your confirmed status codes, in whatever document already holds the small facts about your system, so the next person does not have to work it out again.
Do the same before any number leaves the building. A figure quoted to an accountant, a consultant, or a lender only means something with its basis attached. Claims over ninety days describes two very different populations depending on which start date produced it, and the person receiving the number has no way to tell which one they were handed.
The date the filing deadline runs from
A filing limit is commonly counted from the date of service. That is the second reason to prefer that basis for the worklist: where it holds, it is the clock the payer is keeping, so aging from it puts your list in the same order as your actual risk. The claim closest to being uncollectible sits at the top, which is where a human should be looking.
We are not going to publish a limit here, and you should not take one from any list on the internet. Both the length of the limit and the event it starts from are terms of a specific plan and a specific participating provider agreement, and they vary. Find them in the payer’s own provider manual or in your signed agreement, and record them per payer alongside the payer name, so the answer lives beside the claims it governs rather than in somebody’s memory.
Record the starting event as well as the number, because that is the part people skip. A limit counted from the date of service and a limit counted from some later event behave completely differently on the same claim, and a secondary claim in particular may run from a different starting point altogether.
What to do when a claim comes back refused for being late is a separate subject, and it is covered in the guide on claims denied for timely filing.
Picking one basis and holding it
The recommendation is short. Use the date of service for the worklist and for any figure the office compares month over month. Keep first submission for a payer turnaround measure, reported separately and labelled so nobody mistakes it for an age. Never mix the two inside one number, because a blended figure cannot be interpreted by anybody, including the person who built it.
Making the choice stick
- Write it down as a decision, not a preference. One sentence naming the basis, kept with the rest of your reporting notes. A basis that lives in one person’s head is a basis that changes when that person is away.
- Apply it to every report, export and saved view. One screen left on a different basis is enough to put two believable ages for the same claim in front of two people, and sorting that out costs more time than fixing the screen did.
- Confirm it again after an upgrade or a conversion. This is the one that catches people. A conversion can rewrite submission dates while leaving dates of service intact, so on a last submission basis every claim in the practice looks new on the first day in the new system. The oldest column empties overnight and it looks like a win.
- Say the basis out loud whenever the number is quoted. Aged from date of service. Five words, and a whole class of arguments about whose number is right stops happening in your office.
This decision does not add any information to your reports. It decides which claim a human picks up first, and every other improvement to the process runs downstream of that ordering. Get the starting line right and an ordinary list, worked oldest first, does most of the work by itself.
The short version
- A claim carries at least three dates, and an aging report is only meaningful once you know which one it counts from.
- Aging from the last submission means every resend restarts the clock, so the claims your team works hardest look the youngest.
- The date of service is the only basis a resubmission cannot move, which is why it belongs under the worklist.
- First submission answers exactly one question, how long the payer took, and should be kept separate and labelled as such.
- A filing limit is commonly counted from the date of service, though the starting event is a term of the specific plan, so aging from anything else can hide a claim that is nearly out of time.
Read next
Where this sits in Practice Evolved
Practice Evolved ages every claim from its original date of service, so a resubmission does not reset the clock and a claim that has been chased repeatedly still sorts where it belongs. The basis is stated on the screen rather than assumed, so nobody has to reverse engineer it from a claim they happen to recognise. That is an architectural choice about which date the list is built on, not a claim about what the list will collect.