Hey there, We’re Shivang & Tania. Each week, we write in plain English (and some sass) about how health insurance works, why claims get denied, and how patients and healthcare teams can get paid or reimbursed. If you’re new here, we recommend you start with RCM 101: How Healthcare Gets Paid, Eventually, Maybe

When Sage submits Biscuit’s claim, her software sends an electronic file called an 837. The responses tell her whether the file passed basic checks and whether the claim was accepted for processing. None of that means the insurer has agreed to pay. After reviewing the claim, the insurer sends back an 835 explaining the payment, adjustments, or denial. The distinction matters: “accepted” means there’s still work to follow up on. If a claim stalls and nobody notices, the deadline to correct and resubmit it can pass.

In this issue, we cover:

Start with the thing itself. When Sage clicked submit, what left her computer?

It wasn't a bill, and it wasn't a PDF. Nothing you'd look at and recognize as Biscuit's claim. Everything we've built over the last few issues, the patient and subscriber details, Dr. Singh's provider identifiers, the date of service, the Z80.41 family-history diagnosis, the CPT 81432 for the hereditary panel, the modifier, the charge, gets packed into one structured electronic file.

That file is called an 837. It's the standard electronic format for sending a healthcare claim from a provider to a payer, and HIPAA requires everyone to use the same one so the computer on the other end can read it the instant it arrives. When Sage's software "sends the claim," this is what it sends.

In plain English, the 837 says one thing: here is the claim, and here is everything you need to process it. You don't need to know how one is built, only what it is. Everything that happens next is a computer answering that opening line, one question at a time.

Before the conversation can start, there's a packaging problem to solve, and it's worth thirty seconds because it explains three acronyms you'll otherwise trip over forever.

Two computers exchanging claims have to agree on some structure, or the receiver has no way to tell where one thing ends and the next begins. Is this one claim or four hundred? Who sent it, and who is it for? The shared format they use is EDI, Electronic Data Interchange, which is how computers trade business documents in a fixed, agreed-upon layout instead of mailing paper or emailing a PDF.

Here's the one piece of EDI worth understanding. A claim in EDI is built from short coded lines rather than sentences, and each line is called a segment. A segment starts with a two- or three-letter name that says what it is, then the data that belongs to it. The whole 837 is just segments stacked in order: one holds the patient's name, another holds a diagnosis code, and so on down the claim.

Some segments carry no claim data at all. Their only job is to mark where a section starts and stops, so the receiving computer can keep the pieces straight. These marker segments come in pairs, a header to open a section and a trailer to close it, and they nest inside one another like a document in a folder in a shipping box. There are three pairs, working from the outside in:

The box and folder are just a way to picture how the data is organized. In the actual file, these are codes that tell the computer what belongs together. Sage’s software adds them automatically.

Why does this matter? Because a problem with the packaging can stop the claim before the insurer reviews it. If the file passes these checks, the computer can move on to processing what’s inside. Whether Biscuit’s test is covered, and how much the insurer will pay, is still to be decided.

After Sage sends the 837, she needs to know whether it went through. The responses can tell her whether the electronic envelope passed its checks, whether the file was formatted correctly, and whether Biscuit’s claim was accepted for processing. These are separate checks, and none confirms that the insurer will pay.

1. TA1: Was the electronic envelope valid?

The receiving system checks the outer envelope, the ISA and IEA we just covered. It checks details such as the sender and receiver information and whether the envelope follows the required format.

The response is called a TA1, or interchange acknowledgment. An accepted TA1 means the outer envelope passed its checks. It doesn’t tell Sage whether the claims inside are valid. If the envelope is rejected, she needs to investigate the error and correct the submission.

2. 999: Was the file put together correctly?

Next, the receiving system checks the structure of the 837. Are the required sections present? Is the information arranged in the expected format?

