Issue

KDD066 defined the approach to simplify and standardize the EDI landscape.
It stated that for each business process there should be:

• One Primary EDI

• One Secondary EDI, allowed only as an exception

However, when KDD066 was approved, the Primary and Secondary EDIs listed were indicative only. They were based on conceptual design and not on detailed process analysis.

Since then, SyWay has moved into Detailed Design. During this phase, the processes, integrations, and partner constraints are now much clearer.

Because of this, the EDI assignments from KDD066 need to be:

• Reviewed process by process

• Evaluated against the SyWay To-Be design

• Finalized for execution

In addition, a governance approach is required to manage any future need for new EDIs.

Recommendation

It is recommended to formally confirm the Primary and Secondary EDI platforms per business process, based on the outcomes of the SyWay Detailed Design.

The recommended EDI assignments:

• Aligns with the SyWay To-Be architecture

• Supports standardization while respecting business realities

• Ensures business continuity where legacy solutions must remain

• Avoids uncontrolled growth of the EDI landscape

The table below captures the final proposed EDI positioning per process, replacing the indicative assignments from KDD066.

Background & Context

KDD066 was created at an early stage of the SyWay program, when the objective was to set a strategic direction for the future EDI landscape. The focus at that time was on reducing complexity by limiting the number of EDI platforms and introducing the concepts of Primary and Secondary EDI.

Following KDD066, the SyWay program progressed into Detailed Design across multiple domains, including Sales, Procurement, Logistics, Transportation, Finance, and Global Trade Services. This phase delivered several important clarifications:

• A clear To-Be integration architecture, centred on SAP S/4HANA and SAP Integration Suite, with preference for API- and event-based integrations and controlled coexistence of legacy EDIs

• A defined customer and supplier collaboration strategy, including Commerce Portal, Supplier Portal, and selective use of Ariba Business Network

• A confirmed approach for 3PL integration, clearly distinguishing between integrated 3PLs and no-integration scenarios

• Finalised bank connectivity decisions, retaining SWIFT Bureau connectivity

• A regional GTS / Customs Control Tower model, with broker harmonisation and broker-agnostic message design

These Detailed Design outcomes provide the necessary maturity to move from conceptual intent to concrete, executable EDI decisions.

Therefore, this KDD builds on KDD066 by validating the original principles, reassessing the options per process, and confirming the final Primary and Secondary EDI platforms aligned with the SyWay To-Be design.

As a result, the indicative EDI assignments in KDD066 no longer reflect the executable To-Be design and must now be formally confirmed or adjusted.

Assumptions

Following are some of the assumptions that are considered as part of the analysis.

• API-based and event-based integrations are preferred where possible

• Legacy EDI solutions will remain only where required for business continuity

• New partners will use the defined Primary EDI by default

Constraints

Following are some of the constraints that are already considered as part of the recommendations 

• Existing contracts with customers, suppliers, banks, and brokers

• 
  

  Different levels of partner technical readiness

• 
  

  Regulatory and country-specific requirements

• 
  

  Parallel run between legacy systems and SyWay S/4HANA

Impacts

Business Impact

• Clear and consistent EDI rules per process

• Easier partner onboarding

• Better alignment across regions and GBUs

IT / Integration Impact

• Reduced number of EDI platforms

• Clear default integration patterns

• Better monitoring and error handling

Change Impact

• Some legacy EDIs will remain for specific partners

• New partners will be guided to standard solutions

Financial Impact

Supplier portal - custom portal

3PL - Interfaces

BN4L - Integration

Business Rules

• Each business process must have Primary EDI and Secondary EDIs are allowed only by exception

• New EDIs require governance approval

• New partners must use the Primary EDI

• Exceptions must be documented and reviewed regularly

Options considered and Evaluation

For each functional area, EDI options were assessed based on:

• Fit with SyWay architecture

• Scalability and reuse

• Partner readiness

• Risk and business continuity

The following sections describe the selected Primary and Secondary EDIs per domain.

Sales (Order to Cash)

For Sales Orders and Invoice, following are the options

