Van der Aalst et al. (2018) describe RPA as an umbrella term for a range of tools that interact with systems of computers through user interfaces, in the way a human would do. RPA aims to replace manual efforts while maintaining the existing software and hardware infrastructure, rather than changing the information systems themselves, which means that it can be seen as a ‘lightweight’ automation technique (Herm et al. 2023). This implies that RPA can be implemented in many situations, provided that the process in which the RPA tools operate is well described. Since accounting information is stored in a structured way, the potential benefit for RPA is substantial (Eulerich et al. 2022). For example, Cooper et al. (2019) describe that Big 4 firms use RPA in their tax services: while clients may have multiple ERP systems being used by their subsidiaries, RPA tools can scrape these systems and consolidate the data in a consistent way to prepare tax returns. Zhang et al. (2023) provide an example of an RPA application in the finance department of a telecom provider with respect to the order entry process: customers receive an automated email with an offer to upgrade, and when a customer accepts the offer, the robot logs the information from the email (product description, price, date) into the company’s ERP system, from where the order is transferred to the operations department. More generally, Kokina and Blanchette (2019) note that common tasks that are automated involve reading an email, copying data gleaned from the mail into a form, and accessing the ERP system to log the data: for example, a robot can access a job report within the accounting system to obtain information for invoicing time and materials to a customer.

Using RPA in accounting processes can yield important benefits, both with respect to efficiency (productivity) and effectiveness (quality). By automating repetitive tasks, RPA reduces the time employees spend on these tasks, while the tasks may be completed on a 24/7 basis, and at a higher level of consistency and accuracy – provided that the source information used by the RPA tool is correct (Cooper et al. 2019; Kokina and Blanchette 2019). Moreover, RPA may have additional effects since applying it may make processes more structured and transparent, which can further reduce costs and improve accuracy (Perdana et al. 2023).

Despite these advantages, challenges exist in the implementation of RPA. From a technical perspective, a shortage of employees skilled in RPA technology poses a significant hurdle (Vincent et al. 2020). More importantly, RPA implementations that are initiated appear to have a substantial failure rate: Kokina and Blanchette (2019) state that 30 to 50% of the initial projects that use RPA to automate fail.

To understand the challenges in RPA implementation Zhang et al. (2023) provide a framework of six themes. The first theme is the workforce: the employees whose tasks are automated, as well as the employees who have to work with the output of the RPA tools, including higher managers and internal auditors. These employees have to change the routines in their daily jobs. More importantly, there are concerns among employees about job displacement due to RPA adoption (Wewerka et al. 2020). Kokina and Davenport (2017) acknowledge that low-skilled tasks in finance are at risk. Still, they argue that this does not necessarily mean that fewer people will be needed in the future: employees in the financial sector are expected to transform their work into a consultancy, supporting, or data scientist role compared to traditional accounting.

The second and third theme deal with governance and security. The IT governance of RPA implementations is important: while the automated processes do not change, the source processes may be the responsibility of different departments. Furthermore, RPA tools may give rise to auditability concerns, especially when these tools are managed by employees themselves (Eulerich et al. 2024). This is directly related to Zhang et al.’s (2023) third theme of data security, when poor design of the RPA tools may increase the risk of errors or even fraud: for example, the tool may process information that is subject to the four-eyes principle.

Zhang et al.’s (2023) final three themes deal with the implementation process. System sustainability refers to the maintenance of the tools, but also to the fact that when a tool is in place, it may create hurdles for changing and improving the underlying processes out of fear that this will impact the performance of the RPA tool. RPA impact measurement refers to the question of whether the benefits of RPA can be measured, both in terms of time savings and in terms of quality. Finally, issues of trust and communication between the employees and the developers of the RPA tool may affect success.

