r/edi

Project underway to kick off using the 275 006020X314 claim attachment. The T3 guide says you're supposed to use the TRN02 to associate the attachment to the 837 claim. But we've known for years that many of the lazier providers will use the CLM01 patient control number from the 837 as the TRN02 trace routing number. And we also know that they will sometimes re-use a value for the patient control number such as [patient last name]+[provider's patient ID] which means we could easily get 275s with duplicate values that we are supposed to associate with claims.

To add to that, we are expected to hold on to the image for 3 days to see if the claim shows up late and associate them. So that pretty much means that we've sent the 999 already by that point.

Yeah. Anyway, so my real question is: what do you do with your 275s? Do you send an 824? Do you just revert to an email to the provider like some kind of savage? Do you just toss it in a bin and hope nobody notices the smell?

Inquiring minds want to know

Hello, I discovered EDI from my current job and didn't know it could be a career I could go into until recently

A little background about me

I've been in warehousing/logistics since about 2018, starting off as a picker. Since then, I've learned how to do Crossdock, Shipping and Receiving, and now scheduling, invoicing, handling inbound and outbound deliveries, order entry, and dealing with the customer service side of things as well

Is it possible for me to switch into this career? What would I have to learn or do for my resume/portfolio to stand out?

Any advice will be appreciated!!

Hi there,

Some of you probably read my post that I have been posting for a while on what to do next. I found a person who is willing to train me on the IBM Sterling product. I used to see quite a bit of requirements for IBM Sterling, in fact, a lot of times I would lose the opportunity as I did not have that experience. Now, I don't see much requirement for IBM sterling EDI professionals. Am I wrong? Maybe I am just going through an anxiety phase and losing it! lol

Hiya.

Ok, so you have multiple streams, right? You have all the health care transactions: 270, 275, 276, 278, 834, 835, 837. But you also have different lines of business. You have special partnerships with other payers, you have regular claims, and repricing claims, and so on.

Each of these has their own edits in place -- the relaxations of errors, the special rules written in, bumping an error from the 999 to the 277CA, etc. And your software handles all those edits like a champ. Good for them, good for you.

But you know what that software does *not* do? Give you a clear and easy report on all the edits you've put in place over twenty years for each of those streams in a language any business user can understand. So you get requests for why transactions did what they did. And, sure, you can find the edit in question that caused the outcome, but you don't know when that was installed. Maybe it was before your time. And sure, there's a demand/ticket/request/remedy out there somewhere. But maybe that was on the old change control software. Or maybe it's been archived. Or maybe it was just not written in a way that's easy to find.

So how in the hades does anybody keep track of the countless edits? In a way that can be viewed by non-tech folks that they will understand? Is this just going to end up being a gigantic spreadsheet, or perhaps a dozen of them?

This is the link to a current job opening in EDI in the Nashville, TN area. Hybrid/remote available. Applications are open until 08/24/2026.

Hi! I’m currently in a billing dispute with SPS Commerce and wanted to see if anyone has dealt with something similar.

They’re claiming I owe about $1,800. I’ve offered to pay roughly $500 covering the period when the services were active, but I’m disputing the remaining charges. SPS’s position is that they can continue billing even after access/services have been suspended.

Has anyone disputed a balance with SPS Commerce before? Did they actually send a relatively small balance like this to collections?

If it went to collections or legal action, what ultimately happened? Did you end up paying the full balance, settling for less, or successfully disputing it? And were any collection costs or legal fees added?

Would really appreciate hearing from anyone who has dealt with SPS specifically.

I mentioned a while back that I’d post a clear breakdown of the 277 RFAI.

Most explanations of the RFAI are often made up of recycled X12 companion guide descriptions. They don’t answer the real questions people actually have when they receive an electronic “Request for Additional Information” in the real world. Here is a practical breakdown.

1. What a 277 RFAI really is

An RFAI isn’t just a claim status message. It’s the payer notifying you they cannot finish processing a claim until additional information is sent. It’s a structured “Request for Additional Information” wrapped inside the EDI X12 277 format. Instead of denying the claim, the payer pauses (pends) the claim and asks for follow‑up documentation, clarification, or proof.

2. Why payers send RFAIs

RFAIs are triggered when the payer has enough data to identify the claim but not enough to adjudicate it. This can happen for many reasons: missing clinical notes, unclear procedure justification, mismatched identifiers, or simply because the payer needs supporting documentation. The important part is that an RFAI is not a denial, it’s a request to complete or correct the submission so the claim can move forward.

3. The structure of an RFAI

The RFAI follows the same general layout as a standard 277, but the STC loops take on a different meaning. Instead of reporting claim status, they report what information is missing and what the payer needs. The STC segment becomes the heartbeat of the message, containing reason codes and category codes. Often an MSG segment also contains descriptions of the request. Once you understand how the STC loops are organized, the entire RFAI becomes relatively easy to interpret.

4. The “request” inside the RFAI

Every RFAI contains a specific “request”: the payer designates exactly what is required to continue processing the claim. This might be medical records, operative notes, proof of eligibility, corrected identifiers, or additional documentation. The STC segment is usually followed by an MSG segment that spells this out in plain text. The key is recognizing that the RFAI is "actionable": it’s not just informational, it is a to-do list. Once you satisfy the request, the claim can move forward without being resubmitted.

5. How the EDI X12 275 fits into the response

The 275 is the mechanism you use to respond to the RFAI. It carries the attachments, documentation, and supporting records the payer has requested. The 277 RFAI tells you what they need; the 275 is how you send it back. The two transactions are designed to work together. If you don’t send a proper 275 in response, the payer will simply wait, and the claim will stall indefinitely.

6. A real example (summarized)

A typical RFAI might identify a claim, list the patient and provider, and then include an STC segment with codes and an MSG segment stating something like: “Additional documentation required: operative report missing”. The message will include the claim’s tracking identifiers and the specific reason code that corresponds to the request. After further review, you’ll see the pattern becomes obvious: identify the claim, state the issue, request the documentation. In my experience so far, I have found the structure is consistent across multiple payers even if the wording varies.

7. Practical advice from the EDI Doctor

When you receive an RFAI, the correct workflow is straightforward: read the STC and MSG segments, determine what the payer is asking for, gather the required documentation, and send it back via a 275. Don’t resubmit the claim, don’t wait for a denial, and don’t assume the payer will follow up. The RFAI is the follow‑up. Responding quickly prevents delays and keeps the claim alive. Once this process loop is understood, RFAIs stop being mysterious and become just another part of the normal EDI workflow.

I know I make it sound simple, but in the real world there will be messy edge cases. On the positive side, understanding is at least half the battle that brings you one step closer to implementation.

I’m happy to chat in future

I recently met with CINTAP orbit and they showed me a demo where they were able to onboard a new customer in less than an hour for an 850 document with end to end automation. We currently use CIC (Cleo Integration Cloud) and we have had some concerns implementing basic setups like routing the order to multiple end points etc..

CINTAP is completely an agentic model and they built it on their own LLM. You can autopilot the whole process by sharing samples of input, output, IDEs etc.. or just create individual setups using their AI. Obviously, I was blown away thinking of the time I would save by moving to them.

Does anyone in this group have any experience with them or any reviews you would like to share so that I can make a more informed decision.

Hello EDIers,

I have done many EDI go lives with various providers and systems. Current client wants me to switch to a new VAN with old ERP. Then six, 9, 12 months later keep same VAN and new ERP.

I am not see a big value add to move to new VAN first, might as well wait until new ERP. So that we only have to retest the EDI with customer once.

As I recall, depending on the customer, I will still need to retest all messages with new ERP and same VAN. I did have some customers say to me "I dont care about your new ERP, you make sure everything works on your side, and we get all EDI messages exactly the same way we do now. We do not want to hear about it, and do not need to test with you."

Have you got any feeling about what percentage of customer INSIST that you retest if you are changing your ERP, but not changing your VAN. I was thinking 50%, but not really sure.

Thanks for any input.

Neal.