Tax requirements are changing
Requirements towards TaxTech solutions exemplified by non-cash benefit processing
Changed framework conditions
GoBS / GDPdU and GoBD point the way
As early as 1995, the Generally Accepted Principles of Computer-Based Accounting Systems (“Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme” GoBS) 1 contained statements on the internal control system (IKS) and on the fact that the description of this system is also part of the procedural documentation. The GoBS were continued in the Principles Of Data Access and Auditability of Digital Documents (“Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen” GDPdU) 2 published in 2001 and finally in the Principles of Proper Keeping and Retention of Books, Records and Documents in Electronic Form as well as Data Access (“Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff” GoBD) 3 published in 2014. The latter were amended in November 2019 and adapted to current IT developments. 4 The respective requirements do not only relate to the actual core accounting systems, but fundamentally affect all systems that collect, generate, store or process tax-relevant data.
“An offer to taxpayers”: Tax CMS
With the publication of the Application Decree on Section 153 of the German Fiscal Code (AO) 5, the tax authorities have outlined their offer to establish so-called tax compliance management systems ("Tax CMS"). In it, the Federal Finance Ministry distinguishes between purely tax-related corrections pursuant to Section 153 AO and voluntary disclosure pursuant to Section 371 AO. Accordingly, a Tax CMS can be an indication against conditional intent and thus work in favour of the taxpayer, in that the notification is evaluated as a correction according to § 153 AO and not as a self-disclosure according to § 371 AO. Accordingly, the existence of a Tax CMS or corresponding processes can represent a weighty argument and must be taken into account by the tax auditor or the fine and criminal proceedings office when assessing the relevant facts.
Tax control design is always of particular relevance. Care must be taken to ensure that components such as user control, plausibility checks, completeness checks, a dual control principle or approval loops are introduced and implemented. Specific information on the practical design can be found in particular in the GoBD.
Changes at tax authorities
The tightened framework conditions in many areas have also led to a significant change in tax audit practice. In addition, the "digital evolution" has also found its way into tax administration and the increasing availability of digital information has long been screened by means of IDEA & Co. Further developments such as the targeted use of risk management systems and the use of artificial intelligence and machine learning will follow. And yet another trend is currently emerging. Tax auditors are increasingly asking questions about tax processes, controls and the associated process documentation.
The audit procedures of the tax authorities are in part comparable to those of the auditors. Individual processes and the associated IT systems (preliminary and core systems) are scrutinised for their systematic functionality and the existence of controls and, if necessary, validated by auditors specially trained for this purpose.
Demands towards internal (auxiliary and preliminary) systems with non-cash benefits as an example
In the light of tighter demands and changing framework conditions, questions about what a software must be able to do in order to compete in this context arise. We attempt to illustrate the respective demands towards TaxTech solutions with the taxation of non-cash benefits as an example.
What systems are relevant?
The subject of an external tax audit, according to the GoBD, are the documents that must be recorded according to non-tax and tax regulations and the documents that must be kept according to § 147 (1) AO; in simplified terms, this can also be referred to as "tax-relevant data". These are not found exclusively within the core accounting systems (e.g. SAP FI, DATEV, etc.), in fact the opposite is true. Thus, upstream or downstream systems such as cash register systems, merchandise management systems, systems for time recording, document management systems or travel expense accounting must also be included in the consideration. In the context of the taxation of non-cash benefits, the focus must be placed on financial and payroll accounting systems as well as on purchasing and travel expense systems.
Generic GoBD requirements
The German Fiscal Code (Abgabenordnung), made more concrete by the aforementioned GoBD, imposes numerous requirements on process design and, in turn, on the tax-related ICS. In the following, we will examine three essential requirements in the context of the taxation of non-cash benefits in more detail. Completeness All non-cash benefits must be recorded individually and in full. Particularly in the case of frequently occurring cases involving gifts, hospitality or even smaller in-house events, manual processes usually quickly reach their limits. In the GoBD the tax authorities therefore require that the "complete recording and reproduction of all business transactions must be ensured by a combination of technical (including programmed) and organisational controls (e.g. recording controls, etc.)". This includes plausibility controls during data entry, content-related plausibility controls, automated data set number allocation, gap analysis and multiple assignment analyses for receipt numbers. The use of MS Office products such as MS Excel can barely meet these requirements as they don't fulfil various requirements (change logging, consistent data retention, etc.). In this context, system-based TaxTech solutions guarantee completeness in recording thanks to automated checks.
Data inalterability
According to Section 146 (4) AO, a booking or recording may not be changed in such a way that the original content can no longer be determined. To this end, no changes may be made that do not allow conclusions to be drawn as to whether they were originally or subsequently initiated, according to the GoBD. The data processing method used must provide a corresponding guarantee that all information (including information on contributions in kind), once introduced into the processing procedure, can no longer be suppressed or overwritten, deleted, changed or falsified without being identified.
The recording of all data should therefore be done in such a way that the content of the original version can be determined subsequently. In other words, changes must be able to be traced after they have been made. Suitable controls for this aspect are demanded and must be performed by the taxpayer. Technically, this can be done via automated change logs in the systems. These must always be implemented in such a way that the logs run in the background and cannot be altered manually.
Neatness
Receipts can be assigned to bookings and vice versa in many ways. Assigning unique identifiers such as numbers or bar codes can be used to establish an unambiguous reference. Modern systems also allow users to “pin” the receipt to the respective booking so that one can access the receipt directly from the booking entry. Alternatively, one can link the receipt to the associated booking. In the area of non-cash benefits whose tax assessment often requires secondary documents such as procurement invoices or other documents (participant lists, flyers, etc.), in particular, electronic links can yield substantial time saving and thus, significantly improve usability.
Compliance via software
Tax regulations
Based on generic GoBD requirements, a suitable software has to map the existing tax specifications correctly and consistently. § 37b EStG (non-cash benefit income tax flat rates) form the core rules in the context of non-cash benefits. Flat rate taxation is regularly excluded if (1) expenses per recipient and fiscal year or (2) expenses for individual benefits exceed an amount of 10,000 Euros. However, the Income Tax Act offers other flat rate taxation options as well as countless exemption limits and allowances. The example of “company events” illustrates the associated tax-related complexity. Apart from income tax flat rates in special cases acc. to § 40 EStG, a tax allowance of 110 Euros per employee must always be taken into account. With this in mind, it is hardly surprising that many companies fail in monitoring their tax limits. And what’s more: Since they often cannot produce proof, companies sometimes even forgo the application of exemption limits such as the 44 Euro limit for non-cash benefits.
Data collection
As early as data entry, an intuitive solution should guarantee that all tax evaluations concerning non-cash benefits are completely and correctly incorporated into further calculations, without requiring tax-related background knowledge. To make this possible, all required documentation mechanisms should act in accord. Translating technically recorded data into cases that can be evaluated in terms of tax must, in the end, be provided by the tax regulations stored in the solution.
Figure 1: CITAX NG recording of benefit master data
A maximally easy-to-use user interface (UI) with input masks divided by topic should guide the user through the individual data areas step by step and ideally, without appearing overly complex. Modern web applications focus on so-called user experience (UX) connected with the target of high acceptance. Even technologies such as intelligent algorithms and machine learning will increasingly trickle into the respective solutions and are increasingly used to collect and detect data.
Workflow
Wherever tax-related cases are processed by tax “laypeople”, in particular, a system-supported workflow can help. The latter should suggest various verification and approval paths, depending on criteria such as case types, value limits etc. It can also be used to set up a “double checking principle” as well as approval procedures (approval by superiors, checks by tax departments and the like) and thus, sustainably secure tax compliance.
System integration and interfaces
The implementation of interfaces plays an important role when it comes to mapping a complete end-to-end non-cash benefit taxation process in a company. The following applies to this: The deeper one integrates a software solution into an existing system landscape, the higher the chance that tax processes are completely and regularly covered by it. The process chain should stretch from receipt intake and check to electronic filing and, later on, the provision of documents to tax authorities and should embed itself into the existing IT ecosystem such as ERP systems and electronic filing systems maximally seamlessly. To this end, target systems such as accounting or payroll should be automated and fed with the respective data. Finally, the system should be equipped with suitable evaluation capabilities that can then also be provided to tax authorities in the course of data access.
Procedural documentation
Meaningful procedural documentation is to be kept for systems used in the framework of non-cash benefit taxation, including the implemented interfaces – documentation that provides complete and concise information on content, sequence and results of the IT procedure. The goal should be that auditors (expert third parties) receive an overview of the system and insights into how tax-related activities are processed.
Figure 2: CITAX NG workflow
The procedural documentation usually consists of a general description, user documentation, technical system documentation and operations documentation. Software usually comes with suitable documentation elements. These should then be used for training purposes by the employees responsible for the system. Additionally, however, one needs to regularly and individually adapt the procedural documentation to the company's unique features such as receipt checks, filing or data access provisions.
Summary
Digitalisation is the talk of the town and affects almost every field of economic activity. It's hardly surprising that demands towards processes and IT systems are also on the rise in the field of taxes. Adding to this is the fact that tax authorities themselves tighten their framework conditions and digital audits increase pressure on taxpayers to change. In times of skilled labour shortages, in particular, support the IT systems that can be neatly integrated into existing process landscapes, help tax departments shoulder their tasks and evaluate tax-related cases, thus creating the required tax compliance.
Figure 3: Process and system integration
References
1 BMF vom 07.11.1995 – IV A 8 – S 0316 – 52/95, BStBl. I 1995 S. 738.
2 BMF vom 16.07.2001 – IV D 2 – S 0316 – 136/01, BStBl. I 2001 S. 415.
3 BMF vom 14.11.2014 – IV A 4 – S 0316 - 13/10003, BStBl. I 2014 S. 1450.
4 BMF vom 28.11.2019 – IV A 4 – S 0316/19/10003 :001, BStBl. I 2019 S. 1269; zu den Neuerungen vgl. ausführlich Groß, Rethinking Tax 1/2020 S. 50.
5 BMF vom 23.05.2016 – IV A 3 – S 0324/15/10001, BStBl. I 2016 S. 490.
This contribution's author Ralph Schmieder is responsible for the Tax Solutions field at DCCS and the first contact person for tax-related IT solutions and projects.
Get in touch!
We are looking forward to your message
* Please fill out all fields
