Summary for the developers
Context
We are a third-party medical billing agency operating under a single Accuro data centre. We bill for 47 practitioners, each with their own practitioner number and payee number, and submit through Teleplan. MSP pays on a semi-monthly cycle — 24 pay periods per year — so a complete per-payment reporting cycle for our roster is 1,128 Remittance Summary reports annually.
We use the report for two purposes:
Per-payment reconciliation. After each MSP payment run, each doctor should receive a record of what was billed, paid, and adjusted. We want to send these every cycle. We currently don't, because each cycle means 47 separate report generations plus 47 manual file renames, 24 times a year. The work isn't justifiable, so our practitioners go without a routine statement they should be getting.
Year-end tax reporting. At each client's fiscal year-end we provide a single summary of everything paid across that year. This is what their accountant works from. Fiscal year-ends vary — some practices run the calendar year, others end in June, September, or another month depending on incorporation — so no fixed annual period would serve all of them.
The existing single-period report is correct and readable. The billed / paid / adjusted breakdown is exactly what we need. The problem is scope and output, not content.
Why a calendar rule won't work
MSP close-off and payment dates are semi-monthly but not fixed. Per the MSP close-off and remittance schedule, 2026 close-offs fall on the 5th and 20th in January, the 3rd and 17th in February, the 3rd and 19th in March, the 1st and 20th in April — shifting month to month around designated holidays. Payment dates shift the same way, landing between the 13th and 15th, and between the 27th and the 31st.
Any date-range feature must therefore resolve periods from the close-off and payment dates already attached to each remittance record, not derive them from a calendar rule such as "1st–15th and 16th–month-end." That assumption would misassign claims at nearly every boundary.
Problem
The report offers one pay period at a time, or "All." "All" returns everything from the practitioner's start date with us to the present — too much for reconciling a recent payment, and useless for a fiscal year, since it can't be bounded at either end. A single period is the right scope but covers only that one period.
There is no way to request "the last two months" or "April 1 to March 31." We identify every period inside the window, run each separately, and reassemble by hand. A full fiscal year is 24 report generations for one practitioner, or 1,128 across our roster.
Every generated file then has to be renamed manually before it can be filed or sent, since the output doesn't identify the practitioner or period usably.
Multi-select doesn't help. Selecting several practitioners merges them into one combined PDF, which can't be sent to anyone. Each doctor is entitled to see only their own remittance data; distributing a merged report would disclose one practitioner's billing and payment information to another. One-practitioner-at-a-time is the only safe path, which defeats the purpose of the multi-select entirely.
The net effect: a reporting feature we would use constantly is usable only in small manual doses.
Proposed solution
Four changes to the Remittance Summary:
Multi-select pay periods. Let the existing dropdown accept multiple selections. Smallest possible change, no boundary ambiguity, since every selection is a whole period.
User-defined date range, resolved by payment date. Accept a From/To date and include every pay period whose payment date falls within it, using the dates already recorded against each remittance rather than a derived calendar rule. Anchoring on payment date gives clean fiscal-year boundaries: consecutive years neither double-count a straddling period nor drop one. Periods are never split. The report should state which periods it covers, with their payment dates, so an accountant can verify coverage without cross-checking against MSP records.
Split output per practitioner. When more than one practitioner is selected, generate one PDF per practitioner rather than one merged document. A checkbox such as "Generate separate report for each practitioner" preserves current behaviour for anyone who wants the combined view.
Configurable filename template. Let the user define an output filename pattern using tokens — for example RemittanceSummary_[PractitionerLastName][PractitionerNumber][PayeeNumber][StartDate][EndDate]. Files write to a chosen directory in one operation, with no per-file save dialog. Without this, a 47-file run still requires 47 manual renames and most of the batching gain is lost.
Report structure for a multi-period run
Each pay period appears as its own section, retaining the current layout and its own billed / paid / adjusted tallies, labelled with its payment date. A summary block at the end totals billed, paid, and adjusted across all included periods. Period-level figures must stay visible rather than collapse into the aggregate — reconciliation happens per payment, since that is how MSP pays, while the aggregate is what the accountant uses.
Acceptance criteria
A user can select all practitioners and multiple pay periods (or a date range), run once, and receive one distinct PDF per practitioner.
Each PDF contains only that practitioner's data. No other practitioner's claims, totals, practitioner number, or payee number appears anywhere in the file, including headers, footers, and summary pages.
Pay periods are always included whole. A date range never produces a partial period.
A pay period is included when its actual payment date falls within the selected range. Period boundaries are read from remittance data, not derived from a calendar assumption.
The report states which pay periods it covers, with their payment dates.
Each period retains its existing billed / paid / adjusted breakdown, with a grand total across the range.
Two consecutive, non-overlapping date ranges include every pay period exactly once between them — no gaps, no duplicates.
Filenames generate from a user-defined template; no manual renaming before distribution.
A run producing 47 PDFs completes as a single unattended operation to a chosen directory, with no per-file prompts.
Impact
This closes a confidentiality gap, removes an error-prone manual process, and makes Accuro directly useful for work its customers currently do by hand or skip entirely. In our case it converts routine per-payment statements from impractical to automatic across 1,128 reports a year. Any customer billing for more than one practitioner — agencies, clinics with shared billing staff, locum groups — hits the same wall, and every one of them has clients with differing fiscal year-ends.
One caution on the 1,128 figure: that assumes every practitioner is active across all 24 periods. If some of your 47 are part-time, seasonal, or joined mid-year, the real number is lower, and a product manager who checks will notice. Either verify it or phrase it as "up to 1,128."
