Knowledge Center

📋 Knowledge Center · ACA & Regulatory Compliance

ACA and Regulatory Compliance in Premium Billing

What the rules require, where health plans incur compliance risk, and what billing software must do to keep plans on the right side of CMS, state regulators, and auditors.

📋 9 questions answered
🏥 Health plan focus
🔄 Updated March 2026
🏛️

ACA Marketplace Billing Compliance

3 questions

A binder payment is the first premium payment a newly enrolled ACA marketplace member makes before their coverage becomes effective. It is not simply a deposit. It is the enrollment activation trigger. Until a binder payment is received and confirmed, the member's coverage does not begin, and the health plan has no obligation to pay claims. Getting binder payment processing right is therefore a compliance requirement with direct consequences for member coverage continuity and plan liability.

The compliance requirements around binder payments operate at several levels:

Payment confirmation and enrollment activation. The billing system must receive the binder payment, confirm it has cleared, and transmit confirmation. The timing of this confirmation determines the member's coverage start date and must align precisely with the exchange's enrollment records. A billing system that fails to process or report binder payments accurately creates a mismatch between what the exchange records and what the health plan records, which produces enrollment discrepancies that could ripple forward through every billing cycle.

Handling members who do not submit a binder payment. CMS rules require that health plans have a defined process for members who enroll but do not submit a binder payment by the required date. The plan must void the enrollment and notify the exchange that coverage was never activated. Plans that pay claims for members who never submitted a binder are at risk.

Special enrollment period binder timing. Members who enroll through a Special Enrollment Period (SEP) often have different binder payment windows than open enrollment members, depending on the qualifying life event. A job loss SEP may allow retroactive coverage effective dates tied to the date of the qualifying event rather than the payment date.

The 2025 ACA Marketplace rule introduced a change to how health plans must calculate the threshold at which a member is considered delinquent. It shifted the standard from a fixed dollar threshold to a net premium percentage threshold. Understanding this change is important because it affects both how delinquency is calculated and what billing software must be able to configure.

What changed. Under the rule, health plans participating in federally facilitated exchanges and most state-based exchanges must set their delinquency threshold at no less than 95% of the net premium. The net premium is the member's share of the premium after APTC subsidies are subtracted. So for a member whose gross premium is $600 per month and who receives $450 in APTC, the net premium is $150. The 95% threshold on that net premium is $142.50. The member is considered to have paid in full if they pay $142.50 or more, even if they have not paid the full $150.

Why this matters for billing software. Prior to this rule, many health plans used fixed dollar thresholds, which are simpler to configure and administer. A net premium percentage threshold requires the billing system to calculate each member's current APTC amount, subtract it from the gross premium, apply the threshold percentage, and use the resulting dollar figure as the member-specific delinquency threshold. This calculation must update dynamically when APTC amounts change due to income changes, household changes, or mid-year eligibility redeterminations.

The interaction with the three-phase APTC grace period. The 95% threshold rule does not change the structure of the three-phase grace period for APTC-eligible members. The grace period clock still starts when a member's payment falls below the threshold, the plan must still pay claims for the first 30 days, may pend claims from days 31 to 90, and may terminate and recover claims if the member does not pay by day 90. What the 2025 rule changes is the calculation of when the clock starts.

The OBBBA sunset provision. Health plans should be aware that the 2025 rule included provisions subject to legislative review under the One Big Beautiful Budget Act. As of the publication of this page, the net premium threshold requirement remains in effect, but health plans should monitor CMS guidance for any amendments to the rule's implementation timeline or scope.

2025 ACA Payment Threshold Rule: Key Parameters
Threshold method required Net premium percentage (minimum 95%)
Net premium defined as Gross premium minus applicable APTC subsidy
Applies to FFE and most SBE marketplace plans; does not apply to non-marketplace ACA plans, Medicare Advantage, or Medicaid
Fixed dollar threshold No longer compliant as the sole threshold method for marketplace plans
Software requirement Dynamic per-member threshold calculation that updates when APTC changes; configurable percentage parameter
Compliance risk for plans on legacy systems Health plans still using fixed dollar delinquency thresholds for marketplace populations are not compliant with the 2025 rule. Legacy billing systems that do not support net premium percentage threshold calculations require manual workarounds, spreadsheet-based calculations, or custom development to achieve compliance. Each approach carries error risk and staff overhead that a configurable purpose-built platform eliminates.

