CMS Universe Tables: Every Routinely Submitted Table Across the Five 2026 Audit Protocols
July 28, 2026
When a CMS program audit engagement letter arrives, the clock that matters most is 15 business days: the deadline for producing your universe tables in the exact record layouts CMS defines. Which tables you owe depends on which protocols are in scope, and plans routinely discover mid-scramble that nobody is certain of the full list.
This is that list. Sixteen tables are routinely submitted across the five 2026 protocols, a few more exist but are collected only when CMS asks, and every one of them shares a set of field conventions that produce most of the validation failures we see. All of it traces to two primary sources: the record layout specifications CMS publishes through OMB-approved form CMS-10717, and the CMS Audit Submission Checklist.
Key Takeaways
- •16 universe tables are routinely submitted across the five protocols: 5 ODAG, 6 CDAG, 3 FA, 1 SNPCC, 1 CPE.
- •FA Table 3 (PDE) and ODAG Tables 6 and 7 (AIP, CARA AR) exist in the layouts but are collected only on CMS instruction. Do not build your submission plan around them.
- •Universes are due 15 business days from the engagement letter. Several supplemental items, including the SNPCC Questionnaire, are due in 5.
- •Every table shares the same conventions: CCYY/MM/DD dates, the 11-character MBI, receipt date as the date the request first arrived through any channel, and blank fields are never valid.
- •An inaccurate or incomplete universe that survives three submission attempts becomes an Invalid Data Submission (IDS) finding.
The Sixteen Routine Tables at a Glance
| Protocol | Routine tables | Count |
|---|---|---|
| ODAG (Part C) | OD, RECON, PYMT_C, EFF_C, GRV_C | 5 |
| CDAG (Part D) | CD, CDER, PYMT_D, RD, EFF_D, GRV_D | 6 |
| FA (Part D) | RCFA, RCT, NE | 3 |
| SNPCC | SNPE | 1 |
| CPE | COA | 1 |
The sections below name every table and what it captures. For per-table field detail, timeliness standards, and failure modes, each protocol has a quick reference and a full table-by-table guide; both are linked in place.
ODAG: Five Tables (Part C)
Organization Determinations, Appeals, and Grievances covers how the plan handles Part C requests for services and payment, appeals of denials, and complaints.
- OD (Table 1): organization determinations, the plan's first decisions on requests for services or payment.
- RECON (Table 2): reconsiderations, the first-level appeals of denied organization determinations.
- PYMT_C (Table 3): payment determinations on the medical side.
- EFF_C (Table 4): effectuations, proof that approved and overturned cases were actually put into effect.
- GRV_C (Table 5): grievances about care or service quality.
Detail: the ODAG quick reference or the full ODAG table-by-table guide.
CDAG: Six Tables (Part D)
The Part D counterpart to ODAG, with tighter clocks and one structural difference: exception requests get their own table instead of living inside coverage determinations.
- CD (Table 1): coverage determinations on Part D drugs.
- CDER (Table 2): exception requests, covering tier, formulary, step therapy, and quantity limit exceptions.
- PYMT_D (Table 3): payment determinations on the pharmacy side.
- RD (Table 4): redeterminations, Part D's first-level appeals.
- EFF_D (Table 5): effectuations.
- GRV_D (Table 6): grievances.
Detail: the CDAG quick reference or the full CDAG table-by-table guide.
FA: Three Routine Tables (Part D)
Formulary Administration tests whether the plan administers the CMS-approved formulary at the pharmacy counter. Nearly all of this data originates inside the PBM's claim adjudication system.
- RCFA (Table 1): pharmacy point-of-sale claims rejected for formulary or utilization management reasons.
- RCT (Table 2): transition fills provided to new enrollees and long-term care residents who hit a formulary issue.
- NE (Table 4): the roster of members who became eligible during the period, cross-referenced against RCT to confirm transition obligations were met.
Detail: the FA quick reference or the full FA universe guide.
SNPCC: One Table Plus Supplemental Submissions
For Special Needs Plans, the care coordination protocol runs on a single universe:
- SNPE: every current SNP enrollee, with the HRA and care plan dates CMS tests timeliness against.
Two supplemental submissions ride along and are not universe tables: the approved Models of Care and the SNPCC Questionnaire, and the questionnaire is due in 5 business days rather than 15. Detail: the SNPCC quick reference or the SNPE universe deep dive.
CPE: One Table
Compliance Program Effectiveness collects one universe, and under the 2026 discussion-based review it doubles as the agenda for the audit conversation:
- COA: Compliance Oversight Activities, the plan's auditing, monitoring, and investigation activity across 12 data elements.
Detail: the CPE and COA quick reference or the full CPE COA universe guide.
The Tables CMS Collects Only on Instruction
Three tables exist in the record layouts but are not part of the routine submission package, and treating them as routine wastes preparation time plans do not have:
- FA Table 3, PDE (Prescription Drug Event data): submitted only when CMS instructs during the audit.
- ODAG Table 6, AIP (Dual SNP benefit reductions): not routinely collected; treat it as historical unless CMS asks.
- ODAG Table 7, CARA AR (CARA At-Risk Determinations): collected only on instruction.
The distinction comes straight from the CMS Audit Submission Checklist, and it is one of the fastest ways to tell whether a vendor or consultant is working from the current protocol or an old one.
Field Conventions Every Table Shares
The sixteen tables have different columns, but the conventions below apply across all of them, and they account for most of the validation failures we see when plans run files through the scrubber.
Dates are CCYY/MM/DD
Not MM/DD/YYYY, not Excel's default. A correct date in the wrong format is still a validation error, and Excel silently reformats dates on open and save.
The MBI is 11 characters, everywhere
The same member must carry the same Medicare Beneficiary Identifier in every table and every protocol. PBM and TPA systems that carry internal member IDs need a clean mapping back to MBI before the file is assembled.
Receipt date is when the request first arrived
Through any channel. If a provider faxes a request on Monday and intake logs it Wednesday, Monday is the receipt date, and every timeliness clock runs from it.
Blank is never valid
Where the record layout allows "None" as a value, it must be written out. An empty cell is a missing field, not an implicit None, and missing required fields are exactly what universe integrity testing exists to catch.
Excel is a hostile environment for final files
Dropped leading zeros, reformatted dates, and hidden characters from copy-paste all survive visual review and fail validation. Validate the file you will actually submit, not the working copy.
Tables must tell one consistent story
Approved determinations need matching effectuation rows, appealed denials must appear in the appeal table, and FA rejections generally need corresponding CDAG coverage determinations when the member was at the counter. CMS reads the tables together.
Where Bad Tables End Up: IDS
Under the 2026 framework, a sponsor that cannot produce an accurate and complete universe within three submission attempts receives an Invalid Data Submission finding, one of the three finding classes alongside CAR and Observation. It is the finding a plan can fully prevent before the audit begins, because every trigger above is checkable in advance. Our IDS in 2026 guide covers the mechanics.
Validate All 16 Tables Before CMS Sees Them
The CMS Universe Scrubber validates every routine table across all five protocols against the CMS record layouts: formats, required fields, timeliness logic, and cross-table consistency. Or start free by checking your file structure with the Universe Header Check.
Frequently Asked Questions
How many universe tables does a CMS program audit include?
Sixteen tables are routinely submitted across the five 2026 protocols: five for ODAG (OD, RECON, PYMT_C, EFF_C, GRV_C), six for CDAG (CD, CDER, PYMT_D, RD, EFF_D, GRV_D), three for FA (RCFA, RCT, NE), one for SNPCC (SNPE), and one for CPE (COA). A handful of additional tables exist in the record layouts but are collected only when CMS instructs the plan to produce them, including FA Table 3 (PDE) and ODAG Tables 6 and 7 (AIP and CARA AR).
Which universe tables are not routinely submitted?
Per the CMS Audit Submission Checklist, FA Table 3 (Prescription Drug Event data), ODAG Table 6 (AIP, Dual SNP benefit reductions), and ODAG Table 7 (CARA At-Risk Determinations) are collected only on CMS instruction during the audit. SNPCC also includes two supplemental submissions that are not universe tables: the approved Models of Care and the SNPCC Questionnaire, and the questionnaire is due in 5 business days rather than the 15 business days universes get.
What date format do CMS universe tables require?
CCYY/MM/DD, per the CMS record layout specifications. Dates in MM/DD/YYYY or any other format are validation errors even when the underlying date is correct. Excel is a common source of silent damage here because it reformats dates on open and save, which is one reason plans validate the final file rather than the working copy.
Do universe tables have to reconcile with each other?
Yes. CMS tests cross-table relationships within and across protocols: an approved organization determination should have a matching effectuation row, a denied case that was appealed should appear in the reconsideration or redetermination table, and pharmacy point-of-sale rejections in the FA universe should generally have corresponding coverage determinations in CDAG when the member was at the counter. Tables that are individually clean but tell inconsistent stories still produce findings.