Status
Owner	The person responsible for driving this decision and documenting it. Type @ to mention people by name
Stakeholders	The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name

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.

Area	Transaction	Primary EDI	Secondary EDI
Sales	Quotation	None
	Sales Contract	None
	Sales Order	Commerce Portal	Elemica
	Billing	Commerce Portal , E-Invoicing
	Complaints	None
Procurement	RFx	None
	Catalogs	Ariba Catalogs
	Contracts	None
	Purchase Orders	Ariba Network , Supplier Portal
	Order Confirmation	Ariba Network , Supplier Portal
	ASN	Ariba Network , Supplier Portal
	Service Entry Sheet	Ariba Network , Supplier Portal
	Invoice	Ariba Network , Supplier Portal , E-Invoicing
TM	Freight Orders	Ocean	BluJay , Transwide, CASS
	Invoices	None	CASS , TMS/CHEMLOGIX
	Transport Event Update	BN4L , Project 44
Logistics	Inventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.)	3PL EDI Interfaces
	Inbound	None	Elemica
	Outbound	None	Elemica
	Goods Reciept	None	Elemica
Finance	Payment	Swift
GTS	Customs	Customs Brokers EDI Interfaces

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.

Area	Transaction	Primary EDI	Secondary EDI
Sales	Quotation	None
	Sales Contract	None
	Sales Order	Elemica	Esker
	Billing	Customer Portal	Elemica , Tungsten, E-Invoicing, ARKHINEO
	Complaints	None
Procurement	RFx	None
	Catalogs	Ariba Catalogs
	Contracts	None
	Purchase Orders	Ariba Network	Elemica
	Order Confirmation	Ariba Network	Elemica
	ASN	Ariba Network	Elemica
	Service Entry Sheet	Ariba Network	Elemica
	Invoice	Ariba Network	Fedex , ProMaster , Synchro , Xerox , Ariba Network , E-Invoicing , Citibank , OpenText
TM	Freight Orders	None	BluJay , Transwide, CASS
	Invoices	None	CASS , TMS/CHEMLOGIX
	Truck Weight Update	None	Weighbridge Systems: Selfy Weighbridge, LAS, Weightbridge - Tecsidel, APAC Weighbridge Systems, Qbit Portaria
	Transport Event Update (via SAP BNL)	None	Selfy, Simba, Project 44, FDTMS
Logistics	Inventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.)	3PL Template Interfaces	Arcese, Katoen Natie, Sunland Infor, Kenco, Mitsui Soko, PML CN, DHL CN
	Inbound	None	Elemica
	Outbound	None	Elemica
	Goods Reciept	None	Elemica
Finance	Payment	Swift	Swift , Bank Portals
GTS	Customs	None	Seeburger , COMEX , Jet etc..

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

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

The recommended EDI approach does not introduce large, unplanned investments.

Most activities (Supplier Portal, 3PL interfaces, BN4L integrations, Customs Broker) are already part of the SyWay scope and are aligned with existing delivery plans.

By limiting the number of EDI platforms and defining clear Primary EDIs, the approach avoids future incremental EDI costs driven by ad-hoc partner requests.

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

Limited bank coverage
New implementation effort
No strong added value over current setup

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)

Option	Description	Pros	Cons	Evaluation
Option 1	Commerce Portal for all customers	Single, standardized channel for all customers Scalable and aligned with SyWay digital strategy Reduced dependency on multiple legacy EDIs Better visibility and self-service capabilities	Requires customer change and onboarding effort Not all strategic customers are willing to migrate Risk of commercial impact if migration is forced	Not suitable as single approach
Option 2	Legacy EDIs as primary	No disruption for existing customers Stable and already integrated for some strategic accounts	Multiple EDIs increase complexity and support effort Not scalable for onboarding new customers Not aligned with long-term SyWay architecture	Not aligned with strategy
Option 3	Portal as default, legacy EDIs by exception	Clear default channel for new customers Protects strategic customers who cannot migrate Limits growth of legacy EDIs Balances standardization with business reality	Requires governance to control exceptions Dual model must be clearly communicated	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 (Source to Pay)

Following are the options for Purchase Order, Invoices

Option 1: Ariba Business Network as Primary EDI for all suppliers

Option 2: Supplier Portal as Primary EDI for all Suppliers

Option 3: Supplier Portal as default, Ariba for selected suppliers (Recommended)