Special Enrollment Period (SEP) members present distinct billing compliance challenges because their coverage effective dates, premium prorating rules, and binder payment timelines differ from open enrollment members based on the qualifying life event that triggered the SEP. A billing system that applies a single invoice template and coverage effective date logic to all new enrollees will generate incorrect invoices for SEP members and create billing records that do not match exchange enrollment records.

Retroactive coverage effective dates. Several SEP qualifying events entitle members to retroactive coverage. A member who loses job-based coverage is entitled to an effective date of the day after their prior coverage ended, which may be weeks before the binder payment is received. The health plan must issue an invoice that correctly reflects the premium owed from the retroactive effective date, not from the binder payment date. For members with APTC, the subsidy amount must also be calculated from the retroactive effective date, which requires coordination with the exchange to confirm the APTC amount for the retroactive period.

Premium proration for mid-month effective dates. SEP effective dates are frequently mid-month, which requires the first invoice to reflect a prorated premium for the partial first month. Prorating rules under the ACA require the premium to be calculated on a daily basis for the effective days of coverage in the first month. A billing system that does not support first-month proration will either overbill the member (charging a full month when they are only owed a partial month) or underbill them, both of which create reconciliation and compliance problems.

Binder payment windows for SEP members. SEP binder payment windows are typically shorter than open enrollment windows, and they interact with the retroactive effective date in ways that require careful tracking. If a member's retroactive effective date is in a prior month, the plan must be prepared to receive and process a binder payment that covers past-due premium for the retroactive period as well as the current month's premium in a single transaction, and to allocate that payment correctly across billing periods.

Verification of SEP eligibility. CMS requires that health plans confirm SEP eligibility documentation before activating coverage for certain SEP types. While this is primarily an enrollment function, it has billing implications. The billing system should not generate invoices or activate a member's billing record until SEP eligibility has been confirmed and the coverage effective date is finalized. Premature invoice generation for members whose SEP eligibility is subsequently denied creates billing records that must be reversed.

SEP billing complexity by qualifying event Loss of minimum essential coverage, marriage, birth or adoption, and relocation to a new coverage area all have different effective date rules under the ACA. The billing system must support coverage effective date logic that varies by SEP type, not a single default rule applied to all SEP enrollments.

🗺️

Multi-Market and State Compliance

3 questions

The ACA establishes a federal floor for premium billing requirements, but states have broad authority to impose additional requirements above that floor. Health plans operating in multiple states must comply with both the federal baseline and any state-specific rules that apply in each state, which creates a compliance matrix that varies by state and market segment simultaneously.

State continuation and grace period requirements. Several states have extended grace period requirements that exceed the ACA's 30-day minimum for non-APTC marketplace members. Some states require 60-day or 90-day grace periods before a plan may terminate coverage for non-payment, regardless of subsidy status. A health plan operating in these states must apply the state's longer grace period to all applicable members, even when the federal minimum would permit earlier termination. The billing system must be able to configure state-specific grace period lengths that override the federal default for members in those states.

State notice requirements. State insurance departments frequently impose notice content and timing requirements that go beyond the ACA's notice provisions. Some states require that termination notices include specific statutory language, be delivered by certified mail in addition to electronic delivery, or be filed with the state insurance department contemporaneously with delivery to the member. A billing system that generates a single national notice template will not satisfy state-specific notice requirements in these markets.

State-based exchange billing integrations. Health plans participating in state-based exchanges (SBEs) rather than the federal exchange must integrate their billing system with each state exchange's data systems, which may differ significantly in format, timing, and data structure from the federal exchange's systems. California's Covered California, New York's NY State of Health, and Washington's Washington Healthplanfinder all have distinct integration specifications. A billing platform that only supports federal exchange integration formats requires additional custom development for each SBE market the health plan enters.

Small group market billing rules. Several states impose additional billing requirements in the small group market, including restrictions on when premiums may be collected, requirements for remittance reporting to employer groups, and rules about how billing must reflect dependent vs. employee coverage allocations. These rules vary enough between states that health plans entering new small group markets should verify state-specific requirements before assuming that their existing billing configuration is compliant.