• Option 1 – Commerce Portal for all customers

• Option 2 – Continue legacy EDIs (Elemica, Esker) as primary

• Option 3 – Portal as default, legacy EDIs by exception (Recommended)

Conclusion

• Commerce Portal is Primary EDI

• Legacy EDIs remain Secondary, only for existing strategic customers

• Note: For Invoicing E-Invoicing is primary EDI for all the countries where it is mandatory as part of Regulation

Procurement

Supplier Portal – Primary EDI

Description

• SAP-integrated, API-based supplier collaboration channel enabling purchase order exchange, order confirmations, and document sharing.

• Designed as a lightweight, scalable entry point for suppliers without requiring heavy onboarding.

• Access managed via email-based authentication, allowing rapid enablement of suppliers.

Why Primary

• Can be used by any supplier, regardless of size, volume, or technical maturity.

• Requires no formal onboarding project, reducing time, cost, and dependency on suppliers.

• Aligns with SyWay detailed design and SAP-standard integration patterns.

• Acts as the default collaboration channel for non–Ariba suppliers.

• Avoids forcing small or low-volume suppliers into complex platforms.

• Supports gradual, controlled adoption of more advanced platforms where justified.

Ariba Business Network – Primary EDI (Selective)

Description

• SAP-managed B2B network supporting structured, system-to-system procurement transactions.

• Provides M2M integration for purchase orders, confirmations, ASN, service entry sheets, and invoices.

• Widely adopted by large, high-volume suppliers with existing enterprise licenses.

Why Primary (Selective)

• Preferred channel for high-volume, digitally mature suppliers already active on Ariba.

• Enables straight-through processing with minimal manual intervention.

• Leverages existing supplier investment in Ariba licenses and integrations.

• Covers a significant portion of total PO volume through a limited number of suppliers.

• Avoids unnecessary duplication of integration channels for suppliers already optimized on Ariba.

Transportation Management – EDI by Mode of Transport

Road Transport

Primary EDI:

• BN4L

Secondary EDI (Transition / Exception):

• Transwide (Europe – transition)

• BluJay / TMS4S (US & Canada – transition)

Rationale

• BN4L provides global road carrier collaboration with a single operating model.

• Transwide and BluJay remain only where migration is still in progress.

• Target state is one global platform for road freight collaboration.

Ocean Transport

Primary EDI:

• BN4L

Secondary EDI:

• None (target state)

Rationale

• BN4L will cover carrier collaboration for ocean freight, including the USA and Canada where no collaboration tool is currently integrated

  TM

  .

• Eliminates gaps and manual processes in ocean freight execution.

• Aligns with the global standardisation objective.

Air Transport

Primary EDI:

• BN4L

Secondary EDI:

• None (target state)

Rationale

• BN4L enables air carrier collaboration, currently not supported by an integrated platform.

• Provides consistent visibility and execution across regions.

• Reduces dependency on emails and manual coordination.

Summary Table – TM EDI by Mode

Logistics – 3PL Integration Decision Model

(3PL Integrated vs No Integration)

Context

SyWay defines a standardized, scalable approach for integrating third-party warehouses with SAP S/4HANA, while also recognizing that not all external warehouses justify or require system integration

3PL SyWay TO BE Final (1)

.

The To-Be model therefore supports two clear scenarios:

1. 3PL with system integration

2. No system integration (manual / SAP-only execution)

Option 1 – 3PL Integrated

Description

• The 3PL WMS is system-integrated with SAP S/4HANA via SAP Integration Suite.

• Supports outbound, inbound, and warehouse execution processes through APIs (primary) or EDI (secondary).

• Real-time or near real-time exchange of delivery, inventory, and status information.

When this applies

• High or medium transaction volume

• Operational dependency on the 3PL for execution

• Need for inventory visibility and reconciliation

• Strategic or long-term warehouse partner

• Regulatory or service-level requirements

Characteristics

• Standard SyWay interface set (DI01–DI06, PU01–PU02, IM01–IM02)

• Event-driven processing from SAP

• Status acknowledgements from 3PL

