In this blog post, we'll explore the technical objects and BAdIs in SAP Document and Reporting Compliance.
The figure below shows a visual overview of the ABAP class map and the key BAdIs, as well as a summary table as to how these are used in country-/mandate-specific implementations.
This is important because a large part of the business logic for SAP-delivered content is embedded in technical ABAP or SAP BTP objects. Understanding these objects becomes key when the processes don’t function as expected due to configuration issues, lack of information on how certain data points are mapped, gaps in the standard logic, and so on.
As you can see, there are two key sets of ABAP objects, as follows:
In the following sections, we’ll walk through some of the important technical objects used by SAP Document and Reporting Compliance as well as the key BAdIs you may consider implementing to meet individual requirements during an implementation.
The following points explain how these technical objects (e.g., classes, tables, structures, etc.) are used in the SAP Document and Reporting Compliance framework and where they are referred to:
This implements the country-specific logic (steps, actions, etc.). If multiple mandates and scenarios may be applicable to a single country, additional eDocument instance creation can be triggered by registering additional factory classes in table EDOFACTORY, maintenance view EDOFACTORYV. Sample entries for India e-invoicing are shown here.
Tables Storing eDocument-Related Data by eDocument Unique ID
The following tables store process-specific data for a unique eDocument identifier (e.g., information provided by the response of the authority web service):
The assignment of eDocument types to the EDO[countrycode] tables from the previous
step, which store eDocument process–relevant data, can be found here.
These objects handle the database operations for country-specific tables and functions (e.g., creation, update, and deletion of entries).
This contains the main logic for mapping from source applications to the target country-/mandate-specific structure, including the execution of the SAP Application Interface Framework transformations.
In this step, the process steps, actions, and other parameters are defined per process. A process generally refers to an electronic mandate; however, specific processes exist based on various characteristics such as the direction of the messaging (e.g., outbound invoices vs. inbound invoices) or type of document (e.g., delivery notes vs. invoices).
The link to the ABAP classes is defined where the steps are connected to the implemented class method of the eDocument handling class defined, such as CL_EDOCUMENT_[country code/mandate specifics], as shown in this figure.
In table/maintenance view EDOCOMPANYACTIV, the source types (sales invoices, financial accounting invoices, etc.) are activated by company code.
Table EDOSRCTYPE (maintenance view EDOSRCTYPEV) specifies the ERP source types and how these are fetched (ABAP class and the source structure).
The eDocument type defined in table EDOTYPE is associated with the source ERP documents and interface types (e.g., table T003EDOC for accounting documents, table TVFKEDOC for billing documents, and table EDOINTTYPE for the link to the interface type, each has a corresponding maintenance view, including the “V” suffix such as view T003EDOCV).
Lastly, we need hooks to trigger the eDocument creation process off the back of specific events in the SAP S/4HANA system.
Examples include Business Transaction Events (BTEs) that are triggered after the financial accounting documents are posted (e.g., for outbound scenarios). These BTEs, along with their corresponding function modules, need to be assigned in Transaction FIBF. Other mandates such as incoming invoices may rely on different hooks or mechanisms for the creation of the eDocument transactions.
This figure shows which events are associated with which eDocument-specific hooks/function modules (as defined in Transaction FIBF).
BAdIs provide key extensibility options when organizations need to adjust and extend the logic SAP delivers or create their own eDocument-related processes, for example, implementing a mandate that isn’t covered by the standard content/country version. Let’s look at some key BAdIs, as follows:
This BAdI allows for the enhancement of the logic for the interfacing aspects, for example, integrating the eDocuments with SAP Application Interface Framework.
The BAdI is implemented with its specific business logic with the filters used to tie the implementation to the given country/electronic mandate, as shown in this figure.
Each mandate will have its own implementation, and you can implement your own logic as well, as shown here.
As shown in the figure below, this BAdI allows for eDocuments to be adjusted in the following ways, among others:
Using its filters, country-specific implementations can be added.
This BAdI allows logic to be added for eDocuments to be sent on to external parties, such as business partners and customers. For example, this functionality enables eDocuments to be sent to customers in emails in Germany, including adding attachments.
This BAdI makes it possible to add custom fields to the EDOCUMENT table.
Editor’s note: This post has been adapted from a section of the book SAP Document and Reporting Compliance: The Comprehensive Guide for Finance and Tax by Genevieve Watson, Eliza Alberts-Muller, and Iain MacIntosh. Genevieve is an experienced tax ERP and transformation leader, and a Partner within Deloitte's Tax Technology Consulting team. Eliza is a Partner within Deloitte‘s Tax Technology Consulting team with close to 20 years of experience in (indirect) tax and tax technology gained both in industry and consulting. Iain is a Principal at Deloitte with more than 25 years of experience implementing SAP.
This post was originally published 11/2025.