How to run a CoC APR

If your organization holds a Continuum of Care grant, you owe HUD an Annual Performance Report on it. One report per grant, per operating year, submitted through Sage. It is the document that says what the grant did, for whom, and with what result.

HUD publishes a thorough guidebook covering every field. This is the other half: the sequencing, the dates that are not where you expect them, and the failures that show up in practice. It assumes you have done this once and it did not go smoothly, or that it has just landed on your desk and nobody handed you a process with it.

When yours is due

Ninety days from the end of your grant operating year.

The catch is in the second half of that sentence. Your operating year is not the calendar year and it is not the federal fiscal year. It is set in eLOCCS based on when you began incurring eligible costs under that specific grant. For a new grant with no capital costs, it starts on the first day of the month in which you or your subrecipient began incurring them. For a grant with capital costs, it starts when you first draw non-capital costs and begin serving people.

Sage shows the operating period for each report on your dashboard. Use those dates. Do not calculate your own, and do not carry last year's range forward.

What you are actually submitting

Two different things, and keeping them separate in your head makes the whole exercise easier to plan.

Forms you fill in by hand inside Sage. Contact information, performance accomplishments, financial information, program eligibility, bed and unit utilization if your project type has beds, and optional additional comments. None of this comes from your HMIS. Somebody has to sit down and write it.

One file generated by your HMIS. This is the APR CSV, and it carries the numbers.

The APR CSV

A zip file containing 67 CSV files, one per question on the report. You generate it in your HMIS for the operating period, upload it in Sage, and Sage tests it and tells you what it found.

Three rules account for a large share of failed uploads:

• It must be the FY2026 format. Uploads in an older APR CSV format are rejected outright. Sage will not accept them and will not partially process them.
• Generate it for the operating period Sage displays. Not the period you assumed, and not a tidy calendar year.
• Zip it once. Double-zipped files, password-protected files, and files that were never zipped all fail.

What the report asks

Sixty-seven questions sounds worse than it is. They group into seven areas, and once you can see the groups you can see which part of your data each one is testing.

Two definitions run through most of it. A stayer is someone with no exit date, or an exit date after the reporting period ends. A leaver is someone whose exit falls inside it. A surprising number of confusing APR numbers trace back to an exit date that was never entered, which quietly moves someone from one column to the other.

The data quality section is a preview of your monitoring visit

Q6a through Q6f are usually treated as a hurdle to clear. They are more useful than that. Those six tables are HUD telling you, in advance and in writing, which parts of your data it considers worth checking.

Q6e is the one small organizations tend to score worst on, and it is the one that has nothing to do with the report. It measures timeliness: how long after an intake or an exit the record was actually entered. A record entered forty days late is complete and correct and still counts against you. The fix is not a reporting fix. It is a question about what happens on a Tuesday afternoon when the shelter is full.

Read those six tables in month two of your operating year rather than in month twelve. Everything they flag is fixable while the year is still running and nearly impossible to fix afterward, because correcting a record honestly means going back to whoever was in the room.

Five things that send an APR back

Sage sorts upload failures into categories. These are the ones worth knowing before you are looking at red text at four in the afternoon on day eighty-nine.

One more that is not an upload error. If your bed and unit utilization comes in under 90 percent, you have to explain why and say what the project will do about it. That is a narrative you should write deliberately rather than at the last minute, because it is read.

What changed for FY2026

The FY2026 HMIS Data Standards took effect for data from October 1, 2025. Three changes touch the APR directly.

• Gender, element 3.06, was retired from required collection. Historical data remains.
• Sexual Orientation, element R3, was also retired from required collection.
• A new element, 4.21 Sex, was added, required for certain funding sources including CoC YHDP, the Unsheltered and Rural Special NOFOs, CoC Builds, ESG RUSH, HUD-VASH and SSVF.

On the report itself, the gender questions Q10a, Q10d, Q24c, Q25c, Q26c and Q27c came out, and Q24e went in to capture sex across household types. If you are comparing this year's numbers to last year's, those questions are the reason a few rows do not line up.

Four situations with their own rules

• Joint TH and RRH components submit two separate APR CSV zip files inside the one APR. One for the transitional housing side, one for the rapid rehousing side.
• Victim service providers cannot export from HMIS, so where a subrecipient is a VSP, multiple uploads are allowed. One file comes from the HMIS and the other from the comparable database.
• Multiple subrecipients should normally be aggregated into a single APR CSV covering every project under the grant. Your HMIS Lead can help if your system will not do it directly.
• The Coordinated Entry APR is a system-wide report for the whole CoC, not a project-level one, regardless of how your CE system is organized.

One rule about who presses the button: the recipient has to be the entity that submits, and the login of the person submitting is what proves it. A subrecipient cannot submit on your behalf unless you have granted that authority through a configuration request in Sage. Sort this out before the week it is due, because it is an access problem and access problems take days.

If it comes back rejected

HUD either accepts your APR, accepts it with comments, or rejects it. A rejection is not a finding and it is not a crisis. The report returns to your dashboard marked rejected and unlocked, you address what the CPD representative raised, and you resubmit.

How you fix it depends on what was wrong. A data error means correcting the record in your HMIS, regenerating the CSV, and uploading the replacement. An eligibility question is answered in the Program Eligibility form or in Additional Comments. A utilization question is answered by editing that narrative.

A sequence that works

Ninety days is generous until you discover on day eighty that your HMIS project type is wrong. This is our suggested order rather than a HUD requirement, built backward from the deadline.

The one thing to change for next year

Almost every painful APR is a data quality problem discovered eleven months late. The report itself is mechanical. What makes it hard is that ninety days is not enough time to reconstruct a year of records nobody kept current, and the parts you can reconstruct honestly are limited to what someone actually remembers.

Run the data quality questions quarterly instead. Q6a through Q6f take minutes to generate and they tell you exactly where the gaps are while the people who were there can still fill them. An organization that does this spends its ninety days writing narrative and checking numbers, which is what the ninety days were meant for.