Single Source of Truth in EDI - Easier Said Than Done

Something I’ve seen over and over in EDI:

The EDI layer slowly takes on business logic it was never meant to own.

It doesn’t happen all at once. It happens one reasonable decision at a time.

• A partner sends something slightly different, so we adjust it in the mapping.
• A value doesn’t line up, so we add a lookup.
• A field needs to be interpreted, so we build a bit of logic.

All of it makes sense in the moment.

But over time, your source of truth starts to drift away from your ERP.

A Few Real Examples

Each vs Case Conversions

A partner sends quantities in eaches, but internally you work in cases. So EDI converts based on the material.

It works… until the conversion changes, or a new material is added and missed.

Now that logic lives in both places - and they don’t always match.

UPC Manipulation

Converting between each-level and case-level UPCs by adding or stripping leading 0’s or 1’s.

It’s a quick fix, but now product identification logic sits in EDI instead of your material master.

Date Adjustments for Transit Time

Adjusting requested delivery dates in EDI to account for transit time.

But transit time could be maintained in SAP in your routes.

Now you have your EDI team maintaining business data.

Partner Location Lookups

Building partner-specific lookups in EDI instead of using standard partner determination (VOE4 / EDPAR).

It solves the immediate need, but every new partner adds more custom logic instead of reusing what’s already in SAP.

The Pattern

None of these are necessarily bad decisions on their own and usually have some justification behind them.

They’re usually the fastest way to get something working.

But this is how EDI turns from a translation layer into a decision engine.

• Logic gets duplicated
• Ownership gets unclear
• Changes take longer than they should
• And simple questions become harder to answer

What Should Happen Instead

EDI should move data.

Your ERP should define it.

• Conversions belong in the material master
• Transit logic belongs in routes
• Partner relationships belong in standard configuration

The closer you stay to that, the easier everything is to support and scale.

Final Thought

Each piece of logic added to the EDI layer usually has a good reason behind it. Overtime though, this leads to a system that is harder to support and makes questions harder to answer.

The best long term strategy is to dig deeper into each decision asking if this logic truly belongs in EDI or it’s better in your ERP where the business already manages that process.