• Central monitoring via AIF + Fiori

• Plug-and-play onboarding with controlled adaptations

Key Benefits

• Real-time visibility of warehouse operations

• Reduced manual effort and errors

• Standardized execution across 3PLs

• Scalable onboarding of new providers

• Improved SLA monitoring and issue resolution

Option 2 – No Integration (SAP-Only / Manual)

Description

• No system-to-system integration between SAP and the external warehouse.

• Warehouse execution is handled outside SAP, with postings performed manually or via periodic updates.

• SAP remains the system of record, but without automated message exchange.

When this applies

• Low transaction volume

• Temporary or short-term storage

• Non-strategic warehouses

• 3PL has no WMS or no integration capability

• Cost or effort of integration not justified

Characteristics

• Manual creation and confirmation of deliveries and goods movements

• No real-time inventory visibility

• No automated status or acknowledgment messages

• Operational reliance on procedures rather than interfaces

Key Benefits

• Zero integration cost

• Faster short-term setup

• Suitable for exceptional or transitional scenarios

Comparison – 3PL Integrated vs No Integration

KDD Decision Positioning

• 3PL Integration is the default choice where volume, criticality, or visibility requirements justify it.

• No Integration is an accepted exception, not a target state.

• The decision must be taken per warehouse, based on business and operational criteria.

• Where integration is chosen, API-based integration is primary and EDI is secondary, per SyWay standards.

Bank Connectivity – SWIFT vs Multi-Bank Connectivity

SWIFT Bureau (via Worldline) – Primary Connectivity

Description

• Bank connectivity via an external SWIFT Bureau providing access to SWIFT and external banks.

• Acts as a centralized hub for payment files and electronic bank statements.

• Used across SAP and non-SAP systems, including the legacy PI1 landscape and SyWay S/4HANA.

Why Primary

• Existing connectivity already in place and operationally stable.

• Covers all banks, with no dependency on bank membership limitations.

• Lower implementation risk, using a proven and well-understood setup.

• Cost-effective when considering overall transition and change effort.

• Provides flexibility during the interim period (parallel PI1 and S/4 connectivity).

• Good support model and operational maturity.

• No compelling functional or strategic benefit identified to justify migration away.

SAP Multi-Bank Connectivity – Not Selected / Secondary (Future Consideration)

Description

• SAP-native connectivity solution enabling direct integration between SAP systems and banks.

• Supports standardized payment and bank communication formats within SAP.

Why Not Primary

• Limited number of participating banks, reducing global applicability.

• Would require a new implementation during SyWay, increasing cost and complexity.

• Transition would be more complex during the coexistence phase.

• Transactional cost benefits do not offset overall implementation and change costs.

• Support maturity and external feedback not sufficiently strong.

• No substantial functional advantage compared to the current SWIFT Bureau setup.

SWIFT Bureau vs SAP MBC – Comparison

Global Trade Services (GTS) – Customs & Broker Integration Strategy

Context

Syensqo is moving to a regional Customs Control Tower model to improve trade compliance, increase agility to regulatory changes, and reduce the number of customs brokers and EDI connections by 2027.

SyWay must align to this strategy by:

• Supporting regional broker harmonisation

• Designing standard, broker-agnostic EDI messages

• Ensuring business continuity where regions are confirmed as AS-IS

Regional Positioning

Europe (EU)

• Primary broker: Maersk

• Control Tower already live

• SyWay approach: Integrate with the regional broker using standardized GTS EDI messages

Americas (excluding Brazil)

• Primary broker: Expeditors

• Implementation planned

• SyWay approach: Integrate and support transition to the harmonized broker model

APOC (Asia Pacific outside China)

• Broker to be selected via RFP

• Go-live planned post-selection

• SyWay approach: Broker-agnostic design to allow future onboarding without redesign

China

• Customs system: JET

• No change planned before 2027

• SyWay approach: Maintain AS-IS integration

Brazil

• Customs system: Comex Sonda

• No broker change planned

• SyWay approach: Retain system and integrate with S/4HANA, improving data and process quality

Summary

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log