Corporate tax practitioners have received many invitations for webinars and seminars about the "Future of the Tax Function," with related technology consulting and software offerings. Tax functions, it is said, will leverage predictive analytics to anticipate and mitigate the likelihood of audit, use connected general ledger systems that interface directly with government systems, and rely on intelligent software capable of taking action without human intervention.1 At the heart of these predictions is a promise of automation; that is, through the automation of everything from the tax return preparation process to the collection of sales tax exemption certificates, tax practitioners will cease to be movers and processors of data.
In a world of machine learning, neural networks, and robotic process technology, these promising outcomes are at least theoretically possible. But the practical reality of the automated tax function remains elusive for several reasons: First, in most firms, a technology project must be justified by payback. Second, tax functions do not implement technology in a vacuum but, rather, are prioritized within an enterprisewide technology demand management process. Finally, during the process of implementation, the firm will encounter resource constraints, in that its teams will need to keep up with legacy processes while serving as implementers of new technology solutions. In short, there are only so many dollars, people, and hours in the day.
Approaches to these tax transformation obstacles — payback, technology demand management, and resource constraints at implementation — are discussed below. For purposes of this article, it is assumed that the basic ingredients for tax automation already exist in a finance organization. These could include, for example, a recently established center of excellence for development of robotic process automation (RPA) throughout the finance organization or recently authorized project spend on solutions that augment the quarter close. In either case, the practical realities of corporate tax function automation are no less daunting at this stage. For tax leaders, the question is, what next?
The outsourced-automation conundrum
The technologies that support tax automation are unavoidably attractive, as with any technology on the automation or "cognitive" technology spectrum. Promises of a more efficient close, fewer late nights during time-compressed compliance periods, and improved controls appeal to tax managers and staff alike. But at budget time, automation projects may need to do more; in most firms, they must first present a compelling return.
Consider, for example, a tax team that seeks to automate the creation and export of a set of reports from Thomson Reuters's ONESOURCE Tax Provision (OTP) for use in an account reconciliation tool, such as BlackLine, which generally occurs during each quarter close. This task has all the indicia of one that can and perhaps should be automated. Specifically, the task is rules-based and repeatable. It must be completed routinely each quarter. Automation of the task would free up many hours of one or more associates' time. Well-documented, step-by-step desk procedures that explain how the process is completed by an associate-level staff person are in place. These attributes put the task in the wheelhouse of automation.
Having determined that the task is ripe for automation, the firm calls its chosen outsourced-automation provider to develop cost estimates for the project. To develop this robotic task, the provider tells the firm, it will need both RPA and several Microsoft Visual Basic scripts to format the data once it is exported to Microsoft Excel. Nevertheless, relatively few variables and "clicks" are required to complete the task, so the provider scores this as a low-complexity robotic process, estimating development costs of approximately $50,000 and a run rate of $5,000 annually to maintain and update the bot.
With these estimates, the automation project will yield a negative return. Given the simplicity of the task, it is assumed that a temporary resource from an accounting staffing firm could complete it by following written desk procedures in approximately 20 hours each quarter, at a fully loaded hourly rate of $60 per hour. This cost — $4,800 per year — is dwarfed by the cost of the automation developer's proposal of $50,000 with recurring annual maintenance of $5,000. The firm may attempt to justify the cost of automation on other grounds, such as enhanced internal controls, but at this differential, a valid business case is more than a heavy lift.
This problem is inherent across many low-volume, automation-ready activities. There are, of course, high-volume use cases where the quantitative case for outsourced development will prove attractive. But, more often than not, this issue will arise for repeatable, rules-based tax function tasks. In particular, brief, rules-based tasks are littered throughout income tax compliance and tax provision processes. If automated, these tasks could aggregate to significant overall automation of the function. But the cost of the external expertise required to implement this automation will often far exceed the cost of continuing legacy processes with labor. This is the outsourced-automation conundrum; expertise in the automation of repeatable tasks is abundant in ready-to-serve firms, but the cost to deploy this expertise may invalidate the business case for doing so.
If this is so, why not pass on automating the low-volume activities and continue to apply human labor to these tasks?
The strategic case for tax automation
There is a clear disconnect between the case-by-case quantitative analysis of automation use cases, like the one above, and the strategic choice to implement automation in the back office broadly. The former has intuitive appeal as a firm builds the annual tax budget or rationalizes IT spend. It empowers a finance department to accept any individual implementation on its quantitative merits alone. But, over the long term, this incremental approach is a half-measure in the context of a more compelling transformation.
The cost of a corporate tax function is often higher than that of peer finance disciplines, driven both by overall professional fee demands and generally competitive labor markets for in-house tax personnel. Corporate tax departments themselves also tend to be small — the average large-company function has only 16 employees at headquarters2 — which makes each team member's contribution critical. But tax directors and staff alike describe the day-to-day work as primarily driven by the need to find, extract, and manipulate data. That is, the bulk of a corporate tax practitioner's day is spent moving data into and out of Excel, organizing that data to complete one of a number of commonly used calculations, and using that calculation to reach a conclusion or complete a filing obligation.
This poses parallel problems of management: First, using the few tax personnel the business has, at a relatively high cost, to find, extract, modify, and push data is uneconomic. These low-value tasks are the province of database applications and reporting engines rather than the stuff of thought-work. But a related problem is likely to be significantly more costly to the organization. While the firm's tax team is working away at spreadsheet development, they are not identifying tax opportunity, challenging auditors, or working with business partners to tax-optimize transactions in process. These tasks are decidedly strategic and require real thought from tax personnel with a deep understanding of the tax law and accounting literature. These personnel may be available but otherwise engaged with the business of manually working through a morass of disaggregated tax data. Enabling these personnel to address the business's important strategic areas without significantly increasing tax headcount requires an accumulation of automation across the many brief, repeatable activities of the function. In short, the case for extensive automation is also the case for a strategic, versus transactional, tax function.
If the often high cost of outsourced-automation solutions and the strategic imperative to automate low-volume tasks are mutually exclusive, insourcing tax automation may provide a viable alternative. In this case, insourcing may be achieved at the enterprise level by building development capacity in the firm's IT function with skill sets in RPA and scripting languages (such as Microsoft Visual Basic for Applications (VBA) or Python). This is the usual approach, but directing this tax automation work to the firm's IT function invites a host of problems. First, the IT function will inevitably be managing competing requests from across the organization, and tax automation proposals may not fare well when compared with other, broader IT initiatives. For tax leaders, it will often be hard to compete for project time and resources within such an enterprisewide technology demand management process.
Consider for example, the business case described above, which failed a cost/benefit analysis when outsourced development was assumed. While the cost may be improved by insourcing, the cost/benefit of other, larger projects that serve more enterprise users will likely crowd out these small, incremental tax automation projects.
Second, the nature of tax automation is to be read-only and low-risk. Excel-like data manipulation is used to reach a calculated result rather than drive a system-based customer interaction, general ledger entry, or other outcome. As a result, many of the risk-mitigation techniques employed in the usual IT function development process, such as the involvement of the project management office or the use of nonproduction environments for development, will be overkill and significantly slow the process, while increasing the expense, of deployment. A more agile approach is required. The perhaps surprising answer is to insource development of these low-risk incremental automation cases into the tax function.
At first glance, development of these solutions by tax personnel may seem a daunting workaround to the problems of outsourced development (cost) and rejection or indefinite deferral by internal IT development resources. The typical tax practitioner has a software skill set that focuses on Microsoft Office and tax compliance or provision software. But many of the new tools of automation are code-free and require little more technology savvy than do the tools required to complete processes manually. Further, new associates may be willing and excited to learn the more complex process of developing automation via scripting languages, such as VBA and Python, to create powerful, agile, desktop-level automations. Integrated development environments have further democratized these tools, making them accessible to finance professionals without prior formal training in computer science.
As a starting point, a tax function might simply make an RPA license (such as Blue Prism or UiPath) available to a tax associate for experimentation. The setup of an RPA development environment requires internal IT support, but once it is established, the barrier to entry for a tax associate to attempt development is low. Training partners offer weeklong courses to new developers, which are sufficient for basic RPA development, and no code is required.3 Within Blue Prism, for example, tasks and procedures are visually represented in process maps and can be read and followed intuitively. As described above, this type of insourcing provides for the organic development of solutions by tax team members, based on need and at low cost; avoids the significant investments required of a formal software development initiative with IT support; and, if managed appropriately, will yield nominal IT security risk.
Mapping the automation journey
Given a strategy to introduce automation across the function and the identified obstacles to implementing automation in low-volume tasks (such as the outsourced-automation cost obstacles noted above) the firm's entry point in the tax automation journey should be a high-volume, high-return-on-investment (ROI) process such as one from the indirect tax space. A firm might, for example, begin with automation that modifies Vertex return data, converting the many repeat, manual return adjustments required for each month's sales tax compliance. Ideally, the payback for such a project will come in the form of some reduced cost, such as professional fees avoided, and this will be most possible in the context of these high-volume, manual, repeatable tasks. With payback, these projects may proceed with outsourced development, providing early wins and garnering support for the overall tax automation journey.
During this first phase, as outsourced development of high-volume, high-ROI use cases proceeds, selected associates may begin a parallel retooling phase. Specifically, these team members will complete training to enable downstream internal automation development. As described above, this will require access to the company's RPA development environment, completion of online training modules, and meetings with other technology gatekeepers to answer implementation questions and provide other necessary support. For example, what are IT's ground rules for RPA developers? Is testing by internal audit required before putting an automation into production?
In a particularly tech-savvy tax function, this retooling phase can also involve training in the building blocks of script-based solutions, such as via Python or VBA. These programming languages will enable the function to independently develop automation solutions at the desktop on the fly and to leverage application programming interfaces that avoid the problems sometimes associated with RPA, such as unexpected changes in the login screen of a key application that can cause purely robotic automation to fail.
As the first phase of outsourced-automation development for high-return projects winds down and staff retooling is completed, the second phase of internal development by the tax team can begin. This will facilitate automation of many lower-frequency tasks in the income tax area. Consider, for example, applying automation to enable the function to use the journal entry module within OTP for quarter-close tax accounting. Practitioners may not currently be able to use the standard module outputs, given a particular formatting requirement in accounting, and customization options are limited. Here, reliance on the OTP journal entry alone might introduce significant manual work and control risk to reformat or modify the stock output from OTP. But in most cases, this issue can be corrected via a combination of a simple VBA or Python script running after a Blue Prism bot call.
The security risks associated with these automations are nominal, and the development time may be rapid if kept primarily within the function. The result is likely to increase controls and significantly decrease non—value-added manual work during the income tax close. Many other similar use cases exist in the income tax area, and, once the tax function's development skill set is in place, these automations can be stacked together, driving tax automation at scale.
A strategic destination
Pervasive tax automation presents a host of cost, demand, and resource problems. But these can be overcome by upskilling the function to develop automation internally, while targeting high-frequency automation use cases with outsourced teams. In the aggregate, a critical mass of automations, both high- and low-frequency, promise a transformation of the function. This transformation will enable the evolution of tax from transactional support team to a strategic, value-creating thought center — the result of a carefully crafted automation journey.
Building a Robotics Process Automation Business Case (#188750, online access)
Robotic Process Automation Fundamentals for Accounting and Finance Professionals Certificate (#188710, online access)
For more information or to make a purchase, go to aicpastore.com or call the Institute at 888-777-7077.
|Michael Sala, CPA, J.D., M.S., is head of tax for United Rentals Inc. in Stamford, Conn. He is a CPA and attorney and is admitted to practice in Connecticut. For more information about this article, contact firstname.lastname@example.org.