Chapter 27 — Electronic Claims Submission: Clearinghouses, EDI, the ANSI 837, and the Digital Pipeline

📍 Where you are

Chapter 25 built the professional claim. Chapter 26 built the institutional one. Both chapters described forms — rectangles with numbered boxes.

Almost nobody submits a form. They submit a file, and the file has a different structure, a different vocabulary, and a set of failure modes that have no equivalent on paper.

This chapter is the wire. What happens between the moment a biller clicks submit and the moment a payer's adjudication system has the claim — which is three days for Account 10-4471, and is forever for a claim nobody noticed was rejected.

Overview

Chapter 25's Case Study 1 was four months of two competent groups failing to talk to each other. A practice described its problem in item numbers. A vendor described the same problem in loops and segments. Nothing was wrong with anyone's understanding of the work, and the fix took three days once somebody translated.

This chapter is the translation.

It is also, unavoidably, a chapter with a lot of numbers in it — 837, 835, 270, 271, 276, 277, 277CA, 278, 999, TA1. They are not hard. They are just unfamiliar, and the reason to learn them is concrete:

When something goes wrong in the pipeline, everyone who can help you describes the problem using these numbers. A biller who cannot say "did the 999 accept it, or did the 277CA reject it?" is dependent on somebody else's summary of what happened.

Three things this chapter wants you to be able to do.

Ask the right question. §27.6's acknowledgments each prove something different, and knowing which one you are missing tells you where the claim is.

Know what your clearinghouse is doing on your behalf — §27.5 — because some of it is genuinely helpful and some of it is hiding a problem you will meet again at scale.

And never, ever treat a rejection as a denial. §27.7. A denied claim is in the payer's system and has appeal rights. A rejected claim does not exist, and the deadline is running anyway.

27.1 What HIPAA standardized and what it did not

Before 1996, every payer had its own electronic format, and a practice submitting to twenty payers maintained twenty different interfaces or paid somebody to.

The Health Insurance Portability and Accountability Act's Administrative Simplification provisions required standard formats for defined electronic health care transactions. The standards adopted are the X12N implementation specifications — commonly called EDI, electronic data interchange.

What that means in practice: the structure of an electronic claim is the same for every payer. The segments are in the same order. The data elements have the same names. A vendor writes one 837, not twenty.

What it did not standardize

And this is the part that decides your working life.

   HIPAA STANDARDIZED           HIPAA DID NOT STANDARDIZE

   the FORMAT                   which SITUATIONAL elements
   the SEGMENTS                   a given payer requires
   the ELEMENT NAMES            what a payer does with them
   the ORDER                    the payer's OWN edits
   the CODE SETS                how the payer NAMES a problem
                                what the payer will accept
                                  as an attachment

The implementation guide defines three levels of requirement for a data element: required, situational, and not used. The interesting one is situational — the guide says "required when X, otherwise optional," and payers differ on what X is.

⚖️ Compliance Check

This is why the companion guide exists, and it is the third time this book has told you to read one.

Chapter 14 §14.8 — bilateral reporting conventions. Chapter 21 §21.11 — proprietary edits. Chapter 25 §25.9 — the fields a payer requires. And now the transaction itself.

A payer's companion guide states how that payer requires the standard transaction populated.

It is not optional reading and it is not a courtesy document. Where the implementation guide says "situational," the companion guide says what this payer's situation is — and a claim that satisfies the national standard and violates the companion guide gets rejected by that payer and nobody else.

Chapter 25's Case Study 2 was fourteen months of a practice not opening one. The requirement was published three ways.

A second thing HIPAA did not do: it did not require payers to use the standard for everything. Attachments are the famous gap — §27.8 — and forty years into electronic claims, the answer to "how do I send the operative note?" is frequently still "fax it."

The other two things Administrative Simplification standardized

Transactions get the attention. Two companions matter as much and are rarely taught together.

STANDARD CODE SETS. ICD-10-CM, ICD-10-PCS, CPT, HCPCS Level II, and CDT are the adopted code sets for the standard transactions. Chapters 7 through 20 were, without saying so, a tour of the HIPAA code sets.

STANDARD IDENTIFIERS. The NPI for providers and the EIN for employers. Chapter 25 §25.7's Type 1 and Type 2 exist because of this rule, and the reason legacy payer-assigned provider numbers disappeared from claim forms is that a national identifier replaced them.

Why put them together? Because a claim is a standard transaction, carrying standard code sets, identifying parties by standard identifiers — and when any one of the three is wrong, the failure arrives looking like the others.

A terminated CPT code, a Type 2 NPI in a rendering field, and a malformed date produce three rejections that a biller reading a terse message may not be able to tell apart. Knowing there are three different things that can be wrong is most of the diagnosis.

Versions, and why "it worked last year" is a real answer

The standards have versions. The industry moved from 4010 to 5010 — a transition that required simultaneous change by every payer, provider, vendor, and clearinghouse in the country, and it was neither quiet nor quick. A further version is a standing topic.

Two practical consequences:

A version change is not a software update; it is an industry event. It changes what elements exist and what is required, and it arrives with a compliance date everyone must hit together.

And more mundanely: your vendor's implementation of a version is not your payer's. Where they differ, the claims that break are the unusual ones — the secondary claim, the claim with an unusual relationship code, the claim with an atypical provider — which is why a version change surfaces first in whatever your practice does least often.