Option	Description	Pros	Cons	Evaluation
Option 1	Ariba Business Network as Primary EDI for all suppliers	Strong automation for high-volume suppliers Mature and proven SAP solution Supports straight-through processing	Heavy onboarding effort for small and medium suppliers Supplier resistance based on past experience High operational effort for procurement teams	Not suitable for all suppliers
Option 2	Supplier Portal for all suppliers	Lightweight and easy to onboard Usable by all suppliers Low change impact and fast adoption	Limited automation for very high-volume suppliers Not optimal for M2M integration scenarios	Not sufficient alone
Option 3	Supplier Portal default, Ariba for selected suppliers	Flexible model based on supplier maturity Reduces onboarding friction Leverages Ariba where it adds real value Supports long-tail suppliers effectively	Requires clear supplier segmentation rules Two primary channels must be governed	Recommended

Conclusion

Supplier Portal is Primary by default
Ariba Business Network is Primary for selected suppliers

Logistics – 3PL (Warehouse Execution)

Following are the options for 3PL integrations

Option 1 – Integrate all 3PL warehouses

Option 2 – No integration for any 3PL

Option 3 – Integrated 3PL where justified, no integration otherwise

Option	Description	Pros	Cons	Evaluation
Option 1	Integrate all 3PL warehouses	Full visibility and automation Reduced manual effort and errors Standardized execution across sites	Not justified for low-volume or temporary warehouses Higher upfront integration cost	Not pragmatic
Option 2	No integration for any 3PL	No integration cost Simple short-term setup	Manual processes and delayed visibility Higher operational effort Not scalable	Not scalable
Option 3	Integrate where justified, no integration otherwise	Integration effort aligned with business value Supports strategic warehouses Avoids unnecessary cost Clear and pragmatic model	Requires decision per warehouse Needs governance to avoid inconsistency	Recommended

Conclusion

Two supported models: 3PL Integrated and No Integration

Transportation Management (TM)

Following are the options for Transportation Management tools

Option 1 – Keep multiple regional TM tools

Option 2 – Single global carrier collaboration platform (Recommended)

Option

Description

Pros

Cons

Evaluation

Option 1

Keep multiple regional tools

No immediate change in regions
Existing carrier adoption

Fragmented landscape
Higher support and integration effort
No global standard

Not aligned

Option 2

Single global TM platform

Transwide (Europe – transition)
BluJay / TMS4S (US & Canada – transition)

Simplified landscape
Global standard processes
Lower long-term support effort

Transition effort for some regions
Carrier onboarding required

Recommended

Conclusion

One global TM platform is confirmed as Primary

Mode of Transport	Primary EDI	Secondary EDI	Notes
Road	BN4L	Transwide (EU), BluJay / TMS4S (US & CA)	Transition to global standard
Ocean	BN4L	None	New global coverage
Air	BN4L	None	New global coverage

Finance (Bank Connectivity)

Option 1 – Move to SAP Multi-Bank Connectivity

Option 2 – Retain SWIFT Bureau (Recommended)

Option	Description	Pros	Cons	Evaluation
Option 1	SAP Multi-Bank Connectivity	SAP-native solution Potentially lower transaction costs	Limited bank coverage New implementation effort No strong added value over current setup	Not justified
Option 2	SWIFT Bureau	Stable solution Covers all banks Lower risk and cost Supports transition period	External dependency as it is a non-SAP solution	Recommended

Conclusion

SWIFT Bureau remains Primary

Global Trade Services (GTS)

Following are the options for Customs Broker Integration

Option 1 – Country-specific brokers and EDI designs

Option 2 – Regional broker harmonization with broker-specific EDIs

Option 3 – Regional brokers with broker-agnostic EDI design (Recommended)

Option	Description	Pros	Cons	Evaluation
Option 1	Country-specific brokers & EDIs	Local flexibility Minimal short-term change	High fragmentation Difficult to govern High future change cost	Not sustainable
Option 2	Regional brokers with broker-specific EDIs	Reduced number of brokers Some level of standardization	Broker dependency remains Redesign needed if broker changes	Limited flexibility
Option 3	Regional brokers with broker-agnostic EDIs	Supports broker harmonization strategy Flexible to future broker changes Reduced rework and dependency Clear regional governance	Slightly higher initial design effort	Recommended

Conclusion

Regional model confirmed with broker-agnostic EDI

Issue

Recommendation

Background & Context

Assumptions

Constraints

Impacts

Business Impact

IT / Integration Impact

Change Impact

Financial Impact

Business Rules

Options considered and Evaluation

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

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

Procurement (Source to Pay)

Logistics – 3PL (Warehouse Execution)

Transportation Management (TM)

Finance (Bank Connectivity)

Option 1 – Move to SAP Multi-Bank Connectivity

Option 2 – Retain SWIFT Bureau (Recommended)

Global Trade Services (GTS)

Option 1 – Country-specific brokers and EDI designs

Option 2 – Regional broker harmonization with broker-specific EDIs

Option 3 – Regional brokers with broker-agnostic EDI design (Recommended)

See also

Change log