State CHIP and Medicaid premium rules. For health plans operating as managed care organizations under state Medicaid and CHIP programs, premium billing requirements are defined in each state's managed care contract. These contracts may specify premium amounts, grace period lengths, notice requirements, and termination procedures that differ from the health plan's commercial market practices. Non-compliance with the managed care contract terms is both a contractual breach and a CMS compliance issue.

William™ multi-state configuration William™ supports population-level rule sets that can be configured independently. Grace period lengths, notice templates, threshold calculations, and effective date logic can all be set differently for each population.

Medicare Advantage premium billing operates under a distinct regulatory framework from ACA marketplace billing, governed by CMS Medicare Advantage and Part D regulations rather than ACA marketplace rules. Health plans operating across both markets must maintain separate billing rule sets for each, and the compliance requirements are different enough that conflating them is a common source of compliance errors.

Non-payment termination procedures under MA regulations. CMS defines a specific process for MA plan non-payment terminations that differs from ACA marketplace termination rules. MA plans must provide a notice of intent to disenroll for non-payment before the disenrollment can take effect. The notice must meet CMS timing and content requirements, and the disenrollment must be reported to CMS through the Medicare Advantage Organization's reporting obligations. An MA plan that applies ACA marketplace termination logic to its MA population is likely out of compliance with the MA-specific requirements.

Part B premium integration. Many MA members have their plan premium deducted from their Social Security benefit alongside their Part B premium. Plans that offer Social Security withholding as a payment option must coordinate with SSA and CMS for enrollment in the withholding program, track withholding amounts per member, and reconcile the amounts actually withheld against the member's premium obligation. This reconciliation is separate from the APTC reconciliation that ACA marketplace plans perform but requires similar rigor in the billing system's accounting records.

Low Income Subsidy (LIS) and Extra Help coordination. MA members who qualify for the Low Income Subsidy program may have reduced or zero plan premiums. LIS status changes when members' income or eligibility changes, sometimes mid-year. The billing system must receive and process LIS status updates from CMS, adjust premium amounts for affected members, and reverse any charges collected for periods when the member was LIS-eligible but was billed at the full premium rate. Failure to process LIS updates accurately creates both compliance exposure and member service problems for a population that is particularly vulnerable to billing errors.

CMS bid and revenue reconciliation. MA plans participate in an annual bidding process that sets the plan's benchmark and member premium for the following plan year. The plan's billing system must be updated annually to reflect the new premium amounts resulting from the bid, and premiums must be adjusted precisely on January 1 of the plan year without requiring manual intervention for each member account. Mid-year changes due to CMS risk score adjustments must also be reflected in capitation payment reconciliation.

CMS Medicare Managed Care Manual CMS's Medicare Managed Care Manual, Chapter 2, defines the specific requirements for MA plan enrollment and disenrollment for non-payment, including required notice content, timing, and the reporting obligations that follow. Health plans should ensure their MA billing compliance processes reference the current version of this guidance, as CMS updates it periodically.

Regulatory change management is one of the most practically demanding aspects of billing compliance, because CMS and state regulators issue rule changes that affect billing operations with meaningful frequency. The ACA marketplace alone has seen billing-relevant rule changes almost every plan year since 2014. Health plans that lack a defined process for monitoring, assessing, and implementing regulatory changes routinely find themselves operating out of compliance while working to catch up.

Monitoring for billing-relevant regulatory changes. Not every CMS rulemaking affects billing, but several annual rule cycles routinely include billing-relevant provisions: the Notice of Benefit and Payment Parameters (NBPP) for ACA marketplace plans, annual Medicare Advantage and Part D rate announcements, and state insurance department bulletins. A health plan billing compliance function should monitor all of these channels and triage new rules for billing impact within a defined window of publication.

Assessing billing system impact. Once a billing-relevant rule is identified, the health plan needs to assess what changes are required in the billing system. Some changes require only configuration updates (a threshold percentage, a grace period length, a notice template). Others require changes to billing logic that the system may or may not support without custom development. The assessment should distinguish between these two categories early, because the implementation timeline differs substantially.