The themes of Zhang et al. (2023) provide a structure for analyzing the implementation of RPA. However, these themes do not fully address the dynamics relating to the employees who are affected by the RPA tools, especially with respect to why employees take the initiative to start up an RPA implementation. This is important: because RPA replaces human actions in user interfaces, the processes are likely carried out by various individual employees, possibly without a formal process owner (Plattfaut and Borghoff 2022). The input of the process owners is crucial in developing RPA tools (Kokina and Blanchette 2019), and if they do not initiate an RPA implementation it is likely that many potential applications go unnoticed. To understand why employees may be reluctant to use RPA, we rely on the Technology Acceptance Model (Davis et al. 1989) as a framework for comprehending the acceptance of new technologies within work contexts. The TAM argues that user adoption of technology is influenced by two main factors: (1) perceived usefulness of the technology, and (2) perceived ease of use, both of which are linked to system characteristics and user experience (Davis et al. 1989). While the initial TAM has been extended to include additional factors and moderators (Legris et al. 2003), we rely on this basic model for a first analysis of our case setting.

Perceived usefulness determines an individual’s willingness to embrace new technology: do users see any benefit for them in using the technology? For instance, an employee is more likely to adopt technology like automation in Excel if they perceive it as a time-saving tool, enabling them to focus on other essential tasks. Perceived ease of use impacts perceived usefulness. When users find a technology challenging to use, they are less likely to perceive it as useful. For example, an employee might understand the utility of automating repetitive work but might not invest effort if they lack the know-how (Venkatesh and Bala 2008).

The TAM has limitations. Legris et al. (2003) criticize the TAM’s assumption that people are rational and plan their actions regarding technology adoption. In reality, individuals might delay implementation despite intending to adopt a new technology. Moreover, the TAM’s focus on information systems in isolation overlooks the interplay between technology and organizational processes (Orlikowski and Hofman 1997). Venkatesh and Bala (2008) also note that the TAM does not suggest how the new technology is useful or what the perceived ease of use is. The technology is simply ‘there’; using it likely will make tasks easier or more doable, and the user has to be convinced about its usefulness and ease of use. This point is also made by Van der Heijden (2004), who argues that providing access to systems that can make work easier does not automatically translate into increased productivity when individuals are not helped or trained in using the system.

We summarize the observations for employees regarding the workforce in Table 2, where we distinguish between employees who work with RPA and employees who do not use RPA. The remaining themes are summarized in Table 3, where we also include the findings from RPA developers and managers. These are the themes concerning governance, data security, system sustainability, RPA success measurement, and trust and communication.

We illustrate the findings with interview quotations to understand and explain the reasoning of the interviewed participants. First, the users of RPA perceive benefits in terms of time savings and quality:

Well, it saves a lot of repetitive work that you don’t have to do anymore, so it saves time. Time can then be put down earlier for your analysis of things instead of having to deal with the process of running. [GL_2]

It saves a lot of time but also reduces the sensitivity to errors. Human action could make a mistake faster than a robot that is set up properly. Then almost no more errors can occur, except when, for example, you get stuck, or the robot did not run properly in some way. But the error sensitivity, that’s a lot less. [CCD_1]

Non-users argue that they do not fear for their job security but at the same time see that there are fewer and fewer people in the department. The employees understand that work is getting more efficient, and consequently that employees who retire or leave the company are not always replaced:

I don’t think it necessarily leads to job loss directly, but it does lead to the outflow of someone who retires, and his functions are taken over by other colleagues together with a piece of robots. If you consider that we as a department started in 2014 with well over 20 people and we are now only 10 or twelve and the work has remained the same, then this was mainly automation with a bit of robotization. This has all happened because functions have changed but not because anyone has been laid off. People are not replaced [when they leave] or work is merged, things like that. [AR_2]

Thus, non-users understand that when productivity increases, this will result in fewer jobs over time, but they see this as a gradual process. However, non-users put forward quality-related reasons to not use RPA. This results in employees not using robots, even when these robots are already implemented. The examples provided by employees suggest that the issues are minor, but from a user perspective they can be frustrating:

We mainly suffer from internet problems... When our Microsoft Outlook doesn’t want to open fast enough, the robot simply gives up because it can’t complete the process. We also have problems with the Q disk as we are the only one still working with it, the robot retrieves files but can no longer find the path after an update, for example [TS_1]

