How a participant becomes eligible

CACFP pays a different amount for the same meal depending on the household that ate it. A child's eligibility tier is therefore a money decision, and a state reviewer will ask you to prove how it was reached.

This page describes the whole eligibility design PTRS implements, and then the two sentences that matter more than the design.

Two facts that govern everything below

1. The one working screen types the tier by hand. The only eligibility control in the product is a three-option dropdown on the enrolment form, defaulting to Free. Nothing carries a worked-out tier onto an enrolment, and the enrolment's own link to an income application has no writer anywhere in PTRS.

2. The tier is never used to price a meal. The one reimbursement calculation that actually runs looks up the Free rate for every meal regardless of tier. Changing a child from Paid to Free changes no number in PTRS.

So the eligibility design below is real, complete, and, today, financially inert. It is documented because it is specific enough to be fixed, and because the records it produces are records a reviewer will read.

The three tiers

PTRS defines exactly three tiers:

Tier	What it means	Badge
Free	Household at or below the free threshold	Green
Reduced	Above free, at or below the reduced threshold	Yellow
Paid	Above the reduced threshold	Grey

Any value that is not one of the three shows as a grey badge with its raw text.

From the regulation, PTRS's own source cites the federal rule for the tier model. Check the regulation itself before relying on a threshold.

The four determination methods

PTRS records how a tier was reached, stored on the enrolment and shown on the enrolment detail page.

Method	What it is meant to mean	What PTRS does with it
Area Eligible	The site qualifies on feeder-school data, so every participant is Free	Stored. Nothing checks that an area-eligibility record exists
Income Application	A household income application was approved	Stored. Nothing checks that an application exists, and no field links to one
Categorical Eligibility	Participation in SNAP, TANF or FDPIR	Stored. Nothing records which programme, or any evidence
Default	No determination, treat as Paid	Stored. Does not force the tier to Paid

PTRS checks the method is one of the four and stores it. There is no cross-check of any kind between the method and the tier, and no rule that pairs them.

A record reading "Tier: Free, Method: Income Application" is therefore an assertion by whoever filled in the form, not a derived fact, and PTRS holds nothing that supports it.

The income application, where a tier is computed

This is the one place in PTRS that calculates an eligibility tier from data rather than accepting it as input. It works in three steps.

Step 1, annualise the reported income

The reported income is multiplied by a factor depending on how often it is received:

Reported as	Multiplier
Annual	× 1
Monthly	× 12
Twice Monthly	× 24
Bi-Weekly	× 26
Weekly	× 52

Step 2, find a threshold for the household size

PTRS first looks for a stored income guideline row matching the household size exactly, for the programme year given. If the household is larger than every stored row, the largest row is extended: its base figure, plus the extra household members multiplied by that row's own per-member increment.

From that base figure, PTRS works out two thresholds: the free threshold is the base times 1.30, and the reduced threshold is the base times 1.85.

Step 3, compare

An annualised income at or below the free threshold makes the tier Free; one at or below the reduced threshold, but above the free one, makes it Reduced; anything higher makes it Paid. A household exactly on a threshold gets the more favourable tier.

The thresholds PTRS actually uses

The income guideline table has no way to be filled in, so the stored path has never run

The only way anything is ever written to the income guideline table has no screen anywhere in PTRS. There is no built-in starting data either.

So the table is empty in every copy of PTRS, and every tier PTRS has ever computed came from the fallback figures below. PTRS's own code comment warns that an installed copy must fill in that table through direct system access, and the only way to do that has no screen.

The fallback figures, worked out in full, the two threshold columns are the base figure times 1.30 and times 1.85:

Household size	Base figure	Free at or below	Reduced at or below
1	15,650	20,345.00	28,952.50
2	21,150	27,495.00	39,127.50
3	26,650	34,645.00	49,302.50
4	32,150	41,795.00	59,477.50
5	37,650	48,945.00	69,652.50
6	43,150	56,095.00	79,827.50
7	48,650	63,245.00	90,002.50
8	54,150	70,395.00	100,177.50
each further member	+ 5,500	+ 7,150.00	+ 10,175.00