Testing before the effective date. Billing rule changes should be configured and tested in a non-production environment before they go live. For threshold changes, this means running a test billing cycle against sample member data to confirm the new threshold logic produces the expected results. For notice template changes, it means reviewing the generated output against the regulatory language to confirm it meets the content requirements. Changes deployed to production on the effective date without prior testing carry unnecessary risk.

Documentation for audit purposes. Every regulatory change that affects billing configuration should be documented, including what the rule requires, what was changed in the billing system, when the change was implemented, and who approved it. This documentation is the foundation of a defensible response to a regulatory audit. Health plans that rely on institutional memory rather than written records of compliance configuration changes are exposed when staff turnover occurs or when an auditor requests a compliance history.


🔒

Audit Readiness and Compliance Risk

3 questions

CMS audits of ACA marketplace plan operations and Medicare Advantage plans routinely examine billing and premium collection practices. State insurance departments conduct examinations that include billing compliance as a standard scope area. Health plans that treat audit readiness as something to address when an audit is announced are in a fundamentally weaker position than those that maintain continuous audit readiness as an operational standard.

Audit readiness in billing operations comes down to four capabilities that the billing system must support:

Complete and accessible transaction history. Auditors examining billing compliance will request the full payment history for a sample of member accounts, including every invoice generated, every payment received, every notice sent, and every status change in the delinquency workflow. This history must be retrievable quickly and must be presented in a format that is traceable to its source. A billing system that cannot produce a complete, chronological audit trail for a specific member account within minutes is not audit-ready. Systems that require manual reconstruction of member history from multiple data sources are particularly vulnerable.

Documented grace period compliance. CMS audits of ACA marketplace plans specifically examine whether grace period rules were applied correctly to APTC-eligible members. The audit will look for members who were terminated before their 90-day grace period expired, members whose claims were denied during the first 30 days of a grace period, and members who were not provided required notices at each stage of the grace period. The billing system must produce a grace period history report that shows the date each member entered the grace period, the notice dates, the claims pend status, and the resolution date and outcome.

Notice delivery records. Required member notices must be documented with delivery timestamps and confirmation. For electronic notices, this means delivery confirmation from the email service provider. For print notices, it means a fulfillment center record showing the notice was printed and mailed. Auditors who find that required notices were generated but cannot confirm they were delivered will treat this as a compliance gap regardless of whether the notice content was correct.

Configuration change history. Auditors examining whether a health plan implemented a regulatory change correctly will want to see when the billing system's configuration was updated and confirm that the effective date of the configuration change preceded or matched the regulatory effective date. Billing platforms that do not log configuration changes with timestamps and user attribution cannot support this inquiry. This is a gap in many legacy systems that purpose-built platforms address through their configuration audit logging.

Common Audit Finding Root Cause Risk Level
APTC member terminated before day 90 Billing system applied 30-day instead of 90-day grace period logic High
Claims denied during days 1–30 of grace period Claims pend/pay logic not correctly configured for APTC population High
Required notices not sent at correct intervals Manual notice process with inconsistent execution High
Delinquency threshold non-compliant with 2025 rule Fixed dollar threshold still in use for marketplace population High
Regulatory change implemented after effective date No defined process for monitoring and implementing rule changes Medium
APTC payments not reconciled within required window Manual APTC matching process with reconciliation backlog Medium
Member history incomplete or untraceable Billing system lacks complete transaction audit trail Medium

Wrongful termination in premium billing refers to a situation where a member's coverage is cancelled due to non-payment when it should not have been, either because the termination was premature, procedurally deficient, or based on incorrect billing data. It is one of the most serious compliance and member relations risks in health plan billing operations, because it can leave members without coverage during a period when they believed they were insured and may have incurred claims that the plan subsequently refuses to pay.

The most common causes of wrongful termination fall into several categories:

Grace period rule misapplication. Applying the wrong grace period length to a member is the most frequent root cause. An APTC-eligible marketplace member who is terminated after 30 days instead of the required 90 days has been wrongfully terminated. An MA member terminated without following the CMS-prescribed notice and disenrollment process has been wrongfully terminated. These errors are most common in billing systems that apply a single grace period rule to all members rather than population-specific rules.

