Please use Chrome for a better browsing experience as Internet Explorer is not supported

Download Chrome

Opening Pandora’s (Tax) Box

Now we’re into a new decade, LinkedIn (other social networking sites are available) has been flooded recently with people and their ten-year comparisons. What was “Person A” doing at the end of 2009, comparing it with a decade-later version of themselves and talking about how far they’d come. Mine is a similar story – at the end of the last decade I was midway through my ACA exams, working through a graduate scheme in the Big 4 at 22 years old. Now I run a Product team at a tech scale-up.

Separately, it’s testament to how far technology has moved in those ten years that we now see the world very differently. For example, “the cloud” is now a thing. Ten years ago, the vast majority of firms wouldn’t have dreamed of housing information in any way other than on-premise, whereas now most firms are cloud-only, or at least cloud-first, and desktop software and on-prem SQL servers are going the way of the dodo.


The black box of Tax Software

One thing I remember back in my graduate days was a project for a large multi-national, who wanted to roll out a tax calendar, centrally managed by their European HQed tax team. What this involved from my side was about three months of SQL-coding, to translate tax logic and deadlines into a format the system they were using could understand and render. Realistically, it didn’t require a great deal of SQL know-how, it required a great deal of copy/pasting know-how (I remember the days of your fingers aching from so many repeated bashings of Ctrl+C, Ctrl+V). This resulted in a firm relying on tens of thousands of lines of code to ensure they didn’t miss any tax filings across Europe.

Fast-forward a few years to 2012-13, where I spend a couple of years working on a year-end tax provisioning piece of software. It worked using Excel taxpacks, that would be distributed to local teams for completion, then sent into the tax team for consolidation and reporting. The technology was extremely painful to use, but the power in the tool came from the deep tax-technical knowledge that resided in the Excel taxpacks. The formulas in there were incredible (read: long) and catered for every nuance of the weird and mysterious world of tax provisioning.

However, herein lies the first problem. If you typed in £1000 into Box A, and the answer came out in Box D as £320, you just had to accept that it’s correct. Given the entirely obtuse nature of complicated Excel formulas, particularly ones with all kinds of nested IFS, LOOKUPS, array formulas, etc, you had to just trust the black box to do its job. It had a Big 4 logo slapped on it, so it must’ve been right!

And the second problem? The audit trail would look like this:

  • Person A uploaded some data
  • Person B checked out Tax pack
  • Person B checked back in Tax pack
  • Person C approved Tax pack

Excel, and other Excel-like tools, don’t give much in the way of a useful audit trail. The fact the number £1000 became £320, for example – untracked. That’s a problem that can be solved, but a problem that’s trickier to solve is an expansion on this and is something I refer to as “the whole process”.


The whole process

When doing Tax (or indeed, wider Finance) compliance, there absolutely is a key part of the process that involves data cleansing, manipulation and transmission. Numbers are key. However, the numbers aren’t the whole process. A survey we did in 2019 found that 25% of firms spend 21 days or longer doing their VAT compliance; not all that time is number-driven. For example, what about:

  • Have you checked with Geoff that he’s updated the company car log for the month?
  • Finance are meant to send the bad debts over by WD5, but it’s now WD7 and they haven’t arrived yet?
  • Have you checked with the advisers if those changes to disclosure around provisioning have come into play yet?

Or, perhaps, more commonly…

  • Come on Chris, you were meant to upload the SAP data for the whole quarter, but you only uploaded it for month 1, please try again.

There is an entire process that goes around the data that happens in compliance, that is typically lost with tax software. Legacy tax software, built by accountants, focuses on translating tax IP into code. It’s not designed with users, or the whole process, in mind.


The rise of the Product Manager

Over the 2010s, the emergence of Product teams across the technology landscape has been huge. For example, me, and my team, went to MindTheProduct back in October, along with 1,500 like-minded others. MindTheProduct as an organisation that wasn’t even founded until 2010, with the first meeting of 25 people, in the back of a London pub. Product as a profession has come a long way.

Tax, as it often seems to do, has somewhat lagged behind other industries in terms of its adoption of new technology. LegalTech came to prominence in the mid-2010s, and the term “FinTech” is already up there along with Blockchain and RPA as key “buzzword bingo” terms.

The one key thing I’ve been proud of personally during the 2010s is my career change; from “technologist” (or even, if I really have to say it, “Taxologist”) to “Product person”. To some it may be semantics, but to me they are totally different things. Taxologists are people that sit at the intersection of Tax and Technology, so are able to build out custom tech (often 3rd party tech, like SAP, or an RPA tool) that works for their specific tax department. The difference with Product is that we add in User Experience (UX) to the mix, and focus not on codifying tax logic, but on solving user problems for whole industries. At a recent Tax Technology conference, I listened to ten minutes of a talk on RPA where the speaker (Head of Tax at a well-known FTSE) said that to use RPA for Tax you basically needed a coder in your team. I shuddered. That’s why Arkk are different.


Breaking into the black box

When we first launched for:sight, we used SQL to do transformations. That was because we needed to get to market, and SQL can cater for all of them. However, it meant our users couldn’t understand what was going on with their data, which we didn’t like. That’s why we’ve improved both our uploads and our data transforms to enable our users to understand what’s going on, and to be able to amend them if things change. For example, when transforming SAP data:


No more SQL, just an easy-to-use interface that explains how data is re-coded. Digitally linked, auditable, usable.


Catering for the whole process

This is an area we’re always working on. The first step on this journey landed late last year, when we added comments and @mentions into the platform. This enabled our users to have a meaningful dialogue in the product, without having to resort to separate email chains or untracked phone calls. By adding these in, giving them context, and emailing users that have been mentioned, we empowered our users to start moving the whole process online:



Ten years has seemed like a lifetime in technology, and on a personal note I’ve moved from Chief Copy-Paster to Chief Product Officer. It’s also meant that by hiring a Product team not just made-up of accountants (yes, there are still some, myself included…) my view on technology has changed. It’s meant that we don’t take a “traditional” view on TaxTech, and that’s only a good thing. The 2010 decade of Tax software is one that we should all be keen to leave behind as soon as possible, and I look forward to the end of the 2020s when we have a good laugh about what came before. Tax, and tax software users, have many problems to solve, and at Arkk, we look forward to solving them.