These are the numbers in PTRS. They are not presented here as the published federal guideline

PTRS's own comment calls these "Fallback FY 2025 thresholds" and gives no citation, no Federal Register notice, no date of publication.

This is the same caution as the two disagreeing reimbursement rate tables: check the published guideline before relying on any row above. An income threshold stated wrongly is a federal eligibility error, not a display mistake.

The one piece of good news is that PTRS holds one threshold table, not two.

You cannot tell which basis was used

Looking up an application returns the household size, the reported amount, the frequency, the annualised income and the resulting tier, and not the threshold it was compared against, nor whether that threshold came from a stored guideline or the fallback.

The audit trail records only that an income application was submitted for the child, with the resulting tier, nothing about which thresholds decided it.

Matching a programme year to a stored guideline set requires an exact match of the text, so a guideline set stored as 2025-2026 will not be found by an application whose programme year is 2026-2027. When that happens, PTRS silently uses the fallback and nothing in the response, the record or the audit trail says so.

An income application's lifecycle

PTRS defines four statuses. Three are reachable.

Status	Set by	Reachable
Pending	Submitting it	Through direct system access
Approved	Approving it	Through direct system access
Denied	Denying it	Through direct system access
Expired		No writer anywhere. No code assigns it

Approving sets the determination date and effective date from what is sent, stamps the expiry date as twelve months after the effective date, and records who certified it. Both dates come from whoever is approving it, so an approval can be backdated or forward-dated freely, nothing checks them beyond whether they are real dates.

Denying stores the reason and stamps the determination date as today.

Both refuse anything that is not currently Pending, saying it has already been processed, so an approval cannot be reversed and a denial cannot be appealed through any path in PTRS.

Nothing expires an approved application

The expiry date is written on approval and read by nothing. There is no scheduled task and no check anywhere that compares it to today, and the Expired status has no writer. An application approved once stays Approved indefinitely, and the tier it determined stays with it.

CACFP eligibility determinations are annual. PTRS records the expiry date and never acts on it.

None of it reaches an enrolment

This is the connection that does not exist.

Every enrolment has a field meant to link it to the income application that supported it, and PTRS has an action built to set that link. Nothing ever calls it. Creating an enrolment never sets it, and updating one never touches it either.

So that link is always empty, and approving an income application changes nothing about any enrolment. The two records are unrelated rows that a person would have to connect by hand.

Income verification, the 3% sample

PTRS can draw a sample of approved applications for verification.

The population. Applications in your organisation matching the fiscal year given, that are Approved, not already selected for verification, and not marked exempt.

The sample size. 3% of that population, rounded up, with a floor of 1 whenever the population is not empty. An empty population draws a zero-sized sample rather than an error.

The draw. A random selection with no repeatable starting point, so the same run cannot be produced again. The method of selection is not recorded; the audit trail records only the counts.

What it writes. One verification per selected application, starting Pending, copying its current tier as a starting point, and it marks each selected application as having been selected.

Three things this action does not do

• It applies no as-of date. It samples whatever is Approved at the moment it runs, for the fiscal year given. From the regulation, check the federal rule for the date the sample must be drawn against; PTRS does not implement one.
• It is not repeatable. Because it excludes applications already selected, running it twice draws a further 3% of what is left, not the same sample again.
• It has no screen. No screen in PTRS can draw the sample.

Completing a verification

Completing one marks it Completed, stamps the completion date, records who verified it, and, when the outcome changes the tier, writes the new tier back onto the income application itself.

It does not touch any enrolment, because nothing links them.

Field	State
Status	Only Pending (on creation) and Completed (on finishing) are ever written. In Progress and No Response have no writer, In Progress is read by the outstanding-list filter and can never match
First notice date, second notice date	No writer anywhere. The two-notice follow-up these fields exist for is recorded nowhere
Who verified it	Recorded using your own signed-in account, in a field named for a staff record, the same pattern as the claim fields described in How a claim moves through its lifecycle

The "no response" outcome cannot be recorded