Payment posting errors. A payment that was received but posted to the wrong member account, or a payment that was received but not processed due to a system error, can result in a member appearing delinquent in the billing system when they are not. If the delinquency workflow triggers automatically without a manual review step, the member may progress through the grace period and receive a termination while a payment they submitted sits unmatched in the suspense queue. Regular suspense queue review and prompt resolution of unmatched payments is a critical control for preventing payment-posting-related wrongful terminations.

Enrollment change timing errors. When an enrollment change (a plan change, an income change affecting APTC, or a household composition change) is processed in the enrollment system but takes time to reach the billing system, the billing system may continue generating invoices at the old premium amount or continue applying the old grace period parameters. If the enrollment change extended or modified the member's grace period eligibility and the billing system has not received that change, a termination based on the pre-change rule set may be wrongful.

Deficient notice delivery. Even when the grace period timing is correct, a termination can be procedurally deficient if the required notices were not delivered as required. A termination made without the required pre-termination notice gives the member grounds to challenge the termination as procedurally invalid even if the underlying delinquency is accurate.

Prevention requires automated controls, not reliance on staff vigilance. The common thread in most wrongful termination scenarios is that a manual process or a gap between systems allowed an error to persist uncorrected through the delinquency workflow until it produced a termination. Automated controls that flag anomalies before they become terminations are far more reliable than periodic staff review.

Regulatory and financial consequences CMS takes wrongful termination findings seriously in ACA marketplace and Medicare Advantage audits. Findings may result in corrective action plans, civil monetary penalties, and requirements to reinstate coverage and pay retroactive claims for the wrongfully terminated period. State insurance departments treat wrongful termination as an unfair trade practice with similar enforcement consequences.

Billing software is not a passive tool in compliance. It is the primary mechanism through which most billing compliance requirements are implemented and enforced. The difference between a health plan that passes a CMS audit and one that receives a corrective action plan often comes down to whether the billing system was built with compliance as a core design requirement or bolted onto a general-purpose platform as an afterthought.

These are the specific software capabilities that determine whether a billing platform supports compliance or creates compliance risk:

Population-level rules. The system must maintain entirely separate, independent rule sets for each regulatory population: ACA marketplace with APTC, ACA marketplace without APTC, Medicare Advantage, Medicaid, commercial group, and any sub-populations with distinct state requirements. Rule sets must not share parameters that would allow a change to one population's rules to inadvertently affect another's. This isolation is an architectural requirement, not a configuration option that can be retrofitted into a system designed around a single rule set.

Dynamic threshold calculation. For ACA marketplace populations subject to the 2025 net premium percentage threshold rule, the system must calculate each member's threshold individually based on their current APTC amount and update that calculation whenever the APTC amount changes. This must happen automatically and must produce an auditable record of the threshold applied at each point in the member's billing history.

Automated, timestamped notice generation and delivery confirmation. Required notices must be generated automatically based on rule-configured triggers, not manually by staff. The system must record the date and time each notice was generated, the delivery method, and the delivery confirmation status. For print notices, integration with a fulfillment center that provides delivery confirmation is required. Electronic notice delivery must integrate with an email service that provides delivery and open tracking.

Configuration change audit logging. Every change to a billing rule, threshold, or compliance parameter must be logged with a timestamp, the identity of the user who made the change, and the prior and new values. This log must be searchable and exportable for audit purposes. Configuration change logging is the compliance documentation trail that allows a health plan to prove when a regulatory requirement was implemented and by whom.

William™ compliance architecture William™ was designed from its foundation to support multi-population compliance in the health plan market. Its Perfect Balance™ accounting architecture provides the auditable transaction records that CMS and state audits require. Population rules, dynamic threshold calculations, and automated notice workflows are all native capabilities, not custom additions. Certifi issues regulatory update notifications to clients through a defined process and makes platform updates available ahead of effective dates.

See How William™ Supports Billing Compliance

From the 2025 ACA threshold rule to Medicare Advantage disenrollment procedures, William™ is built to keep health plans compliant across every market they serve. Talk to our team about your specific compliance requirements.

Schedule a Demo

This page is part of the Certifi Premium Billing Knowledge Center

← Back to Knowledge Center

Start typing and press Enter to search