Request for Payment: Collecting Patient Balances Without Waiting for the Statement Cycle

A patient balance has two clocks. The first runs from the encounter to the moment you know the exact amount the patient owes — that clock is controlled by the payer, and it stops when the 835 posts. The second runs from that moment to cash in your operating account, and it is controlled entirely by you.

Most independent practices spend all their improvement effort on the first clock and almost none on the second. That's backwards. Adjudication takes what it takes. But a balance that was fully specified on day 8 and first asked for on day 31 spent 23 days sitting in a queue waiting for a print vendor — and every one of those days was a decision your billing system made, not the payer.

This article walks the second clock end to end: what a request-for-payment (RfP) workflow actually is at the message level, a day-by-day comparison of the same $84.60 balance through a statement cycle and through an RfP, the HIPAA constraints on sending balance information outside your portal, and the implementation steps that fit a practice without a dedicated integration team.

Where the days actually go

Break the post-adjudication path into its real components and the latency is easy to locate:

• Batch generation. Statements run on a monthly or semi-monthly cycle. An 835 that posts on day 3 of that cycle waits for the run. Mean wait is roughly half the cycle length, and the variance is worse than the mean.
• Physical transit. Print, insert, presort, mail. Add several business days that no amount of follow-up recovers.
• Patient decode time. A claim-level "patient balance" with no itemization is not actionable. The patient either calls you (staff cost) or sets it aside (aging).
• Instrument friction. A check has mail float plus manual posting. A card carries interchange and PCI scope if you store the PAN. An ACH debit carries NSF return risk and a stored authorization you must retain and honor.
• Serial dunning. Statement one, wait 30, statement two, wait 30, statement three. The escalation ladder is measured in months by construction.

Here is the same balance moving through four channels, scored on the clock rather than on features:

Card-on-file is fast but shifts the problem: you are now storing a credential, absorbing interchange, and exposed to disputes on an amount the patient never affirmatively approved. RfP gets the latency without the custody.

What a request for payment is, mechanically

An RfP inverts the direction of the transaction. You are not pulling funds from an instrument you hold. You are sending a structured request into the patient's own banking app, where they approve it with credentials they already trust, and their bank pushes the credit to you.

On the RTP network the request travels as an ISO 20022 pain.013 creditor payment activation request. The patient's institution returns a pain.014 status message, and approval triggers an ordinary credit transfer (pacs.008) that settles in seconds. The FedNow Service supports a comparable request-for-payment message flow. Message versions, network reach, per-transaction limits, and which of your patients' banks actually receive RfP are all moving targets — confirm current specifications with your financial institution before you design against them [verify].

Three properties do the work here:

1. Credit-push. No stored PAN, no debit authorization, no NSF return, no chargeback path. The patient affirmatively approves and funds are final on settlement.
2. Always on. Requests can be sent and approved at 9pm on a Sunday, from a phone, in a parking lot. There is no banking-calendar dead time between the ask and the cash.
3. Structured remittance. The request carries itemization, so the patient sees why the number is what it is at the moment they decide whether to pay it.

The finality property is worth its own treatment — see The Architecture of Real-Time Settlement in Healthcare Payments for what irrevocability means for your reconciliation and refund process [verify link target].

Worked example: one $84.60 balance, two timelines

Synthetic values throughout — no real identifiers, no patient data.

A two-line professional claim adjudicates as follows:

CLP*PCN-4471*1*315.00*138.40*84.60*12*ICN-2026-0820-0913*11~
SVC*HC:99214*220.00*126.40**1~
CAS*CO*45*62.00~
CAS*PR*2*31.60~
SVC*HC:93000*95.00*12.00**1~
CAS*CO*45*30.00~
CAS*PR*1*53.00~

The service-line balancing rule — SVC02 = SVC03 + the sum of that line's CAS amounts — holds on both lines: 220.00 = 126.40 + 62.00 + 31.60 and 95.00 = 12.00 + 30.00 + 53.00. At the claim level, CLP03 − CLP04 = 315.00 − 138.40 = 176.60, which equals the sum of all four CAS amounts. The PR-group total is 31.60 + 53.00 = 84.60, matching CLP05.

So the patient owes $84.60 — 53.00 deductible and 31.60 coinsurance — and the $92.00 in CO-45 contractual adjustments is not billable to them at all. (For how to isolate that reliably at scale, see Automating Line-Level 835 Reconciliation [verify link target].)

Timeline A — monthly statement cycle

Timeline B — RfP triggered on 835 ingest

The payer took 8 days in both timelines. The difference is entirely in the interval you own: roughly 23 days to first ask versus two minutes. That interval — 835 receipt to first outbound request — is the single most useful number to instrument, because unlike your collection rate it is a property of your system rather than of your patient population. Measure your own baseline before assuming anything about what it will do to your days in A/R [verify].