PTRS's own list of outcomes includes a value for a household that never responds. The check that runs first on completing a verification accepts a different spelling of that idea, one PTRS does not actually store.

So sending the spelling the check accepts passes the check and then fails, naming the value as invalid. Sending the real value is rejected by the check itself with a message listing the spelling PTRS does not have.

Three of the four outcomes can be recorded and the fourth cannot, and the fourth is the one that matters, because a household that does not respond to a verification request is the case the whole follow-up process exists for. Same shape as the sixth meal type described in CACFP troubleshooting.

Area eligibility, the site-level route

An ARAS site can qualify on where it is rather than on who attends. PTRS holds the feeder-school evidence for this.

The threshold, stated in PTRS's own design:

• The direct test is free/reduced enrolment at 50% or above, worked out as the free/reduced count divided by total enrolled students.
• A CEP school qualifies instead on its identified student percentage, multiplied by 1.6, reaching 50 or above.

From the regulation, PTRS's own source cites the federal rule for the 50% requirement. Note that the message a user would actually see carries no citation: it names only the percentage and the 50% threshold.

The data source recorded is one of School District, CEP Data, Direct Certification or Census.

Three consequences of how the threshold is enforced

A failing site cannot be recorded. Creating a record computes the percentage and refuses to save anything below the threshold. There is no way to document that a site was assessed and did not qualify, which is exactly the record a reviewer asks for when a site stops claiming.

The organisation-wide "below threshold" count can only be zero on the create path. No record can be created failing the threshold.

But an update is not re-checked. Updating an existing record recomputes the percentage from new enrolment counts and saves without checking the threshold again. A record created at 60% can be edited down to 10% and stored. That is the only way the below-threshold count becomes non-zero, and the only way the area-eligibility card's red state can ever appear.

Expiry is recorded and not applied

An expiry date is required when a record is created. Looking one up returns whichever record was certified most recently for the site, with no check for whether it has lapsed, and the card that shows it does not display the expiry date at all.

So a certification that lapsed two school years ago renders as a green "Area Eligibility: 62.0%" card with no indication that it is stale. The actions that would compute expiry, listing sites about to lose eligibility, and the organisation-wide dashboard, have no screen.

DDOE approval is self-granted

Marking a site DDOE-approved is a plain switch on the update action, and setting it stamps today as the approval date. Nothing narrows this beyond the module's usual rule, so any account that can reach the CACFP part of PTRS, including a front-line staff member, can mark a site as state-approved. The card then prints "| DDOE Approved."

This action has no screen, so this is reachable only through direct system access today.

What all of this is worth

The eligibility record has one real consumer and it is not the money.

Two claim checks count active enrolments, the checks for meals versus enrolment, and enrolment verification. Both are blocking, and both are among the only four checks of twenty that run a real, distinct test. They count enrolments; they do not read the tier. See what each rule tests.

The reimbursement calculation ignores the tier entirely. It looks up the rate for Free tier and ARAS programme for every meal record, in a step whose own surrounding description calls it "tier-disaggregated reimbursement", which it is not. Against the rate table behind the loading action, that prices a Paid-tier lunch at the Free rate, more than eight times over, and prices a Summer Food site at ARAS rates. The full arithmetic is on The reimbursement arithmetic.

So the honest summary is:

Question	Answer
Can PTRS compute a tier from household income?	Yes, correctly, against a threshold table it holds, reachable only through direct system access
Can PTRS put that tier on a participant's enrolment?	No. Nothing links them, and the enrolment tier is typed by hand
Does the tier change what a meal is worth?	No. Every meal is priced at the ARAS Free rate
Can a site's area eligibility be recorded?	Through direct system access only, and only if it passes
Can a lapsed determination be detected?	No. Both expiry dates are written and read by nothing

Related

• Enrol a participant, the one eligibility flow that completes, and what it silently accepts
• Work the enrolment screens, what the three panels on the enrolment screen are actually counting
• Enrolment and eligibility fields, every field and its rule
• Who can do what with enrolment and records, all 41 things PTRS can do here, and which have a screen
• The reimbursement arithmetic, why the tier does not reach the money
• CACFP troubleshooting