270/271 Eligibility & Benefits Verification
Post-n-Track provides real-time 270/271 eligibility and benefits verification: accurate coverage data at the point of care, returned directly into the submitter's workflow, to prevent eligibility-related claim denials.
How Post-n-Track Handles Eligibility Verification
Relying on outdated batch files or manual portal queries to verify patient eligibility is a recipe for downstream denials. When front-desk staff lack real-time access to accurate benefit information, the entire revenue cycle is compromised from the start.
Post-n-Track provides high-speed, real-time connectivity for 270/271 eligibility verification. We enable provider and vendor systems to directly query payer databases, returning benefit details directly into the submitter's workflow.
- Fewer eligibility denials Coverage confirmed before care is delivered.
- A better patient financial experience Accurate benefit details at the point of care.
- Staff time back Real-time answers in the workflow, with no batch files or portal queries.
Reading the Response Correctly
The X12 270 is an eligibility inquiry; the 271 is the response. Under implementation guide 005010X279A1, a 271 either returns coverage and benefit detail or returns an AAA rejection code explaining why the inquiry could not be answered. The most consequential mistake in eligibility workflows is treating an AAA rejection as a statement that coverage is inactive. An AAA rejection means the question was not answerable as asked.
What the 271 actually returns
A successful 271 carries coverage status in the EB segment: active coverage, plan detail, and, depending on the payer's implementation, service-type-level benefits, copay, coinsurance, deductible accumulators, and plan date ranges. Payers vary enormously in how much of this they populate. A 271 from one payer may return thirty service types with financial detail; another returns active/inactive and little else. This variance, more than the standard itself, is what makes eligibility hard.
An unsuccessful 271 carries an AAA segment instead. The AAA segment appears at different loop levels depending on what failed: 2100A for the information source, 2100B for the information receiver, 2100C for the subscriber, 2100D for the dependent. The loop level tells you who the payer thinks is at fault, and it is the first thing to read.
AAA 72 and AAA 41, the two that matter
AAA 72 means invalid or missing subscriber identification. It is the single most common eligibility rejection, and it says nothing about whether the member has coverage. It means the identifier submitted did not resolve at that payer. The causes are mundane and fixable: a member ID transcribed with a prefix the payer does not expect, a name mismatch against the payer's file, a date of birth off by a digit, a dependent submitted in the subscriber loop, or an identifier that was valid before the member's plan year rolled.
AAA 41 means authorization or access restrictions: the inquiry was structurally valid but the submitter is not permitted to ask it. This is a trading-partner problem rather than a patient problem. It typically indicates the submitter is not enrolled with that payer for eligibility, or is asking outside a permitted relationship.
The workflow consequence is direct. An organization that routes AAA 72 into the same bucket as inactive coverage will convert a correctable data-entry error into a self-pay determination or a denied claim. The correction path for AAA 72 is to re-inquire with corrected demographics or to run coverage discovery. The correction path for inactive coverage is entirely different. Collapsing them is a measurable and avoidable source of denial volume.
| AAA code | Meaning | What it is not | Correction path |
|---|---|---|---|
| 72 | Invalid or missing subscriber/insured ID | Not a statement about coverage status | Re-inquire with corrected demographics; run coverage discovery |
| 41 | Authorization/access restrictions | Not a patient issue | Resolve trading-partner enrollment with the payer |
| 73 | Invalid/missing subscriber name | Not inactive coverage | Correct name against payer file and re-inquire |
| 75 | Subscriber/insured not found | Ambiguous; may be wrong payer | Verify payer identity; run coverage discovery |
| 79 | Connection/service unavailable | Not a data problem | Retry per payer availability schedule |
Why front-end validation matters more than retry logic
Most eligibility failures are generated before the 270 is ever transmitted. The identifier is wrong at registration, or the payer selection is wrong, or the subscriber/dependent relationship is coded incorrectly. A system that transmits whatever it is given and retries on failure is spending payer-side transactions to discover data quality problems it could have caught locally.
Shift-left validation means enforcing the 005010X279A1 conformance rules (segment presence, identifier format, date validity, loop placement of subscriber versus dependent) at ingestion, before transmission. The transaction that never had to be sent is the cheapest one.
PNT validates 270 inquiries against the implementation guide at the boundary and returns conformance failures to the submitter immediately rather than transmitting a transaction that will predictably return AAA 72.
Eligibility verification versus coverage discovery
These are different questions and they are frequently conflated. Eligibility verification asks: is the coverage we have on file for this patient active, and what does it cover? Coverage discovery asks: does this patient have coverage we don't know about?
The second question matters after a self-pay registration, an emergency encounter with incomplete demographics, or an AAA 72 that could not be resolved by correction. It is also the question underneath a meaningful share of write-offs that did not need to happen.
The transactions are related but the workflows are not interchangeable. A 270 requires you to know which payer to ask.
Medicare eligibility and HETS
Medicare eligibility runs through the HIPAA Eligibility Transaction System (HETS) rather than a commercial payer endpoint, and it has its own access regime. HETS requires an approved trading-partner relationship, and a trading-partner attestation requirement took effect May 11, 2026. Organizations accessing HETS through an intermediary should confirm their attestation posture directly rather than assume it is handled.
MBI (Medicare Beneficiary Identifier) lookup is a related but separate capability: retrieving a beneficiary's current MBI when it is unknown or has changed.
Frequently Asked Questions
What does AAA error code 72 mean on a 271?
AAA 72 means the subscriber identifier submitted on the 270 was invalid or missing: the payer could not resolve the member. It does not mean the patient has no coverage. Common causes are a transcribed member ID, a name or date-of-birth mismatch against the payer's file, a dependent submitted in the subscriber loop, or an identifier that changed at plan year rollover. The correction path is to re-inquire with corrected demographics or to run coverage discovery, rather than treating the patient as self-pay.
What does AAA error code 41 mean?
AAA 41 indicates authorization or access restrictions: the inquiry was structurally valid but the submitter is not permitted to ask it of that payer. This is almost always a trading-partner enrollment issue rather than anything to do with the patient, and it is resolved with the payer, not by re-inquiring.
What is the difference between eligibility verification and coverage discovery?
Eligibility verification confirms whether coverage already on file is active and what it covers, using a 270 inquiry directed at a known payer. Coverage discovery identifies coverage the provider does not know about, which matters after self-pay registration, incomplete demographics, or an unresolvable AAA 72. Verification requires knowing which payer to ask; discovery does not.
What version of the 270/271 is required?
005010X279A1 is the mandated implementation guide version for the eligibility inquiry and response pair. Conformance includes correct AAA error handling and correct loop placement of subscriber versus dependent information.
Why do eligibility rejections turn into claim denials?
Because AAA rejections are frequently misread as coverage determinations. An AAA 72 routed into the same workflow bucket as inactive coverage converts a correctable data error into a self-pay determination or a claim submitted to the wrong payer. Separating inquiry failures from coverage findings is the single highest-yield change most organizations can make to eligibility workflow.
Does Medicare eligibility work the same way?
Medicare eligibility runs through HETS rather than a commercial endpoint and requires an approved trading-partner relationship. A HETS trading-partner attestation requirement took effect May 11, 2026. Organizations accessing HETS through an intermediary should confirm their own attestation posture rather than assume it is covered.
Ready to talk through your use case?
Talk to a Post-n-Track specialist about your data challenges. A direct conversation, starting with what you need.