Collecting Patient Balances Without Mailing Statements

The statement cycle is a 30-day loop with three costs attached to it: a print-and-postage cost, an inbound-call cost, and a reconciliation cost that shows up later because a check or a card payment arrives detached from the claim line it was supposed to pay. Most practices treat that loop as fixed infrastructure. It isn't. Request-for-payment inverts it — the practice pushes a payable request into the patient's own banking app, the patient authorizes it there, and the reference travels back with the money.

This piece covers the mechanism first and the workflow change second, because the workflow only makes sense once you know what the message actually is. It sits inside the broader problem of revenue cycle management for physician practices, and it depends on one upstream discipline: the balance you request has to be the balance the remittance established, not an estimate.

All EDI segments, dollar amounts, and identifiers below are synthetic illustrations constructed for this article. They contain no patient data.

What a statement cycle actually costs

Don't take a benchmark for this. Industry averages for statement cost are quoted widely and sourced thinly, and yours will differ by print vendor, cycle count, and how much of your call volume is balance-explanation versus scheduling. Compute your own with the inputs you already have:

Cost per cycle = (statements mailed × unit print + postage cost)
               + (balance-related inbound call minutes × loaded staff rate)
               + (payment posting + reconciliation minutes × loaded staff rate)

Cost per collected patient dollar = Cost per cycle ÷ patient dollars collected in that cycle

Two of those three terms are invisible on any vendor invoice. The call-minutes term is the one that usually surprises people: a statement that shows a claim total with no line-level breakdown generates a call, and that call is answered by someone who has to open the remittance to answer it. The reconciliation term is the other — a paper check arrives with a stub that may or may not carry a usable reference, and a card payment posted at the practice carries whatever reference the person keying it typed.

Run the formula for one month before you evaluate any alternative. If the third term is near zero because nobody is measuring posting time, measure that first.

How a request for payment works

A request for payment (RfP) is a message, not a link. The practice's bank sends it over a real-time rail to the patient's bank; the patient sees it inside their existing banking app alongside their other bills; if they approve it, their bank originates a credit transfer back to the practice. The practice never touches card credentials and never holds an account number.

Three properties matter operationally:

• It is credit-push. The patient authorizes a payment out of their account. There is no debit pull against an account you stored, and no card network chargeback path. On The Clearing House's RTP network, credit transfers are final on settlement; funds return only by request, not by unilateral reversal [verify current terms against the TCH RTP Rulebook].
• Structured remittance rides along. The rail's message format (ISO 20022; RTP's RfP is built on the pain.013 request-for-payment message [verify message identifiers against current network specs]) carries reference data with the payment, so the response can be matched to the claim and line that generated it without a human reading a check stub.
• Coverage is not universal. The patient's bank must participate and must expose RfP to consumers; the practice's bank must be able to originate the request. FedNow also offers a request-for-payment capability, with its own participation profile [verify current FedNow Service documentation and your institution's supported message set]. Assume mixed channels for the foreseeable future and design for fallback.

Here is how the four common patient-payment channels actually differ:

The "distrusted as phishing" row is not a small point. A payment link in an SMS is indistinguishable from a fraud attempt, and patients have been correctly trained to treat it that way. A request that appears inside the banking app the patient already trusts is a materially different trust posture.

The balance you request is the balance the 835 established

This is where most patient-billing workflows leak. If the request is generated from an estimate, or from a claim-level remainder, you will bill amounts that aren't the patient's. Source it from the service-line adjustments instead.

Synthetic three-line professional claim:

CLP*PCN-8802*1*385.00*118.50*74.50*12*ICN-2026-0512-0417*11~
SVC*HC:99213*160.00*74.50**1~
CAS*CO*45*60.00~
CAS*PR*2*25.50~
SVC*HC:69210*130.00*44.00**1~
CAS*CO*45*37.00~
CAS*PR*1*49.00~
SVC*HC:87880*95.00*0.00**1~
CAS*CO*97*95.00~

The service-line balancing rule is non-negotiable — an 835 that violates it is malformed:

SVC02 (submitted charge) = SVC03 (line payment) + the sum of that line's CAS amounts (X12N 835 TR3, 005010X221A1).

Line by line:

• 99213 — 160.00 = 74.50 + 60.00 (CO-45 contractual) + 25.50 (PR-2 coinsurance) ✓
• 69210 — 130.00 = 44.00 + 37.00 (CO-45) + 49.00 (PR-1 deductible) ✓
• 87880 — 95.00 = 0.00 + 95.00 (CO-97, benefit included in another service) ✓

Roll up: CLP03 − CLP04 = 385.00 − 118.50 = 266.50, and the CAS amounts across all lines sum to 60.00 + 25.50 + 37.00 + 49.00 + 95.00 = 266.50. CLP05 is 25.50 + 49.00 = 74.50 — exactly the PR-group total. The claim balances.

So the requestable amount is $74.50. Not 266.50, which includes 97.00 of CO-45 contractual adjustment that is not AR at all and should leave the balance the moment the 835 posts. And not 169.50, which would sweep in the 95.00 CO-97 line — a provider-side work item with an appeal deadline, not a patient charge. Group-code semantics are defined in the WPC claim adjustment reason code list; check the current list rather than a cached copy, since codes are retired and added on a published schedule [verify retrieval date].

For a small practice without a dedicated denials analyst, the workable version of denial management is exactly this routing step: CO and OA lines go to a queue tagged with the payer's appeal deadline and the paired line attached (here, 87880 belongs with 69210 so whoever works it can see the bundling argument immediately); PI lines go to a contract-review queue; only PR lines are eligible for a patient request. Rank that queue by dollars, not by count. If you want the segment-level detail behind any of this, start with reading the CAS segment that set this balance [verify link target before publish].

Two screens must pass before a PR dollar becomes a request:

1. COB and secondary status resolved. If there is a secondary payer, the primary's PR amount is not the patient's balance. Requesting it before the secondary adjudicates bills the patient for money a payer owes.
2. Eligibility-based billing prohibitions checked. Medicare providers may not bill Qualified Medicare Beneficiary (QMB) individuals for Medicare cost-sharing, and other dual-eligible categories carry their own restrictions — see current CMS guidance and your state Medicaid rules. Screen the eligibility response before the request is generated, not after a complaint arrives.

Designing the request and handling what comes back

Timing. Generate the request against remittance receipt, not against a calendar cycle. The reason the 30-day loop exists is that mail batching made per-claim timing uneconomical; a message has no batch cost. But don't send before your posting run has confirmed the PR amount and both screens above have cleared. If your payer mix still settles on batch rails, the remittance and the deposit may arrive on different days — see how long the payer side actually takes to settle [verify link target before publish].

What the patient sees. An itemized, line-level breakdown reduces inbound calls for the same reason a claim-level total generates them: the patient's question is "what is this for," and a single number doesn't answer it. Service description, date, and the split between deductible and coinsurance are what resolve the question at first read.

Exceptions. Declined, ignored, and partial are three different outcomes and need three different rules. A decline is a signal — route it to a human, not to a re-send. An ignored request expires; decide in advance how many go out before the account moves to a phone call. Partial payments and payment plans need a rule for how the remaining balance is represented on the next request. Set the human-contact threshold by dollars and by age, write it down, and apply it uniformly; inconsistency here is what turns a billing process into a compliance problem.

What stays HIPAA-safe

The 835 is a covered transaction and contains PHI, so anything parsing it needs the standard controls: BAA in place, encryption, access controls, audit logging, minimum necessary. The design pattern that limits exposure is to keep PHI in your system of record and move opaque references — a claim reference, an amount, a reason code — through the payment path, so the request message itself never needs to carry identifiable clinical detail.

Applied to the request: an amount, a practice identifier, and a reference token belong in the message. Diagnosis codes, clinical narrative, and anything describing why care was rendered do not — a payment message is read by intermediaries that have no business need for it. Whether your specific deployment meets your obligations is a determination for your privacy officer and counsel, not one any vendor can make for you.

FAQ

Is a request for payment a collections action? No. It is a payable message the patient can approve or decline, and it carries no reporting or enforcement mechanism. That said, how and when you may contact patients about balances is governed by your payer contracts and by applicable state and federal law — the mechanism being softer does not change the rules that apply to the outreach. Consult counsel for your jurisdiction.

What happens when a patient's bank doesn't support request for payment? You need a fallback, and you will need it for a while — consumer-side RfP availability varies by institution [verify current network participation]. The practical design is to attempt the request, detect non-participation, and fall through to your existing channel automatically, with the same line-level breakdown attached. The value of the line-level sourcing carries over to any channel; only the delivery mechanism changes.

Can this replace card on file entirely? For balance collection after adjudication, it addresses the same job with better reference data and no chargeback exposure. For point-of-service copay collection, card is still the practical instrument — the patient is standing in front of you and the amount is known before any remittance exists. Expect both to coexist, and keep the reconciliation path identical for both so posting doesn't fork.

Try it against your own remittance

The shteg.ai sandbox accepts a de-identified 835 and returns the patient-request view: PR-group totals per claim with the CO, OA, and PI dollars excluded and labeled, SVC/CAS balancing checks per line, a flag on any claim where secondary payer status is unresolved, and a preview of the request message payload showing exactly which fields would leave your environment.

Bring one file and compare the PR total it produces against what your statement run would have billed for the same claims. The gap, if there is one, is the argument.

[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, claim identifiers, and dollar amounts in this article are synthetic illustrations and contain no patient data. Payment network capabilities, message specifications, participation, 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, including protections for QMB and other dual-eligible individuals; consult counsel for your jurisdiction.

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