Bill Patients for What They Owe

Once the payers have answered, what is left on a claim is the patient’s to pay, along with any open charges on the patient’s account. The statement cycle turns those balances into statements, a review queue catches the ones that must not be mailed, and a batch carries the rest to the printer.

Before You Start

You need the User role, a client licensed for statements and work queues, and patient balances on the ledger. The cycle bills what Transactions shows against patient responsibility; with nothing owed, it has nothing to do.

Run the Cycle

1. In the sidebar, select Statements.
2. Select Run Statement Cycle. A toast names the task the cycle runs as. The button greys and says the cycle is running, and a banner above the list says when it started.
3. When the banner clears, read the tiles. Held counts what the cycle stopped and Ready to Send counts what passed.

Result: every account owing at least the minimum, not billed within the cadence, and with no statement still waiting to be sent, has a new statement: Ready if it passed the check, Held if it did not. If an account fails, the cycle’s task ends Failed; retrying is safe, because accounts already billed are skipped.

If the list says no cycle is scheduled, the button still runs one with the defaults: a $5 minimum and 30 days between notices. An Administrator sets the policy by scheduling the Generate Statements task on Schedules.

Release What Was Held

1. In the sidebar, select Work Queues.
2. Open the Statement Review queue for the day the cycle ran. Each practice day has its own, such as Statement Review · 09/27/2026.
3. In the queue list, select an item. Each is labelled with the statement number, its amount and how many holds block it. The workspace shows the Holds and Bill To cards, with a note where the document would be.
4. Read each hold. An address hold is fixed here. A restriction hold links to the patient’s card. A minor without a guarantor is fixed on the patient’s Guarantor card. A balance hold cannot be released: void the statement and generate a new one. Every other hold names a reason not to bill that lives outside the statement.
5. Optional: for an address hold, complete the address on the Bill To card.
6. Optional: select Save Changes. Saving re-runs the check, and the address hold clears. A Zip Code that is not 5 or 9 digits is refused. If someone else saved the statement first, Reload takes the place of Save Changes and drops your edit (A Save Was Refused).
7. Optional: for a restriction hold, select Manage restrictions, end the restriction on the patient’s card if it no longer applies, and return to the item.
8. Select Release. Release refuses while a bill-to edit is unsaved, or while another biller is working the item or it is assigned to someone else. It re-runs the check rather than trusting what you saw: if an error still holds the statement, ClaimPod refuses, says how many, and stays put. A Deceased or Payment plan warning is released by this step, which records that you checked it.

Result: the statement is Ready, leaves the queue, and the processor advances to the next item.

Caution

A statement held for a payer still adjudicating has nothing to edit on the item. Either leave it and select Release again once the payer answers, or ask a Manager or Administrator to open it with Open Statement from the item’s menu and void it there; the balance stays on the account.

A restriction that still applies is not something to release around. Leave the statement held, or have it voided; a QMB restriction in particular means the balance is not the patient’s to pay.

Send the Batch

1. In the sidebar, select Batches, then the Statement Batches tab. Create Statement Batch is greyed while nothing is ready to send.
2. Select Create Statement Batch. The dialog says how many statements are ready and their total. When some drifted from the balance, it counts them, such as 3 ready · 1 changed since, and moves them to Held; with nothing else ready, no batch is created.
3. Optional: in Deliver to, choose a connection. Download only keeps the files on the batch page. A connection also pushes them into its output folder for the mail house to collect.
4. Select Create Batch to confirm. The batch appears as Pending, and its page updates itself while it generates.
5. Open the batch.
6. Select Download PDF Bundle. One PDF, every statement in mailing order.
7. In the header menu, select Download Manifest. One CSV row per statement, for the mail house.

Result: every included statement is Sent, and Sent This Cycle on Statements counts it. Anything excluded stays Ready and rides the next batch, with the reason on the batch page. A sent statement is frozen as the paper you mailed.

Record the Mailing Date

Once the envelopes are in the mail, or the mail house confirms it sent them, record the day on the batch.

1. In the sidebar, select Batches, then the Statement Batches tab, and open the batch.
2. Select Mark Mailed and enter the day the envelopes went out. On the batch page, Mailed changes from Not yet to that date and your name.
3. Optional: if the day was wrong, select Change Mailing Date in the header menu and correct it.

Result: the batch records when it was mailed, and every patient in it has a started collections clock.

Caution

The collections clock starts at the first mailing you record, not when a statement is generated. A final notice for a patient whose clock has not started is held and does not print; the hold names the batch to mark mailed, and marking it releases the notice. Mark every batch mailed when it goes out, or final notices will stall.

Why Some Statements Are Held

The cycle checks every statement it makes against ClaimPod’s own holds and the client’s rules at the statement generated trigger, and holds anything an error touches. The Statement Page lists every hold and where its fix lives.

Related: Statements · Statement Batches · The Queue Processor · Work a Queue Item · Import Patient Payments