Who bears the cost of setting up APIs? From client perspective, software suppliers can levy high charges.
There isn’t an industry standard on this yet, so it’s down to negotiation between the firm and the client. Of course, as an auditor you need to be able to access the information to perform your audit, and we do have options if a client refuses to provide access to the records we need. The cost of using the software sits with the client, and really clients should be considering the cost of audit when choosing systems, but we know they don’t always do so. The ICAEW and others are speaking to the major ERP providers about this issue, so we may see more clarity in the medium term. However, do bear in mind that the cost of taking a more manual extraction approach – in terms of both quality of data and the effort required to obtain and use it, on a recurring basis – may still make the cost of setting up the API more viable, given it is typically a one-off cost.
How do you overcome situations where clients are nervous about data security etc. when using connector based systems such as in Inflo?
The best way to reassure your client is to assure yourself of the security of any technology you are using. That way you’re well placed to answer any client questions. Things you can check are whether the software comes with any security accreditation like ISO27001, and whether the software keeps data in your environment, the client’s environment, or stores it elsewhere (which, in itself, is not necessarily a problem providing there are robust security controls in place). Have an understanding of how encryption is employed when extracting and transferring the data. Where the company is based and does data processing can also be relevant – for good reason many organisations have geographic restrictions on where they are willing to send their data. And also ask if any processing is done manually or if it’s entirely automated. Systems where data is run entirely through automated processes and users are restricted from accessing are much safer for your client than systems which rely on human processing. Some technology vendors are more transparent about this than others, so it is always worth asking the question!
With all the hassle in set up etc., is it not possible to run analytics on the clients own system rather than sucking it all out?
Unless you are willing to use the client’s own finance system to do all of your analysis (and spoiler alert – they set up that system so from an independence perspective you shouldn’t be!) then there’s never going to be a way around extracting or at least reading data from client systems into your own analytics tools.
What might be possible, and what firms like Engine B are beginning to design, is ways to perform analytics in the client’s own environment (i.e. within their IT perimeter) and so reduce the pain taken to get data into the auditor’s environment safely. There are significant challenges with this, not least that most organisations won’t let you put software into their environment without knowing the details of what it does, which might mean making the client aware of your audit procedures, and the very real risk of the client’s system not having sufficient processing or storage capacity – no auditor wants to be held responsible for taking down their client’s system! But this is an ambition for a lot of firms and will likely become reality in 5-10 years for sufficiently mature clients with the right controls and checks in place.
I've recently joined a firm with a very antiquated and amateur audit approach - any advice on helping the firm understand WHY they need to become more mature, before we get to clients?
Over the next few years firms are increasingly going to find that if they don’t move towards using data, they are going to be cut out by competition. They will be stuck in the middle between firms who can offer engagements at the same prices as now but deliver significantly more insight and quality, or firms which offer roughly the same kind of output as now but for a significantly cheaper fee, because by automating a lot of work some firms will be able to make a comfortable profit from more engagements at lower fee levels.
Firms which are not investing now will face a fairly steep challenge to catch up with those who started earlier in finding out what technology works for them and how to adapt their engagements using technology. They will also find it increasingly difficult to hire and retain staff, because bright new graduates and newly qualified auditors will significantly prefer working for firms where dull, repetitive processes are already automated.
Finally, it is only a matter of time before AQA, the FRC and ICAEW start holding firms accountable for quality issues which could have been prevented using data and analytics. Even if it’s only picking up inconsistent but correct tests because of a lack of automation, it is better to get ready in advance than have to spend more playing catch-up after a bad quality rating.
I agree that the aim is for a better process but so far I've not seen it. The process is still clunky and requires a lot of input from us (the client) and we are still also required to provide the data. So, in short so far I've seen no benefit and only cost and time going up.
The first few years of adopting a new technology can be painful, and they are an investment. It can often take a while for the benefits to be realised. Year 1 of using something new is often worse than year 0, when you weren’t using it at all!
Having said that, it’s a bit like learning to ride a bike. At first it’s very difficult, you don’t know what you’re doing, you’re slow, wobbly and you’re probably wondering why bother. But once you get the hang of it, you’re away – you can go faster, further, and with a freedom you didn’t have before – and that bike-riding skill is with you forever!
From the client’s point of view, it can be particularly challenging to understand why we have to go through all of this pain when we don’t always see the benefit. In this case, it’s absolutely worth having an upfront conversation with your audit firm, during the planning stages, about what benefit they expect you’ll get from analytics, and how the process should work. Unfortunately, I wouldn’t expect them to be offering you reduced fees anytime soon – though given staffing costs and the increased pressures that audit firms are under, it may mean the fees go up less steeply. But a well-implemented data extraction approach should be able to reduce the amount of back and forth, and support a far better understanding of your system. Indeed, it may even be that they can play back some of this understanding by way of additional insight and analysis. If clients push their auditors to explain their data and analytics strategy, we’ll have many more firms implementing analytics in ways that benefit the audit and the client!
ETL has been used for many years for reporting. Can this not be used for both?
Absolutely, and a lot of the technologies used for ETL (Extract, Transform, Load) for reporting can also be used for audit. Having said that, audit often requires significantly more data than reporting does, and other kinds of data too (including unstructured data like contracts and invoices). So while the existing toolset shouldn’t be forgotten, it may not be enough on its own.
Watch the webinar, and others from the Data Analytics Community, by going to Data Analytics Community on-demand content.