ACA Consent vs Application Review: Two Records Agents Still Confuse

ACA consumer consent and ACA application review are two different documentation requirements. Consent is the record that the consumer gave you permission to help with Marketplace enrollment or updates. Application review is the record that the consumer reviewed the eligibility application information, had the attestations explained, and confirmed the information was accurate before submission. CMS allows the same documentation to satisfy both requirements only if it clearly captures those two separate events.

A lot of ACA compliance problems start with one bad assumption: that if the client said “yes, help me,” the file is covered.

It is not.

For HealthCare.gov states and State-based Marketplaces on the federal platform, CMS treats consumer consent and application review as separate requirements. One happens at the front of the workflow, before you help. The other happens at the back end, before you submit. If you collapse them into one vague memory of “the client was on the phone with me,” you are missing the actual structure CMS expects.

The short answer

Consumer consent answers the question: “Do I have permission to help this person?”

Application review answers the question: “Did this person review the information going into the Marketplace application, have the attestations explained, and confirm it was accurate before I submitted it?” CMS’s 2025 compliance deck lays out separate minimum-content requirements for each, and CMS’s model form and FAQ materials reinforce that they are two distinct events in the workflow.

That distinction matters because the records are not interchangeable. A permission record by itself does not prove the consumer reviewed the application before submission. And a final confirmation record does not solve the problem if you never documented that the consumer gave you permission to assist in the first place.

What ACA consumer consent actually is

CMS says agents and brokers must document receipt of consent from the consumer or the consumer’s authorized representative before providing enrollment assistance or facilitating enrollment. The consumer or authorized representative has to take an action that produces the documentation, and the record has to include, at minimum, the scope, purpose, and duration of the consent, the date it was given, the name of the consumer or authorized representative, the name of the agent, broker, or agency being granted consent, and a way for the consumer to rescind it. CMS also says the documentation must be maintained for at least 10 years and produced to CMS upon request.

In plain English, consent is your record that the client authorized you to step into the file. CMS’s model consent form shows what that looks like in practice: permission to search for an existing Marketplace application, complete an eligibility or enrollment application, provide ongoing account maintenance and enrollment assistance, or respond to Marketplace inquiries, all tied to a defined duration and a stated method for revoking consent.

What ACA application review actually is

Application review is a different checkpoint. CMS says agents and brokers must document that the eligibility application information was reviewed by, and confirmed to be accurate by, the consumer or authorized representative before application submission. At minimum, that record has to include the date the information was reviewed, the name of the consumer or authorized representative, an explanation of the attestations at the end of the eligibility application, and the name of the assisting agent, broker, or web-broker. That record also has to be kept for at least 10 years and produced to CMS upon request.

CMS’s model eligibility-application-review form makes the distinction even clearer. The consumer states that they reviewed the Marketplace eligibility application information, confirmed its accuracy before submission, and had the attestations explained with an opportunity to ask questions. That is not just permission to help. That is confirmation that the application, as prepared, was actually reviewed and approved by the consumer before it was sent in.

The easiest way to remember the difference

The cleanest operational rule is this:

Consent is before assistance.
Application review is before submission.

CMS’s own model verbal scripts follow that exact logic. The consent script is read at the beginning of the conversation because consent has to be obtained before helping with the application or enrollment. The application-review script is read later, before submission, after the attestations are explained and the application information is reviewed with the consumer for accuracy.

That is why these records feel related but are not the same. They live at different points in the workflow and prove different things.

Can one document cover both?

Yes, but only if it actually shows both events.

CMS’s FAQ says the same documentation may be used to comply with both requirements as long as it appropriately captures the two separate events. CMS explains that the first event is the consumer giving consent before assistance, and the second event is the consumer reviewing and confirming the accuracy of the eligibility application information after the application has been completed and before it is submitted. CMS even gives the example of timestamped communications showing the first event and then the second event.

That is also why CMS’s model form is useful even if you do not use it word for word. The model is expressly presented as an example that can document both consumer consent and consumer review and confirmation of the accuracy of eligibility application information, and CMS says agents, brokers, web-brokers, and agencies may tailor it to fit their business model.

So the real answer is not “Do I need one form or two?” The real answer is: however many records you use, the file has to show two different moments happened.

What agents usually get wrong

