The reimbursement arithmetic

Every calculation in PTRS that turns a meal into money. All of it was read end to end and all of it is printed here, including the parts that never run, because knowing which calculation is running is the whole question on this page.

Nothing on this page is a statement of the published federal rate

PTRS holds two different rate tables, both labelled for the same fiscal year and both citing the same Federal Register notice. They disagree in every shared cell. Neither is reproduced here as authoritative, they are reproduced as what PTRS itself contains, so the disagreement is visible.

Check the Federal Register notice before relying on any figure below.

The short answer

Question	Answer
Is there a calculation that turns meals into dollars?	Yes, one. It feeds the Est. Reimbursement tile on CACFP Meal Service
Does it produce a non-zero number today?	No. Twice over, it counts only validated meal records, and no meal record is ever validated; and it multiplies by a rate table that no screen can fill in
Does a claim work out its own total?	PTRS has a method for it, built and never called by anything, and the line items it would add up have no writer anywhere
Does the claim apply the child's eligibility tier?	No. The one calculation that runs applies the Free tier to every meal, regardless of who ate it

The two rate tables

Both are built into PTRS's code. Both carry the same description, seeding the current fiscal year's USDA CACFP reimbursement rates against the same Federal Register notice.

One of the two sits behind the one action that could load rates; the other has no path into PTRS at all.

Programme	Meal	Tier	Table behind the loading action	The unused second table
ARAS	Breakfast	Free	2.08	2.48
ARAS	Breakfast	Reduced	1.68	2.18
ARAS	Breakfast	Paid	0.38	0.39
ARAS	Lunch	Free	3.92	4.53
ARAS	Lunch	Reduced	3.52	4.13
ARAS	Lunch	Paid	0.48	0.41
ARAS	Supper	Free	3.92	4.53
ARAS	Supper	Reduced	3.52	4.13
ARAS	Supper	Paid	0.48	0.41
ARAS	AM Snack	Free	1.06	1.13
ARAS	AM Snack	Reduced	0.53	0.57
ARAS	AM Snack	Paid	0.10	0.09
ARAS	PM Snack	Free	1.06	1.13
ARAS	PM Snack	Reduced	0.53	0.57
ARAS	PM Snack	Paid	0.10	0.09
SFSP	Breakfast	Free	2.57
SFSP	Lunch	Free	4.40
SFSP	Supper	Free	4.40
SFSP	AM Snack	Free	1.12
SFSP	PM Snack	Free	1.12

Both tables run from 1 July 2025 to 30 June 2026. Neither table covers Summer Food at the Reduced or Paid tier; the one behind the loading action covers Summer Food only at Free.

Loading rates ignores the fiscal year you give it

Asking PTRS to load rates for a fiscal year stores the year you name, and then fixes the effective dates to 1 July 2025 through 30 June 2026 regardless, carrying the current year's amounts whatever year you named.

Asking to load "2027-2028" produces twenty rows labelled that way, carrying this year's money and this year's dates. Nothing checks the year you give it.

This action has no screen, so this only matters to someone with direct system access, which is currently also the only way to get any rate into PTRS at all.

The one calculation that runs

This is the Est. Reimbursement tile in the CACFP Monthly Claim panel on CACFP Meal Service, and it is a preview: it does not read from or write to any actual claim.

Step 1, the period. The current calendar month. Not selectable, and not the claim month of any actual claim.

Step 2, the records. Every meal record for that site in that month.

Step 3, the counts. The total served is the sum of every record's count. The valid total is the sum of every record's count where the record is marked valid, which is none of them. The invalid total is the difference between the two. The meal days figure is the count of distinct dates with a record.

Step 4, the money. For every validated meal record, PTRS looks up the Free-tier ARAS rate for that record's meal type, and multiplies the record's total by that rate. Est. Reimbursement is the sum of those amounts across every validated record.

Three things follow, and all three are load-bearing.

1. Every meal is priced at the Free tier, regardless of who ate it. The eligibility tier is a real idea in PTRS, both on the rate table and on a child's enrolment, and this calculation does not consult it. Against the rate table behind the loading action, a Paid-tier lunch would be priced at 3.92 rather than 0.48, more than eight times the Paid rate.
2. A missing rate is silently priced at zero. If the rate table is empty, which it is in every copy of PTRS out of the box, the whole figure is $0.00 with no message and no warning.
3. The figure is zero regardless, because the calculation only looks at validated records, and nothing ever marks a meal record valid.

The panel above the figure divides the valid total by the total served and prints it as Valid Rate, turning amber below 90%. That is permanently 0%.

The calculation that has never run

A claim's own total is meant to come from adding up its line items: the line total plus any cash-in-lieu total, and separately the sum of the meal counts.

Nothing in PTRS ever calls that. And the line items it would add up have no writer anywhere, no action, no screen, no built-in starting data. So the totals are effectively zero because there is nothing to add.

A line item would carry a meal count, the rate applied, a line total, a cash-in-lieu total and a number of operating days. The line total is a stored figure, not a worked-out one, nothing in PTRS multiplies the meal count by the rate applied. Whatever created the line item would have had to supply that product itself.

So the answer to "can the reimbursement arithmetic be read end to end?" is yes for the preview and no for the claim, not because the calculation is hidden, but because the calculation that would fill in a claim does not exist. That is stated here rather than softened, because this page is about federal money.