This response is called a 999, or implementation acknowledgment. An accepted 999 tells Sage the file passed those formatting checks. It doesn’t confirm that Biscuit’s individual claim was accepted or that his test is covered.

3. 277CA: Was Biscuit’s claim accepted for processing?

The 277CA, or claim acknowledgment, reports on individual claims. A file might contain hundreds of claims, and some can be accepted while others are rejected.

For Biscuit, this tells Sage whether his claim passed the initial claim checks. If the payer accepted it, it can move forward for review. If it was rejected, the response includes codes explaining the problem so Sage can work out what needs correcting.

Even a payer’s acceptance here doesn’t mean payment is approved. It means the claim has reached the processing stage. The insurer still needs to decide what it covers and how much, if anything, it will pay.

Sage won’t necessarily see three separate messages every time. Some systems send a TA1 only when there’s an envelope error. The clearinghouse may also send its own acknowledgments before the payer responds, so she can receive more than one 277CA for the same claim. Her billing software may display these as status updates rather than show her the files.

When Sage checks those updates, she needs to know who sent the response and what it confirms. Acceptance by the clearinghouse doesn’t establish that the payer has accepted the claim.

One honest caveat, because last week's clearinghouse matters here. That clean three-step sequence is the standard, but it's tidier than what most billers see on a Tuesday. The claim passes through a clearinghouse on the way, so the answers come back in layers: the clearinghouse runs its own checks and reports first, then the payer's answers arrive on top. It's normal to get more than one 277CA on a single claim, one from the clearinghouse and one or two from the payer. Most billing software also hides the raw TA1 and 999 and just shows a status trail, and plenty of payers only send a TA1 when the interchange actually broke. The names and the order still hold. You usually meet them as rows on a screen, not as separate files.

This is where people lose real money, so I'll be blunt. Of every word in this conversation, "accepted" is the one that fools the most people. It sounds like a finish line when it's much closer to a starting gun.

Biscuit sees the word ACCEPTED on a status screen and hears "approved, we're paying, you're fine." Sage sees the same word and asks the question that actually matters here: accepted by whom, and for what?

Every one of those is a real "accepted," and none of them is a decision to pay. A claim can pass all four and still get denied on the merits an hour later. Acceptance says the claim is readable and in line. Payment is a separate question, decided later, about whether the plan actually covers what Biscuit had done.

Here's the opinion I'll stand behind. The denials that get all the attention aren't usually what bleeds a practice. The money leaks out of claims that got "accepted" at one step, quietly kicked at the next, and then sat unread in a work queue because everyone saw the first green light and looked away. Those don't get appealed, because nobody knows they died. They age out past the filing deadline, and by then a perfectly legitimate claim is worth zero.

So Sage never trusts an "accepted" on its own. She checks which one it actually is first.

Quick callback, because the conversation makes it sharper. Last week we drew the line between a rejection and a denial, and it lives exactly here. A rejection is a claim that failed one of these early messages, the 999 or the 277CA, before the payer ever judged it. It got stopped for a data or format problem, so you fix the data and resend. A denial happens later, after the claim was accepted for processing and the payer actually decided not to pay it.

Put it in this issue's terms. A rejection is the conversation refusing to go on until you fix your grammar. A denial is the conversation running its course and handing back an answer you don't like. The first one just needs a corrected file and another send. The second needs you to read the reason and decide whether it's worth fighting. We did the full breakdown in Issue 20, so I won't repeat it. The thing to notice is that "rejected" lives in these acknowledgment messages, while "denied" only shows up later, in the one we're about to meet.

Biscuit's claim cleared all three acknowledgments and got its claim number. For the first time, it's genuinely inside BHC, sitting in front of Otis, the French bulldog in the tan blazer who decides what the payer does.

