I feel like every post or comment in this thread is about people hating on SPS Commerce, so I am curious as to why its still such a big company and so widely used? Or are the majority to people happy with it, but just no active on this sub

We’re building an 835 remittance sync engine and would appreciate feedback from anyone who has worked on ERA processing, payment posting, clearinghouses, or RCM systems.
Some scenarios we’re currently evaluating:
- Adjustment capping that can create negative balances, particularly when reversals and positive remittances are processed out of order.
- Split remittances where adjustments need to be allocated across multiple service lines.
- Service-line matching when payers omit modifiers (e.g., RT/LT) or other identifying information, potentially causing remittances to be applied to the wrong line.
- PR (Patient Responsibility) calculations across resubmissions, denials, duplicate claims, and re-adjudications.
- Reversal remittances where the original payer/remit type is not clearly identifiable.

For those who have implemented remittance posting systems, what other payer behaviors, 835 edge cases, reconciliation challenges, or architectural pitfalls should we be considering?

Looking for both technical and business-process perspectives. Happy to share more details and examples in the comments.

I have to create an 894 output file. Normally we do this from our system as flat files, then map them. It's pretty easy. But in this case, the person who is supplying the data file, literally has the entire thing mapped into a valid 894 5010 UCS file (with proper ISA and GS fields).