The operating rules — developed under later legislation and adopted for several transactions — add requirements on top of the standards, chiefly about what an eligibility or claim status response has to actually tell you. They exist because "compliant" and "useful" turned out to be different things: an eligibility response that says "active coverage" and nothing about the deductible satisfies a format and answers none of Chapter 24's questions.

27.2 The transaction set, one line each

Learn these as a set. They come up constantly and they are almost never explained in one place.

Four observations that make the list stick.

The pairs are questions and answers. 270/271. 276/277. The odd number asks; the even number answers — which is a memory hook rather than a rule, and it works.

The 837 family is one transaction with three flavors, distinguished by the kind of provider and the kind of claim. P, I, and D. §27.3.

The 835 is the only one that carries money information back, and it is important enough to have Chapter 28 to itself.

And the acknowledgments — TA1, 999, 277CA — are not a set of redundant receipts. Each proves a different thing, and §27.6 is about which.

🎓 Exam Watch

Three transaction pairs are near-certain on any billing credential, and they are always tested the same way: a scenario describes a task and asks which transaction does it.

"Verify coverage before the visit" → 270/271. "Request prior authorization" → 278. "Find out what happened to a claim" → 276/277.

And the trap is the 835 versus the 277. A 277 tells you the claim's status. An 835 tells you what was paid. A claim can have a status of "finalized/denied" on a 277 and produce an 835 showing zero payment — those are the same event described by two transactions, and only one of them carries the CARC and RARC codes Chapter 28 §28.4 depends on.

One more: the 277CA is an acknowledgment, not a status response. Exams use the similarity deliberately.

27.3 The 837 professional and institutional

An 837 is not a picture of a form. It is the form's data with the boxes removed.

That sentence does more work than it looks like it does, and it resolves a confusion that survives years into people's careers.

   THE FORM                          THE 837

   a rectangle with 33 numbered      a file of SEGMENTS, each one a
   boxes, laid out for a scanner       line of data elements separated
                                       by delimiters

   item 24D holds a procedure code   the SV1 segment holds the
                                       procedure code

   "item 21" locates a field         "Loop 2300, HI segment" locates
     by POSITION ON PAPER              the same information by ITS
                                       PLACE IN A HIERARCHY

The 837P carries the CMS-1500's data. The 837I carries the UB-04's. They are separate implementation guides, because the two claims describe different things — §26.1's distinction, arriving as two file formats.

Three structural differences worth knowing:

The 837I carries revenue codes and the 837P does not. Chapter 26 §26.4's whole code set exists in the institutional transaction and has no professional equivalent.

The 837I carries the circumstance code families — condition, occurrence, occurrence span, value — which again have no professional counterpart. §26.6.

And the 837P carries diagnosis pointers per service line. Chapter 25 §25.5's letters, as a data element. The institutional claim links diagnoses to the claim rather than to each line, which is why Chapter 26 has no pointer discussion at all.

The 837 is not limited the way the form is

Two limits Chapter 25 established as facts about the paper form do not apply to the transaction:

The six service lines. A paper CMS-1500 has six. An 837P is not limited to six — the practical limit is the payer's, and it is far higher. A claim split into two because of a six-line limit is frequently an artifact of a system that was designed against the paper form.

And the four modifiers per line. The transaction structure accommodates the same four positions Chapter 14 §14.3 described, and modifier 99's workaround exists for the same reason — but the underlying constraint is the implementation guide's, not the paper's.

The general lesson, and it explains a lot of otherwise puzzling software behavior: many practice management systems were designed around the printed form and impose its limits on transactions that do not have them. When a system tells you a claim must be split, ask whether that is the payer's rule or the software's.

27.4 Loops and segments without the jargon

This is the section Chapter 25's Case Study 1 needed and did not have.

Forget the terminology for a moment and look at the problem the format is solving.

A claim contains information at different levels. Some facts are true of the whole submission (who sent it, to whom). Some are true of the billing provider. Some are true of the patient. Some are true of one claim for that patient. Some are true of one service line on that claim.

The 837 organizes information by which level it belongs to. That is all a "loop" is.

   THE HIERARCHY — and this is the whole idea

   ┌─ THE INTERCHANGE ─────────────────────────────────┐
   │  who is sending, who is receiving, when           │
   │                                                    │
   │  ┌─ LOOP 1000A/B — SUBMITTER and RECEIVER ─────┐  │
   │  │                                              │  │
   │  │  ┌─ LOOP 2000A — THE BILLING PROVIDER ────┐ │  │
   │  │  │  name, NPI, tax ID, address            │ │  │
   │  │  │                                         │ │  │
   │  │  │  ┌─ LOOP 2000B — THE SUBSCRIBER ─────┐ │ │  │
   │  │  │  │  the policyholder and the payer   │ │ │  │
   │  │  │  │                                    │ │ │  │
   │  │  │  │  ┌─ LOOP 2000C — THE PATIENT ───┐ │ │ │  │
   │  │  │  │  │  (only if NOT the subscriber)│ │ │ │  │
   │  │  │  │  │                               │ │ │ │  │
   │  │  │  │  │  ┌─ LOOP 2300 — THE CLAIM ─┐ │ │ │ │  │
   │  │  │  │  │  │  total charge, POS,     │ │ │ │ │  │
   │  │  │  │  │  │  DIAGNOSES, dates       │ │ │ │ │  │
   │  │  │  │  │  │                          │ │ │ │ │  │
   │  │  │  │  │  │  ┌─ LOOP 2400 ────────┐ │ │ │ │ │  │
   │  │  │  │  │  │  │  ONE SERVICE LINE  │ │ │ │ │ │  │
   │  │  │  │  │  │  │  code, modifiers,  │ │ │ │ │ │  │
   │  │  │  │  │  │  │  charge, units,    │ │ │ │ │ │  │
   │  │  │  │  │  │  │  POINTERS          │ │ │ │ │ │  │
   │  │  │  │  │  │  └────────────────────┘ │ │ │ │ │  │
   │  │  │  │  │  │  (repeats per line)     │ │ │ │ │  │
   │  │  │  │  │  └─────────────────────────┘ │ │ │ │  │
   │  │  │  │  └───────────────────────────────┘ │ │ │  │
   │  │  │  └─────────────────────────────────────┘ │ │  │
   │  │  └───────────────────────────────────────────┘ │  │
   │  └─────────────────────────────────────────────────┘  │
   └────────────────────────────────────────────────────────┘

