/BACK
Most tax accounting solutions in SAP have been based on the usage of the FI-SL module "Special Registers" since the passage of Chapter 25 of the Russian Federation's Tax Code in 2002, or, since the debut of ERP 2004, on the capabilities of a flexible general ledger. The Russian localization of SAP has a "typical design solution" that is extensively used. Original solutions, on the other hand, are frequently found. For example, the author worked on a project around ten years ago where the tax accounting requirements were completely integrated in the EC-CS module, with IFRS and RAS reporting running concurrently. However, all ERP-restricted systems suffer from the same "birth injuries" caused by the inherent constraints of specific register capabilities or the flexible general ledger that underlies their development. Transferring tax reporting from the ERP system to BW is a natural way out of this dilemma. A "role model" might be the seamless transfer of financial reporting consolidation capabilities from ERP (EC-CS) to BW (SEM-BCS) by SAP experts.
The approach and principles of technical execution of the requirements of Chapter 25 of the Tax Code and RAS 18/02 in SAP BW are described in this article. You can fulfill all legal requirements by using OLAP reporting capabilities, which is essentially unachievable with a report generator like Report Painter. It's worth noting that using the BW toolbox gives the accountant access to tools for conducting checks and checking for problems in primary documents that ERP reporting cannot provide under any circumstances. A versatile and powerful technique for creating BW data warehouses allows you to pull together all of the essential data, not just from the General Ledger, but also from multiple ERP modules such as "Controlling" and "Accounting of Fixed Assets." It should be noted that while utilizing FI-SL, this is almost impossible.
It's difficult not to mention SAP HANA at some point. The author believes that using BW on HANA is the most cost-effective solution to improve the return on investment in a business analytical and financial reporting system. The approach given in the article is based on using the "traditional" BW framework to implement it. When it is "migrated" to SAP HANA, however, no major modifications are necessary. Of course, DSO can be used in place of info cubes as data storage objects, but this will have no effect on the general architecture or individual functionality of the system described below.
The design of the solution and the methodology of tax accounting supported by it
As previously noted, the "role model" might be the move of financial reporting consolidation capabilities from EC-CS to SEM-BCS. In both situations, the incentives are the same. Furthermore, the tax accounting implementation will necessarily imitate the concepts that SEM-BCS is built on in many essential respects. Take a look at a few examples:
- Separation of application functionality and "Data Base" to obtain maximal independence from the intricacies of the underlying data warehouse implementation.
- With pre-built customization and expansion possibilities, a clear definition of the supported accounting technique is supplied. A collection of analytical characteristics and indicators that make up the tax accounting data model are fixed as a result of this.
- When moving data from a database to a tax accounting data model, transformation techniques should be as flexible as feasible while still being precisely "sharpened" for the assigned task.
- The reporting system should be integrated into the functioning of the program.
Initially, all source data is saved in the ERP system tables. For tax accounting, the following SAP modules are useful:
- FI-GL - Main book. In practice, a flexible general ledger with a dedicated "tax" register is most common. This isn't necessary, though.
- FI-AA - OS and IA Accounting. The following areas of assessment are presumed to exist:
- assessment in accordance with RAS;
- assessment in accordance with the requirements of Chapter 25 of the Tax Code;
- permanent tax differences;
- tax differences without permanent differences.
- FI-GL-ACE - Future Period Expenses and Income (Accrual Engine). It is not required to use this module. In the accounting module of the FI-AA OS, the write-off of delayed costs is sometimes configured.
- Controlling indirect expenses with CO-OM. In most cases, redistribution of expenditures within the CO-OM module results in a change in their classification from the perspective of tax accounting. Furthermore, precisely allocating capitalized costs and WIP is frequently a tough process.
The corporate data warehouse (CDW) is created by importing the relevant data from the ERP into the BW system. CDW acts as a data source for the Tax Accounting Module while also serving as the foundation for basic analytical reports. CDW is often constructed on the basis of regular BW content, as per SAP standards.
Here's where I'd want to make the following observation. In SAP, there are often two techniques to parallel accounting:
- Separation of accounting categories in the general ledger by the use of unique "off-balance sheet" ranges.
- Separation of accounting kinds in a flexible general ledger utilizing distinct registers.
Supported tax accounting methodology
The solution's ultimate outcome is the creation of reports in line with the legislation's requirements:
- The income tax declaration must follow a specific format that has been defined by law. It is transmitted to the tax authorities in the form of an XML file, but it must also be represented on paper.
- According to Article 313 of the Russian Federation's Tax Code, the tax base is calculated using a consolidated synthetic profit tax calculation register built on the basis of analytical tax accounting registers.
- Articles 313 and 314 of the Russian Federation's Tax Code define analytical registers of tax accounting as "required reporting forms." For the sake of brevity, they shall be referred to as tax registers. Their format is created individually by the taxpayer.
- The tax disparities report - a summary reporting form. depicts the process of accrual and write-off of permanent and temporary tax disparities in the framework of the analytical features accessible in the system. The report's conclusions include determining the basis for deferred tax assets and liabilities accruals and write-offs. Just as the "Calculation of the tax base" is based on data from tax registers, the "Report on tax differences" is based on data from analytical registers of differences.
A mandatory solution, both methodologically and technically, is to construct an intermediate data storage level, between final reports and original documents, where tax categorization takes place (assignment of numbers of tax registers and registers of differences). The following graphic (Fig.1) depicts the overall logical structure of the data flow:
Fig.1. Data flow logic diagram
Each line of the Declaration is a straightforward total of revenue for one or more tax registrations. The "Tax Difference Report," meanwhile, is based on data from the difference registers. The Difference Report and the Declaration are both virtual objects. The level of registers is the storage level for "cleaned" and categorised data that has been optimized for a particular task.
The register numbers are calculated when main documents are transferred from the "Database" to the "Tax Accounting Module." The derivation rules might be sophisticated or simple, and they can employ any information from the original documents. The major objects of the notes, such as the account number, the cost center, the kind of internal order, and so on, are recorded together with the computed register number.
Primary accounting documents (including an accountant's certificate) are the confirmation of tax accounting data, according to Article 313 of the Russian Federation's Tax Code. Individual documents are saved in the system at the "Database" level and not transmitted to the "Tax Accounting Module." It is, however, always feasible to establish which registration a specific main document belongs to.
Each register is assigned a unique number and is the lowest-level item in the following hierarchy:
Each register is assigned a unique number and is the lowest-level item in the following hierarchy:
Figure 2: Tax Register Hierarchy
In the same way, registers of difference can be classified in the following way:
Fig. 3. Hierarchy of registers of differences
The format of the "Tax Difference Report" columns is shown in this diagram. Its lines may be formed using both tax register hierarchy and RAS accounts. A common requirement, for example, is to "scan" tax discrepancies along the lines of Form No. 2. In general, having all of the necessary analytical elements helps you to create successful multidimensional data models for OLAP reporting.
For tax accounting purposes, a single indicator – the amount of turnover in rubles – is sufficient. The financial period is the time granularity of the data stored (month). At the same time, keep in mind that the year and period in which revenue and spending are attributed to the Tax Accounting and RAS may not coincide.
Furthermore, the legislation's details necessitate the inclusion of additional analytics in the data structure "Adjustment Number."
Furthermore, the legislation's details necessitate the inclusion of additional analytics in the data structure "Adjustment Number."
Derivation of tax registers and registers of differences
The fundamental documents lack the analytical aspects of the tax register and the register of differences, which are the foundations of all tax reporting. When data is transferred from the database to the Tax Accounting Module, its derivation occurs in two steps:
- register numbers are allocated to accounting accounts and cost elements by default,
- and the final register numbers are determined using the system's derivation rules.
The actual rules for determining register numbers are highly complex, as practice has shown. First of all, there are a lot of them: each economic action for which a simple mapping to the chart of accounts "doesn't work" results in a new rule. Secondly, there is almost always some logic in the rules, which makes the process of derivation branching. And, thirdly, in defining individual rules, sufficiently large and changing sets of objects can be used (for example, account numbers, SSP elements or internal orders). The fundamental root of these difficulties is, of course, the disparity between RAS and Tax Code standards. However, they are frequently caused by irreversible "flaws" in a productive system's settings, which were developed throughout the installation phase. In a nutshell, this is the situation in which reality proves to be more intricate than "theory."
The system's key node is the generation of register numbers. If it cannot be earned entirely automatically, the claim for the creation of the tax reporting system will be invalidated, and the accountant will be forced to resort to the old method of dumping intermediate data into Excel and manually processing it.
Reporting
The reports "Income Tax Declaration," "Calculation of the Tax Base," and "Report on Tax Differences" all follow the same structure and are used for "documentary" reasons, among other things. Analytical tax accounting registers and registers of discrepancies are basic document registers. Any report's numbers must be verifiable. Finding and fixing mistakes is perhaps the most time-consuming chore an accountant faces on a daily basis. You should utilize a robust tool like BW's OLAP reporting for this purpose. Flexible data filtering and navigation functions let you tackle reconciliation and mistake detection problems in the most efficient way possible. The ability to "fall through" from report to report till reaching the principal document (drill-down) is particularly important.
Technical implementation
The following sections outline the fundamental concepts of the solution's technological execution. It should be stated right away that describing all of its details in one essay is impracticable. As a result, the author's sole purpose is to provide the reader with a broad understanding of how the aforementioned (sections?) work. The SAP BW toolbox may be used to effectively implement the requirements.
The items engaged in the BW process, as well as the data flows between them, are depicted in the diagram below (Fig. 4):
Fig. 4 Technical diagram of the data flow.
Table 1. Objects in the data flow diagram (Fig. 4).
Going from bottom to top with a full description of the data flow is sensible. In typical SAP content, the objects that make up the Database have direct analogs (in the simplest case, they are simply copies of them). Accounting records from the ERP are copied to DSO 04, and the results of indirect cost redistribution are copied to IC 03. There may be instances where tax discrepancies develop as a result of transactions on multiple accounts: accruals are made on one account, while write–offs are made on a different account. The distinction between such charges and write-offs is documented in DSO 01, i.e., the discrepancies are formed. DSO 05 keeps track of the OC and HMA depreciation, whereas DSO 06 keeps track of the DE write-off. It is required to assess data from several evaluation regions in order to appropriately determine the differences. When data is sent to DSO 02 and DSO 03, this occurs in user transformation routines. DSO 01, DSO 02, and DSO 03 would be unnecessary if the work was confined to determining the income tax base. The necessity to compute tax differences makes the technological implementation substantially more difficult.
The IS 01 info source establishes a universal interface for the register number derivation algorithm's incoming data stream. The derivation happens during the transition from IS 01 to IC 01 in the starting program. The algorithm itself necessitates a configurable tool. For implementation, BRF+ (Business Rules Framework Plus) technology is employed, which allows you to define rules of any complexity level using a common graphical interface. This method is ideal for usage inside user applications in transformations since the defined rules are automatically compiled into AVAR code. The IC 01 data cube provides all of the information required to create income tax and tax difference reports. For computations involving planning functions, the IC 02 real-time info cube is employed. It solves the problem of computing income tax for various divisions in particular. MP 01 and MP 02 multi-providers are used for reporting. MP 02 also acts as a base provider for aggregation levels that use BI-IP services such as duplicating the tax base and planning functions computations.
Data travels in the other way, up to the ERP's key records, thanks to report-report connections. Simultaneously, the reports that participate in the interfaces are constructed on virtual info providers, which are essentially shells that sit on top of real DSOs.
What's next?
Income tax, VAT, and property tax reporting are all intertwined. For example, adjusting the disclosure for one of these taxes necessitates adjusting the declaration for another. The creation of a VAT Declaration in BW is an entirely normal process. And, given the potential for reconciliation and mistake detection afforded by OLAP reporting, such a system will provide the accountant with strong tools that he is deprived of in ERP. Because the database on fixed assets was previously built as part of the income tax automation, it's a natural fit to base property tax reporting on it.
Author: Dmitry Bulatov
Candidate of Physical and Mathematical Sciences. Over 25 years of expertise developing information systems in a variety of industries. Expert knowledge of the architecture of SAP ERP and SAP BI platforms. Deep understanding of financial and managerial accounting, budgeting, and consolidation. Successful experience in building complex SAP BI and SAP ERP architectures on Russian and international projects. Expert in SAP BW, FI, CO, FI-FM functionality.
/BACK
Most tax accounting solutions in SAP have been based on the usage of the FI-SL module "Special Registers" since the passage of Chapter 25 of the Russian Federation's Tax Code in 2002, or, since the debut of ERP 2004, on the capabilities of a flexible general ledger. The Russian localization of SAP has a "typical design solution" that is extensively used. Original solutions, on the other hand, are frequently found. For example, the author worked on a project around ten years ago where the tax accounting requirements were completely integrated in the EC-CS module, with IFRS and RAS reporting running concurrently. However, all ERP-restricted systems suffer from the same "birth injuries" caused by the inherent constraints of specific register capabilities or the flexible general ledger that underlies their development. Transferring tax reporting from the ERP system to BW is a natural way out of this dilemma. A "role model" might be the seamless transfer of financial reporting consolidation capabilities from ERP (EC-CS) to BW (SEM-BCS) by SAP experts.
The approach and principles of technical execution of the requirements of Chapter 25 of the Tax Code and RAS 18/02 in SAP BW are described in this article. You can fulfill all legal requirements by using OLAP reporting capabilities, which is essentially unachievable with a report generator like Report Painter. It's worth noting that using the BW toolbox gives the accountant access to tools for conducting checks and checking for problems in primary documents that ERP reporting cannot provide under any circumstances. A versatile and powerful technique for creating BW data warehouses allows you to pull together all of the essential data, not just from the General Ledger, but also from multiple ERP modules such as "Controlling" and "Accounting of Fixed Assets." It should be noted that while utilizing FI-SL, this is almost impossible.
It's difficult not to mention SAP HANA at some point. The author believes that using BW on HANA is the most cost-effective solution to improve the return on investment in a business analytical and financial reporting system. The approach given in the article is based on using the "traditional" BW framework to implement it. When it is "migrated" to SAP HANA, however, no major modifications are necessary. Of course, DSO can be used in place of info cubes as data storage objects, but this will have no effect on the general architecture or individual functionality of the system described below.
The design of the solution and the methodology of tax accounting supported by it
As previously noted, the "role model" might be the move of financial reporting consolidation capabilities from EC-CS to SEM-BCS. In both situations, the incentives are the same. Furthermore, the tax accounting implementation will necessarily imitate the concepts that SEM-BCS is built on in many essential respects. Take a look at a few examples:
- Separation of application functionality and "Data Base" to obtain maximal independence from the intricacies of the underlying data warehouse implementation.
- With pre-built customization and expansion possibilities, a clear definition of the supported accounting technique is supplied. A collection of analytical characteristics and indicators that make up the tax accounting data model are fixed as a result of this.
- When moving data from a database to a tax accounting data model, transformation techniques should be as flexible as feasible while still being precisely "sharpened" for the assigned task.
- The reporting system should be integrated into the functioning of the program.
Initially, all source data is saved in the ERP system tables. For tax accounting, the following SAP modules are useful:
- FI-GL - Main book. In practice, a flexible general ledger with a dedicated "tax" register is most common. This isn't necessary, though.
- FI-AA - OS and IA Accounting. The following areas of assessment are presumed to exist:
- assessment in accordance with RAS;
- assessment in accordance with the requirements of Chapter 25 of the Tax Code;
- permanent tax differences;
- tax differences without permanent differences.
- FI-GL-ACE - Future Period Expenses and Income (Accrual Engine). It is not required to use this module. In the accounting module of the FI-AA OS, the write-off of delayed costs is sometimes configured.
- Controlling indirect expenses with CO-OM. In most cases, redistribution of expenditures within the CO-OM module results in a change in their classification from the perspective of tax accounting. Furthermore, precisely allocating capitalized costs and WIP is frequently a tough process.
The corporate data warehouse (CDW) is created by importing the relevant data from the ERP into the BW system. CDW acts as a data source for the Tax Accounting Module while also serving as the foundation for basic analytical reports. CDW is often constructed on the basis of regular BW content, as per SAP standards.
Here's where I'd want to make the following observation. In SAP, there are often two techniques to parallel accounting:
- Separation of accounting categories in the general ledger by the use of unique "off-balance sheet" ranges.
- Separation of accounting kinds in a flexible general ledger utilizing distinct registers.
Supported tax accounting methodology
The solution's ultimate outcome is the creation of reports in line with the legislation's requirements:
- The income tax declaration must follow a specific format that has been defined by law. It is transmitted to the tax authorities in the form of an XML file, but it must also be represented on paper.
- According to Article 313 of the Russian Federation's Tax Code, the tax base is calculated using a consolidated synthetic profit tax calculation register built on the basis of analytical tax accounting registers.
- Articles 313 and 314 of the Russian Federation's Tax Code define analytical registers of tax accounting as "required reporting forms." For the sake of brevity, they shall be referred to as tax registers. Their format is created individually by the taxpayer.
- The tax disparities report - a summary reporting form. depicts the process of accrual and write-off of permanent and temporary tax disparities in the framework of the analytical features accessible in the system. The report's conclusions include determining the basis for deferred tax assets and liabilities accruals and write-offs. Just as the "Calculation of the tax base" is based on data from tax registers, the "Report on tax differences" is based on data from analytical registers of differences.
A mandatory solution, both methodologically and technically, is to construct an intermediate data storage level, between final reports and original documents, where tax categorization takes place (assignment of numbers of tax registers and registers of differences). The following graphic (Fig.1) depicts the overall logical structure of the data flow:
Fig.1. Data flow logic diagram
Each line of the Declaration is a straightforward total of revenue for one or more tax registrations. The "Tax Difference Report," meanwhile, is based on data from the difference registers. The Difference Report and the Declaration are both virtual objects. The level of registers is the storage level for "cleaned" and categorised data that has been optimized for a particular task.
The register numbers are calculated when main documents are transferred from the "Database" to the "Tax Accounting Module." The derivation rules might be sophisticated or simple, and they can employ any information from the original documents. The major objects of the notes, such as the account number, the cost center, the kind of internal order, and so on, are recorded together with the computed register number.
Primary accounting documents (including an accountant's certificate) are the confirmation of tax accounting data, according to Article 313 of the Russian Federation's Tax Code. Individual documents are saved in the system at the "Database" level and not transmitted to the "Tax Accounting Module." It is, however, always feasible to establish which registration a specific main document belongs to.
Each register is assigned a unique number and is the lowest-level item in the following hierarchy:
Each register is assigned a unique number and is the lowest-level item in the following hierarchy:
Figure 2: Tax Register Hierarchy
In the same way, registers of difference can be classified in the following way:
Fig. 3. Hierarchy of registers of differences
The format of the "Tax Difference Report" columns is shown in this diagram. Its lines may be formed using both tax register hierarchy and RAS accounts. A common requirement, for example, is to "scan" tax discrepancies along the lines of Form No. 2. In general, having all of the necessary analytical elements helps you to create successful multidimensional data models for OLAP reporting.
For tax accounting purposes, a single indicator – the amount of turnover in rubles – is sufficient. The financial period is the time granularity of the data stored (month). At the same time, keep in mind that the year and period in which revenue and spending are attributed to the Tax Accounting and RAS may not coincide.
Furthermore, the legislation's details necessitate the inclusion of additional analytics in the data structure "Adjustment Number."
Furthermore, the legislation's details necessitate the inclusion of additional analytics in the data structure "Adjustment Number."
Derivation of tax registers and registers of differences
The fundamental documents lack the analytical aspects of the tax register and the register of differences, which are the foundations of all tax reporting. When data is transferred from the database to the Tax Accounting Module, its derivation occurs in two steps:
- register numbers are allocated to accounting accounts and cost elements by default,
- and the final register numbers are determined using the system's derivation rules.
The actual rules for determining register numbers are highly complex, as practice has shown. First of all, there are a lot of them: each economic action for which a simple mapping to the chart of accounts "doesn't work" results in a new rule. Secondly, there is almost always some logic in the rules, which makes the process of derivation branching. And, thirdly, in defining individual rules, sufficiently large and changing sets of objects can be used (for example, account numbers, SSP elements or internal orders). The fundamental root of these difficulties is, of course, the disparity between RAS and Tax Code standards. However, they are frequently caused by irreversible "flaws" in a productive system's settings, which were developed throughout the installation phase. In a nutshell, this is the situation in which reality proves to be more intricate than "theory."
The system's key node is the generation of register numbers. If it cannot be earned entirely automatically, the claim for the creation of the tax reporting system will be invalidated, and the accountant will be forced to resort to the old method of dumping intermediate data into Excel and manually processing it.
Reporting
The reports "Income Tax Declaration," "Calculation of the Tax Base," and "Report on Tax Differences" all follow the same structure and are used for "documentary" reasons, among other things. Analytical tax accounting registers and registers of discrepancies are basic document registers. Any report's numbers must be verifiable. Finding and fixing mistakes is perhaps the most time-consuming chore an accountant faces on a daily basis. You should utilize a robust tool like BW's OLAP reporting for this purpose. Flexible data filtering and navigation functions let you tackle reconciliation and mistake detection problems in the most efficient way possible. The ability to "fall through" from report to report till reaching the principal document (drill-down) is particularly important.
Technical implementation
The following sections outline the fundamental concepts of the solution's technological execution. It should be stated right away that describing all of its details in one essay is impracticable. As a result, the author's sole purpose is to provide the reader with a broad understanding of how the aforementioned (sections?) work. The SAP BW toolbox may be used to effectively implement the requirements.
The items engaged in the BW process, as well as the data flows between them, are depicted in the diagram below (Fig. 4):
Fig. 4 Technical diagram of the data flow.
Table 1. Objects in the data flow diagram (Fig. 4).
Going from bottom to top with a full description of the data flow is sensible. In typical SAP content, the objects that make up the Database have direct analogs (in the simplest case, they are simply copies of them). Accounting records from the ERP are copied to DSO 04, and the results of indirect cost redistribution are copied to IC 03. There may be instances where tax discrepancies develop as a result of transactions on multiple accounts: accruals are made on one account, while write–offs are made on a different account. The distinction between such charges and write-offs is documented in DSO 01, i.e., the discrepancies are formed. DSO 05 keeps track of the OC and HMA depreciation, whereas DSO 06 keeps track of the DE write-off. It is required to assess data from several evaluation regions in order to appropriately determine the differences. When data is sent to DSO 02 and DSO 03, this occurs in user transformation routines. DSO 01, DSO 02, and DSO 03 would be unnecessary if the work was confined to determining the income tax base. The necessity to compute tax differences makes the technological implementation substantially more difficult.
The IS 01 info source establishes a universal interface for the register number derivation algorithm's incoming data stream. The derivation happens during the transition from IS 01 to IC 01 in the starting program. The algorithm itself necessitates a configurable tool. For implementation, BRF+ (Business Rules Framework Plus) technology is employed, which allows you to define rules of any complexity level using a common graphical interface. This method is ideal for usage inside user applications in transformations since the defined rules are automatically compiled into AVAR code. The IC 01 data cube provides all of the information required to create income tax and tax difference reports. For computations involving planning functions, the IC 02 real-time info cube is employed. It solves the problem of computing income tax for various divisions in particular. MP 01 and MP 02 multi-providers are used for reporting. MP 02 also acts as a base provider for aggregation levels that use BI-IP services such as duplicating the tax base and planning functions computations.
Data travels in the other way, up to the ERP's key records, thanks to report-report connections. Simultaneously, the reports that participate in the interfaces are constructed on virtual info providers, which are essentially shells that sit on top of real DSOs.
What's next?
Income tax, VAT, and property tax reporting are all intertwined. For example, adjusting the disclosure for one of these taxes necessitates adjusting the declaration for another. The creation of a VAT Declaration in BW is an entirely normal process. And, given the potential for reconciliation and mistake detection afforded by OLAP reporting, such a system will provide the accountant with strong tools that he is deprived of in ERP. Because the database on fixed assets was previously built as part of the income tax automation, it's a natural fit to base property tax reporting on it.
Author: Dmitry Bulatov
Candidate of Physical and Mathematical Sciences. Over 25 years of expertise developing information systems in a variety of industries. Expert knowledge of the architecture of SAP ERP and SAP BI platforms. Deep understanding of financial and managerial accounting, budgeting, and consolidation. Successful experience in building complex SAP BI and SAP ERP architectures on Russian and international projects. Expert in SAP BW, FI, CO, FI-FM functionality.