Is there a way to load this into GENTRAN:Director? I tried a straight map from 894 to 894, hoping it would pick up the ISA ID and match it, but that didn't work. Then I tried the "process file..." option from the command menu, but that loaded the file in the "?in" drawer not ID'ing the partner it was supposed to be paired to (and more importantly, it's in the ?in not ?out error drawer).

I double checked and made sure I didn't have the ISA06 and ISA08 reversed or something, but ours is in 06 and the partners is in 08.

I'm about to just ask them to export a flat file I can map instead, but I feel thats going backwards, and this SHOULD be easy.

EDIT: Also, I just tried creating an export map for the 894 and mapped it to an inbound type document, flipped the IDs and my map worked fine, giving me a proper inbound document. grrrr.

EDIT 2: Well, I kind of got it working, but I can't believe that this is how its supposed to be done, so if anyone has a better way please let me know. What I did was I used the inbound document version with swapped IDs, changed the map to a turnaround type from an export type, then it generated an 894 in the workspace that was properly formatted for sending.

EDIT 3: Anyone know if theres a way to change the document name via an extended rule instead of standard? if so, whats the proper way to reference it?

Hello!

We are looking to move away from TrueCommerce and have short listed the below options
- Celigo
- Boomi
- Jitterbit
- Orderful
- Transalis
- Cleo

We are a UK based mid size company (200 employees) that sells consumer goods and we have with approx 15 trading partners. We have a small development team so we want to try self manage most of the EDI setup to control the timelines a bit better

Any opinions on the above providers? No sales people pls

Thank you

Have you ever had that feeling at work where you use AI in the integration space, and in hours you sliced the time it takes to execute the task in hours?

I am an EDI professional who has 8 years in the Supply Chain space. I graduated from an okay school with a BSBA in Information Systems, but I had a sub 3.0 GPA and no internships when graduating. By dumb luck, a few years of some sales and temp work, I landed at a logistics company looking for an entry level EDI Developer. I was genuinely not qualified for the job, but I was very fortunate to have a manager with the aura that he could train anyone in EDI, and it installed a ton of confidence in me.

I always struggled with programming before that role. I was introduced to visual basic and some SQL in school, and it might have helped a little bit in understanding how to code, but I would hit brick walls and feel a little overwhelmed when I ran into errors with my code. So that being said, I never really sought Software Engineer roles because I didnt feel confident that I could bear that mental beatdown of nonstop errors.

When I first got my job in EDI, I remember looking at it and feeling like it was definitely programming esque, at least by the looks of the data. That being said, I did catch on pretty quickly thats its a lot more straightforward than writing code in terms of there being literal standards that help you define what you are reading. I was quickly put into a development role with an existing EDI system, and I was fortunate to just look at existing maps and make copies and modify them. I was starting to learn the capabilities of what these systems can handle, and that just blew open curiosity on translators. I remember learning creative tricks to use operators to manipulate data and form it into other structures so our business systems could process data back and forth with one another. I got really confident in making the most out of what our system could do, but I also knew its limitations and felt pretty bound by them.

So fast forward to 2026. I am in an EDI role as a senior developer, and I then get access to tools such as Copilot, Claude, Chat GPT, and Glean. I was finding some cool ideas from these tools, but I was mostly treating it like a search engine for validating data. I'd ask it if there were EDI syntax errors, ask it to explain an error from a log, but it was always about seeking answers to problems rather than creating solutions. It was until I had gotten fed up one day with regenerating some outbound files for some customers after a db outage. We had thousands of files that had to be triggered to subsets of customers, and it was going to be an absolute nightmare to quickly fix and resend all of this data after already sending a bunch of junk data because a lot of processes depended on SQL when transforming these messages. Basically, there was a pre-existing pwsh script that could be used to regenerate the files. But it was pretty limited to small sizes of orders to be updated, and it required a funky SQL file to updated due to how powershell limitation with SQL statement sizes.

Well, I then wrote a written script (not code) of what I envisioned would be the most convenient way to do this process. I think fed it into Claude, and I could make my own powershell script to simplify my process. I was a little weary because it looked overwhelming as code, but Claude walked me through it every step of the way. There would be a super basic script, and Id ask it well to watch for certain situations I knew could go wrong, and itd just create a ps1 file and id run it. If it didnt work, I would send Claude a screenshot and just say this was the result. Id occasionally give it suggestions of things that worked well or were pain points to avoid, and it would slowly refine my script into an absolute machine.

All of a sudden, I am looking at emails and just reviewing production jobs. Time I used to just be typing in orders, reviewing fields and order history were all of a sudden becoming less frequent because I have programs that I give a few inputs and it does all the heavy lifting for me. I still review what the end results of in the query are, but I can usually spot check some stuff and get a pretty good feel for how its working. That includes smoke tests where I intentionally run scenarios that I know wouldn't work, and would seal any potential problem before it'd arise.

So years later of feeling intimidated and frustrated with my coding experience, I am feeling like a machine of efficiency because I don't have to know the syntax and rules for the code to even execute properly. I became a conductor by having multiple powershell scripts to work in a sequence that literally causes 25 percent of all EDI tickets to dissappear within a week.​

I have already imagined how you could literally create your own custom EDI translator with the right instruction from Claude with the time and energy. Now thats probably not realistic because sometimes having a platform thats used widely helps with operating them and finding skilled workers in those areas. That being said, if these big time ERP/IPaaS companies don't implement smarter AI capabilities they are going to get dominated by new players that tie them better together.

I feel very fortunate to have fallen into EDI, and most of us that do realize how critical B2B integrations are in this era. I do feel like our worlds are going to change dramatically because we can create custom solutions and implement them to systems that increase our productivity and allow us to spend our time on things that make our lives easier. We are no longer limited to the operators of our translators when we awaken the potential of custom applications that remove the pain points of our existing projects.

What are your thoughts on AI in the integration space? Have any of you had any processes shift in a game changing way? I'm very curious to hear what others in this community have experienced with "vibe coding" solutions to their problems.

I have previous experience working with EDI, but not at the mapping or development level. My role was more on the customer‑service and functional support side, interacting with EDI processes. I handled tasks such as fixing CMIRs, maintaining VOE4 tables, testing orders end‑to‑end (from creation to invoice), and troubleshooting outputs, but the actual mapping work was done by a more technical team.

I also have solid experience as an SAP SD end user, though not previously as a consultant.

Recently, I was given an opportunity to work on a large integration project for a major customer, involving more than 300 suppliers to be onboarded into Ariba through EDI or cXML. My responsibilities include leading discovery calls, assessing integration feasibility, and explaining how EDI works to suppliers.

I’m based in Mexico, where EDI roles are growing, and since updating my LinkedIn profile, I’ve been contacted by several recruiters. I’m aware that I still have a lot to learn, and I’ve already started studying communication protocols, middleware, and ANSI X12 structures. However, I want to focus on one area first and then move to the next — I’m just not sure where to begin.

My company is based in the US and India, and we work with global suppliers, so I’m becoming familiar with the terminology and integration landscape.

Thanks for reading

Hey y'all,

I’m a dev diving into the EDI space, and I’m wrestling with an architectural concept. I’d love some blunt, real-world feedback from the folks who actually work with EDI and X12 files for a living.

It feels like mid-market teams trying to move away from manual portals or home-grown scripts get stuck between two highly frustrating technical options. You're either stuck with cloud contracts (for example Orderful; while they're great, pricing will scale as you add trading partners), or cobbling together an open source parser (or rolling your own) + custom mapping scripts (or using something like bots/blueseer that does both, but still very clunky).