Now the vocabulary, and it is three words.

A LOOP is a level. "Loop 2400" means "at the service-line level."

A SEGMENT is a line of data inside a loop, identified by a two- or three-character tag. SV1 is the professional service line. HI carries diagnoses. NM1 carries a name. DTP carries a date.

A DATA ELEMENT is one field inside a segment, referred to by position.

That is genuinely all of it. A rejection saying "Loop 2010BA, NM109 is missing" is saying "at the subscriber level, in the name segment, the identifier field is empty" — which on the form is item 1a, the insured's ID number.

The translation table

Keep this. It is the thing Chapter 25's practice could not produce.

Two of these deserve a second look.

SV101-3 through SV101-6 are the four modifier positions. Chapter 14 §14.3's rule is not a form limitation — it is in the transaction, which is why modifier 99 exists.

And SV107 is the pointer field. Chapter 25 §25.5 said a pointer is a claim about why a service was performed. It is one data element, and it is one of the most consequential fields in the entire file.

What it actually looks like

One more step, because "SV1 holds the service line" is easier to accept than to picture.

A segment is a string. It begins with a tag, its elements are separated by a delimiter, and it ends with a terminator. Nothing more than that.

   SV1*HC:99214:25*185.00*UN*1***1:2:3:4~
   │   │  │     │  │      │  │ │  │
   │   │  │     │  │      │  │ │  └─ SV107 DIAGNOSIS POINTERS
   │   │  │     │  │      │  │ │      1:2:3:4 — all four
   │   │  │     │  │      │  │ └──── (empty positions)
   │   │  │     │  │      │  └────── SV104 UNITS ......... 1
   │   │  │     │  │      └───────── SV103 UNIT BASIS .... UN
   │   │  │     │  └──────────────── SV102 CHARGE ........ 185.00
   │   │  │     └─────────────────── SV101-3 MODIFIER .... 25
   │   │  └───────────────────────── SV101-2 CODE ........ 99214
   │   └──────────────────────────── SV101-1 QUALIFIER ... HC (HCPCS)
   └──────────────────────────────── the SV1 tag
                                     ~ terminates the segment

Three things to take from that and then never think about again.

You are not going to write one. No biller writes segments. The point of being able to read one is that a rejection message names a position, and now you can find it.

The pointers are numbers here and letters on the form. Chapter 25's item 24E uses A B C D; the transaction uses 1:2:3:4, referring to positions in the HI segment. They are the same claim. A biller who learned pointers as letters and meets them as numbers should recognize them anyway.

And the empty positions are not padding. Each * marks a position that exists and is unpopulated — which is why a rejection can say "element SV105 is invalid" about a field you never filled in. The field is always there. It is the value that is absent.

🔢 Code It

Translate. Here are four real-shaped rejection messages. Say what is wrong in the vocabulary of the form.

text 1. Loop 2300, HI01-2 — invalid code 2. Loop 2400, SV101-3 — invalid modifier 3. Loop 2010BA, DMG02 — missing 4. Loop 2400, SV107 — pointer references a diagnosis not present on the claim

Answers, and the fixes.

1 — the principal diagnosis in item 21 is not a valid code. Loop 2300 is the claim level; HI is the health-care-information segment; HI01 is the first diagnosis. Chapter 8's lookup and Chapter 20 §20.1's quarterly updates are both candidates — an invalid code is frequently a deleted code.

2 — a modifier in item 24D's first modifier position is invalid. Note what this does not say: it does not say the modifier is inappropriate. A payer rejecting an invalid modifier is saying the value is not a modifier; a payer denying modifier 25 is saying it disagrees. Chapter 14 versus Chapter 29, and they arrive on different transactions.

3 — the subscriber's date of birth is missing. DMG is the demographic segment. This is a registration failure — Chapter 24 — and it is a thirty-second fix on the day it arrives.

4 — a service line points at a diagnosis that is not on the claim. Chapter 25 §25.5's pointer discipline, caught structurally rather than clinically. The transaction can tell that pointer 4 refers to nothing. It cannot tell that pointer 1 refers to the wrong thing — and only the second kind costs you a denial.

The lesson: three of these four are the form's problems wearing the transaction's vocabulary, and the fourth is a structural check the paper form could never have performed.

📞 On the Phone

"The clearinghouse rejected it. It says Loop 2310A NM109 is invalid."

You now know exactly what that means, and this is the payoff for the whole section.

Loop 2310A is the referring provider at the claim level. NM109 is the identifier. So: the referring provider's NPI is invalid.

Four things to check, in order:

