Skip to main content

Tax Compliance in Software Engineering: The 30-Billion-Dollar Software Engineering Problem

Tax Compliance in Software Engineering
Table of Contents

If software systems and their developer (teams) are geographically distributed, software engineering has an often overlooked implication: Software engineering across borders becomes taxable.

This very legal implication is the foundation of the litigation between Microsoft and the US tax authorities (IRS) in which the IRS alleges that Microsoft owes an additional $28.9 billion in tax from 2004 to 2013, plus penalties and interest.

In this blog post, we explain why taxation of globally distributed software engineering is not a tax problem but actually a software engineering problem and how we, as software engineering researchers, can remediate it. Therefore, we first need to understand the foundations of international taxation in the context of globally distributed software engineering, before we can discuss how Microsoft addressed tax compliance and where the fundamental problem lies.

Foundations of International Taxation for Software Engineers

Let’s dramatically simplify, Microsoft consists of only two legal entities: Microsoft US and its subsidiary Microsoft Ireland. (In fact, there are two more relevant subsidiaries for this case: Microsoft Operations Puerto Rico and Microsoft Asia Island. We select Microsoft Ireland only as the mechanics are similar.) The developers in the US employed by Microsoft US develop only one product, the operating system Windows, jointly with their Irish colleagues employed by the Irish subsidiary Microsoft Ireland. Microsoft Ireland then sells Windows across all of Europe. Without any further consideration, solely Microsoft Ireland generates profits, which are then fully taxed in Ireland according to Irish law. The US tax authorities (IRS) are left out in the cold because Microsoft US has no share of the profit that could be taxed in the US, although Microsoft contributed significantly to the product that made the success of Windows possible.

To avoid this scenario and to provide a common ground for international taxation, reducing uncertainty for multinational enterprises, and preventing tax avoidance through profit shifting, nearly all countries in the world agreed on and implemented the so-called arm’s length principle as defined in the OECD Transfer Pricing Guidelines for Multinational Enterprises and Tax Administrations.

The arm’s length principle is the guiding principle and the de-facto standard for the taxation of multinational enterprises that requires associated enterprises to operate as if not associated and regular participants in the market from a taxation perspective. This principle ensures that transfer prices between associated companies of multinational enterprises are established on a market value basis and not misused for profit shifts from high to low tax regions.

To comply with the arm’s length principle, Microsoft US and Microsoft Ireland need to operate from a taxation perspective as if they were not associated. Since a regular participant in the market would not provide code contributions, whole components, code reviews, tests, architectural designs, or other contributions free of charge to a closed-source software project, Microsoft Ireland needs to pay for the received contributions, the so-called transfer price.

Transfer prices are the prices at which an enterprise transfers physical goods and intangibles or provides services to associated enterprises. Since software is intangible itself, the transfer of intangibles like source code, components, code reviews, bug reports, etc., is our focal point. This transfer price guarantees that Microsoft US gets its share of the profit, which then can be taxed by the US tax authorities.

In the following figure, we provide a schematic overview of transfer pricing from our simplified example. Although Microsoft US contributed significantly to Windows, the product that is sold in Europe, without a transfer price, Microsoft US has no share of profits; all profits are fully taxable in Ireland only. However, if Microsoft Ireland pays a transfer price reflecting the value of the services and intangible properties received from its associated enterprise in the US, Microsoft US realizes profits which then are taxable in US.

A schematic overview of the necessity and mechanics of transfer pricing
A schematic overview of the necessity and mechanics of transfer pricing: Without considering a market-based compensation, the so-called transfer price, Microsoft US has no share of the profits which could be taxed by the IRS; all profits from the European customers are with Microsoft Ireland and, therefore, all taxes stay within Ireland.

So, how do we now determine a transfer price? The OECD knows five different approaches to determining transfer prices. Microsoft applied one of them, the so-called cost contribution arrangements or short CCA.

At this point, we make two simplifications for didactic reasons we would like to explicitly disclose: (1) The IRS regulations refer to cost sharing arrangement (CSA). In this blog post, we follow the terminology of the OECD Guidelines and refer to CCA. For the sake of this article, they can be assumed to be synonyms. (2) The OECD guidelines know two types of CCAs: Service CCA and Development CCA. Although both are relevant in the context of software engineering, we focus on Development CCA in this article.

In the software engineering context and in layman’s terms, a CCA is a contractual arrangement between subsidiaries to share the assets (software or data) and risks involved in joint development. Each participant of a CCA has rights to the assets shared in the CCA. These rights usually allow the participant to use the assets in a specific region or for a particular purpose. If a participant has rights to any property developed by the CCA, they do not need to pay royalties or other fees to use it (i.e., a transfer price), as long as their contributions are in line with their expected benefits. If not, additional so-called balancing payments are necessary.

The Microsoft Case

Now that we understand the core principles by reference to our simplified setup, we can now look into the actual case. Please note that we heavily rely on the article by Curtis and Avi-Yonah from 2023 who published a detailed account of the Microsoft case in Tax Notes International in March 2023 for this article because detailed information on the tax audit itself is not publicly available. However, the careful and thorough analysis by Curtis and Avi-Yonah allows us to draw conclusions on Microsoft’s tax compliance approach for their software engineering and why the tax audit escalated.