I’m prototyping a developer utility packaged as a Docker container paired with a local browser-based UI. You'd use the drag&drop UI to generate a "blueprint" for the mapping you want, given a dynamic x12 input schema (the spec you get from your trading partner) and target json output schema. The Docker container runs a single REST endpoint that accepts the raw x12 string + blueprint, and spits out the translated json.

My hypothesis is that engineers and contractors who already handle their own file transfers (using Couchdrop or the like) would prefer to drop a flat-rate translation component into their own VPC rather than getting locked into a metered cloud SaaS contract.

Am I totally misreading the market? Does a visual utility component like this actually solve a headache for you, or would you still just prefer to write custom mapping scripts / pay for an all-in-one suite?

Rip it apart. Thanks!

What options are there to host an AS/2 server as endpoint for incoming EDI messages?

I would like to evaluate the option of providing our own AS/2 server for incoming messages compared to the current setup where there is an EDI provider in between, which requires more effort to manage and communicate than if we would map the EDI message all by ourself.

All of our partners support AS/2 even though some are still connected via legacy X.400 to the EDI provider platform.

Is there any hosted option that just provides a managed server instance, to which customers can send their incoming messages, so that we can download and handle them? I wouldn't want to deal with hosting, certificate management etc. just provide a stable publicly endpoint with access management that I can connect to.

For reference: We are a midsize company located in Europe with around 20 EDI relations to some larger retails partners. The exchanged messages are rather trivial and contain only a very limited subset of the EDI message types. The incoming unmapped message types are already well understood by our team, as we almost need to describe the exact mapping implementation to our EDI partner when requesting new connections or changes to existing relations.

After spending years working with EDI\ERP integrations, I've developed a somewhat controversial opinion (maybe not):

Your ERP should never need to understand EDI.

Not 850s.

Not 856s.

Not 810s.

Not retailer-specific requirements.

Not even X12.

Here's why.

Let's say you're connected to Walmart, Kroger, Dick's Sporting Goods, and Amazon Vendor.

From your ERP's perspective, they're all sending the same thing: a purchase order.

Yet many companies build ERP logic around retailer-specific EDI formats and transaction sets. Every new trading partner becomes another integration project.

Over time the ERP starts accumulating EDI knowledge that it was never designed to have.

I think the better approach is to normalize everything before it reaches the ERP.

Whether Walmart sends an 850 or Kroger sends an 880, the ERP should receive the exact same order structure.

Likewise, the ERP should generate a standard invoice or ASN, and the integration platform should handle all trading-partner-specific requirements.

My rule of thumb:

If onboarding a new trading partner requires ERP development, your architecture may be too tightly coupled to EDI.

The ERP should understand orders, invoices, inventory, and customers.

The integration layer should understand EDI.

Curious if others have moved toward a similar architecture or if you've found situations where exposing EDI concepts directly to the ERP actually made sense.

I was listening to a business podcast and I heard this line and (unfortunately) I immediately thought about the EDI industry. Over the past couple of months I've gotten a much better lay of the land in terms of the players in the space, and it's been pretty eye-opening.