Is there supposed to be a referring provider at all? Chapter 25 §25.10's Account 10-4471 has item 17 blank, because nobody referred her. A system that auto-populates the performing physician creates this rejection out of nothing, and the fix is to empty the field.

Is the NPI a Type 1? A Type 2 organizational NPI in a referring-provider field is invalid by definition. Chapter 25 §25.7.

Is it ten digits and does it check-digit? NPIs have a check digit, and clearinghouses validate it — which means a transposed NPI is caught here rather than at the payer, and that is a good thing.

And is the provider in the payer's file? A valid NPI belonging to someone the payer does not have enrolled produces a different message, and that one cannot be fixed by billing. Chapter 25 §25.9.

What to say: "Is the rejection because the element is empty, because the value is malformed, or because the payer does not recognize the provider? Those are three different fixes." Ask that question and you will almost never be given a useless answer.

27.5 The clearinghouse: what it fixes and what it hides

Most practices do not send claims to payers. They send claims to a clearinghouse, which sends them to payers.

A clearinghouse is an intermediary that accepts claims from providers, validates and formats them, routes them to the correct payer, and returns acknowledgments and remittances.

Why it exists is worth stating plainly: even with a standard format, a practice submitting to sixty payers would need sixty connections, sixty enrollments, and sixty sets of credentials. The clearinghouse maintains those.

Four things a clearinghouse does for you:

Connectivity. One connection instead of sixty.

Validation. It checks the file's syntax and runs edits before the payer sees it — which is why most bad claims fail here rather than there, and failing here is much better, because it is faster and because it does not consume a timely-filing day the way a round trip does.

Routing. Payer identifiers, and keeping them current as payers merge and change.

And translation. Which brings us to the part that deserves a warning.

⚠️ Where Claims Die

A clearinghouse fixes some things silently, and that is not entirely a favor.

What "silently" means: the claim your system produced and the claim the payer received are not byte-identical. The clearinghouse normalized a date format, populated a default, reformatted a name, or applied a payer-specific transformation it maintains on your behalf.

Most of the time this is helpful and invisible and you should be grateful for it.

Here is when it is not:

You cannot reproduce the payer's copy from your system. When a payer says "your claim said X," and your system says Y, both can be telling the truth. Chapter 25's Case Study 1 lived in this gap for four months.

A problem your system generates never surfaces as a problem. If your system consistently produces a malformed element and the clearinghouse consistently fixes it, you have a defect you will never find — until you change clearinghouses, or until a payer starts rejecting it directly, at which point it arrives as a sudden mass rejection of something that "has always worked."

And the fix can be wrong. A default value applied on your behalf is a guess. Usually a good one.

The practical response is not to distrust the clearinghouse. It is to know that the file you sent and the file the payer received are two artifacts, and to be able to obtain both. §27.6.

What a clearinghouse's edits are, and what they are not

Clearinghouse edits are frequently BETTER than the payer's published requirements, for a commercial reason worth understanding: a clearinghouse is paid to reduce rejections, so it accumulates knowledge about what each payer actually accepts and encodes it.

But they are somebody's implementation of somebody else's rule, and:

They can be stale. A rule that changed last quarter may still be enforced.

They can be over-strict. An edit that stops a claim the payer would have paid costs you nothing visible and is therefore never questioned.

And they are not the payer's edits. Passing the clearinghouse proves the claim is well-formed and plausible. It does not predict adjudication — which is Chapter 21's entire subject arriving one layer later.

Chapter 25 §25.9's companion guide and the clearinghouse's edit list are two descriptions of the same payer. Where they disagree, the companion guide is authoritative and the edit list is usually more current. Read both; that is not a contradiction.

Enrollment — three separate things nobody tells a new biller are separate

A practice does not simply start exchanging transactions with a payer. It enrolls, and there are three enrollments, they are independent, and they fail independently.

Three consequences, and each one is a real practice's real problem.

You can be enrolled to send and not to receive. Claims go out, payments come back as paper checks with paper remittances, and someone posts them by hand while wondering why the practice has no electronic remittances. Chapter 28 §28.7's autoposting is impossible without ERA enrollment, and this is the most common reason a practice does not have it.

You can receive the 835 and not the money electronically, or the reverse. They are separate enrollments and payers process them separately.

And the enrollments are per payer, not per practice. A practice with forty payer relationships has forty of these, in various states, and the state of each one is invisible until something does not arrive.

The practical instruction: ask for the list. Which payers are you EDI-enrolled with, ERA-enrolled with, and EFT-enrolled with? Most clearinghouse portals will produce it. The gaps in that table are the payers where your money and your remittance are arriving by the slowest available method, and nobody has noticed because the checks do keep coming.

This is not an exciting paragraph and it recovers real time in real practices.

Changing clearinghouses, and why it goes badly

Worth one paragraph, because the warning above predicted it.

When a practice changes clearinghouses, three things happen at once: every payer enrollment must be redone, every report changes its name and format, and every defect the old clearinghouse was silently repairing arrives at the payer unrepaired.

The third is the one nobody plans for, and it presents as a sudden wave of rejections for things that "have always worked." They have always worked because somebody was fixing them.

Two practical instructions if it happens to you: run both in parallel if the contracts permit it, even briefly, so a comparison is possible; and read the first two weeks of rejection reports line by line rather than by exception. The wave is finite, it is diagnostic, and it is the only time anyone gets a clear list of what their own system produces wrong.

27.6 Acknowledgments: TA1, 999, and the 277CA