And now everything we've spent this whole series on finally lands in one place. Is Biscuit eligible, does his plan cover a hereditary panel, was it authorized, do Dr. Singh's notes support medical necessity, do the coding rules hold, is the lab in network, what's the contracted rate, what's Biscuit's share. That's adjudication. We walked that hallway in Issue 17, so I won't re-teach it. The point today is that none of it could start until the claim survived the conversation and actually reached Otis's desk. Everything up to here was the claim earning the right to be looked at. Now it's getting looked at, and once Otis makes his call, the conversation turns around and heads back the other way.

When Otis finishes, the payer sends a message back to the provider carrying the decision and the money. That message is the 835. If the 837 was the opening line, here is the claim and what we're asking you to pay, the 835 is the reply: here is what we did with it, what we paid or adjusted, and why.

The 835 is dense. For a single claim it can report the billed amount, the allowed amount, what the plan actually paid, every adjustment, and what rolls to the patient, each line carrying a coded reason. When that 835 lands in the provider's system and posts against the claim, everyone calls it the ERA, the Electronic Remittance Advice. People use "835" and "ERA" almost interchangeably and it rarely causes trouble. The 835 is the standardized transaction, and the ERA is that same remittance information arriving electronically and getting posted into Sage's payment workflow.

So here's the round trip. The provider sends the 837 out, meaning here's my claim, and the payer sends the 835 back, meaning here's what happened to it. Everything in between, the TA1 and the 999 and the 277CA, was the two systems making sure the claim was even real and readable and in the queue before the money question got asked.

This one trips up patients and plenty of people who work in healthcare. If the 835/ERA already explained the decision, then what is the EOB that showed up in your mailbox? It's the same adjudication, written for a different reader.

The ERA (835) is the provider's copy. It flows into Sage's revenue-cycle system so she can post the payment and see every adjustment, in the coded language billing software speaks.

The EOB, the Explanation of Benefits, is Biscuit's copy. It's the member-facing document that tells him how his insurer handled the claim. Same numbers underneath, written for a human who doesn't read remittance codes.

One thing here is worth more than the rest of the section put together: an EOB is not a bill. It looks like one and has dollar amounts all over it, and somewhere on it, in print nobody reads, it says "this is not a bill." It's the insurer explaining what it did. If you actually owe something, the real bill comes separately, from the provider.

Sage gets those four numbers from the ERA. Biscuit gets the same four from his EOB. It's one decision, described to two people. So when Biscuit calls the office confused because the insurance paper says he owes $150 but no bill has come, this is the reason. What he's holding is the explanation. The invoice, if there is one, hasn't shown up yet.

One more, quickly, because it rounds out the picture. Sometimes no update has come and you just want to know where things stand. There's a message for that too. The provider sends a 276, meaning what's happening with this claim, and the payer sends back a 277 with the current status. It's a status check you can run any time, separate from the acknowledgments that fire on their own after submission.

I bring it up because it makes the point one more way. A claim is never send-one-file-and-hope. There's a message to open it, messages to confirm it, a message to decide it, and one you can send just to ask where it is. It's a conversation the whole way through, running whether or not anyone happens to be looking at the screen.

For billing and RCM teams, the practical stakes are whether a claim stays managed or quietly slips away. Every one of these messages is a place it can stall without anyone noticing: a 277CA that never came back, an "accepted" that turned out to be only an interchange accept, an ERA that posted a $0 payment nobody opened. Treat submission as the finish line and the conversation just carries on without you. The claims that drop out of it don't raise a hand. They sit there until the filing deadline passes and they're worth nothing.

For patients, two things carry most of the value here. First, an EOB is not a bill, so don't pay one off. Second, when someone tells you your claim was "accepted," remember that accepted for processing and approved for payment are different things, and ask which one they mean before you assume you're covered.

