Patient Balance Collection Best Practices: Stop Guessing What the Patient Owes

Most practices treat patient balance collection as a persistence problem. Statement one, statement two, statement three, then a phone call, then an agency. Ninety days of cycle time before anyone has a real conversation, and by then the encounter is a memory and the patient has no idea what they're looking at.

It isn't a persistence problem. It's a specification problem followed by a timing problem. The 835 tells you the exact dollar amount the patient owes and the exact reason for every cent of it, usually within days of the encounter. Everything that goes wrong after that is you failing to use that information, or waiting too long to act on it.

This article reads one remittance down to the patient-responsibility arithmetic, shows what the statement gets wrong, and lays out a collection workflow that starts the day the 835 posts instead of the day the print vendor batches.

The 835 already specifies what the patient owes — and what you may not bill

Every adjustment on a remittance carries a CAS group code that determines whether the dollar is billable to the patient at all:

• PR — Patient Responsibility. Billable. This is the only group that becomes patient AR.
• CO — Contractual Obligation. Not billable. Under a participating-provider agreement, putting a CO dollar on a patient statement is balance billing.
• PI — Payer Initiated Reduction. Generally not billable to the patient; check the specific reason code against your contract [verify].
• OA — Other Adjustment. A routing instruction, usually to a secondary payer or a COB process. Not a bill.

Inside the PR group, the reason code tells you what kind of patient dollar it is, and the three common ones behave completely differently in collection:

• PR-1 (deductible) — usually the largest and the most disputed, because patients rarely know where they stand in their plan year.
• PR-2 (coinsurance) — a percentage of the allowed amount. Verifiable by the patient if, and only if, you show the allowed amount.
• PR-3 (copayment) — a flat amount that your front desk very likely already collected at check-in.

A statement that collapses all of this into one number labeled "patient balance" throws away every piece of information that would have prevented the phone call.

Worked example: one encounter, four lines, three kinds of patient dollar

Here is a synthetic four-line professional claim as it appears in an 835. Every value is constructed for illustration — no real identifiers, no patient data.

CLP*PCN-8821*1*415.00*153.40*120.80*12*ICN-2026-0812-0447*11~
SVC*HC:99214*220.00*118.20**1~
CAS*CO*45*61.80~
CAS*PR*3*40.00~
SVC*HC:93000*95.00*0.00**1~
CAS*CO*45*23.00~
CAS*PR*1*72.00~
SVC*HC:80053*68.00*35.20**1~
CAS*CO*45*24.00~
CAS*PR*2*8.80~
SVC*HC:36415*32.00*0.00**1~
CAS*CO*97*32.00~

The service-line balancing rule is 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 = 118.20 + 61.80 (CO-45 contractual) + 40.00 (PR-3 copay) ✓
• 93000 — 95.00 = 0.00 + 23.00 (CO-45) + 72.00 (PR-1 deductible) ✓
• 80053 — 68.00 = 35.20 + 24.00 (CO-45) + 8.80 (PR-2 coinsurance) ✓
• 36415 — 32.00 = 0.00 + 32.00 (CO-97, benefit included in another service) ✓

Roll it up: CLP03 − CLP04 = 415.00 − 153.40 = 261.60, and all CAS amounts sum to 61.80 + 40.00 + 23.00 + 72.00 + 24.00 + 8.80 + 32.00 = 261.60. CLP05 (patient responsibility) is 40.00 + 72.00 + 8.80 = 120.80, exactly the PR-group total. The claim balances.

Now read it as a collection problem, which is where most of the money leaks:

• The $32.00 CO-97 on the venipuncture is a contractual bundling adjustment. It must never appear on the patient's statement. If your statement logic bills "charges minus payments," it will.
• The $40.00 PR-3 copay was almost certainly collected at the front desk on the date of service. Billing it again produces a duplicate charge, a credit balance, a refund check, and a patient who now distrusts every statement you send.
• The real outstanding patient balance is $72.00 deductible + $8.80 coinsurance = $80.80 — not the 120.80 in `CLP05`, and definitely not the 261.60 a naive charges-minus-payments calculation produces.

Three different numbers, and only one of them is correct. The difference between 80.80 and 261.60 on a single encounter is the entire argument for line-level remittance parsing.

The coinsurance line is also the one you can defend without a phone call: allowed amount is 68.00 − 24.00 = 44.00, the plan paid 35.20, and 8.80 ÷ 44.00 = 20%. Put that arithmetic in front of the patient and the dispute usually doesn't happen.

Why the statement cycle loses the money after adjudication

Once the 835 posts, the amount is known and defensible. Everything after that is delivery, and the legacy delivery path is slow in ways that have nothing to do with the patient's willingness to pay:

• Batch print cycles. Statements typically go out on a monthly or semi-monthly run. An 835 that posts on day 3 of the cycle waits for day 30, then adds mail transit.
• Claim-level granularity. The statement shows a balance, not the SVC/CAS breakdown. The patient can't verify it, so they call — or they don't, and they don't pay either.
• Payment friction. A check has mail float and manual posting. A card carries interchange, PCI scope if you store it, and chargeback exposure. An ACH debit carries NSF return risk and requires an authorization you have to capture and retain.
• Serial dunning. Statement one, wait 30, statement two, wait 30, statement three. Ninety days of elapsed time before escalation, during which the balance ages into the bucket everyone assumes is uncollectible.