Furthermore, the RPA processes may be implemented in a way that does not support process owners’ existing way of working. This means that the process owners have to adjust their routines to the robot, and they do not always choose to do so. Indeed, one RPA user sympathized with non-users in this respect:

I see colleagues who don’t want to use the booking robot because they want to see the booking immediately and do not want to wait for the next day. They might have drawn up a very specific booking and then they do not want to offer it because it will be booked later, they want to book it manually themselves because then it’s right there in the system. I can imagine this, if you work part-time, for example, then you are two or three days further before you can see the booking again and when you get back to work you are busy with other things on your agenda. It should be the case that everyone can give the robot a push because then you will have visible results in five or ten minutes. [AR_1]

When there are no clear goals in the RPA implementation, and no evidence of time savings, non-users sometimes feel that the robots are being built just for the sake of having RPA. One employee described this as follows:

A robot is now checking whether a profit center dummy has been booked, if so, I receive an email. Occasionally I check it manually to see if it is still running smoothly, that is the case. Previously I had to keep an eye on SAP and now on email, the workload stayed the same. I think this process was automated just to check the box of automation. [GL_1]

Even with the dedicated RPA support, the case firm experiences difficulties in getting non-motivated employees on board and keeping them actively involved in automation projects. This is important because the process owners play a crucial role in developing robots, as described by one of the users:

I have completed a process design document, an application form in which you describe all the steps as precisely as possible. But yeah, I think there’s a lot to consider. You have to think about every step you take; Where am I going to take this step? What am I going to call this step? How often do I want this step to be performed? When exactly should this step begin? It’s fun to do, but it takes a lot of time, and you have to think it through. [CCD_2]

The importance of the input of employees is also recognized by the IM team. The IM team does not actively push employees to start working on automation and does not force employees to keep track of efficiency gains or time savings. When the team was just formed the approach was more aggressive, but working with colleagues who voluntarily ask for RPA support has led to more success:

When we first started, we might have been considered a little too ambitious and even too aggressive, too present, and too know-it-all. This led to irritation and resistance. Now we say, okay, you know, we leave it to you, we mainly focus on the areas that want support. We have very good and positive experiences with the people who visit the department voluntarily. [IM_Mgr]

In the interviews, the IM team did not see RPA implementation as a means of increasing productivity, but rather as a way of improving processes. They see RPA as a quick fix, which enables the corporate IT department to develop fundamental improvements in the underlying IT processes:

RPA relieves pressure from IT and gives room to carry out larger ICT projects. I always say RPA is the second-best choice. The best choice is total automation in the background. Only, try to beat RPA in the speed with which change can take place. [Dev_1]

Finally, while the IM unit draws up a business case that has to support the use of RPA before starting a project, once the robot is implemented there is no measurement of the benefits of RPA in terms of savings or quality improvement. The ATC unit manager looks at the overall department performance rather than at individual robots:

You can count how many robots we have if you want to quantify their contribution. But we are looking at whether we can still meet our financial goals to report in less time with fewer people [with the department]. [ATC_Mgr]

Concluding, the interview results show the multifaceted nature of RPA implementation within the organization, showcasing the diverse perceptions, challenges, and experiences of employees, RPA developers, and management. This highlights the need for improvements by showing how robots contribute to employees’ job effectiveness and by taking away worries about job loss. This requires better measurement of RPA impact, setting clear objectives for what robots should and should not achieve, and supporting employees to a greater extent in RPA adoption.

While we have analyzed the difference between users and non-users, there are also within-group differences. For RPA users, these are limited. All users are positive towards RPA, but while some users report frustration with respect to colleagues not wanting to work with robots that are available, other users emphasize examples of successful implementation. With respect to the non-users of RPA, we may identify two groups. On the one hand, non-users argue that they do not work with RPA because they do not know how to use it. They find that training sessions go too quickly, and that the required skills to work with robots are easily lost when they are not used frequently. On the other hand, non-users put forward a quality argument: they believe themselves able to do RPA projects but they first want the governance, data security and system sustainability to be clear as they worry that process owners might leave or that other employees will not be able to interpret the process of the robots. Nevertheless, for both groups of non-users, the benefits of RPA are not large enough to follow additional training sessions or ask for robot adjustments, whereas users appreciate the benefits of RPA in terms of time savings and quality improvements. This shows that different measures for different employees are necessary to help or convince them to start working on RPA-related projects.

