Reduce AR Days at a Medical Practice: Where the Time Actually Goes
Every practice manager has run the same report: total AR divided by average daily charges, and the number is higher than it should be. The usual response is to work the aging bucket — call the payer, refile, escalate. That treats days in AR as one clock. It isn't. It's four clocks running in series, and the levers that fix each one are different. Two of them are not payer-relationship problems at all; they're plumbing.
This article walks through where the days actually accumulate, reads a real remittance line down to the arithmetic, and gives you a checklist you can run against your own data this month.
Days in AR is four clocks, not one
The standard formula is unchanged:
Days in AR = Total AR ÷ (Gross charges over N days ÷ N)Most practices use a 90-day trailing charge window. Benchmark targets vary by specialty and payer mix — check your specialty's published benchmark rather than assuming a single industry number [verify].
The number is useful as a trend line and nearly useless as a diagnostic, because it aggregates four independent intervals:
- Charge lag — date of service to clean claim out the door. Owned by front desk and coding.
- Adjudication — claim received to 835 issued. Owned by the payer; you influence it only through claim quality.
- Settlement transit — 835 issued to funds actually spendable in your operating account. Owned by payment rails.
- Post-adjudication work — patient responsibility that never becomes a request, and denial lines nobody triaged. Owned by you, and usually invisible on the aging report until it's 90+.
Clocks 1 and 2 are where practices spend all their improvement effort. Clocks 3 and 4 are where a surprising amount of the balance sits, and they're both addressable without asking a payer for anything.
Read one remittance line before you touch your AR report
Here is a synthetic three-line professional claim as it appears in an 835. No real identifiers, no patient data — these values are constructed for illustration.
CLP*PCN-4417*1*460.00*102.40*67.60*12*ICN-2026-0731-0099*11~
SVC*HC:99214*220.00*102.40**1~
CAS*CO*45*92.00~
CAS*PR*2*25.60~
SVC*HC:92133*145.00*0.00**1~
CAS*CO*45*103.00~
CAS*PR*1*42.00~
SVC*HC:92250*95.00*0.00**1~
CAS*CO*97*95.00~The balancing rule at the service line is simple and non-negotiable — an 835 that violates it is malformed:
SVC02 (submitted charge) = SVC03 (line payment) + sum of that line's CAS adjustment amounts
Line by line:
- 99214 —
220.00 = 102.40 + 92.00 (CO-45 contractual) + 25.60 (PR-2 coinsurance)✓ - 92133 —
145.00 = 0.00 + 103.00 (CO-45) + 42.00 (PR-1 deductible)✓ - 92250 —
95.00 = 0.00 + 95.00 (CO-97, benefit included in another service)✓
Roll it up to the claim level: CLP03 − CLP04 = 460.00 − 102.40 = 357.60, and the CAS amounts across all lines sum to 92.00 + 25.60 + 103.00 + 42.00 + 95.00 = 357.60. CLP05 (patient responsibility) is 25.60 + 42.00 = 67.60, which is exactly the PR-group total. The claim balances.
Now translate that into AR:
| Amount | What it is | Correct AR treatment |
|---|---|---|
| $195.00 | CO-45 contractual | Not AR. Should leave the balance the moment the 835 posts. If it's aging, your posting logic is wrong. |
| $102.40 | Payer payment | In transit. Aging until the funds land — clock 3. |
| $67.60 | PR-1 + PR-2 | Patient AR. Ages indefinitely unless converted into an actual request — clock 4. |
| $95.00 | CO-97 denial | A work item with an appeal deadline, not a write-off. Clock 4. |
One claim, four different aging behaviors. An aging report that shows $357.60 over 30 days on this claim is describing a contractual adjustment, a rail delay, a patient balance, and a denial as if they were the same problem. They need four different actions, and only one of them involves calling the payer.
Why legacy rails add days after adjudication
Once the 835 is cut, the payer has decided. The money is owed. Everything after that point is transport, and transport on the standard healthcare EFT path is batch-oriented:
- Payer originates an ACH credit, typically CCD+ with a
TRNreassociation trace number carried in the addenda, per the CAQH CORE reassociation operating rules. - ACH settles on a banking-day cycle. Same Day ACH exists but has submission windows and a per-payment cap [verify current NACHA limit], and a payment that misses the last window waits for the next banking day.
- Weekends and Federal Reserve holidays are dead time. A Friday-afternoon origination before a Monday holiday is a four-calendar-day wait with zero business activity.
- The 835 and the deposit arrive on separate channels and separate schedules. Reassociation is a matching problem your team solves manually when the
TRN02doesn't line up cleanly.
Instant rails change the transport characteristics, not the adjudication:
| ACH / Same Day ACH | FedNow / RTP | |
|---|---|---|
| Settlement speed | Next banking day; same-day within windows | Seconds |
| Availability | Banking days, business hours + windows | 24/7/365, including weekends and holidays |
| Cutoff exposure | Missing a window costs a full day or a weekend | None |
| Finality | Returns possible within NACHA return windows | Credit-push, irrevocable on settlement; funds return only by request |
| Per-payment limit | Same Day ACH capped [verify current limit] | Network-specific caps; both have raised limits [verify current FedNow and RTP caps] |
| Remittance data | Addenda-constrained; TRN reassociation | ISO 20022, richer structured remittance capability [verify payer/bank support in your market] |
| Practical effect on AR | Adds banking-calendar days after adjudication | Removes clock 3 almost entirely |
The honest framing: real-time settlement does not make a payer adjudicate faster. It removes the days between "payer decided" and "money is spendable," and it removes the weekend/holiday penalty entirely. That's clock 3 going to roughly zero. How many days that is for you depends on your payer mix and their origination habits — measure it before you assume it.
What line-level remittance intelligence changes
Clock 4 is the one nobody reports on, because it hides inside the aging bucket. Line-level remittance intelligence means parsing the 835 to the SVC/CAS level and routing each line by what it actually is, rather than posting a claim-level payment and letting the remainder age.
Concretely, from the example above:
- $195.00 CO-45 — auto-adjust at post time. It never enters the workable queue.
- $102.40 — reconcile against the settlement notification by trace, not by hand. When settlement is instant and carries structured remittance, reassociation is a lookup, not a spreadsheet.
- $67.60 PR — generate a request-for-payment to the patient's bank app the same day, with the balance itemized by line. Collect according to your payer contract and applicable state and federal law; a request is a request, not a collections action.
- $95.00 CO-97 — route to a denial queue tagged with the appeal deadline, with the paired line (
92133) attached so whoever works it can see the bundling argument immediately.
The variance question is where this compounds. Once you're storing allowed amounts per CPT per payer per contract, you can compare SVC02 − CAS(CO-45) against your contracted rate and flag lines where the payer paid off-schedule. Underpayment is a category of AR that never shows up on an aging report, because the claim closed. It only surfaces at the line level.
A 30-day checklist
- [ ] Split your AR report by the four clocks. Charge lag, adjudication, transit, post-adjudication work. If your PM system can't do this, export and pivot manually once — the distribution alone usually redirects the whole improvement plan.
- [ ] Audit contractual posting. Pull any account with an aged balance that traces to a
CO-45. Every dollar there is a posting defect, not a collections problem. - [ ] Measure clock 3 per payer. For 20 claims per major payer, record 835 production date and the date funds were available. That interval is your real-time settlement upside, stated in days rather than assumed.
- [ ] Rank denial reason codes by dollars, not count.
CO-97,CO-45mismatches, andCO-16behave completely differently. Work the code that carries the money. - [ ] Count PR dollars with no outbound request. Patient responsibility sitting in AR with no statement or RFP sent is not slow collection; it's an unsent bill.
- [ ] Pick one payer and one CPT and check allowed vs. contracted. If they diverge, you have a variance program to build.
- [ ] Confirm your bank's instant-rail support. FedNow and RTP require receiving-side enablement. Ask specifically about receive capability and any per-transaction cap on your account.
FAQ
Does real-time settlement make payers adjudicate faster? No. Adjudication and settlement are separate stages. Instant rails compress the interval between the payer's decision and spendable funds — clock 3. Claim quality, clean-claim rate, and payer edits are what move clock 2.
Is line-level 835 parsing safe from a HIPAA standpoint? The 835 is a covered transaction and contains PHI, so it needs the same handling as any other clinical or claims data: BAA in place, encryption, access controls, audit logging, minimum necessary. Architecturally, the safer pattern is to keep PHI in your system of record and move opaque references — a claim reference, an amount, a reason code — through downstream tooling, so remittance intelligence and payment orchestration never need to hold identifiable data.
What if some of my payers can't send on FedNow or RTP? Most practices will run mixed rails for a while. That's fine and it's the normal migration path — route what can go instant, keep ACH for the rest, and reconcile both against the same 835. The measurement discipline matters more than full coverage: knowing your per-payer transit interval tells you which payer conversations are actually worth having.
Try it against a real 835
The shteg.ai sandbox accepts a de-identified 835 file and returns the line-level breakdown: SVC/CAS balancing checks, contractual vs. patient vs. denial split per line, allowed-amount variance against a contract table you supply, and a simulated settlement timeline comparing ACH against instant rails for the same remittance.
Bring one file. The four-clock split from your own data is more persuasive than any benchmark.
[Open the shteg.ai sandbox →](/sandbox) [verify link target before publish]
Educational content for practice administration and revenue-cycle staff. Not legal, billing, coding, or compliance advice. Segment values and claim identifiers in this article are synthetic illustrations and contain no patient data. Payment network capabilities, transaction limits, and operating rules change — verify current specifications with your financial institution and clearinghouse before making operational decisions. Patient balance collection is governed by your payer contracts and by applicable state and federal law; consult counsel for your jurisdiction.
<!-- generated_by: claude-draft-1 -->