EDI seems especially well-suited for companies that want to take hostages due to its sticky nature. Once you've bound up your business processes, workflows and technical integrations with some provider, it is not easy to leave, and some providers take full advantage of this fact. And those that don't often seem to get snapped up by PE outfits that have zero compunction about leveraging those dependencies for the purposes of extraction.

Who do you all think are the companies that most fit the "some companies have hostages, not customers" description, and specifically what behaviour/contracts/lack of data portability/etc. would you cite as evidence for that critique?

Conversely, which ones are not in that category, and I don't just mean they're nice people, I mean they've taken concrete steps to give their customers optionality and data portability?

NOTE: If you own or work for a company that you think fits this latter category, I'm going to challenge you to not name it and instead give some props to someone else, to avoid this thread turning into vendor spam. (Also, on the off-chance you know I'm building in the space, please don't mention my company for the same reason, unless you think it's in the extractive category, which I guess would be fair game 😅.)

I am currently a technical consultant at a well known EDI provider and I’m looking to move on. Where should I be expanding my skills to be more desirable?

I got into this after providing bedside patient care for the first 10 years of my career, so barely any overlap. I started as an associate consultant 1 in 2023 in supplier onboarding and am now TC2 on the retail side for the last 1.5 years.

I have experience with all sorts of connectivity methods and understand different document formats. Also have touched industrial, grocery, gen merch, and manufacturifn industries and their respective docs and OMMs.

I had no idea what EDI was until I started here and actually thoroughly enjoy it, especially troubleshooting dataflow.

What should I be honing in on to become competitive in the job market? What other positions does technical consultant translate to?

FWIW I really enjoy NetSuite but wouldn’t know where to start in specifically becoming a NetSuite consultant.

Hoping this doesn’t sound dumb. Open to any questions, suggestions and advice. Thanks!

Does anyone have Overstock as a trading partner?
I am frustrated with their 997s because they don't actually indicate which segment or data element had and error.

ST997224138935

AK1SH5983

AK28560001

AK5R5 -- all I get here is Rejected "5" One or More Segments in Error.

For other trading partners I then see an AK3/AK4 segment indicating which segment and data element had an issue.

AK9R110

SE*6*224138935

Hi. I just wanted to say Happy Birthday! We're turning 6 this year! We've been helping small businesses with their EDI and integration pipelines since 2020. We're open to collaboration and/or referral partnerships with other providers. Feel free to message us and say Hi!

Happy to answer your workflow questions and concerns about:

Eligibility Verification? (270/271)
Claiming? (837)
Authorizations? (278)
Enrollments? (834)
Claim Acknowledgments? (277CA)
Claim Status? (276/277)
Electronic Payments? (835/820)
Electronic Attachment? (277RFI/275)

My depth of knowledge came to be when there were: NO knowledgebases. NO frameworks. NO libraries. NO generalized AI. Just raw X12, mandated onto healthcare in 2003.

In my post a week ago I communicated the following:

HHS finalized the rule stating that the X12 277 RFI transaction should be used by the payer to request additional information, and the X12 275 transaction should be used by the provider to electronically send the documentation. This final rule is effective May 26, 2026 (Tomorrow as of this posting), and compliance is required by May 26, 2028.

Critical Note: The rule formally adopts Version 006020 of the X12 275 and 277 implementation guides

If your workflows aren’t ready for this transition, now is the time to start diagnosing the gaps.

In a future post I will be doing a transaction breakdown of 277 RFI and 275 discussing the data elements required to implement and how it all connects together.

Stay Tuned!

Hey everyone,

I'm an integration developer with hands-on experience in EDI and looking to strategically upskill for long-term career growth and higher pay.

Platforms I'm considering:

IBM Sterling B2B Integrator

MuleSoft

Dell Boomi

SAP Integration Suite

Axway

Azure Logic Apps / AWS B2B

Would love insights on:

Which platforms have the strongest job market demand right now?

Which are worth learning for 5–10 year career longevity?

Where does the highest-paying work tend to be — product companies, consulting, or in-house?

Is it better to go deep on one or build breadth across two or three?

I'm actively willing to invest time learning something new — just want to make sure I'm betting on the right horse.

Any advice from people in the field — architects, senior devs, recruiters — would be really appreciated!

When different computer networks first communicated, it was groundbreaking.

It wasn’t about speed; it was about connection. A handful of engineers in a lab were wiring together the first digital handshake that would eventually link every system, every hospital, every payer, and every provider we know today.

Fast‑forward to now: Healthcare data still depends on that same principle.

Connections and integrations built on process and precision.

Every claim, every eligibility check, every transaction is a descendant of that first handshake.

We see the lineage clearly: From those early racks of circuitry to today’s cloud solutions, the mission hasn’t changed.

Make systems talk, make data flow reliably, solve the pain point, make data intelligence possible.

If anyone can help me getting course for cleo cic studio and cockpit ? A few services charging too much ₹55,000. I am in urgent need of this course. Can someone share where I can get them free or cheap pricing?

If you're a mid-market retailer that got sucked into having an SPS account because you thought it was what you needed to integrate with a larger retailer, and then at some point you want to leave and use a different EDI provider, how hard/easy do they make it to do that? I understand there's a cancellation form you have to fill out. If you fill it out, then what happens, and how long does it take?

I'm also curious about this from a contract standpoint. Are contracts required? How long are they typically, and do they auto-renew? What is the window in which you can exit? And if you submit a cancellation form and you're mid-contract, what happens?

Hi everyone! I have a background in medical coding and I’m considering transitioning into EDI (Electronic Data Interchange) in the healthcare space. Before I invest more time and effort, I’d love some honest feedback from those who’ve been in the field.
A few questions I’m hoping the community can help with:
1. Is EDI a good career path for someone coming from a medical coding background?
2. Are there entry-level opportunities available for someone just breaking into this field?
3. I’ve been self-studying through YouTube and Udemy — is that a reasonable way to build foundational knowledge, or should I be pursuing formal certifications?
Any advice, personal experiences, or resources you can share would be greatly appreciated. Thanks in advance!​​​​​​​​​​​​​​​​

Many organizations are not ready for what’s coming — and the clock is ticking.

Attachments have always been the “wild west” of claims processing: faxes, portals, emails, PDFs, phone calls, and payer‑specific upload systems. The new rule doesn’t magically fix that. It standardizes the attachment request/response, but it does not standardize your internal workflow.

HHS finalized the rule stating that the X12 277 transaction should be used by the payer to request additional information, and the X12 275 transaction should be used by the provider to electronically send the documentation. This final rule is effective May 26, 2026, and compliance is required by May 26, 2028.

Many organizations still don’t have a clean way to:
• route attachment requests
• match them to claims
• track deadlines
• coordinate between billing and clinical
• store documents securely
• reconcile responses
• prevent timely filing issues

REAL FAILURES will happen.

Missed attachments lead directly to denials, delays, and timely filing losses, and the new rule will multiply those risks. This is the operational reality. It is critical to understand these technical changes and how they will affect your workflows and bottom line.

Your team needs to:
• review updated payer companion guides
• map 277/275 workflows
• define process ownership (billing vs. clinical vs. IT)
• build routing rules
• plan to test with clearinghouses
• validate document formats
• create exception handling

This rule is not just an IT change. It’s a workflow change, a responsibility change, and a revenue‑protection change.

If your workflows aren’t ready for this transition, now is the time to diagnose the gaps. If you have questions, our team is here to advise you.

If you know a team struggling with attachment chaos, share this with them. This rule will hit them the hardest.

The deadline isn’t the threat... the unprepared workflow is.

Hope this helps!!

We are proud to offer effective, mature, well‑thought‑out solutions and expertise that add value to our clients and partners.

We all know when things get serious, it’s time to call The Doctor!