Three acknowledgments, three different questions answered, and almost nobody can name them in order.

   YOU SUBMIT A FILE
        │
        ├──► TA1     "Was the ENVELOPE readable?"
        │             interchange-level. Structural.
        │             A TA1 rejection means the file itself
        │             was malformed — nothing inside was read.
        │
        ├──► 999     "Was the FILE SYNTACTICALLY VALID?"
        │             functional-group level.
        │             ACCEPTED / ACCEPTED WITH ERRORS / REJECTED.
        │             This says the 837 followed the rules of
        │             the format. It says NOTHING about content.
        │
        └──► 277CA   "Did the PAYER ACCEPT THE CLAIM
                      into adjudication?"
                      claim level, and THIS IS THE ONE THAT
                      MATTERS MOST. A claim can be accepted
                      by the 999 and rejected by the 277CA.

The crucial sentence, and it is the most misunderstood thing in this chapter:

A 999 acceptance is NOT proof that your claim is in the payer's system.

The 999 says your file was grammatically correct. The 277CA says the payer took the claim.

A claim can be perfectly formed and rejected at the 277CA — wrong member number, provider not on file, patient not found — and a practice that stops checking at the 999 believes it has submitted a claim it has not submitted.

Three practical notes.

Not every payer sends every acknowledgment, and your clearinghouse may consolidate them into its own report with its own names. That is fine, and it is why the next paragraph matters more than the transaction numbers.

The 277CA identifies claims individually, with a status for each and a reason for each rejection. It is a work list, and it is the single most under-read document in the revenue cycle.

And the acknowledgments arrive on a timescale of hours to a couple of days, not weeks. If you do not have a 277CA within a few days of submitting, that is itself information.

How a 277CA describes a problem

The vocabulary is two codes and a free-text-ish description, and knowing its shape makes an otherwise cryptic report readable.

   A STATUS CATEGORY CODE — the broad answer
     A1  received
     A2  accepted for processing
     A3  RETURNED — not processed
     A7  RETURNED — not processed, data content error

   A STATUS CODE — the specific reason
     21   missing or invalid information
     562  entity's National Provider Identifier

   AN ENTITY IDENTIFIER — WHOSE information
     the subscriber, the patient, the rendering
     provider, the billing provider, the payer

Read them together and the message resolves. A7:562 on the rendering provider says: returned, not processed, because of a data content error, specifically the National Provider Identifier, of the rendering provider. Which is a sentence.

The entity identifier is the part people skip and it is frequently the whole answer. "Invalid NPI" is not actionable. "Invalid NPI — REFERRING provider" tells you to look at item 17b, and "invalid NPI — BILLING provider" tells you something much more serious is wrong, because that one is the same on every claim you send.

A rejection naming the billing provider is a rejection of everything, and it should be treated as an emergency rather than as one claim's problem.

📋 Read the Chart

Source: a clearinghouse acknowledgment report, the kind that arrives daily What it says:

```text BATCH 4471-0316 submitted 03/16 11:05 PM ───────────────────────────────────────────────────── TA1 ......... ACCEPTED 999 ......... ACCEPTED 38 claims ───────────────────────────────────────────────────── 277CA ....... ACCEPTED ................... 36 claims REJECTED .................... 2 claims

[claim 1]  A3:21  Missing or invalid information
                  — subscriber ID not found
[claim 2]  A7:562 Entity's National Provider
                  Identifier — rendering provider

```

What it means:

Thirty-eight claims were transmitted and thirty-six were submitted. Those are different numbers and the difference is the whole point of the report.

The TA1 and 999 acceptances tell you the file was fine. A practice that reads only these two lines concludes that all thirty-eight claims are with the payer. Two of them are not, and never will be unless somebody acts.

Claim 1's subscriber ID was not found. This is a Chapter 24 problem — registration, or a coverage change. It is a thirty-second fix on day one.

Claim 2's rendering NPI is not recognized as an entity by this payer. Chapter 25 §25.9's third rejection cause: this may not be a billing problem at all. If the provider is not enrolled with this payer, resubmitting will not change anything, and the fix is a credentialing conversation.

What to do about it: work the two, today. And notice what the report cannot tell you — whether the thirty-six that were accepted will be paid. Acceptance is not adjudication. That answer comes back on an 835 and it is Chapter 28's.

Where it appears: every business office, every morning. The failure is not misreading this report. The failure is not opening it.

How to retrieve a submitted claim and its acknowledgments

Chapter 25's Case Study 1 ended with a practical instruction, and this is where it gets its answer.

Call your clearinghouse once, ask these four questions, and write the answers where the whole business office can see them:

"How do I retrieve the actual 837 you transmitted for a given claim?" Most clearinghouse portals can show you the raw transaction. Most billers do not know it is there.

"Where do I find the 999 and the 277CA for a specific claim or batch?"

"What is your report called, who receives it, and how often?" — because it is frequently going to one person's email, and that person may have left.

"How long do you retain these, and how do I get one from six months ago?"

It is one call. It takes fifteen minutes. Chapter 25's practice spent four months unable to answer a reasonable question, and the reason was that nobody had ever made this call.

27.7 Rejection versus denial, and why the distinction is money