The claim's line item table adds up whatever rows it is given and prints a Grand Total, and with no rows it shows "No line items for this claim."

Rate integrity, two of the twenty claim checks

One check compares a claim's stored rate against the rate table. It works like this:

1. If the claim has no line items, it passes immediately, and every claim in PTRS takes this path.
2. Otherwise, it picks a date in the middle of the claim month, loads every rate active on that date, and for each line item looks for a rate matching its meal type and eligibility tier.
3. It fails if no rate matches, or if the applied rate differs from the published one by more than a fraction of a cent.

Matching a line item's meal type maps PTRS's four claim-level meal types onto its five meal-record meal types. A snack on a claim always maps to the PM snack rate, and an unrecognised meal type falls back to Lunch, the second most expensive rate in the table. In both rate tables the AM and PM snack rates are identical, so today the snack mapping changes nothing, but it is a silent choice, and the fallback to Lunch is not.

The Delaware daily limit

The limits. Read per site; when nothing is configured PTRS falls back to:

1. Two meals a day.
2. Two snacks a day.
3. Three meal events in total.

These three are what the Daily Limits panel on Point of Service Entry shows, and they are stated correctly on that screen.

What counts as a meal and what counts as a snack. Breakfast, Lunch and Supper are meals; a single "Snack" category covers both. Meal records themselves keep AM Snack and PM Snack separate, so the daily-limit accounting and the meal record use two different vocabularies for the same idea.

The scope. PTRS is meant to count a child's meals across every site in the organisation for the day, not just the site serving the current meal, so a child attending two clubs in one day is counted once against one budget, by design.

The rule, evaluated in this order, first match wins:

1. If this is a meal, and the child already has today's maximum meals or more, it is disallowed.
2. Otherwise, if this is a snack, and the child already has today's maximum snacks or more, it is disallowed.
3. Otherwise, if the child already has today's maximum total events or more, it is disallowed.
4. Otherwise, it is allowed.

What PTRS does with a disallowed meal, if this ever ran. It records it anyway, for the audit trail, marked as over the limit with a stated reason. It does not block the meal from being served.

Whether an override is possible. Any set of limits other than 2 / 2 / 3 marks a site as using an override and sets its state-approval status to Pending. Nothing in PTRS ever moves that status to Approved, so the Override Active badge and the DDOE Approval Status block on Point of Service Entry would always read Pending once set, if the screen that sets them existed. It does not, so today they never appear at all.

The whole of this section describes a calculation with nothing calling it

The Delaware daily limit service exists in PTRS and is never called by anything. Neither meal-count screen calls it, both simply write a meal record and stop.

The per-child daily meal log this calculation would keep has no writer as a result. Its readers are the roster screen, the per-child log lookup, and one of the twenty claim checks, which counts violations in that empty log and therefore reports zero for every claim, on two of the checks that are supposed to be blocking.

The limit is not enforced, not measured and not reportable. The three numbers on the Daily Limits panel are a configuration display, not a live count.

Rate records, fields and rules

Creating a rate has no screen; the rules are stated so that anyone with direct system access gets it right.

PTRS needs	Required	What PTRS accepts
Fiscal year	Yes	The shape YYYY-YYYY
Meal type	Yes	Breakfast, AM Snack, Lunch, PM Snack or Supper
Eligibility tier	Yes	Free, Reduced or Paid
Programme	Yes	ARAS or SFSP
The rate itself	Yes	Greater than 0
Effective date	Yes	A real date
Source	No	Free text. The loading action writes the Federal Register citation

A duplicate, the same organisation, programme, meal type, tier, fiscal year and still active, is refused, naming the combination.

Every rate created through the one loading action is stored at the organisation level rather than tied to one site; the unused second table takes a specific site instead, a third way the two tables disagree.

An expiry date cannot be set when a rate is created. It can only be set by updating the rate afterwards, which also has no screen.

How a rate is found

Two ways of looking one up, and they filter differently.

The rate schedule behind Reimbursement Rates filters on your organisation and whether the rate is marked active, then optionally on fiscal year and programme. It does not check whether today falls in the rate's effective window, so an expired rate still appears in the schedule.

Finding the current rate for one meal, tier and programme has no screen. It filters on organisation, programme, meal type, tier and whether the rate is active, and takes whichever is effective most recently. It also ignores the expiry date, so the most recently effective rate wins even if it has expired. It fails, naming the combination, when nothing matches.

The rate integrity check described above is the only one of the three that respects the effective window, and it uses the middle of the claim month as its test date.

What a reader should take from this page

• The Est. Reimbursement figure on CACFP Meal Service is a preview of the current calendar month at the Free tier, and it is $0.00 for two independent reasons. Do not quote it, in either direction.
• A claim's Grand Total is $0.00 and always has been. It is not a calculation that failed; it is a calculation with nothing to add up.
• The Daily Limits panel shows the configured limits correctly and shows no usage against them, because usage is never recorded.
• The rate schedule is empty in every copy of PTRS, and the two rate tables built into PTRS disagree. Take rates from the Federal Register.

For what happens around the arithmetic, who can move a claim between states, and what each of the twenty checks actually tests, see How a claim moves through its lifecycle.