The RPA developers were aligned in their reasoning as they followed the same procedures, worked closely together and decided as a team if and how they take on automation requests. The same goes for the manager of IM and the manager of the ATC: both agreed that the process owners stay responsible for the output of the robot, that the process had to be reviewed before requesting RPA support and that robots needed to be tested extensively before going live.

From our interviews and observations, we conclude that the employees of the case company have substantial freedom in choosing improvement projects and are not forced to work on automation projects using specific types of RPA or other software. There is no target with respect to RPA implementations, and the IM team is careful not to push its RPA services but rather tries to work with suggestions from finance employees. How can we explain why employees in this finance department choose to request support to implement RPA in their daily jobs? As a starting point for this discussion, we recall van der Aalst et al.’s (2018, p.269) definition of RPA: ‘tools that operate on the user interface of other computer systems in the way a human would do.’ Using RPA robots implies that employees have less tasks to do, and they no longer can monitor the execution of these tasks. Starting from this definition, one might argue that it is more surprising that employees voluntarily use robots and identify possible new RPA implementation opportunities than that they don’t. Building on the Technology Acceptance Model (Davis et al. 1989), we see that employees requesting RPA development support and using robots understand the benefits of the robots and have positive experiences when using them: the robots eliminate repetitive tasks, improve quality, and though this free up time for analysis. However, the interviews also suggest that RPA users have an intrinsic positive attitude towards innovation and automation. They like to think about their work processes, and they enjoy the interaction with the IM team. In part, this reflects the extension to the TAM model of Agarwal and Karahanna (2000), who identify personal innovativeness as an antecedent of perceived ease of use and perceived benefits. However, we argue that employees requesting RPA support have an additional characteristic in that they are interested in understanding and modelling their work processes, to enable the introduction of new tools. This goes beyond the willingness to try out new technology that is ready to use, which is what is captured by Agarwal and Karahanna’s (2000) personal innovativeness construct: it reflects a willingness to take a step back and consider how the various daily activities are linked together rather optimizing individual steps (cf. Schmiedel et al. 2014).

The non-users of RPA state that they do not fear for their personal job security, but they are aware that ongoing technological developments have resulted in increased productivity and consequently in lower headcount in their department. Rather than the impact on their jobs, they argue that robots do not bring time savings and are not always reliable. While they understand how the robots should function, they need to adjust their way of working to make sure that the robots function as intended. Furthermore, they are worried about the sustainability of the robots once process owners rotate, since the RPA process covers both the employees’ actions that have been automated as well as knowledge of the underlying process (cf. Eulerich et al. 2024).

For non-users, the TAM antecedents of perceived ease of use and perceived benefits are clearly negative: the non-users do not see benefits, mostly due to quality and timing considerations, while the required change to the way of working negatively impacts the ease of use. There may be several reasons why non-users do not see perceived benefits. First, it may be the result of an innate aversion to innovativeness and change (Agarwal and Karahanna 2000). Second, it may result from employees not being able to grasp the benefits of automation of some of their repetitive tasks, which can free up time for more interesting tasks. Related to this, the perceived quality and security issues that are brought up are also present in non-automated processes: employees will have to maintain their manuals, guard against the risk of getting sick, govern the process themselves, and work on the optimization of processes. However, because the case organization does not measure RPA success, there is no readily available data to convince non-users of the positive impact of robots (Zhang et al. 2023). Third, the perceived impact on job security may be more important than the employees suggested in the interviews: while they may not be able to quantify the impact of RPA in their daily work, it is clear that robots replace manual activity, and consequently a part of their current job will be eliminated. While the employees did not advance this argument, it may be present in their thinking. However, we cannot distinguish between these possible reasons based on our data.