The most consequential distinction in this chapter, and the one most often collapsed.

   REJECTION                        DENIAL
   ─────────────────────────────────────────────────────────
   The claim was NEVER              The claim WAS adjudicated.
   ADJUDICATED.                     The payer processed it and
                                    decided not to pay.

   It failed at the clearinghouse   It is IN the payer's system.
   or the payer's front end.

   It is NOT in the payer's         It has a claim number.
   system.

   There is NOTHING TO APPEAL,      It has APPEAL RIGHTS and
   because there is no decision.    deadlines that run from the
                                    decision.

   The fix is CORRECT AND           The fix is APPEAL, or correct
   RESUBMIT — a new claim.          and resubmit as a CORRECTED
                                    claim (Ch. 25 item 22 /
                                    Ch. 26 frequency 7).

   TIMELY FILING KEEPS RUNNING.     Timely filing was met by the
   The clock never stopped.         original submission.

Read the last row twice.

**A rejected claim did not stop the timely filing clock, because from the payer's point of view it

was never submitted.**

This is why a rejection is more dangerous than a denial, and it is the opposite of most people's intuition. A denial is visible, tracked, worked, and appealable. A rejection sits in a report.

Three consequences that follow directly.

A rejection has no CARC or RARC. Chapter 28 §28.4's code sets describe adjudication decisions. A rejection is described by a different vocabulary entirely — the 277CA's status category and status codes — which is why a denial report and a rejection report cannot be merged without care.

A rejection does not appear in your denial rate, and this is a real measurement problem. A practice with an excellent denial rate and an unread rejection report is not performing well; it is measuring half of its failures. Chapter 29 §29.7's metrics must account for it.

And a rejection is cheaper to fix and easier to lose. It is caught within days and it can be corrected in seconds — and it is invisible unless somebody opens a file.

🧮 Run the Numbers

What an unread rejection report costs, in the currency Chapter 24 §24.1 established: MINUTES. (Constructed and illustrative.)

```text A REJECTION CAUGHT ON DAY 1 read the report ....................... 0.5 min per claim correct the field ..................... 1–2 min resubmit .............................. 0.5 min ───────── ~2–3 minutes

THE SAME REJECTION FOUND IN AN AGING REVIEW AT DAY 120 investigate why there is no response .. 10 min locate the original acknowledgment .... 10 min determine whether filing has expired .. 5 min if it has: write off, or pursue an exception with documentation ........ 30–60 min ───────── a different order of magnitude entirely ```

And in a defined fraction of those cases the answer is "nothing" — the filing deadline passed and the claim is not payable by anyone.

Two things to read off this.

The ratio is the same one Chapter 24 §24.1 found at the front end, and it recurs because it is structural: a defect costs roughly its distance from the point of origin.

And the second-order cost is worse than the first. A rejection found at day 120 is not just expensive to work — it is evidence that nobody has been reading the report, which means there are others. You do not find one.

Proof of timely filing, and what actually counts as proof

Chapter 1 defined the timely filing clock — from the date of service, set by contract, commonly ninety days to a year, a calendar year for Medicare by statute. This section owes you the other half: what happens when a payer says the claim was late and you believe it was not.

The question is never "did we send it." The question is "what can we produce."

Four kinds of evidence, in descending order of how well they work:

A payer acknowledgment naming the claim. A 277CA showing the claim was accepted on a date inside the window is close to unanswerable, because it is the payer's own record. This is the strongest document you can have and most practices do not know they have it.

A clearinghouse transmission report showing the claim went to that payer on that date. Good, and weaker, because it is a third party's record of sending rather than the payer's record of receiving.

Your practice management system's claim history. "The system says we billed it on the 16th." This is the weakest and it is what most practices offer, because it is the one on the screen. It records an intent to send.

And a written record of a phone call. Better than nothing, and only just.

⚠️ Where Claims Die

The trap: a claim that was REJECTED and resubmitted after the deadline was never timely filed, and the acknowledgment you are about to produce proves it.

This is the rejection/denial distinction, arriving with the bill attached. A rejected claim never reached the payer — so the acceptance you can document is the acceptance of the RESUBMISSION, which is dated after the window closed. Your best evidence establishes the payer's position, not yours.

Two defenses, and both are preventive:

Work rejections within days, not weeks. A rejection worked on day 3 is resubmitted inside every window there is. A rejection found in an aging review is a coin flip.

And know your shortest window. Most practices know Medicare's year and assume the rest are generous. The payer that allows ninety days is the one that will cost you money, and it is worth knowing which one that is before you need to.

One more, said plainly because students ask: many payers have an exception process for circumstances outside the provider's control — a retroactive eligibility determination, another payer's delay. "We did not read our rejection report" is not one of them, and it will not be.

27.8 Attachments, and the problem nobody has solved

Here is an honest sentence about a mature industry: there is still no universal way to attach a document to an electronic claim.

The situation, as of this writing:

The 275 transaction exists — a standard for additional information — and adoption is incomplete.

Medicare has esMD — electronic submission of medical documentation — a mechanism for responding to records requests through a gateway, and it is not a general claims-attachment solution.

Some payers accept attachments through their own portals, which works and is not standardized.

Some clearinghouses offer attachment services, which also works and is also not standardized.

And a great deal of documentation still moves by fax.

⚠️ Where Claims Die

The attachment gap creates a specific, common, and entirely avoidable failure: the claim and the document arrive separately and are never joined.

How it happens: a claim requires documentation. The biller submits the claim electronically and faxes or mails the operative note. Both arrive. Neither references the other in a way the payer's system can act on. The claim denies for missing documentation; the documentation sits in an imaging queue.

Three defenses:

Put the payer's claim number on the attachment where one exists, and the patient identifier, provider identifier, and dates of service where one does not. A document that cannot be matched to a claim is not evidence; it is paper.