We stayed on the shape of the conversation and skipped the deep grammar. We didn't teach how to build an 837, the raw EDI segments, or the full envelope specification. We didn't get into the coded reasons on an 835, the CARCs and RARCs that explain exactly why a line was adjusted (that's a whole issue). We left the full catalog of rejection reasons, the mechanics of how Otis adjudicates line by line, direct provider-to-payer connections, and payment posting for later. Reply and tell me which one you want first.

Biscuit came in thinking he'd mailed a letter. What he'd actually done was start a conversation, and the machines kept talking to each other the whole time he sat on the couch assuming it was over. That's the part worth keeping. Clicking submit is the first word of that conversation, and the word that decides anything is one of the ones that comes back later, somewhere down the line, with money attached.

Sage understood that when she hit resubmit, which is why she didn't relax. The claim was gone, but the answer wasn't back yet, so she kept watching for it.

That's it for this issue. Hit reply. I read everything.

A note on the workflow. The acknowledgment sequence (TA1, 999, 277CA) and the 837-out, 835-back round trip described here are the standard electronic-billing workflow under the HIPAA transaction standards, and they match CMS's own description: the TA1 validates the interchange (the ISA/IEA envelope), the 999 validates implementation-level syntax and replaced the older 997, and the 277CA reports claim-level acceptance or rejection for processing. None of the three means the claim was adjudicated or paid. In real-world practice the flow is layered rather than tidy, because the claim moves through a clearinghouse: a provider often receives multiple 277CAs (from the clearinghouse and from the payer), most software surfaces these as a status trail instead of raw transaction files, and some trading partners return a TA1 only when there is an interchange-level error. Terminology varies by payer, clearinghouse, and vendor. Biscuit's numbers ($1,000 billed, $600 allowed, $450 paid, $150 patient responsibility) are illustrative, not any real plan's figures. Always work from your own clearinghouse's and payers' current documentation.

Disclaimer: The content published by preimbursed (the "Newsletter") is provided for general informational and educational purposes only and reflects the opinions and commentary of the author. It does not constitute, and should not be relied upon as, medical, legal, financial, tax, insurance, or other professional advice. No physician-patient, attorney-client, fiduciary, or other professional relationship is created by reading the Newsletter or by corresponding with the author. The Newsletter is not a substitute for individualized advice from a qualified professional. Before making any healthcare, coverage, insurance, financial, or legal decision, you should consult your own physician, attorney, benefits administrator, or other licensed advisor and review your specific plan documents, policies, and applicable law. The author is not responsible for any action taken or not taken in reliance on the content herein, and you assume full responsibility for your use of the information provided. Information in the Newsletter is believed to be accurate as of the date of publication and is drawn from the sources cited. Laws, regulations, coverage rules, corporate ownership, market data, and other facts change frequently and may have changed since publication. Certain statements describe pending, recently enacted, or phased-in legal and regulatory changes whose scope, interpretation, and effective dates may shift. The author makes no representation or warranty, express or implied, regarding the accuracy, completeness, timeliness, or reliability of any content, and disclaims all liability for any errors or omissions to the fullest extent permitted by law. References to any company, organization, product, government program, or individual are made solely for purposes of news reporting, commentary, analysis, and criticism, and do not imply any endorsement, sponsorship, affiliation, or partnership. All trademarks, service marks, and trade names are the property of their respective owners and are used only for identification and descriptive purposes. Where a named party disputes a characterization or finding, the Newsletter notes that dispute. Statements concerning identified companies reflect cited reporting and the author's opinion and analysis of matters of public concern. Certain characters, organizations, and scenarios in the Newsletter, including but not limited to Biscuit, Dr. Singh, and composite payer and provider names, are fictional and used for illustration. Any resemblance to actual persons or entities is coincidental.

Disclosure: The authors are the co-founders of Converus.ai, a company that organizes payer policy information for healthcare providers, and therefore has a commercial interest in the subject matter discussed. References to Converus.ai are made only where relevant and are not paid placements. To the fullest extent permitted by applicable law, the author and preimbursed disclaim all warranties and shall not be liable for any direct, indirect, incidental, consequential, or other damages arising out of or in connection with your use of, or reliance on, the Newsletter.