Overview
The ABN Form, officially Form CMS-R-131, is the physical or electronic document by which a provider delivers an Advance Beneficiary Notice of Noncoverage to a Medicare Fee-for-Service beneficiary. The form is CMS-mandated in its layout and content, and using a modified or non-current version risks invalidation at audit. It is the operational embodiment of the ABN process described under advance-beneficiary-notice.
The form has five critical content blocks. (1) Header — identifies the notifier (the provider, in plain English, not just a logo). (2) Body — lists the specific service or item in question, the reason the provider believes Medicare will deny (must be service-specific, not generic), and a good-faith estimated cost to the beneficiary. (3) Options box — the beneficiary selects Option 1 (receive the service, claim submitted to Medicare, may owe if Medicare denies), Option 2 (receive the service, do not submit to Medicare, pays provider directly), or Option 3 (refuse the service). (4) Additional information field — any other information to help the beneficiary understand. (5) Signature and date line.
Operational failures with the form typically cluster in four areas. First, using a stale version — CMS has revised the ABN form multiple times, most recently in 2020 (OMB approval renewed through 2026), and using the wrong version is an audit finding. Second, generic reasons for expected denial — "Medicare may not cover this" is not sufficient; the reason must cite the specific LCD, frequency rule, or clinical scenario. Third, post-service delivery — the ABN must be delivered in advance with enough time for the patient to decline meaningfully; signing at checkout is invalid. Fourth, no option selection or signature — a form with blank option boxes or missing signature is not a valid ABN.
Electronic ABN delivery is permitted and is increasingly common in telehealth and DMEPOS contexts. The electronic form must be viewable by the beneficiary before signature, capture the same elements as the paper form, and include an electronic signature that meets federal e-signature standards. Integration with EHR and registration workflows — auto-populating the service, pulling the LCD-based reason, and routing to patient e-signature — is the mature operational state.
Retention requirements are five years from the date of service. Most compliance programs integrate signed ABNs into the encounter-level document management system so they are retrievable if Medicare requests them during audit.
ABN Form (CMS-R-131) is one of the compliance areas where documentation discipline determines audit outcomes more than policy sophistication. Practices that invest in clean ABN Form (CMS-R-131) records, consistent advance beneficiary notice workflows, and auditable medical necessity evidence come out of OIG, RAC, and MAC audits with materially smaller recoupment exposure than practices with equivalent policies but weaker paper trails.
Industry benchmark
CMS Beneficiary Notices Initiative (BNI): ABN Form CMS-R-131, OMB approval valid through 2026. HFMA and AAPC suggest ≥98% form-completeness rate among ABNs issued as a minimum compliance baseline.
Worked example
A DME supplier delivering a non-covered back brace presents the patient with a filled CMS-R-131 form listing the brace by HCPCS code and description, the reason denial is expected (item does not meet LCD L33640 coverage criteria for this patient), and a $225 estimated cost. The patient selects Option 1 and signs. The supplier retains the signed form for five years and includes modifier GA on the Medicare claim.
Frequently asked questions — ABN Form (CMS-R-131)
Where do we get the current ABN form?
CMS publishes the form on the Beneficiary Notices Initiative page (cms.gov/Medicare/Medicare-General-Information/BNI). Using the current English and Spanish versions is required; older versions are periodically retired.
Can we use electronic ABN delivery?
Yes, provided the electronic form captures the same elements as the paper form, the beneficiary can review the content before signing, and the e-signature meets federal standards. Documentation of delivery time and method must be retained.
How specific does the 'reason Medicare may not pay' language need to be?
Specific enough that a reasonable person could understand why Medicare is expected to deny. Generic statements like 'Medicare may not cover this' are considered invalid. Example of adequate language: 'Medicare only covers this test for diagnoses listed in LCD L36692; your current diagnosis is not on that list.'
Must the ABN be in the beneficiary's preferred language?
Delivery in a language the beneficiary understands is a best practice and, under Section 1557 of the ACA, often a requirement for recipients of federal funding. CMS publishes English and Spanish versions; many providers use translators for other languages.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.