Issue

There are certain countries or jurisdictions that mandate the use of e-invoicing methods and platforms to complete a legal purchase or sale - Syensqo has a legal obligation to create and exchange sales and procurement e-invoices in the global jurisdictions where this is mandated.

The e-invoice platforms from each governing body are usually different and require different attributes and documents to be passed or received in order to complete a successful e-invoice lifecycle. For example, responses are often required back from the governing body to confirm if they have been correctly submitted.

Goods cannot be sold in these jurisdictions and fines can be imposed if the mandatory communications are not fulfilled.

Recommendation

Use a common and standard 3rd party provider across all GBUs and relevant countries to manage the integration from S/4 into the government authority systems and portals for both inbound and outbound invoices (and other relevant documents). This will provide a solution that can be implemented globally in the shortest time whilst ensuring a robust, compliant, auditable and scalable solution for Syensqo in the long-term.

Background & Context

E-invoice exchanges with the regulatory authorities below are currently required or will be required in the next 2 years, when selling/buying goods and services to the countries below. An e-invoice is sent to the authority and often a message is sent back to confirm the approval. Approximate invoice quantities shown below:

The number of countries that require this reporting is expected to rise each year - for example, all EU countries will require e-Invoicing by 2030.

Even though there are similarities between the formats required they can differ substantially by each country. For example, Brazil has a different submission required depending upon the type of good or service sold.

Therefore Syensqo needs an efficient, robust and reliable method to send and receive the legally required sales and procurement invoice information. This should include all relevant document types such as invoice, credits & debits.

In Syensqo's existing systems the requirements for sales e-invoicing are fulfilled by using the various SAP adapters for each country - so each country (or group of countries) needs its own specific set up, testing and integration.

The requirements for Supplier Invoices are fulfilled by receiving the Invoices from the Government Portal into the Readsoft Invoice Process Director. Each Country or group of countries needs its own specific integration from the portal to the Process Director, its own mapping, set up and testing.

Assumptions

• Specific licence costs still need to be established with SAP and any 3rd party supplier - need to ensure future invoice volumes included in this estimation.
• SAP S/4HANA will be the ERP application that will enable the management and execution of the sales through to billing processes.
• SAP / 3rd party suppliers are responsible for keeping up the maintenance and compliance with the differing requirements of each country.
• How suppliers send invoices to the government portal and what data they send is not under Syensqo's control so we assume that this will be implemented on the suppliers side correctly.
• An investigation with any potential 3rd party providers would be required in order to confirm functionality offered - what's mentioned in this document is based on previous experience of implementing this process.

Constraints

• The e-reporting tools chosen to support statutory reporting for Finance is related as there is similar functionality required for government tax submission / reporting. This is treated in a separate KDD on Tax Determination and Tax Reporting in S/4HANA
• We have to have a solution that works for Sales Invoices going into a government portal from S/4HANA and one that works in reverse - going from the portal to S/4 Accounts Payable. Options that work best for inbound may not be the same as for outbound. 

Impacts

Implementation: The initial configuration and testing of the 3rd party solution may take a significant amount of technical resource and expertise. The intention would be to standardise the approach for all countries but there may be differences in how each is interfaced to the 3rd party software. (e.g. EU requirements through PEPPOL compared to LATAM).

Training and Change Management: Training will be required for the new ways of working with the integration with the new 3rd party software and S/4. The integration tools with S/4 have a different look and feel to existing ECC6 set up.

Security: Various front-end and back-end role settings need to be considered during the role building exercise.

Licensing: Additional licensing and therefore costs will be incurred for 3rd party software integration and usage.

Business Rules

None identified.

Options considered

Option A: Use the As-Is SAP approach with the addition of using the new SAP S/4 Document and Reporting Compliance tool set.

The automated DRC functionality can operate in 3 x different ways to cover differing country specific requirements:

1. Document and Reporting Compliance cloud service - exchanges an e-invoice in with selected governments in the format required via Peppol - e.g. Belgium, Poland, France. 
2. Document and Reporting Compliance via customer-managed BTP Integration Suite tenant - exchanges an e-invoice with selected governments in the format required. For example, Saudi Arabia, Chile & Peru. Additionally, file format and transmission provided via integration suite for the Chinese Golden Tax transactions. (version of this currently used in SAP ECC landscape)
3. Document and Reporting Compliance for Brazil  - exchanges an e-invoice with the Brazilian government in the format required using S/4 Nota Fiscal functionality. (a version of this used in Syensqo's SAP ECC landscape). This requires a separate license. 

Despite SAP using a single, simple-sounding "Document and Reporting Compliance" brand, several different integration architectures actually exist across the country scope. The table below summarises an analysis of the situation as of July 2024 based on SAP documentation: 

Even though this is the standard SAP S/4HANA solution there is significant complexity involved here:

• This is not a single process in S/4HANA. There are 2 x principal ways this functions - (1) via the DRC cloud service, and (2) via a Syensqo instance of BTP Integration Suite. The cloud option covers the newer country regulations that work with the Peppol framework - such as France, Belgium, Germany, Spain & Poland and in the future other EU countries. The Integration Suite option is required for countries not using Peppol, who typically have more complex requirements for document interchange with government APIs, including for documents other than invoices. 
• Ultimately SAP's solution is merely a thin interface adapter to the underlying government API. Significant configuration and testing is required to integrate to the government portals and APIs. This is particularly the case for the Integration Suite options where SAP merely provides code for the platform, but Syensqo remains responsible for the deployment, configuration, and testing of the integration with the government APIs. This is typically a substantial task as Syensqo must establish a direct connection with the API of each government, must execute large and complex test scripts, and must perform potentially complex value mappings. 
• On-going maintenance is required in both models - whereby new legislature or tax rules will require additional set up and testing. Experience has shown that this can be very time consuming and often cumbersome in SAP, requiring constant application of SAP Notes to ensure compliance. There is also no committed timeline for SAP to update its code to comply with changing government requirements. 

The most likely architecture which maximises the use of SAP DRC is depicted below. Each country using the customer-managed BTP Integration Suite tenant would have its own AIF content in S/4HANA to create country-specific XML documents, a dedicated ABAP Proxy, and BTP Integration Suite content specific to each country. All of this would be the responsibility of Syensqo to setup, manage and maintain. 

Option B: Automate with 3rd party solution

Sales Invoices

This option would be to integrate a 3rd party provider software into S/4HANA in order to automate the exchange of sales invoice documents - examples of this would be solution by EDICOM or SOVOS. In this case, the 3rd party provider would integrate their software into Syensqo S/4HANA systems to then be able to submit and receive back the relevant document and information directly to the relevant country authorities. The third-party provider would abstract away the details of the government system APIs, and any special local requirements (e.g. use of Golden Tax in China), and provide a consistent interface for the exchange of sales invoices with Syensqo. 

Supplier Invoices

In addition to transmission of documents, any invoices coming in from a government portal or API will need to be mapped to an SAP standard format. A 3rd party "agency" provider would automate receipt of supplier invoices from the government channels, perform the necessary technical validations (e.g. of signing certificates), then and map these to an agreed document format for processing into SAP S/4HANA. As the integration on the S/4HANA side would be custom-built, this allows for the use of advanced Accounts Payable processes such as three-way-matching of invoices against purchase orders, outline agreements, service entry sheets, goods receipts, etc. via for example Vendor Invoice Management.  

An example of how an architecture with a fully-fledged third-party specialist solution could work is below: 

Even though this solution would be provided by a 3rd party, there exist proven and complete solutions by specialist providers with deep experience in this space. The exact provider to be used would be chosen via a competitive process during the Detailed Design phase of the program. However based on prior experience there exist solutions which provide richer functionality than a mere communication adapter to the government API, but also provide:

• Format conversion from SAP-native or abstracted document formats into the formats required by the government APIs
• Pre-submission validation against validation rules published by the government
• Ability to act as a government-certified filing agent on behalf of Syensqo, so that Syensqo need not establish direct, individual relationships with each government, nor executed detailed validation testing with the government. 
• Handle validation of electronic signatures, and other "security handshake" steps of the security protocol. 
• A service which closely tracks the evolution of regulatory and technical changes on the side of the government APIs, and isolates Syensqo from them as far as possible. 

This would considerably reduce the Syensqo technical overhead for system implementation and maintenance.

Option C: Manual download / upload process from S/4HANA into government portal

Sales Invoices

This option would require manually downloading the sales invoice from S/4 in the correct format and then manually uploading this document into the relevant government authority portal.

Supplier Invoices

Retrieving Invoice data sent into the government portal from suppliers in a human readable format and then manually keying into S/4 is not practical for Supplier Invoices. So this solution does not work for this process.

Option D: Use Ariba Network (SAP Business Network) to receive the invoice data from the Government Portal, map and transmit to S/4HANA

Sales Invoices

As the Ariba Network is for suppliers to send invoices to a customer, it is not a viable solution for Sales Invoices.

Supplier Invoices

This would be an out-of-the-box solution as it would rely on Ariba producing country specific connectors between a countries portal and the Ariba network that can then be used by any Ariba Network users in that country. It would also rely on Ariba providing the coverage necessary as well as the ongoing updates and expansions,

If possible this would allow Syensqo to leverage the investment made in onboarding its suppliers onto the network and  also act as a portal for suppliers who use the Network to view invoice statuses. So where an invoice has an issue they can see that issue in Ariba Network and are not reliant on Accounts Payable contacting them to alert them to the issue. 

There are not currently any live Ariba connectors for any government portal and we do not have a confirmed roadmap and timeline for this.

See also

• Associated KDD on Tax Determination and Tax Reporting in S/4 HANA
• SAP Help documentation on E-Invoicing patterns supported by S/4HANA

Change log

Workflow history