Data skills can make the difference between a good Tax Technologist and an excellent one!
Tax Technologists rightly covet their knowledge of Tax engines, ERPs and Tax Reporting tools as well as their implementation experience. These are the headline skills that recruiters look for and lands them jobs. However, the skills that bring extra levels of success are those associated with data. The converse is also true, namely that a lack of focus on the data, even if Tax technology tools are implemented well, will likely result in disappointment at some level. Let’s examine further.
It’s all about the data
First, let’s face facts. If Tax departments were factories they would only have one input – data, and one output – information (data manipulated such that it acquires business meaning or purpose). Some of that information is legal or strategic in nature, but in this article we are concerned primarily with transaction level data.
The Tax department of today is one of the largest consumers of transactional data in the organization. The commonly held view of tomorrow’s Tax function is that it will graduate from consumer status to that of owner, shaper and contributor. However, it is difficult to take more responsibility for transaction data enrichment when for the most part they languish with passive, after-the-fact spreadsheets as their primary data management tool.
Step forward automation. The rollout of Tax engines in particular, should result in the center of gravity for Tax data responsibility ticking upstream in the business flows, but is this actually happening on the ground in the real world?
Let’s set aside that question for the moment.
Tax Technology products work. It’s the Data that’s the problem
Arguably in the past, some of the major internet-era Tax Technology products did not live up to the blurb on the tin. That is no longer true. Today’s leading Tax engines make good calculations and Tax reporting tools create accurate returns. So when results are questionable, which is often the case, it is frequently the data that is the problem.
Of course this is not new. Any Tax Technology project has a significant data component, and the products themselves give over a surprisingly large proportion of their functionality to interface data manipulation. The issue is that implementation projects tend to focus on the data formatting needs of that single tool rather than an overall data model that will serve the entire Tax function and beyond.
Two simple examples show how this can manifest itself:
- When Tax Codes are designed during a Tax engine project ensure they serve the Tax Reporting tool as well as the immediate AR or AP transaction in question. This eliminates the need for further manipulation when extracting from ERP to reporting tool.
- A good understanding of the data will usually show that it is better to use ERP as a source for Tax Reporting than the Tax engine audit trail. This might be counter-intuitive, but data issues and other work-arounds needed to make the Tax engine work on an imperfect ERP generally dictate otherwise. Only by truly understanding the data can this be assessed and/or mitigated.
Returning to our question, it seems that often data is secondary to making the tool work, and is handled implicitly and partially rather than explicitly and comprehensively. This might seem natural when it is the tool that carried the high purchase price or when the data is tied up inflexibly in ERP, but the opportunity cost of this approach can be high.
Data and Digitalization
Unfortunately, sometimes the global Tax automation industry gets a bad rap when in fact it is lack of a cohesive data strategy that is the issue. This concern is magnified when full digitalization of the Tax function is considered – see here for the differences between automation and digitalization. Only a full set of Tax-shaped fingers in the ERP pie will afford a chance for success.
It has become easier over time to find resources with good skills around Tax Technology products, but the most successful ones are those that address the data issues. Tax data sensitization in ERP and Tax data lakes are the way forward, becoming the foundation upon which 3rd party Tax Technology products work.
Start now – even if full realization is some way off, and at least make sure that current projects lean in the right direction. It is time to call out data out as a separate component of the skills matrix if the Tax function is going to embrace the new demands being placed upon it now and in the future.