Companies have started to implement RPA applications since the early 2010s (Van der Aalst et al. 2018), but the academic literature on RPA in accounting and finance is still in an early phase: a Scopus search on ‘robotic process automation’ shows that the first publications are in 2019 (among them Cooper et al. 2019, and Kokina and Blanchette 2019). Consequently, much literature is descriptive with limited theorizing (e.g., Eulerich et al. 2022). To the best of our knowledge, our paper is the first to use the TAM to understand why employees choose to ask for support in developing RPA applications in their own finance processes. This is different from the top-down implementations discussed in e.g. Eulerich et al. (2022) and Zhang et al. (2023). We see the key observations from using TAM to be twofold: first, voluntary RPA adoption requires users to see their activities as a process rather than a series of activities in order to understand the possible benefits. RPA is not about optimizing individual steps in a financial process but about the combination of various steps. Finance departments have many different processes which require interacting with various different interfaces (e.g., Kokina and Blanchette 2019). Automating these processes requires that employees are capable of describing and modelling the process and of identifying the automation opportunities. Not every employee in our case firm is able or willing to do this. Related to this, our second key observation is that it is important to make both the time savings and the quality improvements of RPA explicit, so as to help convince non-users of these benefits. This requires a ‘business case’ for each RPA implementation rather than an overall department level qualitative assessment as the case firm is using right now.

Finally, our results also confirm the finding of Eulerich et al. (2022, 712) that it is not clear whether RPA technology should be the responsibility of the IT department, a specific RPA department, or the finance department. In our case firm, buy-in from finance employees is essential to be able to identify processes that are suitable for RPA; however, allocating the responsibility for initiating RPA to finance employees works for some situations, but not for all.

Our results provide insight into the use and non-use of RPA in a setting where RPA use is voluntary, and where there is dedicated support for RPA development. While we cannot generalize from a case, the results do point to implications for practice in similar settings. First and foremost, we find clear support for Kokina and Blanchette’s (2019) observations that having technical capability is not enough to start RPA projects and that the process owners play a crucial role in implementing RPA. However, we also note that there seems to be a fine line between offering RPA development support to employees and pushing employees to use this support. The case setting shows that because the role of the process owner is so vital, it is essential to get them on board rather than forcing them to request and use RPA. The voluntary nature of asking for RPA support and of using RPA is probably an important reason why users are positive about RPA in the case setting. The employees of this study have dedicated RPA developers who are separate from IT, speak the same language as the employees, are available in the same building, and decide if RPA is the best solution themselves and beforehand. This level of trust and communication resulted in better-designed processes with fewer issues regarding data security, system sustainability, and communication. However, it also results in non-users not feeling any pressure or incentives to work with RPA. This conundrum complicates the implementation of RPA in finance departments, where processes typically are dispersed among employees and are not always well described, and user input is essential in RPA development.

An additional observation is that data security and privacy issues are not perceived as a major risk by employees being mentioned as too big of a risk by employees. This might be because employees know that the robots mimic employee behavior, and this behavior follows the separation of duties which is well designed into the underlying processes. Thus, the security worries which are signalled by Zhang et al. (2023) are likely less salient for employees. For the same reasons, worries about robots being hacked do not surface in our interviews (Eulerich et al. 2024). The flip side of this is that in employee-driven RPA development, these issues may receive too little attention: employees and developers may overlook these risks.

Finally, while the case firm does not have any measures in place to persuade non-users to ask for RPA support in their processes, our analysis suggests several options that any firm might consider. First, organizations can prioritize change management that involves clear communication with employees about the purpose and benefits of RPA is essential. Employees are not always able to see the upside of automating repetitive tasks, so managers should make explicit how freeing up time through eliminating repetitive tasks will result in enriching employees’ tasks. The robots do not replace employees but enable them to enhance their roles, and some employees may need support in realizing this enhancement. Second, the case firm did not use incentives in motivating employees to take on RPA projects. Such incentives may help to convince employees to put in time and effort. We note that this does not necessarily involve monetary incentives but can also take the form of granting employees time to work on this. Third, task rotation may be useful. When employees change tasks, it requires them to understand the process of their new task rather than doing the old task on ‘autopilot’. This process orientation is essential to see the benefits of RPA.