Days in A/R, explained: what actually moves it

Days in A/R is the metric every revenue-cycle leader watches, and one of the easiest to misread. It is often treated like a dial: staff up the follow-up team, work the aging buckets harder, and wait for the number to drop. Sometimes it does. But that does not mean the underlying problem changed. Days in A/R is a lagging indicator. By the time a claim shows up in your aging report, the decisions that determined how long it would sit there have already been made. If you want to move the number durably, you have to move what happens before the claim ever leaves the building.

What days in A/R actually measures

Days in A/R measures the average number of days it takes to collect on services after they are billed. The standard formula is simple: take total accounts receivable and divide it by average daily charges, usually gross charges over the trailing 90 or 365 days. The result is the number of days of revenue currently tied up in unpaid claims and patient balances. It is the industry-standard construction. The AAFP's practice-finance guidance walks through the same calculation, and HFMA's MAP Keys define the hospital version — Net Days in A/R — the same way, using net revenue.

But the important point is this:

Days in A/R is a velocity measure, not a quality measure. It tells you how fast money is moving from "service rendered" to "cash in the bank." It does not tell you why it is moving at that speed. Two practices can have identical days in A/R and very different revenue-cycle health. One may be collecting cleanly and consistently across payers. The other may be masking a pile of stuck old claims behind a wave of newer, fast-paying ones.

That is why the headline number is rarely enough on its own. The two cuts that tell you more:

• A/R aging buckets. The share of A/R sitting in 0–30, 31–60, 61–90, 91–120, and 120+ days. These are the same buckets HFMA uses in its Aged A/R MAP Key. A healthy book is weighted heavily toward the youngest bucket. Money piling up past 90 days is usually the signal that something upstream is breaking down.
• A/R over 90 days as a percentage of total A/R. A single ratio that cuts through the average and shows how much of your receivable has gone stale.

What's healthy, and what isn't

Benchmarks vary by specialty, payer mix, contract terms, and patient-responsibility share, so any single target needs context. That said, the published reference points are consistent:

• Days in A/R: The AAFP's guidance is that days in A/R "should stay below 50 days at minimum; however, 30 to 40 days is preferable." North of 50 usually means something is consistently slowing collection.
• A/R in the oldest buckets: The AAFP's long-standing benchmark, published in Family Practice Management, keeps less than 20% of total A/R aged 120 days or more. Many groups run a stricter version at the 90-day line. When that share creeps up, the average can still look fine while old money quietly accumulates.

That is the trap: optimizing the average in isolation. You can compress the headline number temporarily by writing off stubborn old balances, riding a wave of cleaner claims, or collecting faster from a favorable payer mix. The metric improves, but the process that created the slow claims has not necessarily changed. The aging distribution is harder to fool. When the older buckets shrink, the improvement is more likely to be real.

Why days in A/R is a lagging indicator

Here is the part that is easy to miss: most of your A/R days are decided before submission, not after.

A claim that goes out with the wrong member ID, a missing modifier, a coding inconsistency, or a service the patient was not actually eligible for does not get paid late because your follow-up team is slow. It gets paid late because it was wrong when it left. That claim may be rejected at the clearinghouse or denied by the payer. Then it has to be corrected, reworked, and resubmitted. That adds days, sometimes weeks, to its journey. Every rejection is a payer review cycle thrown away. The clock started the moment the flawed claim went out.

The upstream levers that actually govern A/R days are:

• First-pass acceptance rate. The share of claims accepted on the first submission, with no rejection or rework. Every claim that clears on the first pass collects on the payer's fastest available timeline. Every one that does not starts another loop.
• Eligibility and verification of benefits before the visit. Coverage problems caught at the front desk never become 90-day A/R. The same problem caught after submission becomes a denial, a correction, an appeal, and weeks of delay.
• Clean-claim submission speed. The gap between service date and the moment a correct 837 reaches the clearinghouse. Charges that sit for days before going out add those days directly to A/R before a payer has even seen them.

Working the aging report harder treats the symptom. It can recover individual stuck claims, and that work matters. But it does not change the rate at which new stuck claims are created. The cheaper, more durable fix is upstream.

How clean front-of-cycle work compresses A/R

A/R is not fixed in aging. It is shaped at the front of the cycle. That's why the most reliable way to compress A/R is to fix the front of the cycle—not chase the back of it harder.

That is the part of the cycle AcuraClaim runs. AcuraClaim agents re-check eligibility and benefits before a charge bills, assign and check coding, scrub claims against payer rules, submit clean 837s, and post the ERA/EOB when the payer responds with the 835. The aim is a higher first-pass acceptance rate and faster clean-claim submission. Fewer rejections and faster clean submissions mean fewer claims restarting the adjudication clock. That is what actually moves the A/R average and keeps money out of the 90-plus buckets.

To be explicit about scope: AcuraClaim is front-of-cycle only. We do not do A/R follow-up, denial management, appeals, or payer phone calls. Those back-end functions are real and necessary RCM work. They are just not what we do. We compress A/R days by reducing the upstream errors and delays that create slow claims in the first place — not by working the aging report. By the time A/R shows up in the report, the front end has already done its work. The question is whether it created speed — or delay.

To see the front of the cycle run end to end, book a demo.