The general pattern — that collectability of a patient balance declines the longer you wait after the encounter — is widely reported, but the specific decay curve varies enormously by practice, payer mix, and patient population. Measure your own rather than importing someone else's number [verify].

Request for payment: asking on the day the 835 posts

A request for payment (RFP) inverts the flow. Instead of pushing a bill and hoping for a payment instrument, you send a structured request that lands in the patient's own banking app, where they approve it with credentials they already trust.

Mechanically, on the RTP network the request travels as an ISO 20022 pain.013 creditor payment activation request; the patient's bank returns a pain.014 status, and approval triggers an ordinary credit-push transfer (pacs.008). FedNow supports a comparable request-for-payment flow. Verify current message versions, network reach, and per-transaction limits with your financial institution before designing against them [verify].

Three properties matter for patient balances:

1. Credit-push. You never hold a card credential or a debit authorization. There is no NSF return and no card-network chargeback path — the patient affirmatively approves, and funds are final on settlement.
2. 24/7/365. Requests can be sent and approved on weekends and holidays, on a phone, in the parking lot. No banking-calendar dead time.
3. Structured remittance. The request carries itemization, so the patient sees why they owe $80.80 at the moment they're deciding whether to pay it.

One design constraint that is easy to get wrong: the remittance field on a banking-rail message is not a place for clinical detail. "Office visit 08/12" plus a dollar breakdown by adjustment category is appropriate. Procedure descriptions, diagnosis references, or anything that reveals treatment is not — it renders inside a consumer bank app and travels through parties with no BAA. Keep PHI in your system of record and move an opaque encounter reference plus amounts through the payment path.

A patient-balance workflow you can implement this quarter

• [ ] Parse to `SVC`/`CAS`, not `CLP`. Patient balance is the PR-group sum per line, not charges minus payments. Fix this first; everything else depends on it.
• [ ] Block CO, PI, and OA from patient statements at the code level. Not as a policy someone remembers — as a rule the system enforces. Audit last quarter's statements for CO-97 and CO-45 dollars that reached a patient.
• [ ] Reconcile PR-3 against front-desk collections before any ask goes out. Every duplicate copay bill costs you a refund, a posting entry, and credibility.
• [ ] Measure your 835-to-ask interval. Pull 30 recent encounters with a patient balance and record the days between 835 receipt and first outbound request. That interval, not your collection rate, is the number you can actually move.
• [ ] Show the coinsurance math. Allowed amount, plan payment, patient percentage. Disputes drop when the arithmetic is visible.
• [ ] Collect a mobile number and contact preference at check-in. An instant rail is worthless if you can't reach the patient the day the 835 posts.
• [ ] Run mixed channels deliberately. RFP where the patient's bank supports it, card or portal where it doesn't, paper as the floor. Track collection rate and days-to-cash per channel so the migration argument is made with your data.

FAQ

Should I send the request before or after the 835 posts? Both, for different amounts. A pre-service estimate collected as a deposit is a legitimate practice, but it's an estimate — over-collecting creates refund obligations and, depending on your state and payer contracts, compliance exposure. The post-adjudication request is the exact amount, defensible line by line. If you do both, reconcile the deposit against CLP05 and refund promptly; a stale credit balance is its own problem.

What if the patient's bank can't receive a request for payment? Then you fall back to your next channel for that patient, and you keep the same line-level itemization in whatever you send. RFP receipt coverage is a function of the patient's financial institution, not of your bank, and coverage is still expanding [verify current network reach]. Mixed-channel is the normal state for the foreseeable future — and the value of the 835 parsing work is channel-independent.

Is a request for payment a collections action? No. It's a request the patient approves or ignores; nothing is debited without affirmative action, and nothing is reported to a credit bureau. That said, patient billing is governed by your payer contracts, your financial policy, and applicable state and federal law — including rules on billing practices, financial assistance, and third-party collection activity that vary by jurisdiction. Consult counsel for your state before changing your policy [verify].

Try it against your own remittance

The shteg.ai sandbox accepts a de-identified 835 and returns the patient-balance view directly: PR lines separated from CO/PI/OA, the correct billable amount per encounter, coinsurance arithmetic shown against the allowed amount, front-desk copay reconciliation flags, and a simulated request-for-payment message built from the parsed lines — with the PHI-safe remittance field rendered exactly as a patient would see it in their bank app.

Bring one file. The gap between what your statement says and what the 835 actually specifies is usually the whole argument.

[Open the shteg.ai sandbox →](/sandbox) [verify link target before publish]

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, billing, coding, or compliance advice. All segment values, claim identifiers, and dollar amounts in this article are synthetic illustrations and contain no patient data. Payment network capabilities, message specifications, 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.

Draft notes: ~1,650 words. 5 body H2s + FAQ + CTA. All arithmetic in the worked example balances at both service-line and claim level (CLP03 − CLP04 = 261.60 = sum of all CAS; CLP05 = 120.80 = PR total). Five [verify] flags: PI billability, collectability decay curve, ISO 20022 message specifics/limits, RFP network reach, and state collection law — plus the sandbox link target. No statistics asserted anywhere. Angle deliberately diverges from the revenue-cycle-1 draft in the same workspace: that one used the 835 to explain AR aging, this one uses it to compute the correct billable patient amount, so the shared SVC/CAS explainer doesn't read as duplicate content.

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