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

The below table is the recommendation of the Primary and Secondary EDI platforms for each business process based on the outcomes of the SyWay Detailed Design. These recommendations align with

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

These EDI positions described serve as the guidelines for Sales, Procurement, Logistics, Transportation Management, Finance, and Global Trade Services. They replace the indicative EDI assignments previously documented and provide clarity for SyWay implementation and partner onboarding.

Any future change to the EDI directions defined in the tables will be subject to a formal change request and governance process, to ensure that deviations are assessed, approved, and documented in a controlled manner.

Area	Transaction	Primary EDI	Secondary EDI
Sales	Quotation	None
	Sales Contract	None
	Sales Order	Commerce Portal	Elemica , Esker
	Billing	Commerce Portal , E-Invoicing (EDICOM)
	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 (EDICOM)
TM	Freight Collaboration (Carrier Confirmation, Slot Booking, Spot tendering)	BN4L	TMS4S
	Yard Management (Check-in / Checkout)	Selfy	Simba/Focusol
	Invoices	BN4L	CASS
	Track and Track (Transportation Event Updates) - Ocean	BN4L GTT + P44
	Track and Track (Transportation Event Updates) - Road, Rail, Air	BN4L	TMS4S
Logistics	Inventory Management (Inc. Goods Receipt, Stock Transfer, Goods Issue, Stock on Hand etc.)	3PL EDI Interfaces
	Inbound	None
	Outbound	None	Elemica
	Goods Receipt	None
Finance	Payment	Swift
GTS	Customs	Customs Brokers Interfaces Per Region

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.

Below table is the list of all the EDI assignments from KDD066 - The highlighted ones are evaluated in this KDD.

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

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 as Primary EDI 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 as Primary EDI 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 (EDICOM) 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
The determination of the supplier’s channel (Supplier Portal vs. Ariba Business Network) will be made at the time of supplier onboarding.
Once assigned, the communication channel will remain fixed for the duration of the supplier lifecycle, unless a formal change is requested by the supplier

Logistics – 3PL (Warehouse Execution)

Following are the options for 3PL integrations

Option 1 – Integrate all 3PL warehouses (3PL Specific Integration)

Option 2 – As-Is Integration with existing 3PL's and No integration for other 3PL (3PL Specific Integration)

Option 3 – Integrate where justified, no integration otherwise (Standardize modernised the integration via API)

Option	Description	Pros	Cons	Evaluation
Option 1	Integrate all 3PL warehouses (3PL Specific Integration)	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 scalable	Not pragmatic
Option 2	As-Is Integration with existing 3PL's and No integration for other 3PL (3PL Specific Integration)	Comparatively lower integration cost Quick set-up	Varied processes and delayed visibility Higher operational effort Not scalable	Not scalable
Option 3	Integrate where justified, no integration otherwise (Standardize and modernised the integration via API)	Integration effort aligned with business value Supports strategic warehouses Avoids unnecessary cost Clear and pragmatic model Scalable - Change of warehouses is possible in future	Requires decision per warehouse Needs governance to avoid inconsistency	Recommended

Conclusion

Integrate where justified, no integration otherwise (Standardize and modernised the integration via API)

Transportation Management (TM)

Following are the options for Transportation Management tools

Option 1 – Keep multiple regional TM tools (As-Is)

Option 2 – Global carrier collaboration platform (with US as exception)

Option

Description

Pros

Cons

Evaluation

Option 1

Keep multiple regional TM tools (As-Is)

No immediate change in regions
Existing carrier adoption

Fragmented landscape
Higher support and integration effort
No global standard

Not aligned

Option 2

Global carrier collaboration platform (with US as exception)

BN4L
TMS4S / CASS (Road and Rail) for US and Canada

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	TMS4S/CASS (US & CA)	Transition to global standard
Rail	BN4L	None	New Global Coverage
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

Financial Impact

Business Rules

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

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

Procurement (Source to Pay)

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