Medical Practice Accounts Receivable: What's Actually in the Number

Your AR total is not a debt. It's an inventory of four different things that happen to be denominated in dollars, and each one closes through a completely different action. One of them isn't a receivable at all and should have left the ledger the moment the remittance posted. Another closes only when someone sends the patient a request that nobody has sent. A third is waiting on a banking calendar, not on a payer.

Aging buckets hide all of this. A 30-to-60 column tells you how long a balance has existed; it tells you nothing about who can close it or what closing it requires. This article breaks a synthetic claim into its actual components, walks the same remittance down two settlement calendars hour by hour, and gives you an audit you can run against your own data in two weeks.

What's actually inside the AR number

Take one finalized professional claim from an 835. Claim-level values, all synthetic:

CLP*PCN-8802*1*1240.00*512.30*148.70*12*ICN-2026-0903-4471*11~

CLP03 submitted is $1,240.00. CLP04 paid is $512.30. CLP05 patient responsibility is $148.70. The remaining $579.00 splits across adjustment groups: $421.00 of CO-45 (charge exceeds fee schedule) and $158.00 of CO-197 (precertification absent). The claim balances: 512.30 + 148.70 + 421.00 + 158.00 = 1,240.00.

Now stop treating that as one balance:

Four categories, four owners, four failure modes. The aging report shows $727.70 outstanding and implies a single collections problem. In reality: one line is a bookkeeping error, one is a rails problem, one is an unsent bill, and one is a clock running against a filing deadline that nobody has diaried.

The first structural improvement to most practices' AR is not working the queue harder. It's splitting the queue.

Worked example: one claim, two settlement calendars

The $512.30 category is the one practice managers most often assume is out of their control. It isn't entirely — the payer's decision date and the date the money is spendable are separate events, and the gap between them belongs to payment infrastructure.

Same synthetic claim, tracked against a real calendar. Labor Day 2026 falls Monday, September 7.

Four calendar days between "the payer decided" and "we can spend it," on a claim where the payer did nothing wrong and your staff did nothing wrong. The delay is entirely structural: batch origination, submission windows, a weekend, and a Federal Reserve holiday.

Two things to be precise about, because the marketing version of this gets both wrong.

Instant rails do not change adjudication. Everything left of "payer finalizes" is unchanged. Clean-claim rate, payer edits, and prior-auth discipline are what move that interval. Anyone selling real-time settlement as faster payer decisions is describing something that doesn't exist.

The upside is measurable, not assumed. Your gap between BPR16 and available funds may be one day or five, and it varies by payer and by their origination habits. Measure it on twenty claims per major payer before you build a business case on it.

What does change: FedNow and RTP are credit-push and settle in seconds, 24/7/365, with no weekend or holiday dead time and no submission window to miss. Settlement is final on receipt — funds come back only by request, not by unilateral return within a NACHA window. Both networks carry ISO 20022 structured remittance capability, which turns reassociation from a matching exercise into a lookup. Per-transaction caps differ by network and have been raised more than once; [verify] current limits and your own account's receive-side enablement with your bank, because receiving is not on by default.

Payer-side origination adoption is the real constraint, and it's uneven. Most practices will run mixed rails for a while. That's the normal path, not a failure state.

Line-level remittance intelligence: turning AR into an action list

Claim-level posting is what collapses those four categories back into one number. If your system posts $512.30 against a $1,240.00 claim and lets $727.70 age, the information needed to route each piece was in the 835 and got discarded on the way in.

Parsing to the SVC and CAS level, the same claim produces four routed work items instead of one aging balance:

• `$421.00` `CO-45` — adjusted at post time, never enters a workable queue. If your CO-45 dollars are showing up in aging, fix that before anything else on this list; it inflates every AR metric you report to your physicians.
• `$512.30` — reconciled against the settlement notification by trace reference. Under real-time settlement with structured remittance, this is a key lookup rather than a spreadsheet.
• `$148.70` `PR` — converted to a request-for-payment the patient can act on from their bank app the same day, itemized by service line so the amount is legible. Collection terms follow your payer contracts and applicable state and federal law.
• `$158.00` `CO-197` — routed to a denial queue tagged with the payer's appeal filing limit and the original authorization record attached, so whoever works it isn't rebuilding the case from scratch.

The compounding benefit is variance. Once you store allowed amounts per CPT per payer per contract, SVC02 minus the contractual adjustment gives you the payer's actual allowed amount, and you can compare it against your fee schedule line by line. Underpayment never appears on an aging report, because the claim closed and the balance zeroed. It only surfaces at the line level, and only if you're looking.

A two-week AR composition audit

• [ ] Recategorize your open AR into the four buckets above. If your PM system won't do it natively, export and pivot once. The distribution usually redirects the entire improvement plan.
• [ ] Find every aged balance that traces to a contractual adjustment. That dollar figure is your posting-defect number. It is not collectible and should not be in anyone's queue.
• [ ] Measure `BPR16`-to-funds-available per payer. Twenty claims each, major payers only. That interval is your real-time settlement upside stated in days rather than assumed.
• [ ] Count `PR` dollars with no outbound request on record. Patient balances with no statement and no RFP sent are unsent bills, not slow payers.
• [ ] Rank denial dollars by reason code, and check each code's filing limit. CO-197, CO-16, and CO-18 need different workflows and have different deadlines.
• [ ] Pick one payer and one high-volume CPT. Compare allowed against contracted for a month of claims. If they diverge, you have a variance program to build.
• [ ] Ask your bank two specific questions: can this account receive on FedNow and RTP, and what is the per-transaction cap on receive.

FAQ

Do contractual adjustments ever belong in AR? No. A CO-45 is a contractually agreed reduction, not money anyone owes you. It should clear at the moment the 835 posts. Contractual dollars sitting in aging inflate days in AR, distort every collections metric, and put uncollectible balances in front of staff who then spend time on them.

Our payers all send ACH today. Is it worth setting up instant receive now? The setup is a bank conversation, not an integration project, and it's a prerequisite rather than a switch — you can't receive an instant credit on an account that isn't enabled. The measurement work in the checklist matters more in the short term: knowing your per-payer transit interval tells you which payer conversations are worth having and what the conversion is actually worth to you.

How should credit balances and overpayments appear? Separately, and with their own clock. A credit balance is a liability, not a negative receivable, and netting it against open AR hides both. Federal overpayment rules impose a return deadline once an overpayment is identified [verify current requirements for your payer mix and consult counsel]. Practically: credit balances need their own report, their own owner, and their own aging.

Run your own remittance through it

The shteg.ai sandbox takes a de-identified 835 and returns the composition breakdown described here: per-line contractual, payer-paid, patient-responsibility, and denial splits; SVC/CAS balancing validation; allowed-amount variance against a contract table you supply; and a side-by-side settlement timeline for ACH versus instant rails on that same remittance.

One file is enough. The category split from your own data will tell you more than any benchmark will.

[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. All claim identifiers, segment values, and dollar amounts in this article are synthetic illustrations and contain no patient data. Payment network capabilities, transaction limits, cutoff windows, and operating rules change — verify current specifications with your financial institution and clearinghouse before making operational decisions. Patient balance collection and overpayment handling are governed by your payer contracts and by applicable state and federal law; consult counsel for your jurisdiction.

~1,550 words, 6 H2 sections, two tables (AR composition + dual-path settlement timeline), FAQ, sandbox CTA, disclaimer. Say the word and I'll file it as workspace/drafts/revenue-cycle-2-<id>.md to match the pipeline's naming convention.

<!-- generated_by: claude-draft-1 -->