The controversial point boils down to one question: Is Microsoft Ireland a legit participant of the CCA or is Microsoft shifting profits from the US, where the intellectual property, i.e., the software was actually created and developed, to Ireland and profiting from a corporate income tax there?

Although Microsoft Ireland made a $7 billion buy-in payment to join the CCA in 1999, has about 2000 employees from 71 different nationalities and the local administrative support functions, such as finance, human resources and sales & marketing for Europe, the Middle East, and Africa also appear consistent with the economic substance, the IRS reckons that Microsoft Ireland is a legit participant of the CCA. From the IRS’ perspective, “appeared to play little if any role in the production side of the exploitation activities for the [Windows] […] and primarily performed marketing, sales, and support functions”. Like any tax authority, the IRS is allowed to adjust the transfer price where the prices charged are outside an arm’s length range in accordance with the OECD guidelines. Such an adjustment will carry interest and might be coupled with penalties. In the wake of the OECD’s Base Erosion and Profit Shifting (BEPS) Project, the regulatory framework has become considerably stricter at an international and national level. As a result, the IRS demands $28.9 billion from Microsoft.

Why does the IRS reckon Microsoft’s CCA and Microsoft Ireland as a legit participant of the CCA? There are two main assumption about the software engieering of Windows.

The first assumption is captured by the following quote from Curtis and Avi-Yonah: “Windows operates flawlessly for most users with each successive version because the new version consists only of new programming added to the prior versions with a continuous rolling process of development, testing, launch, and patching. In other words, any new version of Windows is basically the previous version with new features layered onto it in a rigorous testing environment. As a result, the Windows source code has an extremely long decay rate for transfer pricing purposes.” Following this line of reasoning, the value attributable to ongoing software development is comparatively low and the value of previously developed software is high. Undervaluing legacy intellectual property, stipulating artificially low (non-arm’s length) buy-in payments, constitutes an important way to shift substantial IP-based profits offshore. However, there are good counterarguments for undervaluing the continuous development activities from a software engineering perspective:

First, maintaining legacy software is known to be costly, problem-prone, and requiring extra care. For example, older programming languages like C and C++, the dominant programming languages used for the development of Windows, are known for being prone to vulnerabilities that are based on memory errors. Although there are many approaches for mitigating memory errors in C and C++, those memory issues are still the root cause of about 70% of all security vulnerabilities. Modern programming languages inherently protect software from such memory errors and, thus from bugs or vulnerabilities based on memory errors. Thus, we find it difficult to agree that Windows is only a core of legacy (previously developed) software with layers of new features added on top of it.

Second, the perspective neglects the differentiation between interface and implementation, a core principle of software engineering. Microsoft, commensurate with this core principle, is known to carefully avoid changes to Windows APIs while further developing and improving Windows. Every change in how Windows interacts with applications that run on it potentially creates malfunctions in applications that worked seamlessly in an older Windows version. However, keeping these interfaces intact is mostly independent of changing the underlying implementation. The assumption that “any new version of Windows is basically the previous version with new features layered onto it” may be right for interfaces; but needs to be substantiated for (costly) implementations. As a consequence, the IRS might risk overvaluing the legacy IP.

The second argument that significant contributions to Windows come only from the headquarters in Redmond might be counterintuitive for modern software engineering. Modern software development at an industrial scale like in Microsoft is becoming increasingly integrated, collaborative, and self-organized. This manifests for example in the industry-wide adoption of new software development paradigms such as DevOps (where teams are organized to have capabilities both in developing and operating a software system) or inner source (where teams open their development work to contributions from other teams). Microsoft is a prominent and outspoken proponent of these paradigms. For example, they started adopting inner source practices as early as 2008. In a recent talk, Microsoft claims that 10% of work contributions within Microsoft’s firm-internal GitHub platform come from teams who are not responsible for the code they are contributing to. In such a setup, where developers routinely pick their own tasks, it seems far-fetched that developers from certain national entities are solely assigned trivial work.

We also know that developers at Microsoft communicate extensively through code review beyond team boundaries, which indicates that their software engineering is heavily driven by self-organization and collaboration.

Tax Compliance as Software Engineering Problem

One might agree or disagree with our counterarguments, taking sides with the IRS or Microsoft. But the fundamental problem for our Microsoft case and all cases that will follow: Everything is an argument, a line of reasoning, based on assumptions or best guesses. Looking at balance sheets like tax officers tend to do, does not answer the question of whether a participant of a CCA is a legit participant contributing significantly to the software or not. What would answer this question are empirical measurements of the software and software engineering. This makes tax compliance a software engineering problem.

As software engineers, we have the means and competence required to address this uncertainty and can provide empirical measurements to answer the pressing questions for future tax audits. This makes tax authorities a new stakeholder in software engineering. To provide meaningful insights into the software engineering reality for tax audits, we software engineers, however, must better understand the (non-technical) perspective of tax authorities. Addressing tax compliance on an international level is way more complicated than this blog posts article with its dramatic simplifications and shortcuts may suggest.

If want to learn more, read our article published in Tax Notes International and more to come for software engineers.
Michael Dorner
Michael Dorner
Software engineering researcher