Relevant for SAP S/4HANA Cloud, public edition release 2308
The objective of this blog is to provide an introduction and a starting point to the topic of electronic invoicing in SAP S/4HANA Cloud public edition. This blog explains some of the general concepts of electronic invoicing such as the apps that are involved in the S4 system. It also covers a typical system architecture to send electronic invoices to local tax authorities via middleware. The focus of this blog is on processing invoices for example as part of a professional service scenario. Delivery notes are out of scope for this blog.
This blog is concerned with electronic invoices to fulfil local legal requirements. For example, business with public authorities in Germany is required to be invoiced via the electronic invoicing system PEPPOL. In India, it is a legal requirement to issue invoices electronically when a certain invoice amount is reached. Exchanging electronic invoices with customers where this is not a local legal requirement is not covered in this blog. Likewise, the use of invoice management solutions such as SAP Ariba is not covered here.
The topic of electronic invoices that is covered by this blog sits within the framework Document and Reporting Compliance. Hence, searching or filtering for this term on the SAP Help Portal and in SAP notes, may be helpful when looking for information. For example, the country page for Germany of SAP S/4HANA Cloud public edition includes a section on Document and Reporting Compliance. Similar pages are available for other countries as well.
In the SAP S/4HANA Cloud public edition system, there are two main apps to work with electronic documents as a business user. These are the apps Manage Electronic Documents and eDocument Cockpit. The app Manage Electronic Documents utilizes the SAP Fiori design and features the latest innovations. You can learn more about the apps here:
The app eDocument Cockpit is an SAP GUI app. Please note that for some countries such as Mexico only the app eDocument Cockpit can be used for the moment.
After the setup is complete, a typical process of submitting an electronic invoice works as follows. The user prepares the billing document as usual and posts it to accounting. After the document is posted to accounting, the system automatically creates an electronic document in the background. To send this document to the authorities, the user navigates to the app Manage Electronic Documents or eDocument Cockpit. There, they locate the billing document they processed. After that they submit the document to the authorities. For some countries, functionality is also available to automatically submit electronic documents that were created by system to eliminate the manual step of submission. In India, this can be achieved with a configuration activity. In Mexico, a batch job is available that automatically submits electronic documents.
A typical system architecture to create and submit electronic documents involves middleware between the SAP S/4HANA Cloud public edition system and the tax authorities. The data of the electronic invoice is sent from the SAP S/4HANA Cloud public edition system to the middleware. The middleware validates the electronic invoice and it handles the communication with the recipients such as the tax authorities. This integration can involve the SAP Business Technology Platform and the SAP Integration Suite. Pre-build integration packages (integration flows) are available for many eDocument services. One example of such a solution is the SAP product SAP Document and Reporting Compliance, Cloud Edition which covers a wide range of business scenarios in multiple countries. The full list of supported scenarios can be found here: Supported Business Scenarios. The following graphic shows an exemplary system flow for Germany.
Due to this setup, issues regarding the submission of eDocuments can have two major root causes. Either the integration is failing or the content of the document is not compliant with the local rules. For this reason, the app eDocument cockpit has two separate logs: the application log and the interface log. In the interface log, the integration-related issues about connecting to the eDocument service can be found. The application log shows issues relating to the content of the eDocument file.
The specifics to connect a third-party provider's system depend on the chosen business solution. Typically, it is required to activate a communication arrangement in the SAP S/4HANA Cloud public edition system. Separately, an integration flow needs to be installed, configured, and deployed in the SAP Cloud Platform Integration tenant running on Business Technology Platform. Please note that the integration setup needs to be done separately for test instances and production instances. Typically, third-party providers offer a testing endpoint and a separate production endpoint.
The required steps to set up electronic documents after the integration setup is completed can be separated in three categories. These are configuration adjustments, maintaining value mappings, and maintaining the necessary master data. However, before starting with either of the three steps please make sure that the scope item 5XU SAP Document and Reporting Compliance is activated in your system. After that, please activate the features by searching for the configuration activity Activate Document and Reporting Compliance Features in your configuration environment (Central Business Configuration, CBC or Solution Builder). This step is also documented here: Activating Document and Reporting Compliance Features.
After the features of document and reporting compliance are successfully activated, the configuration changes can be started. The specific configuration depends on the country that you are implementing. Some country examples are explained further down in the blog. Please note that configuration is sometimes split into configuration activities that are generally applicable for eDocuments globally and configuration activities that are country-specific. This can be seen below:
A complete implementation will require maintenance of configuration both in the general section and in the country-specific section. Most configuration entries regarding eDocuments will be transported. However, there may be some configuration activities for specific countries where configuration is marked as a redo configuration for downstream systems such as the productive system or the test system.
After maintaining the required configuration, the second fundamental concept of eDocuments are value mappings. In general, value mappings are tables that contain the mapping of internal SAP S/4HANA Cloud public edition values to the external values that need to be used for the third-party provider or the tax authority. For example, the value mapping INVOICE_TYPE_CODE_SD in the namespace /EDUBL maps the internal SAP document types to the external values to be used for PEPPOL in Germany:
Value mappings are maintained with the app Configure Value Mapping. They are not transported but need to be maintained separately in all systems such as the test tenant and the production tenant. To simplify finding the right table, value mappings are structured in a namespace and the specific value mapping name. First, choose the right namespace that corresponds with the desired country. Second, find the right table within a namespace. Which value mappings are required depends on the specific eDocument scope and the countries that are implemented. For some value mappings, SAP provides sample documentation that can be found on the country page on help.sap.com.
Most eDocument implementations require additional master data attributes that need to be maintained on product master data and business partner master data. To use PEPPOL in Germany, a Leitweg ID is required that is maintained on the identification tab of the business partner. In addition, a product classification code such as the HSN code in India may be required that needs to be maintained on the product master for your specific country. More details will be described in the country-specific sections below.
The following sections explain an extract of the required configuration, value mapping, and master data maintenance for eDocument implementations in Germany, Mexico, and India. The three countries provide exemplary cases for how eDocuments can work slightly different depending on the local regulation. Please note that the configuration values and the value mappings contained in the screenshots below are exemplary values. Make sure to adjust these values given your requirements such as organizational structure, the sold products, and the applicable processes.
In Germany, the SAP solution SAP Document and Reporting Compliance, Cloud Edition can be used as an eDocument service. Hence, it is typically not required here to involve a third-party solution. The initial setup of this solution is done on SAP Business Technology Platform. A setup booster is available that guides through the steps of the initial setup. The steps to activate the service are also documented here: Initial Setup. The steps to integrate the service with an SAP S/4HANA Cloud public edition system are document here: Integrating PEPPOL Exchange with SAP S/4HANA Cloud
After the integration setup is complete, the implementation process can continue with maintaining the required configuration. As introduced before, it is necessary to maintain configuration in the General settings for eDocuments section and in the section with configuration specific to PEPPOL.
One-by-one, navigate through the following configuration activities to maintain the required values. The SAP standard company code ID for Germany is 1010. For this reason, the company code IDs in the following screenshots sometimes show 1010.
One-by-one, navigate through the following configuration activities to maintain the required values.
Navigate to the configuration activity Edit tax information for company codes (ID: 105675) within the Tax group. This step is also documented here: Maintaining VAT Number for Company Code (Mandatory).
Navigate to the configuration activity Maintain additional parameters (ID: 102739). This steps is also documented here: Maintaining Tax Number (non-VAT) for Company Code (Mandatory)
As described in the first section of this blog, value mappings are used by the system to map the internal values from the SAP S/4HANA Cloud public edition system to the external values that are used by the PEPPOL framework. There is an overview available about the required value mappings here: Configuring Value Mappings. The purpose of each value mapping is documented on help.sap.com as well. The respective page can be accessed via the links below.
It is required to maintain two identification numbers on the customer master record. These are the Leitweg ID and the VAT number of the customer. The Leitweg ID is specific to the PEPPOL process. The VAT number is also required for the correct determination of tax rates in Germany and within the European Union. The following two links explain how to maintain the identification numbers on the customer master record.
To process eDocuments in Mexico, typically customers partner with a third-party provider. The electronic documents are then sent from the SAP S/4HANA Cloud public edition system to the third-party and the third-party is passing them on to the tax authorities. SAP offers out-of-the-box integrations for the third-party providers Pegaso and Edicom. This third party-provider in Mexico is also called PAC. The tax authorities are referred to as SAT. The system for electronic documents in Mexico is called CFDI. Functions of electronic documents in Mexico that are covered in this blog are the eInvoice, and the ePayment. There also exist the electronic delivery note and the electronic withholding tax certificate. The following graphic shows an exemplary system flow for Mexico.
After the integration setup with the chosen PAC is complete, the configuration changes can be started.
One-by-one, navigate through the following configuration activities to maintain the required values. The SAP standard company code ID for Mexico is 5510. For this reason, the company code IDs in the following screenshots sometimes show 5510. The configuration steps for eInvoices are also documented here: Configuration Options for Key Users: Electronic Customer Invoices and the configuration steps for ePayments are documented here: Configuration Options for Key Users: Electronic Payment Receipt Complements
Please adjust the active from date according to your business needs for the interface versions. The active from date in this configuration is a method to control the version of the CFDI framework that is used. For example, in March 2022 a new version was introduced for eInvoices in Mexico. This was CFDI version 4. With the active from date in this configuration activity, it is possible to define clear cut-off dates when which version is used by the system to generate eDocuments.
The required default configuration in this section should already be shipped with the scope activation. This includes number ranges and ODN prefixes.
Most settings for Mexican eDocuments are steered via value mappings. All value mapping tables are contained in the namespace /EDOMX. A list of value mappings with their explanation is available here: List of Value Mappings for Electronic Documents
Please note that a catch-all value mapping can also be maintained. It is possible to leave the column for the internal value in S4 blank and only maintain an external value. In this case, the system will pass on the external value when there is no value maintained in S4. For example, such a catch-all value mapping can be used in CFDI_PAYMNT_MEANS to default the external value that is passed to the eDocument whenever the payment method is not specified on the sales document. This can be useful since the field forma de pago field is mandatory in the eDocument but the payment method field may not always be filled on the sales document as part of your processes.
The customer master data is required to have the tax number MX1 “Mexico: RFC Number” maintained. Each customer is also required to be maintained in a value mapping to assign the valid tax regime to the customer. On the product master data side no direct enhancements are required. However, the product code for each product needs to be maintained as a value mapping. Alternatively, such product code determination can also be set up to be determined from a product hierarchy. As described above, it is also possible to work with catch-all values in the value mapping.
The RFC number of the company code i.e., of your organization is required to be maintained in configuration activity Maintain Additional parameters in the parameter type MX_RFC. Further, the parameter CFDINA must be set with the parameter value X and the parameter CFDITR must be set with the applicable tax regime for your organization e.g., 601. Please also make sure that the organizational name of your company code and sales organization are exactly aligned with your company name that is registered with the authorities under the RFC number.
To successfully process ePayments, it can be required to maintain additional exchange rates in the system. The central bank of Mexico is publishing official exchange rates for currency pair combinations such as US Dollar to Mexican Peso and European Euro to Mexican Peso. Depending on the invoicing currencies and payment currencies that are used, it may be necessary to maintain the daily valid exchange rates published by the central bank in the SAP S/4HANA Cloud public edition system. Such currencies can be fetched via API and via external providers. To separate the exchange rates maintained for electronic documents from other exchange rates used for group consolidation, it is possible to create a separate exchange rate type for Mexico. The required configuration for such a new exchange rate type is described here: Currency Conversion with Prescribed Exchange Rates | SAP Blogs
To issue compliant eInvoices and ePayments it can be necessary to implement custom logic as well. For example, custom logic can be used to fill the Addenda field in the eDocument XML file. This can be done with the custom logic EDOC_MX_FILL_CUSTOM_DATA_V4. One requirement can be to fill the addenda field with the address information of the customer. Please note that with a three-system landscape, it is possible to debug custom logic in the ABAP Development Tools (ADT) environment. This is explained in this blog: Debugging custom logic using ADT in SAP S/4Hana Cloud | SAP Blogs
To obtain the address information of the customer a SELECT statement can be used with the CDS view I_BillingDocument to retrieve the sold-to party. The CDS view I_Customer can then be used to retrieve the address details. Typically, the PAC requires the address data to be structured in a specific way in the addenda tag to correctly read the data. The PAC will be able to provide the information how the Addenda field needs to be structured. In the custom logic implementation the ABAP method CONCATENATE can be used to combine multiple strings into one variable that is then passed onto the addenda tag.
A second use case of custom logic concerns setting the field forma pago in the ePayment XML file. In standard, this field is filled from the payment method that is passed on the with the journal entry of the payment. The custom logic EDOC_MX_FILL_PAYMENT_METHOD can be used to define more complex logic for the field or to default the field in the XML file to a catch-all value.
At this point, a few good-to-know topics are called out when practically working with electronic documents in Mexico. First, there may be a requirement to send a PDF of the electronic invoice to customers. In Mexico, the SAP S/4HANA Cloud public edition is creating a separate PDF for the electronic invoice in addition to the regularly created PDF file of the billing document. This PDF of the electronic invoice can be downloaded from the eDocument cockpit by navigating to Display -> Display PDF. To generate this PDF, the system is using a special form template. The standard form template can also be adjusted and uploaded through the app Maintain Form Templates. There is a separate configuration activity available Specify Output Forms for PDF Generation (ID: 103727) where the form template for eDocuments is defined.
Second, invoices are required to be submitted as an electronic document within 24 hours of their posting. Hence, the submission of an eInvoice in the eDocument cockpit should be done promptly after the invoice was posted to accounting.
Third, there are a few specialties around the cancellation of invoices in Mexico. The process depends on how fast after creation an invoice was cancelled. The full process and its variants is documented here: Cancellation of Electronic Invoices
To process eDocuments in India, typically a third-party provider is required as well. The electronic documents are then sent from the SAP S/4HANA Cloud public edition system to the third-party and the third-party is passing them on to the tax authorities. For example, SAP offers out-of-the-box integrations for the third-party provider Excellon. The tax authorities in India are referred to as GST. There also is a government portal where submitted documents can be reviewed.
Functions of electronic documents in India that are covered in this blog are the eInvoice. When an eInvoice is successfully submitted to the tax authorities, an IRN number is issued by the authorities. This number is typically required to be printed on the PDF document of the invoice that is sent to the customer. Further, the PDF document typically requires that a QR code is included that also holds the elnvoice information.
To set up electronic invoices in India most of the required steps take place in configuration activities. Like the implementations for Germany and Mexico described above it is necessary to maintain configuration in general configuration activities and in country-specific configuration activities.
The SAP standard company code ID for India is 1810. For this reason, the company code IDs in the following screenshots sometimes show 1810. The configuration steps are also summarized here: Configuration Options for Key Users
When maintaining configuration, please check that the localized or country-dependent configuration activity is used. For regular invoices, the eInvoice is created from the journal entry. Hence, the journal entries used for invoice postings need to be maintained in the configuration activity Assign eDocument Type to Accounting Document Type for eInvoice.
In India, plant and company code are be combined to an organization unit. This is done with the configuration activities Maintain Organization Unit and Assign Company Code and Plant to Organization Unit. The object of an organizational unit can then be used to check authorizations of a user.
Two other important configurations that are not part of the eDocument configuration group are the configuration activity Assign Tax Code to Company Codes and Classify Condition Types for Goods and Services Tax for India in the area Finance -> General settings. In this configuration activity the condition types used in the pricing procedure are required to be mapped to the Indian condition name. This step is also documented here: Pricing Procedure/GL Accounts
No value mappings are required through the app Configure Value Mapping. They are already maintained in the configuration activities.
A key requirement for electronic invoices in India is that the PDF document of the invoice includes information from the eInvoice such as the IRN number and the QR code. Unlike in Mexico, there is no separate PDF document created in the eDocument cockpit as part of the eInvoice submission. Instead, the eDocument details are printed on the regular invoice output that is available directly from the billing document.
However, to make sure that the details from the eInvoice such as the IRN number are printed on the output item it is necessary that the output item is only finalized after the eInvoice was submitted successfully via the eDocument cockpit. For this reason, it is typically necessary to adjust the output parameter determination for the Indian sales organization such that the output is not dispatched immediately but on a scheduled base. This change can be made in the app output parameter determination. By selecting the rule set for Billing Documents and the determination steps Output Type, a rule can be created to set the output dispatch time to scheduled when the sales organization is equal to the Indian sales organization.
After the output parameter determination is adjusted the process steps to create and send out invoices in India are as follows:
Following these steps ensures that the PDF document contains the QR code and the IRN number.
There are a few requirements for material master data and business partner master data. For business partners they are document here: Business Partner Master Data
For products they are documented here: Material Master Data
There is a wide range of information sources available on electronic documents overall and more specifically on electronic invoices. Separately, country-specific information is also available. In general, it makes sense to review the country-specific content on the SAP Help Portal first when starting the implementation of eDocuments in a new country. Second, the overview SAP notes and troubleshooting SAP notes can be reviewed.
I found the following information helpful when I implemented electronic documents before:
To analyze errors for specific eDocuments, it makes sense to review the application log in the app eDocument cockpit first. The same log information is also available in the Fiori app Manage Electronic Documents. If the issue relates to the integration the application log will point to the interface log where a more detailed error description is available. Sometimes this error message will also point to the log files on SAP Cloud Platform Integration if the integration flow to send documents to a third-party provider failed entirely. In a business as usual environment, most submission errors of eDocuments will relate to missing value mappings.
An electronic invoice can best be analyzed by using the XML file that is sent to the third party. This file can be downloaded from the eDocument cockpit. The recommended way to download the right file is to navigate via the History button and to select the latest document with the status SENT or SENDEDOC for the download. This is because the third-party provider returns a response XML file to the SAP S/4HANA Cloud public edition system. If the user just clicks on download XML directly, the system will download the response file and not the file that was sent. Inspecting the XML file allows to understand the error message returned by the application log. As a result, a missing value mapping can be added, or some additional master data maintained. After that, the document can be submitted again in the eDocument cockpit or in the app Manage Electronic Documents.
With this blog, a high level introduction is provided to the topic of electronic invoices. I want to thank Katalin Csengodi and Omar El Hajami for their contributions. Electronic invoices are typically sent from the SAP S/4HANA Cloud public edition system to an eDocument service and then passed on to the tax authorities. To practically work with electronic documents, two apps are important to submit the documents, review responses, and analyze errors. These are Manage Electronic Documents and the eDocument cockpit. Setting up electronic invoices requires integration setup as well as configuration changes, the maintenance of value mappings, and the maintenance of additional master data. If you are working with electronic documents, feel free to share your tips and tricks in the comments.
Introduction & Scope of this blog
The objective of this blog is to provide an introduction and a starting point to the topic of electronic invoicing in SAP S/4HANA Cloud public edition. This blog explains some of the general concepts of electronic invoicing such as the apps that are involved in the S4 system. It also covers a typical system architecture to send electronic invoices to local tax authorities via middleware. The focus of this blog is on processing invoices for example as part of a professional service scenario. Delivery notes are out of scope for this blog.
This blog is concerned with electronic invoices to fulfil local legal requirements. For example, business with public authorities in Germany is required to be invoiced via the electronic invoicing system PEPPOL. In India, it is a legal requirement to issue invoices electronically when a certain invoice amount is reached. Exchanging electronic invoices with customers where this is not a local legal requirement is not covered in this blog. Likewise, the use of invoice management solutions such as SAP Ariba is not covered here.
General concepts for the setup of electronic invoices
The topic of electronic invoices that is covered by this blog sits within the framework Document and Reporting Compliance. Hence, searching or filtering for this term on the SAP Help Portal and in SAP notes, may be helpful when looking for information. For example, the country page for Germany of SAP S/4HANA Cloud public edition includes a section on Document and Reporting Compliance. Similar pages are available for other countries as well.
In the SAP S/4HANA Cloud public edition system, there are two main apps to work with electronic documents as a business user. These are the apps Manage Electronic Documents and eDocument Cockpit. The app Manage Electronic Documents utilizes the SAP Fiori design and features the latest innovations. You can learn more about the apps here:
- A Walkthrough of SAP Document and Reporting Compliance App: Manage Electronic Documents | SAP Blogs
- From eDocument Cockpit to Manage Electronic Documents: Better user experience, more powerful feature...
The app eDocument Cockpit is an SAP GUI app. Please note that for some countries such as Mexico only the app eDocument Cockpit can be used for the moment.
After the setup is complete, a typical process of submitting an electronic invoice works as follows. The user prepares the billing document as usual and posts it to accounting. After the document is posted to accounting, the system automatically creates an electronic document in the background. To send this document to the authorities, the user navigates to the app Manage Electronic Documents or eDocument Cockpit. There, they locate the billing document they processed. After that they submit the document to the authorities. For some countries, functionality is also available to automatically submit electronic documents that were created by system to eliminate the manual step of submission. In India, this can be achieved with a configuration activity. In Mexico, a batch job is available that automatically submits electronic documents.
Integration setup
A typical system architecture to create and submit electronic documents involves middleware between the SAP S/4HANA Cloud public edition system and the tax authorities. The data of the electronic invoice is sent from the SAP S/4HANA Cloud public edition system to the middleware. The middleware validates the electronic invoice and it handles the communication with the recipients such as the tax authorities. This integration can involve the SAP Business Technology Platform and the SAP Integration Suite. Pre-build integration packages (integration flows) are available for many eDocument services. One example of such a solution is the SAP product SAP Document and Reporting Compliance, Cloud Edition which covers a wide range of business scenarios in multiple countries. The full list of supported scenarios can be found here: Supported Business Scenarios. The following graphic shows an exemplary system flow for Germany.
Due to this setup, issues regarding the submission of eDocuments can have two major root causes. Either the integration is failing or the content of the document is not compliant with the local rules. For this reason, the app eDocument cockpit has two separate logs: the application log and the interface log. In the interface log, the integration-related issues about connecting to the eDocument service can be found. The application log shows issues relating to the content of the eDocument file.
The specifics to connect a third-party provider's system depend on the chosen business solution. Typically, it is required to activate a communication arrangement in the SAP S/4HANA Cloud public edition system. Separately, an integration flow needs to be installed, configured, and deployed in the SAP Cloud Platform Integration tenant running on Business Technology Platform. Please note that the integration setup needs to be done separately for test instances and production instances. Typically, third-party providers offer a testing endpoint and a separate production endpoint.
Implementation steps in SAP S/4HANA Cloud, public edition
The required steps to set up electronic documents after the integration setup is completed can be separated in three categories. These are configuration adjustments, maintaining value mappings, and maintaining the necessary master data. However, before starting with either of the three steps please make sure that the scope item 5XU SAP Document and Reporting Compliance is activated in your system. After that, please activate the features by searching for the configuration activity Activate Document and Reporting Compliance Features in your configuration environment (Central Business Configuration, CBC or Solution Builder). This step is also documented here: Activating Document and Reporting Compliance Features.
Making changes in configuration activities
After the features of document and reporting compliance are successfully activated, the configuration changes can be started. The specific configuration depends on the country that you are implementing. Some country examples are explained further down in the blog. Please note that configuration is sometimes split into configuration activities that are generally applicable for eDocuments globally and configuration activities that are country-specific. This can be seen below:
A complete implementation will require maintenance of configuration both in the general section and in the country-specific section. Most configuration entries regarding eDocuments will be transported. However, there may be some configuration activities for specific countries where configuration is marked as a redo configuration for downstream systems such as the productive system or the test system.
Maintaining value mappings
After maintaining the required configuration, the second fundamental concept of eDocuments are value mappings. In general, value mappings are tables that contain the mapping of internal SAP S/4HANA Cloud public edition values to the external values that need to be used for the third-party provider or the tax authority. For example, the value mapping INVOICE_TYPE_CODE_SD in the namespace /EDUBL maps the internal SAP document types to the external values to be used for PEPPOL in Germany:
Value mappings are maintained with the app Configure Value Mapping. They are not transported but need to be maintained separately in all systems such as the test tenant and the production tenant. To simplify finding the right table, value mappings are structured in a namespace and the specific value mapping name. First, choose the right namespace that corresponds with the desired country. Second, find the right table within a namespace. Which value mappings are required depends on the specific eDocument scope and the countries that are implemented. For some value mappings, SAP provides sample documentation that can be found on the country page on help.sap.com.
Maintaining required master data
Most eDocument implementations require additional master data attributes that need to be maintained on product master data and business partner master data. To use PEPPOL in Germany, a Leitweg ID is required that is maintained on the identification tab of the business partner. In addition, a product classification code such as the HSN code in India may be required that needs to be maintained on the product master for your specific country. More details will be described in the country-specific sections below.
Country-specific implementation steps
The following sections explain an extract of the required configuration, value mapping, and master data maintenance for eDocument implementations in Germany, Mexico, and India. The three countries provide exemplary cases for how eDocuments can work slightly different depending on the local regulation. Please note that the configuration values and the value mappings contained in the screenshots below are exemplary values. Make sure to adjust these values given your requirements such as organizational structure, the sold products, and the applicable processes.
Germany
In Germany, the SAP solution SAP Document and Reporting Compliance, Cloud Edition can be used as an eDocument service. Hence, it is typically not required here to involve a third-party solution. The initial setup of this solution is done on SAP Business Technology Platform. A setup booster is available that guides through the steps of the initial setup. The steps to activate the service are also documented here: Initial Setup. The steps to integrate the service with an SAP S/4HANA Cloud public edition system are document here: Integrating PEPPOL Exchange with SAP S/4HANA Cloud
Changes in configuration activities
After the integration setup is complete, the implementation process can continue with maintaining the required configuration. As introduced before, it is necessary to maintain configuration in the General settings for eDocuments section and in the section with configuration specific to PEPPOL.
Configuration section: General Settings for eDocument
One-by-one, navigate through the following configuration activities to maintain the required values. The SAP standard company code ID for Germany is 1010. For this reason, the company code IDs in the following screenshots sometimes show 1010.
- Activating Source Type Documents for Company Code (Mandatory)
- Assigning eDocument Type to Accounting Document Type (Mandatory)
- Activate Additional eDocument Instance Creation
Configuration section: Settings for PEPPOL
One-by-one, navigate through the following configuration activities to maintain the required values.
- Assigning Party ID Types to Business Partners (Mandatory)
- Assigning Party ID Types to ID Types (Mandatory)
- Assigning Party ID Types to Companies (Mandatory)
Navigate to the configuration activity Edit tax information for company codes (ID: 105675) within the Tax group. This step is also documented here: Maintaining VAT Number for Company Code (Mandatory).
Navigate to the configuration activity Maintain additional parameters (ID: 102739). This steps is also documented here: Maintaining Tax Number (non-VAT) for Company Code (Mandatory)
Maintaining value mappings
As described in the first section of this blog, value mappings are used by the system to map the internal values from the SAP S/4HANA Cloud public edition system to the external values that are used by the PEPPOL framework. There is an overview available about the required value mappings here: Configuring Value Mappings. The purpose of each value mapping is documented on help.sap.com as well. The respective page can be accessed via the links below.
- Configuring Partner Function Determination for Customer (SALES_ORG_PART_FUNC) – Optional
- Configuring Tax Exemption Reason Code - CEF VATEX (TAX_EXEMPT_CODE)
- Configuring UNCL1001 Code List Subset BII2 for FI (INVOICE_TYPE_CODE_FI)
With this mapping, the journal entry types that are used for customer invoices are mapped to the respective PEPPOL code.
- Configuring UNCL1001 Code List Subset BII2 for SD (INVOICE_TYPE_CODE_SD)
With this mapping, the billing document types are mapped to the respective PEPPOL code.
- Configuring UNCL4461 Code List (PAYMENT_MEANS_CODE)
This mapping translates the SAP payment methods such as T for transfer to the PEPPOL codes.
- Configuring UCNL5305 (TAX_CATEGORY)
With this mapping, the SAP tax codes are mapped to the PEPPOL values.
- Configuring Unit of Measure to External Value (UNIT_OF_MEASURE_CODE)
- Configuring Total Sales Value - Taxable Trans. - Tax Code (TOT_VALUE_TAX_TAXCD)
Configuring Namespace Dependent Parameters (SETTINGS)
Required master data
It is required to maintain two identification numbers on the customer master record. These are the Leitweg ID and the VAT number of the customer. The Leitweg ID is specific to the PEPPOL process. The VAT number is also required for the correct determination of tax rates in Germany and within the European Union. The following two links explain how to maintain the identification numbers on the customer master record.
Mexico
To process eDocuments in Mexico, typically customers partner with a third-party provider. The electronic documents are then sent from the SAP S/4HANA Cloud public edition system to the third-party and the third-party is passing them on to the tax authorities. SAP offers out-of-the-box integrations for the third-party providers Pegaso and Edicom. This third party-provider in Mexico is also called PAC. The tax authorities are referred to as SAT. The system for electronic documents in Mexico is called CFDI. Functions of electronic documents in Mexico that are covered in this blog are the eInvoice, and the ePayment. There also exist the electronic delivery note and the electronic withholding tax certificate. The following graphic shows an exemplary system flow for Mexico.
Changes in configuration activities
After the integration setup with the chosen PAC is complete, the configuration changes can be started.
Configuration section: General settings for eDocument
One-by-one, navigate through the following configuration activities to maintain the required values. The SAP standard company code ID for Mexico is 5510. For this reason, the company code IDs in the following screenshots sometimes show 5510. The configuration steps for eInvoices are also documented here: Configuration Options for Key Users: Electronic Customer Invoices and the configuration steps for ePayments are documented here: Configuration Options for Key Users: Electronic Payment Receipt Complements
- Activate source type documents for company code
- Assign eDocument Type to Accounting Document Type
- Redefine activation date for interface version
Please adjust the active from date according to your business needs for the interface versions. The active from date in this configuration is a method to control the version of the CFDI framework that is used. For example, in March 2022 a new version was introduced for eInvoices in Mexico. This was CFDI version 4. With the active from date in this configuration activity, it is possible to define clear cut-off dates when which version is used by the system to generate eDocuments.
Configuration section: Mexico: eDocuments
The required default configuration in this section should already be shipped with the scope activation. This includes number ranges and ODN prefixes.
Maintaining value mappings
Most settings for Mexican eDocuments are steered via value mappings. All value mapping tables are contained in the namespace /EDOMX. A list of value mappings with their explanation is available here: List of Value Mappings for Electronic Documents
Please note that a catch-all value mapping can also be maintained. It is possible to leave the column for the internal value in S4 blank and only maintain an external value. In this case, the system will pass on the external value when there is no value maintained in S4. For example, such a catch-all value mapping can be used in CFDI_PAYMNT_MEANS to default the external value that is passed to the eDocument whenever the payment method is not specified on the sales document. This can be useful since the field forma de pago field is mandatory in the eDocument but the payment method field may not always be filled on the sales document as part of your processes.
Required master data
The customer master data is required to have the tax number MX1 “Mexico: RFC Number” maintained. Each customer is also required to be maintained in a value mapping to assign the valid tax regime to the customer. On the product master data side no direct enhancements are required. However, the product code for each product needs to be maintained as a value mapping. Alternatively, such product code determination can also be set up to be determined from a product hierarchy. As described above, it is also possible to work with catch-all values in the value mapping.
The RFC number of the company code i.e., of your organization is required to be maintained in configuration activity Maintain Additional parameters in the parameter type MX_RFC. Further, the parameter CFDINA must be set with the parameter value X and the parameter CFDITR must be set with the applicable tax regime for your organization e.g., 601. Please also make sure that the organizational name of your company code and sales organization are exactly aligned with your company name that is registered with the authorities under the RFC number.
To successfully process ePayments, it can be required to maintain additional exchange rates in the system. The central bank of Mexico is publishing official exchange rates for currency pair combinations such as US Dollar to Mexican Peso and European Euro to Mexican Peso. Depending on the invoicing currencies and payment currencies that are used, it may be necessary to maintain the daily valid exchange rates published by the central bank in the SAP S/4HANA Cloud public edition system. Such currencies can be fetched via API and via external providers. To separate the exchange rates maintained for electronic documents from other exchange rates used for group consolidation, it is possible to create a separate exchange rate type for Mexico. The required configuration for such a new exchange rate type is described here: Currency Conversion with Prescribed Exchange Rates | SAP Blogs
Custom logic implementations
To issue compliant eInvoices and ePayments it can be necessary to implement custom logic as well. For example, custom logic can be used to fill the Addenda field in the eDocument XML file. This can be done with the custom logic EDOC_MX_FILL_CUSTOM_DATA_V4. One requirement can be to fill the addenda field with the address information of the customer. Please note that with a three-system landscape, it is possible to debug custom logic in the ABAP Development Tools (ADT) environment. This is explained in this blog: Debugging custom logic using ADT in SAP S/4Hana Cloud | SAP Blogs
To obtain the address information of the customer a SELECT statement can be used with the CDS view I_BillingDocument to retrieve the sold-to party. The CDS view I_Customer can then be used to retrieve the address details. Typically, the PAC requires the address data to be structured in a specific way in the addenda tag to correctly read the data. The PAC will be able to provide the information how the Addenda field needs to be structured. In the custom logic implementation the ABAP method CONCATENATE can be used to combine multiple strings into one variable that is then passed onto the addenda tag.
A second use case of custom logic concerns setting the field forma pago in the ePayment XML file. In standard, this field is filled from the payment method that is passed on the with the journal entry of the payment. The custom logic EDOC_MX_FILL_PAYMENT_METHOD can be used to define more complex logic for the field or to default the field in the XML file to a catch-all value.
Practical process information
At this point, a few good-to-know topics are called out when practically working with electronic documents in Mexico. First, there may be a requirement to send a PDF of the electronic invoice to customers. In Mexico, the SAP S/4HANA Cloud public edition is creating a separate PDF for the electronic invoice in addition to the regularly created PDF file of the billing document. This PDF of the electronic invoice can be downloaded from the eDocument cockpit by navigating to Display -> Display PDF. To generate this PDF, the system is using a special form template. The standard form template can also be adjusted and uploaded through the app Maintain Form Templates. There is a separate configuration activity available Specify Output Forms for PDF Generation (ID: 103727) where the form template for eDocuments is defined.
Second, invoices are required to be submitted as an electronic document within 24 hours of their posting. Hence, the submission of an eInvoice in the eDocument cockpit should be done promptly after the invoice was posted to accounting.
Third, there are a few specialties around the cancellation of invoices in Mexico. The process depends on how fast after creation an invoice was cancelled. The full process and its variants is documented here: Cancellation of Electronic Invoices
India
To process eDocuments in India, typically a third-party provider is required as well. The electronic documents are then sent from the SAP S/4HANA Cloud public edition system to the third-party and the third-party is passing them on to the tax authorities. For example, SAP offers out-of-the-box integrations for the third-party provider Excellon. The tax authorities in India are referred to as GST. There also is a government portal where submitted documents can be reviewed.
Functions of electronic documents in India that are covered in this blog are the eInvoice. When an eInvoice is successfully submitted to the tax authorities, an IRN number is issued by the authorities. This number is typically required to be printed on the PDF document of the invoice that is sent to the customer. Further, the PDF document typically requires that a QR code is included that also holds the elnvoice information.
Changes in configuration activities
To set up electronic invoices in India most of the required steps take place in configuration activities. Like the implementations for Germany and Mexico described above it is necessary to maintain configuration in general configuration activities and in country-specific configuration activities.
The SAP standard company code ID for India is 1810. For this reason, the company code IDs in the following screenshots sometimes show 1810. The configuration steps are also summarized here: Configuration Options for Key Users
When maintaining configuration, please check that the localized or country-dependent configuration activity is used. For regular invoices, the eInvoice is created from the journal entry. Hence, the journal entries used for invoice postings need to be maintained in the configuration activity Assign eDocument Type to Accounting Document Type for eInvoice.
In India, plant and company code are be combined to an organization unit. This is done with the configuration activities Maintain Organization Unit and Assign Company Code and Plant to Organization Unit. The object of an organizational unit can then be used to check authorizations of a user.
Two other important configurations that are not part of the eDocument configuration group are the configuration activity Assign Tax Code to Company Codes and Classify Condition Types for Goods and Services Tax for India in the area Finance -> General settings. In this configuration activity the condition types used in the pricing procedure are required to be mapped to the Indian condition name. This step is also documented here: Pricing Procedure/GL Accounts
Maintaining value mappings
No value mappings are required through the app Configure Value Mapping. They are already maintained in the configuration activities.
Changes required in output management
A key requirement for electronic invoices in India is that the PDF document of the invoice includes information from the eInvoice such as the IRN number and the QR code. Unlike in Mexico, there is no separate PDF document created in the eDocument cockpit as part of the eInvoice submission. Instead, the eDocument details are printed on the regular invoice output that is available directly from the billing document.
However, to make sure that the details from the eInvoice such as the IRN number are printed on the output item it is necessary that the output item is only finalized after the eInvoice was submitted successfully via the eDocument cockpit. For this reason, it is typically necessary to adjust the output parameter determination for the Indian sales organization such that the output is not dispatched immediately but on a scheduled base. This change can be made in the app output parameter determination. By selecting the rule set for Billing Documents and the determination steps Output Type, a rule can be created to set the output dispatch time to scheduled when the sales organization is equal to the Indian sales organization.
After the output parameter determination is adjusted the process steps to create and send out invoices in India are as follows:
- The invoices for India are created as normal and posted to FI. Because of the change in output parameter determination the PDF output is not created immediately.
- The invoices are submitted in the eDocument cockpit or the app Manage Electronic Documents
- Schedule the application job “Schedule Billing Output” to run periodically. Through its parameters the job can be configured to process all invoice documents for the Indian sales organization. The job then generates all invoice outputs that have been “waiting” in the status scheduled. This means emails are sent when the job runs or invoice printouts are then created.
Following these steps ensures that the PDF document contains the QR code and the IRN number.
Required master data
There are a few requirements for material master data and business partner master data. For business partners they are document here: Business Partner Master Data
For products they are documented here: Material Master Data
Error handling and information sources
There is a wide range of information sources available on electronic documents overall and more specifically on electronic invoices. Separately, country-specific information is also available. In general, it makes sense to review the country-specific content on the SAP Help Portal first when starting the implementation of eDocuments in a new country. Second, the overview SAP notes and troubleshooting SAP notes can be reviewed.
I found the following information helpful when I implemented electronic documents before:
- Scope item 5XU on the Process Navigator
- Documentation on the SAP Help Portal
- Country-specific content on the SAP Help Portal
- SAP S/4HANA Cloud Customer Community – SAP Document and Reporting Compliance
- SAP notes on me.sap.com
- Germany: Overview note 2690949, Troubleshooting 2926868
- Mexico: Overview note 2565791, Troubleshooting 2523263
To analyze errors for specific eDocuments, it makes sense to review the application log in the app eDocument cockpit first. The same log information is also available in the Fiori app Manage Electronic Documents. If the issue relates to the integration the application log will point to the interface log where a more detailed error description is available. Sometimes this error message will also point to the log files on SAP Cloud Platform Integration if the integration flow to send documents to a third-party provider failed entirely. In a business as usual environment, most submission errors of eDocuments will relate to missing value mappings.
An electronic invoice can best be analyzed by using the XML file that is sent to the third party. This file can be downloaded from the eDocument cockpit. The recommended way to download the right file is to navigate via the History button and to select the latest document with the status SENT or SENDEDOC for the download. This is because the third-party provider returns a response XML file to the SAP S/4HANA Cloud public edition system. If the user just clicks on download XML directly, the system will download the response file and not the file that was sent. Inspecting the XML file allows to understand the error message returned by the application log. As a result, a missing value mapping can be added, or some additional master data maintained. After that, the document can be submitted again in the eDocument cockpit or in the app Manage Electronic Documents.
Conclusion
With this blog, a high level introduction is provided to the topic of electronic invoices. I want to thank Katalin Csengodi and Omar El Hajami for their contributions. Electronic invoices are typically sent from the SAP S/4HANA Cloud public edition system to an eDocument service and then passed on to the tax authorities. To practically work with electronic documents, two apps are important to submit the documents, review responses, and analyze errors. These are Manage Electronic Documents and the eDocument cockpit. Setting up electronic invoices requires integration setup as well as configuration changes, the maintenance of value mappings, and the maintenance of additional master data. If you are working with electronic documents, feel free to share your tips and tricks in the comments.
- SAP Managed Tags:
4 Comments