Use the payer's stated method, not the convenient one. Chapter 25's companion guide states it. A method that "usually works" is Chapter 25 Case Study 2's oral tradition.

And record the submission — date, method, confirmation. When the payer says it never arrived, the only useful response is a record, and the second submission should be trivially easy.

Chapter 13 §13.9's special report, Chapter 22's medical necessity documentation, and Chapter 30's appeal packet all depend on this working. It is the least glamorous section in the chapter and it decides a lot of money.

27.9 Batch, real time, and the claim status inquiry

Two modes, and the difference explains a lot about how a business office's day is shaped.

BATCH. Claims accumulate and are transmitted as a file, typically nightly. Acknowledgments come back on their own schedule. This is how claims are submitted.

REAL TIME. A single transaction is sent and an answer comes back in seconds. This is how eligibility works — Chapter 24 §24.3 — and it is why a front-desk staff member can verify coverage while the patient is standing there.

Why claims are batch and eligibility is real time is not arbitrary: an eligibility answer is a lookup, and a claim requires adjudication against benefits, edits, provider files, and history. Some payers offer real-time claim submission and even real-time adjudication for simple claims, and it is genuinely useful where it exists.

The claim status inquiry — and why to use it sparingly

The 276 asks a payer what happened to a claim; the 277 answers. Most practice management systems can issue it automatically.

Two uses that are legitimate:

A claim with no acknowledgment and no remittance after a reasonable interval. The 276 answers "do you have it?" without a phone call.

And confirming a claim's status before working it. Chapter 29's work queue is more efficient when it knows which claims are still in process.

One habit that is not legitimate:

Automatic status inquiries on every claim every few days generate enormous volume and answer a question the 835 will answer anyway. Some payers throttle it. And more importantly, it substitutes for reading the acknowledgments you already have — a practice that runs status inquiries on claims whose 277CA rejections it has not opened is asking the payer about claims the payer never received.

The reasonable default: read your acknowledgments daily, and use the 276 for claims that are genuinely unaccounted for.

🔍 Check Your Understanding

For each situation, name the transaction or acknowledgment that answers it.

1. Before the visit: is this patient covered?
2. Was my submitted file's envelope readable?
3. Did the payer accept my claim into adjudication?
4. What did the payer pay, and why that amount?
5. It has been three weeks and I have heard nothing. Does the payer have my claim?
6. Does this payer require prior authorization, and will it grant it?

Answers:

1 — 270 (and the 271 answers). 2 — TA1. 3 — 277CA. 4 — 835, and Chapter 28 owns it. 5 — 276 (and the 277 answers) — but check whether you have a 277CA first, because if the claim was rejected, the payer has nothing to tell you. 6 — 278.

Item 5 is the one to sit with. The instinct is to ask the payer. The cheaper question is whether you were ever told the claim was rejected, and the answer is usually in a file you already have.

27.10 🗂️ The Encounter — following one claim through the pipeline

Account 10-4471, from checkout to acknowledgment. Chapter 1's Encounter timeline, days 0 through 3 — and this is the part of the calendar no chapter has yet walked through.

   DAY 0 — Tuesday, March 14
   ────────────────────────────────────────────────────────────
   3:40 p.m.  Visit ends. Charge capture at check-out.
              \$30.00 copay collected (Ch. 24 §24.11).
   6:42 p.m.  Note signed electronically.

              ► NOTHING has been submitted. The claim does not
                exist yet, and this is the day on which every
                fact it will assert was created.

   DAY 1 — Wednesday, March 15
   ────────────────────────────────────────────────────────────
              Coder reviews the note. Codes assigned:
                99214-25 · 20610-RT · J1030 · 36415
                A M25.561 · B E11.9 · C I10 · D E78.5
              Claim built. Pointers set (Ch. 25 §25.10):
                99214 → A B C D · 20610 → A · J1030 → A
                36415 → B

   DAY 2 — Thursday, March 16
   ────────────────────────────────────────────────────────────
              SCRUBBER runs. Clean.
   11:05 p.m. 837P transmitted to the clearinghouse in the
              nightly batch.

              ► The claim is now a FILE. Item 24E has become
                SV107. Item 21 has become the HI segment in
                Loop 2300.

   DAY 3 — Friday, March 17
   ────────────────────────────────────────────────────────────
              999 ......... ACCEPTED   (the file is valid)
              277CA ....... ACCEPTED   (the payer took the claim)

              ► THREE DAYS from service to acknowledged.
                And the claim is now WAITING. Nothing else
                happens for fourteen days.

   DAY 17 — Friday, March 31
   ────────────────────────────────────────────────────────────
              835 posts. \$70.30 paid.
              LINE 1 DENIED — CO-97 / N19.
              ► Chapter 28 opens here.

Four things to notice, and the last one is the point of the chapter.

The pipeline worked perfectly. Every acknowledgment was positive. The 999 accepted, the 277CA accepted, and the claim that was accepted contained a line the payer was going to deny. Acceptance is not adjudication and never was.

The three days are mostly waiting for a batch. Day 1 is a coder's work. Day 2's scrubber takes seconds and the claim then sits until 11:05 p.m. Same-day submission would have saved roughly a day, which matters far less than it sounds like it should — the fourteen days between acknowledgment and remittance dwarf it.

The scrubber cleared a claim that was correct. This is worth saying because it is the ordinary case: Chapter 21's edits, Chapter 22's necessity linkage, and Chapter 25's field requirements were all satisfied, and the denial that arrives on day 17 is about none of them.

