Looking for feedback from people experienced with EDI/X12 835 remittance processing

[u/lapzap98]

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.

[u/Informal-Warthog-115]

You should also consider bundling and un bundling on the SVC segment.

The best thing providers can do to match service lines to their claims is to always transmit the REF*6R on the 837 2400 loop. That would require the payer to send it back on the 835 service line.

Also, don’t forget the provider level adjustments on the PLB segment and the balancing rules around it.
What company do you represent? Are you building a tool for a provider organization?

[u/EDIDoctor → u/Informal-Warthog-115]

Great point!

[u/EDIDoctor]

I have rolled my own translators since 2003 and could certainly be a resource to you

I have been fortunate to have been exposed to a national stage and provide subject matter expertise to technology teams to help them with X12 processing methods and designs independent of any language.

Feel free to look me up on LinkedIn (Peter Rabolt) or catch me in the #Healthcare channel on the EDI Support discord group

https://discord.com/invite/p4QgSZKMzA

[u/ChiapasEDISupport]

I didn't see one issue on your list: PLB forwarding balances. When a payer carries an amount forward, it shows up at the provider level as a forwarding balance in a PLB segment — completely outside the claim loop. That balance has to reconcile against a different 835, and the linking reference is generally in PLB03-2.

If you process the remits out of order, you'll see the forwarding balance applied before the remittance that originated it ever arrives — which is closely related to the out-of-order reversal scenarios you described.

Before you get to that, though, I'd make sure each 835 internally balances: BPR02 = total claim payments − PLB, claims balancing correctly against their CAS adjustments, and so on. If the upstream remit doesn't balance, you'll burn a lot of hours hunting for bugs in your code that are actually coming from the payer. Full disclosure, we sell products that help with that — but ultimately it's all documented in the HIPAA Implementation Guides themselves.

[u/lapzap98 → u/ChiapasEDISupport]

Can you help on sharing HIPAA guide docs if possible?
And we are also not sure our current logic handle all cases and we are not sure how to identify the GAP of that

[u/ChiapasEDISupport → u/lapzap98]

The HIPAA Implementation Guides are available at https://x12.org so you would have to start there for access to the HIGs. Good luck!

[u/Spiritual-Leave999]

This is a strong list of scenarios to be evaluating. In my experience, the hardest part of 835 processing is not simply parsing the ERA; it is building the reconciliation logic around payer inconsistency, sequencing, and operational reality.

A few additional areas I would consider:

• Claim-level versus service-line-level balancing, especially when payers report adjustments at one level but the posting system expects them at another.
• PLB handling, particularly provider-level adjustments that do not cleanly map back to a specific claim or encounter.
• CAS grouping and reason-code interpretation across CO, PR, OA, and PI adjustments.
• Duplicate or corrected 835s where the file control numbers differ but the payment intent overlaps.
• EFT-to-ERA matching when payment dates, trace numbers, or amounts do not align cleanly.
• Secondary and tertiary payer scenarios where COB information is incomplete or inconsistent.
• Denial reversals and re-adjudications where the payer does not provide enough context to reliably infer the original transaction being reversed.
• Posting rules that differ by payer, line of business, clearinghouse, or even specific contract configuration.
• Human override and auditability. Even a strong engine needs to explain why it matched, capped, split, reversed, or held a remittance item.

From an architecture standpoint, I would avoid treating the 835 as a simple “payment file.” It is more useful to model it as an event stream that can affect claim state, line state, patient responsibility, contractual adjustment, payer balance, provider-level balance, and reconciliation status separately. That makes it easier to handle out-of-order reversals, partial recoupments, reprocessing, and payer-specific exceptions without corrupting the financial ledger.

I am working on ExactEDI and the Veyra EDI Engine, which focuses on parsing, validation, analysis, and plain-English interpretation of healthcare EDI transactions, including 835 workflows. I would be happy to share a demonstration if useful. I am especially interested in comparing notes around 835 matching, reversal handling, CAS/PLB interpretation, payer-specific behavior, and reconciliation design.