The world has been changing for a while drastically and a change deeper has been augmented with everchanging regulations and speeded up by COVID19. The way businesses transact has never been under such a huge transformation than ever and coupled with the regulations in a digital economy has only been becoming more complex. In such an environment, the term e Invoicing has been quite a parlance especially in APAC and Europe. So what exactly is e Invoicing? Simply put, it means the process of invoicing your customers electronically. However, of late many governments and tax authorities in many countries have made it legally mandated, that the invoices, both outgoing and incoming need to be sent for information or approvals, before they can be legally valid. In many countries, such as Italy or some countries in Latin America, the invoices are also distributed to the end customers by the respective legal authorities.
SAP’s ERP (ECC or S/4HANA) being the ecosystem for business enterprises have a product called as e Document or Digital Compliance Services (DCS), that enables the generated documents to be transformed into predefined exchange formats and transfer it electronically externally to external systems such as Tax Authorities or Governments. The data formats are country specific and in most cases, it is the XML format which is used for transmission of data. Some of the key countries, which have country specific solutions on e Document framework are India, Chile, Most of European Countries (for B2G Customers), Mexico, Taiwan, Thailand, Spain to name a few. A typical architecture for e Documents looks as below:
Typical steps for the flow of data from transactional system to recipient includes:
While the overall process looks straightforward, there are lot of things to be taken care of during the implementation for e Invoicing using e Documents. Some of the learnings from my implementation experience in various countries is:
Mapping what transactional data should be sent to Recipient – In my view, this is one of the most critical information that needs to be decided. A typical e Document project would inform that all invoices, credit notes, debit notes, both on sales and purchase side need to be informed to the tax authorities. However, here in lies the challenge since the key trigger for the e Document to be generated is the assignment of accounting document type in the configuration of e Document. In most of my project experiences, the accounting document used for sales transaction including invoices, credit note, debit note and cancellation document is same. Eg, RV is the accounting document type used for posting of sales transaction unless, a specific document type is used in the billing type configuration
There are various approaches to handle this scenario:
1) Create multiple new accounting document types and assign to the billing type configuration. This is a simple and straight forward way. However, it may not be possible if the billing type is used in many countries and not restricted to specific sales organization
2) The e Document framework has country specific BADI available, where the customers can write their own logic. In such a case, we can read the corresponding billing type from the billing document and read the category of the SD Document to generate the required electronic file. This would also be important since most of the countries do not allow a cancellation of the invoicing document and only a credit note or debit note is allowed as per law
Postings of FI Only invoices – In my project experience, lot of customers also use FI documents for posting sales and purchase transactions, which also need to be reported to the tax authorities through the e document transaction. For the global customers it is a common practice to have restricted number of document types that can be used and similar transactional processes need to be used in multiple countries.
In one of my projects, a document type AJ was used for procurement of fixed assets as well as purchase of low value assets. This customer had business operations in India and it is required to ensure, that both the sales and purchase transaction need to be reported to the tax authorities using the e document framework. With the same document type being used for different purposes, the standard configuration of assigning the Accounting document type to e Document type for transformation file would not work. In such a case, there are enhancement points provided, where a BADI Implementation can help to identify the nature of transactions based on posting keys, which than generates the corresponding electronic file for transmission.
A clear strategy has to be considered to determined which document types should be mapped for e Document. If the mapping of document types is incorrect, the legal reporting can go for a toss. It is absolutely critical that the implementation consultant looks at the nature of transactions along with the posting keys used to make sure, that only the relevant document types are used for mapping in the e document framework.
Data Transformation in the electronic file – The e Document implementation project for a country is available with country specific set of notes from SAP, which are easier to implement. However, in addition to the electronic files being sent to the tax authorities, the most critical and daunting task is also to make sure that the right content is available in the file, since there are lot of validations and checks at the recipient side to make sure that the right data is reported. Some of the file transformation issues that I have encountered in my various implementation projects related to e invoicing are as below:
A. Tax Code set up and information – One of the key challenges in e Document is the use of right tax codes and tax information in the file itself, due to which lot of time the invoices are rejected. Some of the cases that have been encountered are:
B. Master Data Set up for customer and vendors – One of the most important reason why the transactional data fail in approval by tax authority is the master data set up. The electronic files pull in lot of information like Tax Registeration No (VAT ID, GSTIN No etc), details of the suppliers like name, address, country, city etc and all this information is filled in the master data. My experience in dealing with multiple projects for e Documents is:
Europe: VIES
India: Goods & Services Tax (GST) | Services
Most of the tax authorities have these kind of services to verify the data
C. Transaction Information in the electronic file – Many of the countries, which have mandated electronic invoicing also need information like gross price, discounts, other mark ups, Base Amounts for tax and tax amounts to be updated in the electronic file for e documents. This information is critical for the file to be approved. In Outgoing invoices, this information typically flows in from condition types in the billing document. In such a case, it is critical for the implementation consultant to identify, what condition type is used for which kind of business information and map the same in AIF mapping framework correctly. Similarly, holds true for purchasing information as well. In addition to the values related mapping, the invoices also contain information on quantities of good/services being sold. Many of the customer use ISO Specific Unit Of measurement, but they also use their own custom defined units of measurement. This becomes a key challenge, as the custom unit of measurement are not accepted by the tax authorities. A clean up of transaction data is key to successful project implementation.
Invoice Output and Distribution – The key aspect for e document framework is to get the invoices sent to the customers, which are legally compliant. In many countries like the upcoming e Invoicing change in India, the invoice output itself should contain an approval from the tax authority. This is also the case in countries like Argentina, Italy and Colombia as well. It is important that any digital or paper output should be generated only after the electronic files have been approved by the tax authorities successfully and the required information is available to be captured in invoice outputs. In my projects, we have implemented checks that invoice outputs through digital means like EDI, emails of PDF outputs are triggered only after the invoices have been approved. This is a critical check to be built to ensure legal compliance
Cutover Strategy for Implementation Projects – One of the key asks in projects is that all invoices which are generated after a legally mandated date should be generated with the electronic file. Some of the key aspects that need to be looked into are:
The above points are just some of the aspects of e Document implementation projects which must be considered for a successful project.
Okumaya devam et...
SAP’s ERP (ECC or S/4HANA) being the ecosystem for business enterprises have a product called as e Document or Digital Compliance Services (DCS), that enables the generated documents to be transformed into predefined exchange formats and transfer it electronically externally to external systems such as Tax Authorities or Governments. The data formats are country specific and in most cases, it is the XML format which is used for transmission of data. Some of the key countries, which have country specific solutions on e Document framework are India, Chile, Most of European Countries (for B2G Customers), Mexico, Taiwan, Thailand, Spain to name a few. A typical architecture for e Documents looks as below:
Typical steps for the flow of data from transactional system to recipient includes:
- Posting of transactional document in ERP (ECC or S/4HANA)
- Generation of electronic file in the framework (e Document)
- Throughput of the e document to the recipient using integration system (eg, SCP)
- Acknowledgement and approval of e Document by the recipient
- Update of the e document status in the source system
While the overall process looks straightforward, there are lot of things to be taken care of during the implementation for e Invoicing using e Documents. Some of the learnings from my implementation experience in various countries is:
Mapping what transactional data should be sent to Recipient – In my view, this is one of the most critical information that needs to be decided. A typical e Document project would inform that all invoices, credit notes, debit notes, both on sales and purchase side need to be informed to the tax authorities. However, here in lies the challenge since the key trigger for the e Document to be generated is the assignment of accounting document type in the configuration of e Document. In most of my project experiences, the accounting document used for sales transaction including invoices, credit note, debit note and cancellation document is same. Eg, RV is the accounting document type used for posting of sales transaction unless, a specific document type is used in the billing type configuration
There are various approaches to handle this scenario:
1) Create multiple new accounting document types and assign to the billing type configuration. This is a simple and straight forward way. However, it may not be possible if the billing type is used in many countries and not restricted to specific sales organization
2) The e Document framework has country specific BADI available, where the customers can write their own logic. In such a case, we can read the corresponding billing type from the billing document and read the category of the SD Document to generate the required electronic file. This would also be important since most of the countries do not allow a cancellation of the invoicing document and only a credit note or debit note is allowed as per law
Postings of FI Only invoices – In my project experience, lot of customers also use FI documents for posting sales and purchase transactions, which also need to be reported to the tax authorities through the e document transaction. For the global customers it is a common practice to have restricted number of document types that can be used and similar transactional processes need to be used in multiple countries.
In one of my projects, a document type AJ was used for procurement of fixed assets as well as purchase of low value assets. This customer had business operations in India and it is required to ensure, that both the sales and purchase transaction need to be reported to the tax authorities using the e document framework. With the same document type being used for different purposes, the standard configuration of assigning the Accounting document type to e Document type for transformation file would not work. In such a case, there are enhancement points provided, where a BADI Implementation can help to identify the nature of transactions based on posting keys, which than generates the corresponding electronic file for transmission.
A clear strategy has to be considered to determined which document types should be mapped for e Document. If the mapping of document types is incorrect, the legal reporting can go for a toss. It is absolutely critical that the implementation consultant looks at the nature of transactions along with the posting keys used to make sure, that only the relevant document types are used for mapping in the e document framework.
Data Transformation in the electronic file – The e Document implementation project for a country is available with country specific set of notes from SAP, which are easier to implement. However, in addition to the electronic files being sent to the tax authorities, the most critical and daunting task is also to make sure that the right content is available in the file, since there are lot of validations and checks at the recipient side to make sure that the right data is reported. Some of the file transformation issues that I have encountered in my various implementation projects related to e invoicing are as below:
A. Tax Code set up and information – One of the key challenges in e Document is the use of right tax codes and tax information in the file itself, due to which lot of time the invoices are rejected. Some of the cases that have been encountered are:
- Right tax code set up in ERP especially for countries in European Union. The tax codes must have the right set up to identify an EU Transaction, a domestic transaction or a non EU Transaction.
- In countries like Peru, it is important to have the right tax information in the electronic file. Eg, In Peru, the detraction tax is allowed only for invoices and not for Credit notes. So it is important to have the right tax set up in the ERP System and it should also flow into the electronic file set up for the country
- In India, there are taxes, which must be paid by the reporting entity on behalf of foreign affiliates and suppliers. The tax codes for such transactions need to set up in a specific way so that self invoices can be generated and e document sent to the tax authorities
B. Master Data Set up for customer and vendors – One of the most important reason why the transactional data fail in approval by tax authority is the master data set up. The electronic files pull in lot of information like Tax Registeration No (VAT ID, GSTIN No etc), details of the suppliers like name, address, country, city etc and all this information is filled in the master data. My experience in dealing with multiple projects for e Documents is:
- It is important to have the right tax number filled in the master data. There are lot of Government websites, which can be used for verifying the data
Europe: VIES
India: Goods & Services Tax (GST) | Services
Most of the tax authorities have these kind of services to verify the data
- Lot of tax authorities also check for other master data related information like address, city and region or province of the customer/vendor. In my case, I have come across these kind of errors in multiple countries like Italy, Peru, India etc where the information was not correctly updated, which leads to the failure of the invoices.
C. Transaction Information in the electronic file – Many of the countries, which have mandated electronic invoicing also need information like gross price, discounts, other mark ups, Base Amounts for tax and tax amounts to be updated in the electronic file for e documents. This information is critical for the file to be approved. In Outgoing invoices, this information typically flows in from condition types in the billing document. In such a case, it is critical for the implementation consultant to identify, what condition type is used for which kind of business information and map the same in AIF mapping framework correctly. Similarly, holds true for purchasing information as well. In addition to the values related mapping, the invoices also contain information on quantities of good/services being sold. Many of the customer use ISO Specific Unit Of measurement, but they also use their own custom defined units of measurement. This becomes a key challenge, as the custom unit of measurement are not accepted by the tax authorities. A clean up of transaction data is key to successful project implementation.
Invoice Output and Distribution – The key aspect for e document framework is to get the invoices sent to the customers, which are legally compliant. In many countries like the upcoming e Invoicing change in India, the invoice output itself should contain an approval from the tax authority. This is also the case in countries like Argentina, Italy and Colombia as well. It is important that any digital or paper output should be generated only after the electronic files have been approved by the tax authorities successfully and the required information is available to be captured in invoice outputs. In my projects, we have implemented checks that invoice outputs through digital means like EDI, emails of PDF outputs are triggered only after the invoices have been approved. This is a critical check to be built to ensure legal compliance
Cutover Strategy for Implementation Projects – One of the key asks in projects is that all invoices which are generated after a legally mandated date should be generated with the electronic file. Some of the key aspects that need to be looked into are:
- Master Data is updated correctly
- All invoices which should be have been generated before the legal mandate date have been completed
- AIF Set up for condition type is completed
- Connection set up through integration channel is completed
The above points are just some of the aspects of e Document implementation projects which must be considered for a successful project.
Okumaya devam et...