What each figure is computed from
Every figure PTRS shows in this module, what it reads and the arithmetic applied. Where a figure is structurally zero, the row says so and points to the full chain.
The windows
Four settings control almost every date range in the module, and none of them is changed anywhere in an installed copy of PTRS, so these are the values everyone actually sees.
| Setting | Default | Used by |
|---|---|---|
| The dashboard's rolling window | 30 days | Dashboard KPIs, the whole executive dashboard |
| The trend window | 90 days | Attendance, compliance, incident and enrolment trend charts |
| The report default window | 30 days | Operational reports and the financial summary when no dates are given, and the funder report period, always |
| The staff retention window | 12 months | Staff retention |
Choosing YTD sends no window at all, which falls through to the same 90-day trend window used everywhere else, so pressing it returns the last 90 days on every trend chart and the last 30 on the KPI strip. Nothing in PTRS computes a true year-to-date figure.
Dashboard KPI strip
Six tiles. Four are real.
| Tile | Computed from | Status |
|---|---|---|
| Total Members | A count of member records for the organisation | Real |
| Active Members | Members marked active and carrying an active status | Real |
| Total Staff | Active staff, narrowed by location when one is selected | Real |
| Open Incidents | Incidents that are neither resolved nor closed | Real |
| Avg Daily Attendance | The mean of a daily summary figure over 30 days | Always zero. The table has no writer |
| Compliance Score | The mean of the latest compliance snapshot per active location | Always zero. No snapshot can be written |
All six tiles carry a fixed "no change" comparison and an empty sparkline. No comparison figure is ever requested or computed, so every tile shows "+0%" beside the caption "vs prior period".
Two details make it worse. The Open Incidents tile shows a rising trend whenever the count is above zero at all, which is an alarm dressed as a trend, not a trend. And the "Compare to previous period" switch always shows the previous period as identical to the current one on every tile, because the change it is dividing by is fixed at zero.
Executive dashboard
Thirteen organisation figures and a per-location table. Reachable only as a direct download. See who can do what with analytics and reports.
| Figure | Computed from | Status |
|---|---|---|
| Total and Active Locations | A count of locations, and a count where active | Real |
| Total and Active Members | As the KPI strip | Real |
| Total Staff | Active staff | Real |
| Incidents, 30 days | Incidents in the last 30 days | Real |
| OCCL Pending | Incidents pending OCCL review, all time, ignoring the 30-day window shown beside it | Real, but not actually a 30-day figure |
| Meals Served, 30 days | The sum of meals served | Real |
| Meal Days, 30 days | Distinct dates with a meal record | Real |
| Overall Compliance Score | The mean of the latest snapshot per active location | Always zero |
| Avg Daily Attendance | The mean of the daily summary figure | Always zero |
| Per-location Members | Distinct members with an active enrolment at that location | Real |
| Per-location Compliance, Attendance | As above | Always zero |
The per-location figures cost five separate reads per location, so an organisation with twenty sites runs a hundred round trips for one request; nothing pages or limits it.
The spreadsheet includes a Meals Served column in its location table that the document's version of the same table omits. The organisation summary above it includes the figure in both.
BGCA Monthly Statistical Report
The module's largest computation, and the one with the most assumptions built into it. It reads real check-in records directly, unlike everything else attendance-shaped in this module.
The age calculation is an approximation
Every age in this report is a mid-year age, not an age on any particular date. It uses the birth month only, never the day, so a child born on the 30th of June and one born on the 1st of July are placed a year apart, and neither is checked against the report's own date. It drives every age-banded row in the report: Sections 1A, 1B, 2, 5 and 9.
The Demographics chart, the Demographic Summary operational report and Program Demographics all use an exact calculation that checks the birthday against today's date, and they use different age bands too: Under 6, 6 to 8, 9 to 11, 12 to 14, 15 to 17, 18 and over, against this report's 5 and under, 6 to 8, 9 to 11, 12 to 14, 15 to 17, 18 to 20.
So the Demographic Summary report and the statistical report will disagree about the same children, by both method and band, and neither states which it used.
Section by section
| Section | Computed from | Note |
|---|---|---|
| 1A Attendance | Check-in records, grouped by mid-year age band and month | Counts check-in events, not distinct children |
| 1A Days Accessible | Distinct dates with any check-in, per month | A day the club opened with no check-ins counts as closed. At county or state level, one site's activity marks the day open for the whole group |
| 1B ADA | Section 1A divided by Days Accessible, rounded to a whole number per band | The Total row sums the rounded band values, so it can differ from Section 1A's own total divided by days |
| 2 Registered Members | Members active today whose enrolment date falls on or before month end, with a current or renewing status | Not historical. A child who left in March is absent from January's figure too, so re-running last year's report gives different numbers each time |
| 3 Other Youth Served | Nothing. Twelve zeroes per band | A fixed stub with no data behind it |
| 4 Total Youth Served | Section 2 plus Section 3 | Since Section 3 is always zero, this can never differ from Section 2 |
| 5 New Memberships | Members whose enrolment date falls in that month of the report year | The same today-only population as Section 2 |
| 6 Teen ADA | Nothing. Three rows of twelve zeroes | A fixed stub with no data behind it |
| 9 Members by Age and Gender | Active members by exact mid-year age, 5 to 20, plus a 21-and-over group | PTRS records five gender values; the report has three columns, so two extra values are folded into "Other" |
| 10 Days Open | The same as Days Accessible | |
| 10 Total Hours | Ten hours a day in June, July and August; five hours a day otherwise | See below |
| 11 Ethnicity | Active member counts per ethnicity, divided by all active members | Every ethnicity value PTRS records is included |
| 12 Meals and Snacks | Meals served, by meal type and month | Covers all five meal types; nothing is dropped |
| 13 Program Participation | Distinct members with an active enrolment, by program type | Written into the January slot of a twelve-month grid, because participation has no monthly breakdown |
Every figure in Section 10's Total Hours row is a fixed estimate: ten hours a day in summer, five otherwise, for every site in every organisation, with no setting behind either number. PTRS stores each site's actual operating hours on its own profile, and this report does not read them.
The Avg column on every grid in this report divides by the number of months with a non-zero value, not by twelve and not by the months the club was actually open. A club running a ten-week summer program shows a summer-only average presented as an annual one, on Average Daily Attendance, the statistic this report exists to produce.
What the Level choice does
Site, County and State decide which locations are included: one location, every location in a Delaware county, or every active location in the organisation. The level itself changes nothing about the arithmetic; it only appears in the report's own title, its file name and its header.
Financial summary
The best-evidenced report in the module. It states its own assumptions in what it sends back, and the screen and all three exports print them.
| Figure | Computed from |
|---|---|
| Funding Committed | The sum of every funder's grant amount, for funders whose grant period overlaps the window. A funder with no start and no end date always counts |
| Member Receivables | The sum of every active member's monthly fee: one month of billing, not an amount owed |
| Outstanding Balances | The sum of every active member's balance due: the amount actually owed |
| CACFP Projected | See below |
| Net Projected Position | Funding Committed plus CACFP Projected, minus Outstanding Balances |
| Members tracked, with a balance | A row count, and a count where the balance is greater than zero |
| Subsidised | Members whose billing type is Subsidized, or who receive a childcare subsidy |
| Scholarship | Members whose billing type is Scholarship |
PTRS itself calls Net Projected Position a cash-position view, not an accounting figure. That caveat does not reach the screen; the smaller print under the tile gives only the arithmetic.
The screen labels the tile "Member Receivables" with the outstanding balance relegated to the smaller print beneath it. The spreadsheet exports call it "Member Receivables (monthly fees)"; the document calls it simply "Receivables". Three formats, three labels, one figure, and the shortest label is the most misleading.
The CACFP projection
For each meal record in the window, PTRS finds the location's active CACFP enrolments and works out each eligibility tier's share of them. If the location has no active enrolments, it assumes every meal was served at the lowest, most conservative rate. For each tier with a real share, it finds the most recent active reimbursement rate for that location, meal type and tier, effective on the meal's own date, falling back to an organisation-wide rate if no site-specific one exists. The claim for each tier is the meals served multiplied by that tier's share, multiplied by the rate, rounded to the cent.
If no rate can be found for a tier at all, that tier's meals are dropped from the money total while still counting toward Total meals served.
CACFP's own Est. Reimbursement figure only counts a meal record once it has been marked valid, and none ever is, so it stays at zero permanently.
This projection ignores that validity flag entirely and prices every meal record in the window. So the same rows produce zero on the CACFP screen and a positive figure here, and neither screen mentions the other. Treat this projection as a planning estimate over every recorded meal, exactly what its own assumptions text says, and never as a claimable amount.
The 50-row cap
The member table on screen and in every export shows the fifty highest balances. The headline totals are worked out over the full set before that limit is applied, so they are correct, not truncated. The document labels the table "Member accounts (top N)", which is honest; the screen and the workbook do not repeat that label.
Funder figures
| Figure | Computed from |
|---|---|
| Funding breakdown, dashboard chart | The sum of every funder's grant amount, grouped by funder type, each as a percentage of the total |
| Funder report Total Attendance | The sum of a daily summary figure since the period start: always zero |
| Funder report Total Enrollment | A count of active enrolment records tied to the organisation's programs: enrolment counts, not distinct children, so a child in three programs counts three times |
| Funder report period | Always the last 30 days, regardless of the funder's own reporting frequency, which is nonetheless stamped on the report as its type |
| Funder shown as active on the list | No grant end date, or one that has not yet passed |
| Funder shown as active on the detail page | Its stored status equals Current: a different rule from the one the list uses |
The funder report counts enrolment rows. The program demographics report counts distinct members per program and sums across programs, so a child in two programs counts twice there. The statistical report counts distinct members across the whole organisation. Three figures called "enrolment", three different denominators, and nothing on screen tells them apart.
Staff retention
The figure PTRS calls Staff Retention is a running count of everyone ever hired, worked out without regard to whether they are still employed. It is non-decreasing by construction: a chart called retention that structurally cannot show a departure.
Nothing calls it today, so no screen actually renders it.
Timezone
Both heatmap figures in this module group by the calendar date in universal time. Delaware runs four or five hours behind it, so anything recorded after roughly 7 or 8 in the evening, local time, lands on the next day's cell. The statistical report is unaffected: it reads a plain date with no time attached.
Every export footer and every "Generated" stamp in the module is printed in universal time, labelled as such in the documents and unlabelled on screen.
Checked against PTRS on 7 September 2026.