Keeping the request HIPAA-safe outside the portal

Moving balance information out of the patient portal changes your exposure surface. The constraints are specific and mostly architectural:

• The remittance field is not for clinical detail. It renders inside a consumer banking app and passes through parties operating under no BAA. An opaque encounter reference, a date, and dollar amounts by adjustment category are appropriate. Procedure descriptions, diagnosis references, or anything revealing treatment are not.
• Same rule for the notification body. If you send an SMS or email pointing to a payment page, the message itself should carry no clinical content and no PHI in the URL query string. Use an opaque token that resolves server-side.
• Step-up before disclosure. A link that displays an itemized balance to anyone holding the URL is a disclosure control failure. Require a second factor the patient knows (date of birth, or the last four of an account reference), scope the token to one encounter, and expire it.
• Document contact preference and consent at check-in. Billing communications fall under payment operations, but the channel still matters — automated texts implicate TCPA consent independently of HIPAA [verify with counsel].
• Know your BAA boundary. HHS guidance has long treated financial institutions conducting payment-processing activities differently from business associates, but the boundary depends on exactly what data your vendor touches and in what role. Get this mapped explicitly rather than assumed [verify with counsel].
• Log the disclosure. Who saw what, when, through which channel — the same accounting you'd expect for portal access.

Implementing RfP in an independent practice

A workable sequence, roughly in dependency order:

• [ ] Move the trigger from a batch to an event. The dispatch should fire on 835 ingest, not on a nightly or monthly job. This is the change that produces almost all of the latency reduction.
• [ ] Enforce group-code suppression in code. CO, PI, and OA amounts must be structurally incapable of reaching a patient-facing message — a system rule, not a policy someone remembers.
• [ ] Net PR-3 against front-desk collections before dispatch. Every duplicate copay request costs a refund, a posting entry, and your credibility with that patient.
• [ ] Capture mobile number and contact preference at check-in. An instant rail is worthless if you can't reach the patient on the day the 835 posts.
• [ ] Define the guardrails before you automate. An amount threshold above which a human reviews, a financial-assistance and payment-plan path, and a suppression rule for accounts in dispute.
• [ ] Keep fallback channels and instrument per channel. RfP where the patient's bank supports it, portal or card where it doesn't, paper as the floor. Track 835-to-ask latency and days-to-cash separately for each so the migration argument is made with your own data.

Try it in the shteg.ai sandbox

The sandbox takes a de-identified 835 and returns the full RfP path: PR lines separated from CO/PI/OA, the exact billable amount per encounter, the request message built from the parsed lines, and the PHI-safe remittance field rendered as the patient would see it in their banking app — alongside the simulated settlement timestamps.

Bring one file. The distance between when your system knew the balance and when it first asked is usually the entire finding.

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

FAQ

What happens if the patient's bank can't receive a request for payment? You fall back to your next channel for that patient, carrying the same line-level itemization into whatever you send. RfP receipt depends on the patient's financial institution, not yours, and coverage is still expanding [verify current network reach]. Mixed-channel operation is the normal state for the foreseeable future — which is why the parsing and trigger work matters more than the rail: it improves every channel you run.

Can we send the request before the claim adjudicates? You can send an estimate, and a pre-service deposit is a legitimate practice, but it is not the same instrument. Over-collecting creates refund obligations and, depending on your state and payer contracts, compliance exposure. If you collect pre-service, reconcile against CLP05 when the 835 lands and refund promptly. The post-adjudication request is the one you can defend line by line.

Is this just text-to-pay with extra steps? No — different rail, different risk profile. Most text-to-pay products deliver a link to a card checkout: you get interchange cost, PCI scope if you store the credential, and chargeback exposure. An RfP is a credit push originated by the patient's own bank: no stored credential, no interchange in the card sense, and settlement finality on approval. The patient experience looks similar; the accounting and liability underneath do not.

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, billing, coding, or compliance advice. All segment values, claim identifiers, dollar amounts, and timestamps 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 billing and collection practices are governed by your payer contracts and by applicable state and federal law; consult counsel for your jurisdiction.

Draft notes: ~1,690 words. 5 body H2s + FAQ H2 (6 total), CTA as H3. Worked example is a settlement timeline with the 835 arithmetic verified at both levels (SVC02 = SVC03 + ΣCAS on both lines; CLP03 − CLP04 = 176.60 = ΣCAS; CLP05 = 84.60 = PR total). One comparison table (channel latency). Six [verify] flags: RfP network reach/message specs, A/R baseline, TCPA consent, BAA boundary, and two internal-link targets. No statistics asserted. Internal links to briefs #2 and #3 placed per the brief's linking strategy.

Want me to save this to examples/seo-presence/workspace/drafts/patient-payments-1-<id>.md to match the pipeline convention? I held off because a patient-payments-1-* draft already exists there and I didn't want to collide with it without your call.

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