Overview
Modifier GZ indicates that the billing provider believes the item or service will be denied by Medicare as not reasonable and necessary, and that no Advance Beneficiary Notice of Noncoverage (ABN) was obtained from the Medicare beneficiary before the service. Claims submitted with Modifier GZ are automatically denied by Medicare and the provider cannot bill the beneficiary for the denied amount. The provider absorbs the full loss.
Modifier GZ exists to promote compliance transparency. Providers who furnish services expected to be denied without obtaining ABN have no clean way to handle billing: they cannot bill Medicare (the service is not reasonable and necessary), cannot bill the beneficiary (no valid ABN), but may still want to submit the claim for denial documentation or secondary coverage. Modifier GZ allows this submission while ensuring Medicare automatic-denies and the provider cannot pursue the beneficiary.
The intended alternative to Modifier GZ is the ABN + GA workflow. When the provider reasonably expects denial: (1) the beneficiary is provided an ABN before service describing the expected denial and giving beneficiary choice to receive service and accept financial responsibility; (2) the beneficiary signs the ABN; (3) the service is provided; (4) the claim is submitted with Modifier GA (ABN signed, beneficiary accepts responsibility). If Medicare denies, the provider can then bill the beneficiary. Modifier GY applies when the service is statutorily excluded and ABN is not required.
For RCM, Modifier GZ is a sign that something has gone wrong in the ABN workflow. It should appear rarely — most cases of expected denial should have had ABN obtained and should be billed with Modifier GA instead. Monitoring Modifier GZ claim frequency identifies breakdowns in front-office ABN processes, provider education gaps, or documentation issues.
Common scenarios producing Modifier GZ include: provider suspected denial but forgot to obtain ABN due to workflow rush; ABN was obtained but not signed by beneficiary; ABN was signed but lacks required elements (the specific service, reason for expected denial, beneficiary acknowledgment); provider was uncertain about denial prediction and didn't offer ABN defensively. Each pattern has a process remedy — typically pre-visit ABN-determination workflow, standardized ABN forms meeting CMS requirements, and staff training.
Medicare Administrative Contractors analyze Modifier GZ submission patterns. Excessive GZ claims at a provider can trigger Comprehensive Error Rate Testing (CERT) scrutiny and Targeted Probe and Educate (TPE) programs. Providers with chronic GZ issues face program-integrity attention.
Modifier GZ interaction with other modifiers is minimal — GZ is a standalone signal modifier. It does not combine with payment modifiers meaningfully because the claim is auto-denied. It should not coexist with Modifier GA (contradictory meanings) or Modifier GY (different denial type). EHR/claim-scrubbing rules should block inconsistent modifier combinations.
When a provider truly believes a service is covered (not expecting denial), no GZ, GA, or GY modifier applies. Only when the provider anticipates denial and is managing the ABN process should these modifiers be considered. Over-application of defensive modifiers is a separate compliance issue.
Industry benchmark
Medicare Claims Processing Manual Chapter 30 (Financial Liability Protections). CMS ABN Form Instructions.
Worked example
A DME supplier provides a continuous passive motion (CPM) machine for home use after a knee replacement. CPM home use is typically not Medicare-covered per LCD criteria; the supplier expects denial. The supplier fails to obtain a signed ABN from the beneficiary before delivery. Claim submitted with Modifier GZ. Medicare automatically denies. Supplier cannot bill beneficiary (no ABN). Supplier absorbs full cost of the rental. The correct workflow would have been: obtain ABN pre-delivery, bill Modifier GA, pursue beneficiary payment on Medicare denial.
Frequently asked questions — Modifier GZ (Item or Service Expected to Be Denied)
What does Modifier GZ signal to Medicare?
That the provider expected the service to be denied as not reasonable and necessary but did not obtain an ABN from the beneficiary. Medicare auto-denies GZ claims; the provider cannot bill the beneficiary and absorbs the loss.
What's the difference between Modifier GA and GZ?
Modifier GA: ABN obtained, beneficiary accepts financial responsibility; if Medicare denies, provider can bill beneficiary. Modifier GZ: ABN NOT obtained; Medicare denies and provider cannot bill beneficiary. GA is the correct workflow when expecting denial; GZ is the fallback when the ABN process failed.
When should Modifier GZ be used?
Almost never — GZ indicates a process failure. Providers who expect denial should always obtain ABN and use Modifier GA. GZ is a transparency/compliance modifier for the edge case where ABN was not obtained but the claim must be submitted for denial documentation or secondary coverage.
Can I bill the beneficiary if Modifier GZ is on the claim?
No. GZ specifically indicates no valid ABN exists. Medicare auto-denies and the provider must write off the amount. Pursuing the beneficiary without a valid ABN when Medicare denies for medical necessity is a Medicare billing violation.
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.