The first common mistake is treating consent like it solves everything. It does not. Consent proves the client let you help. It does not prove the client reviewed the final application or had the attestations explained before submission.

The second mistake is relying on verbal-only workflow without preserving the record. CMS says acceptable documentation can include a signed document, an audio recording, a written electronic response, or similar records, but an unrecorded verbal attestation that is not memorialized in a written record will not demonstrate compliance. CMS also says unwritten verbal consent, by itself, is not enough.

The third mistake is assuming a simple checkbox is enough. CMS’s FAQ says that if a workflow only requires the consumer to check a box confirming they provided consent, that practice will likely not be sufficient for the consent requirements or the application-review requirements.

The fourth mistake is forgetting that application review is not just for brand-new applications. CMS says that whenever changes are made to the eligibility information on a consumer’s Marketplace application, including plan and enrollment changes, the application-review requirements must be met again.

What counts as acceptable documentation

CMS does not prescribe one mandatory documentation format for either consent or application review. CMS’s current guidance says compliant documentation can take different forms as long as it creates a record the agent can maintain and produce to CMS if requested. CMS’s model materials and FAQs give non-exhaustive examples including recorded phone calls, text messages, emails, electronic documents with digital signatures, physical documents with wet signatures, written responses from the consumer, and audio recordings capturing verbal confirmation.

That flexibility helps operationally, but it also creates sloppier files when agents are not careful. The method is flexible. The proof is not. If the documentation would not let CMS see what happened, when it happened, and whether the consumer actually took the required action, it is not a strong record no matter how convenient it felt at the time. CMS also says it does not provide advance approval of the wording or methods agents use, so the burden stays on the agent to make sure the documentation is sufficient.

One more thing: this is not the same as Call Center authorization

Agents often blend a third concept into this mix and make the file even messier.

Marketplace Call Center authorization is its own issue. CMS’s 2025 compliance deck says that when an agent works with the Marketplace Call Center on behalf of a consumer without the consumer participating in the call, the agent must both document consumer consent and application review and obtain authorization to work on the consumer’s behalf with the Call Center. CMS specifically says Call Center authorization alone will likely not satisfy the consent and application-review requirements, and the consent/application-review documentation will not automatically provide Call Center authorization.

That is a useful operational reminder because it keeps agents from thinking one generic “client okay” note solves every federal workflow problem. It does not.

Important scope point: this is a HealthCare.gov rule set

This post is about the federal Marketplace documentation framework for Federally Facilitated Exchanges and State-based Exchanges on the Federal Platform. CMS’s FAQ says these federal consumer-consent and application-review requirements do not apply to state-based Marketplaces that do not rely on the federal platform. In those states, agents still need to follow any applicable state, exchange, carrier, privacy, and agency rules, but the specific federal framework discussed here is tied to FFE and SBE-FP operations.

That point matters because a lot of ACA compliance content overgeneralizes. If you sell in multiple states, you should be clear on which clients are on HealthCare.gov-type workflows and which are not.

A practical workflow agents can actually use

A clean ACA workflow looks like this: first, get and document consent before you search for an application, change an application, or assist with enrollment. Then complete the application work. Then, before submission, walk through the application information with the consumer, explain the relevant attestations, get the consumer’s confirmation that the information is accurate, and document that second event. If the application is changed later, document review and confirmation again before the updated submission. That sequence is not just cleaner; it matches the way CMS structures the requirements and the way CMS’s model verbal scripts are written.

The agents who get into trouble are usually not the ones who never talked to the client. They are the ones who cannot prove the right thing happened at the right time.

Bottom line

ACA consumer consent and ACA application review are not two names for the same record.

Consent is the consumer’s documented permission for you to help. Application review is the consumer’s documented confirmation that the eligibility application information was reviewed, the attestations were explained, and the information was accurate before submission. CMS allows one set of documentation to satisfy both only if it clearly captures both events as separate steps in the workflow.

That is the practical rule agents should remember: permission first, confirmation last. If your ACA workflow cannot show both, it is weaker than it looks.

If your ACA records are split across call recordings, e-sign packets, texts, and Marketplace notes, Vault gives you one place to keep the consent record, the application-review record, and the rest of the file tied together.

This article is for educational purposes only and is not legal advice. Agents should review current CMS guidance, carrier rules, and agency policies, and consult qualified counsel or compliance professionals for specific requirements.