And nothing in this pipeline could have caught the day-17 denial.

A scrubber checks the claim against rules. A clearinghouse checks the file against a format. A 277CA confirms receipt. None of them evaluates whether this payer, on this contract, will pay an E/M with modifier 25 on the same day as a minor procedure.

That is an adjudication decision, and the only way to learn it is to submit the claim and read what comes back. Chapter 28 reads it. Chapter 29 classifies it. Chapter 30 appeals it.

Q4 remains open. The denial is coming and this chapter does not touch it.

Summary

HIPAA standardized the FORMAT of electronic transactions and did not standardize what payers require inside it. The implementation guides define elements as required, situational, or not used — and situational is where every payer's companion guide lives. That document has now been named four times in this book (Chapters 14, 21, 25, 27), which should tell you something.

The transaction set is a small vocabulary and it is worth memorizing: 270/271 eligibility · 276/277 claim status · 277CA acknowledgment · 278 authorization · 835 remittance · 837P/I/D claims · 999 and TA1 acknowledgments. Odd asks, even answers, as a memory hook.

An 837 is the form's data with the boxes removed. The 837P carries diagnosis pointers per line; the 837I carries revenue codes and the four circumstance families. Neither is limited to six service lines — that limit belongs to the paper form, and software that imposes it is imposing a constraint the transaction does not have.

A LOOP is a level. A SEGMENT is a line of data. A DATA ELEMENT is one field. "Loop 2400, SV107" means "at the service-line level, the diagnosis pointer." That is the whole vocabulary, and it is what Chapter 25's Case Study 1 spent four months not having.

A clearinghouse provides connectivity, validation, routing, and translation — and it fixes things silently, which means the file you sent and the file the payer received are two artifacts. A defect your clearinghouse consistently repairs is a defect you will never find until something changes — which is why changing clearinghouses produces a wave of rejections for things that "have always worked."

And there are THREE enrollments, they are separate, and they fail separately: EDI to send claims, ERA to receive the 835, EFT to receive the money. Per payer, not per practice. A practice enrolled to send and not to receive gets paper remittances and cannot autopost, and that is the most common reason Chapter 28 §28.7's automation is not running somewhere it should be.

Three acknowledgments answer three different questions. TA1: was the envelope readable? 999: was the file syntactically valid? 277CA: did the payer accept the claim into adjudication? A 999 acceptance is not proof that your claim is in the payer's system.

A REJECTION IS NOT A DENIAL.

A rejected claim was never adjudicated, is not in the payer's system, has nothing to appeal, and — the part that costs money — did not stop the timely filing clock. A denial is visible and tracked. A rejection sits in a report, and it does not appear in your denial rate.

Which makes proof of timely filing the rejection's sting. The strongest evidence is a payer acknowledgment naming the claim — the payer's own record — then a clearinghouse transmission report, then your system's history, then a note about a phone call. And a claim that was rejected and resubmitted late is one whose best evidence proves the payer's position rather than yours, because the only acceptance you can produce is the resubmission's.

There is still no universal electronic attachment mechanism. The 275 exists with incomplete adoption; Medicare's esMD handles records requests; payer portals and clearinghouse services work and are not standard; and fax persists. The defense is to identify the document, use the payer's stated method, and record the submission.

Claims go in batches; eligibility runs real time. The 276 claim status inquiry is for claims genuinely unaccounted for — not as a substitute for reading acknowledgments you already have.

And Account 10-4471 went from checkout to acknowledged in three days through a pipeline that worked perfectly and could not have caught the denial that was coming. Day 0 charge capture, day 1 coding, day 2 scrubber and an 11:05 p.m. batch, day 3 the 999 and the 277CA — then fourteen days of nothing, and then Chapter 28.

Key Terms

EDI · X12 · HIPAA transaction standards · implementation guide · required / situational / not used · companion guide · 270 / 271 · 276 / 277 · 277CA · 278 · 835 · 837P / 837I / 837D · 999 · TA1 · loop · segment · data element · SV1 · HI segment · NM1 · SV107 · clearinghouse · clearinghouse edits · front-end rejection · rejection versus denial · timely filing · batch · real time · claim status inquiry · attachment · 275 transaction · esMD · standard code sets · standard identifiers (NPI, EIN) · version 5010 · operating rules · status category code · claim status code · entity identifier · EDI enrollment · ERA enrollment · EFT enrollment · proof of timely filing

Spaced Review

From Chapter 14 §14.3 — the four modifier positions. They are SV101-3 through SV101-6, and modifier 99 exists because of a transaction limit, not a paper one.

From Chapter 21 §21.11 — proprietary payer edits. A clearinghouse's edit list is a third description of the same payer's rules, alongside the companion guide and the published policy.

From Chapter 24 §24.3 — the 270/271. You have been using a standard transaction since Chapter 24 without being told what it was called.

From Chapter 25 §25.5, §25.9, §25.10 — pointers, the rejection causes, and Account 10-4471's blank item 17. All three arrive here as data elements, and the blank item 17 is a live rejection risk in Loop 2310A.

From Chapter 26 §26.4, §26.6 — revenue codes and the circumstance families. Both exist in the 837I and have no professional equivalent, which is §26.1's distinction expressed as two file formats.

Coming up: Chapter 28 takes the 835 apart — the group codes, the CARCs and RARCs, and what actually happened to Account 10-4471's line 1 on day 17.