A statement per patient, a dozen formats
A practice with a handful of active patient balances can review each statement by eye. A practice with hundreds cannot — and the statements themselves rarely arrive in one consistent format, because different billing systems, different specialties, and different clearinghouses each produce their own layout.
This page is about reading those statements regardless of layout — the balances, the charges, the payments and adjustments that explain how the balance got to where it is — into one spreadsheet that reads the same way no matter which system produced the original document.
Why this is worth automating
Retyping a balance from a statement is not just slow, it is systematically error-prone. A transposed digit on a patient balance misstates what is actually owed; a missed adjustment line makes a balance look larger than it is, which is exactly the kind of mistake that turns into an awkward call with a patient who was billed for money they do not actually owe.
It also does not scale. Twenty statements a week is manageable by hand; two hundred is not. Automated reading scales the other direction — the effort to process five statements or five hundred barely differs, because what remains is reviewing the handful the extraction itself flags as uncertain.
What gets read
| Field | Notes |
|---|---|
| Patient identifier | Name and account or record number, as the statement states them |
| Statement date and due date | For period assignment and aging |
| Prior balance | What was owed before this statement's activity |
| New charges | Total new charges billed in this period |
| Payments and adjustments | Anything reducing the balance since the last statement |
| Current balance due | The figure the patient is being asked to pay |
Where a field is not on the statement, it is left blank rather than guessed — a missing due date is not something to invent, and a blank cell tells you the statement itself did not state one, which is more useful than a plausible-looking date that was never actually printed.
Charges, payments and adjustments — the detail behind the total
A summary balance answers one question. It does not answer why the balance is what it is — which is exactly what a patient asks when they call about their bill. Where a statement itemises its charges, payments and adjustments line by line, each line is read separately: date, description, and amount.
That line-item detail is what turns a single balance figure into an answerable history — the specific visit a charge relates to, the specific payment that was applied, the specific adjustment that reduced what was owed. Reconstructing that by hand from a phone call takes minutes per patient; having it already read into a table takes seconds.
What does not get filled in
Whether a balance is actually collectible. That is a judgement about the patient's situation, not something a document states.
A field the statement itself does not include, such as a due date some billing systems omit entirely.
The reason behind an adjustment, beyond whatever the statement's own wording provides.
Anything about insurance coverage or claims status — that lives on the remittance, not the patient statement.
How it works
Upload statements
One statement or a whole batch — PDF, scan, or photo.
Every field read
Balances, dates, charges, payments and adjustments, per statement and per line item.
Balance checked
Prior balance plus charges minus payments and adjustments compared against the stated current balance.
Export
Excel, CSV or JSON — one row per statement, or one row per line item.
A batch of statements, read
Six patient statements from a single billing run, five different balance situations.
| Patient | Prior | New charges | Balance due |
|---|---|---|---|
| Patient A | 0.00 | 180.00 | 180.00 |
| Patient B | 95.00 | 0.00 | 95.00 |
| Patient C | 220.00 | 60.00 | 0.00 |
| Patient D | 340.00 | 0.00 | 160.00 |
Patient C's balance dropping to zero despite carrying a prior balance and new charges is not a printing error — it means a payment or adjustment this period covered both, visible in the line items behind the summary row. Patient D's balance dropping from 340 to 160 without a full payoff shows a partial payment applied, exactly the kind of detail a summary-only read would miss.
Building an aging report
Once balances and statement dates are read consistently across a batch, grouping them into an aging report — current, 30 days, 60 days, 90 days and beyond — is a straightforward sort rather than a separate data-gathering exercise.
That report is where patient balances become genuinely actionable: a balance sitting at 90 days deserves a different response than one at 30 days, and having the age of every balance already in one table is what makes that distinction fast to act on instead of a separate research project every time someone asks which patients are overdue.
It is also where patterns become visible that a single statement never reveals — a specific referring physician whose patients consistently carry older balances, or a particular service line where collection lags the rest of the practice. Neither pattern is visible from any individual statement; both are obvious the moment a hundred statements sit in the same aged table, sorted the same way.
Building that table once a month, on a fixed cadence, is what turns aging from an occasional exercise into a habit the practice can actually plan collections activity around — a set day each month when the aged list is refreshed, reviewed, and acted on, rather than an ad hoc task that happens whenever someone remembers to check.
Once that cadence exists, the monthly review itself takes minutes rather than the half day it would take to build the list from scratch each time, because the underlying statements have already been read consistently in the weeks between reviews, ready and waiting rather than needing to be gathered and re-read under the same time pressure every single month, month after month, for as long as the practice keeps billing patients — the setup cost is paid once, and every month after that simply draws on it, cheaply and reliably, without repeating the work.
Matching against deposits
A patient balance is only half the picture — the other half is whether a payment actually arrived. Because FlowParse also reads bank statements and insurer remittances, patient payments recorded on a statement can be checked against what actually cleared the account, closing the loop between what a patient was billed and what was collected.
Who this is for
Practice managers
Building an aging report or reconciling patient balances without retyping every statement.
Billing services
Processing statements across several client practices in one batch.
Front-desk and billing staff
Answering a patient's balance question with line-item detail, not just a total.
Bookkeepers and accountants
Building patient-receivables data that reconciles against what actually landed in the bank.
Formats and layouts this handles
Patient statements vary more in layout than almost any other financial document a practice deals with. Some billing systems print a simple summary with one balance line. Others produce a full itemised ledger with every charge, payment and adjustment since the account was opened. Some combine several family members onto one statement; others issue one per patient regardless of household.
None of that variation requires a separate setup step. Because the reading is based on identifying what a field means — a prior balance, a new charge, a payment — rather than where it sits on a specific template, a statement from a billing system used for the first time is read the same way as one from a system the practice has used for years. A combined family statement is read the same way too, with each patient's portion kept as its own row rather than merged into a single household total that would hide which specific patient owes what.
Scanned statements — printed originals photographed or scanned for a paper-based practice still transitioning to digital records — go through OCR first and are then structured and checked the same way as a digital PDF, with the same balance arithmetic verification applied regardless of how the document originally arrived.
From one statement to a full billing run
Reading a single statement by eye is a two-minute task, and automating that alone would not be worth much. The value shows up at volume — a practice running two hundred patient statements in a billing cycle, where reading each one individually would consume the better part of a day, and where a transposed digit or a missed adjustment on any single statement is easy to miss precisely because there are so many to get through.
At that scale, the balance-arithmetic check becomes the thing that actually makes the batch trustworthy. Rather than reviewing two hundred statements individually, the practical workflow is reviewing the handful the check flags — a statement where prior balance plus charges minus payments and adjustments does not equal the stated current balance — and trusting the rest, because the same arithmetic that would catch a genuine misread has already been applied uniformly across every one.
That shift — from reading everything to reviewing only what the check surfaces — is what makes the difference between two hundred statements taking a day and taking twenty minutes, and it does not require the batch to be any smaller or the statements to be any simpler.
Family and combined statements
A common wrinkle: some billing systems consolidate an entire family — parents and children under one guarantor — onto a single statement, with one combined balance at the top and each family member's individual charges and payments listed separately beneath it. Reading only the top-line combined figure answers “what does this household owe” but not “what does each individual patient owe”, which is often exactly the question a practice needs answered.
Each patient's section within a combined statement is read as its own set of rows, with the guarantor relationship kept as a separate field rather than discarded — so a practice can report on the household total when that is useful, and on each individual patient's balance when that is what a specific question calls for, without having to re-read the document twice for two different views of the same underlying numbers.
This distinction matters most in pediatric and family-medicine practices, where combined statements are the norm rather than the exception, and where a parent calling about “the family balance” often actually needs to know which child's specific visit is driving it.
The same principle extends to a guarantor covering an unrelated group of patients — a caregiver managing an elderly relative's account alongside their own, for instance. Whatever grouping the statement itself presents is preserved rather than flattened, so the data reflects the actual billing relationship instead of an assumption about what a household looks like.
Getting that grouping right matters beyond convenience — a collections call made to the wrong person, or a balance attributed to the wrong patient within a household, is exactly the kind of small error that erodes trust with a patient far more than the balance itself ever would, and one that is entirely avoidable once the statement's own grouping is respected rather than overridden.
What this is not
Not a patient billing system
It reads the statements a billing system already produces — it does not generate, send or manage them.
Not a collections service
It surfaces balances and their age. Contacting patients or pursuing overdue amounts remains a practice task.
Not insurance verification
It reads what a patient statement states about the balance owed, not eligibility or coverage details.
Not a guarantee against every reading edge case
The arithmetic check catches most misreads, but an unusual layout occasionally needs a human glance — that is what the confidence flags are for.
A statement flagged by the balance check is worth a look before it is trusted for an aging report or a patient-facing answer — the flag exists precisely so an uncertain read gets a human glance instead of silent trust.
Privacy
Uploads are transferred over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Statements are never used to train AI models.
For a practice handling patient billing data on behalf of others, that is not a footnote — details are on the security page.