Skip to main content

Why counts must be point-of-service

What "point of service" means​

A point-of-service count is a count taken at the moment a child is handed a meal, by the person handing it over, of meals that actually met the meal pattern.

It is not the number of children signed in that morning. It is not the number of portions the kitchen prepared. It is not a number reconstructed at the end of the day from the roster.

Every one of those alternatives is higher than the true figure, and every one of them is a disallowance in a review.

From the regulation, PTRS's own built-in claim check cites the federal rule that meals claimed must not exceed participants documented as physically present, for the check that requires meals to be compared against attendance. A separate check cites the rule for the enrolment ceiling.

Why the timing is the whole point​

Three properties follow from taking the count at the serving line, and none of them survives taking it later.

It is bounded by reality. A count taken at the line cannot exceed the number of children who were there. A count reconstructed from an attendance roster can, and routinely does, a child signed in at 3pm who left before snack is in the roster and not in the count.

It is attributable. Someone specific took it, at a specific moment, and can be asked about it. A reviewer's first question about an unusual month is who counted.

It is contemporaneous. A count written down at the time is evidence. A count written down afterwards is a recollection. That distinction is the whole reason CACFP recordkeeping requirements exist.

The daily limit follows from the same logic: a child may be claimed for at most two meals and two snacks in a day, three events in total, across every site they attend, a rule that can only be applied against a per-child record, and is meaningless against a batch total.

What PTRS actually records​

PTRS records a batch total, not a point-of-service count.

A meal record is one row per site, per date, per meal period, holding a total and a breakdown by age band. It carries the staff member who recorded it, and when it was created.

So PTRS holds who and when it was entered, not when it was counted, and not which children. There is no field for the time of service and no field for the time the count was taken.

That is a design decision, not a defect: an aggregate count is what most CACFP software records, and it is what a monthly claim needs.

Where it becomes a defect is that the per-child layer exists in PTRS's design and is never filled in.

The per-child layer that never fills​

PTRS's design includes a per-child daily meal log, one row per child, per date, per meal event. It would carry the child, the site, the date, the meal type, a link to the meal record, running counts of that child's meals and snacks for the day, and whether the child is within the daily limit.

The calculation built to keep it, the Delaware daily limit service, does this correctly, counting across every site in the organisation, applying the site's configured limits, and recording the event even when it is over the limit, for the audit trail.

Nothing anywhere in PTRS ever calls that calculation. Neither meal-count screen calls it. The log has readers and no writer.

Four consequences, all of them on the point-of-service question:

  1. The Delaware daily limit is never applied. A child can be claimed for six meals in a day and nothing notices.
  2. The multi-site case is invisible. A child attending two clubs is counted twice with no record connecting the two.
  3. Two of the twenty claim checks, both meant to be blocking, one federal and one state, count entries in an empty log and report zero for every claim.
  4. The panel headed "Daily Meal Roster" on Point of Service Entry lists meal types, not children, because the real per-child roster has no screen. A reviewer asking to see the roster will be shown a summary.

The screen called "Point of Service Entry"​

Point of Service Entry is subtitled "Record daily meal counts and view real-time daily limit status."

Its form saves through the ordinary aggregate meal-count action, the same one every other meal-entry screen uses. There is no per-child entry path anywhere in PTRS.

And the form on that screen fails on every save, because it sends the signed-in user's email address where a staff record is required. The one screen in the product named for point-of-service counting cannot record a count. See Record a meal count.

The attendance cross-check​

The proper compensating control for an aggregate count is to compare it against attendance: meals served on a day should not exceed children present that day.

PTRS builds this twice and reaches it neither time.

In the claim checks. The "Meals vs Attendance Count" rule is federally required and blocking, and it always passes without looking, its own comment says it is waiting on a connection to the Attendance module that was never finished. Two more rules are pointed at the same stub and therefore also always pass.

In the reconciliation calculation. A separate reconciliation service genuinely compares each meal record's total against the day's check-in count and marks it over-claimed when meals exceed attendance, or matched otherwise. It also works out attendance by age group from members' dates of birth, and records a discrepancy for an over-claim. It is real work, and it is reachable three ways, none of which runs:

  • The nightly reconciliation task is built and never put on a schedule. Every one of PTRS's twelve scheduled tasks runs at its own set time, and this is not one of them.
  • Running reconciliation for a day is called by Attendance-Meal Reconciliation's Run Reconciliation button, which asks for "every site" and is refused before PTRS even reads it.
  • Looking up the monthly reconciliation report is called by the same page with the same request, refused the same way.

So the page reads "Failed to load reconciliation data. Please try again later." permanently, and the one calculation in PTRS that would catch an over-claim has never run.

Two further things about that page, for when it is fixed. Its four stat tiles read Total Days, Matched, Over-Claimed and Unreconciled, and nothing ever assigns the Unreconciled outcome: the calculation only ever marks a day Matched or Over-Claimed, so that tile can only ever read 0. And the calculation stops immediately on a day with no meal records at all, so a day with children present and no meal recorded produces no reconciliation row at all, the failure mode closest to lost reimbursement is the one it does not see. The page's own colour key also lists a fourth outcome that PTRS does not actually define.

What this means for a club today​

Plainly, because this is the part that costs money:

  • Take the count at the serving line, on paper, at the time. PTRS does not capture the moment and cannot reconstruct it.
  • Enter the total into PTRS the same day, through + → Meal Count, naming the person who took the count. That attribution is real and it is stored.
  • Keep the paper record. It is the point-of-service documentation. PTRS holds a total and an attribution; it does not hold a roster, a service time, a meal pattern verdict or a daily-limit check.
  • Do your own daily-limit check for children who attend more than one site. Nothing in PTRS will do it.
  • Do your own attendance-versus-meals comparison before a claim period closes. Both of PTRS's own mechanisms for it are unreachable.

What a fix would look like​

For completeness, and because two of the three are small:

  1. Call the Delaware daily limit calculation from the meal-count screens. It is complete. It needs the children's ids, which the aggregate form does not collect, so this depends on a per-child entry screen existing first.
  2. Put the nightly reconciliation task on a schedule, and send a real site id from Attendance-Meal Reconciliation. Both are small changes, and together they turn on the attendance cross-check.
  3. Build the meals-versus-attendance claim check. The comment says what it needs, and the reconciliation calculation already contains the comparison.

Recorded, with the technical detail behind it, for the PTRS team.

Checked against PTRS on 7 September 2026.