Towards a Software Architecture Description for Tax Compliance
This study demonstrates that while a minimal software architecture description can effectively visualize cross-border component reuse for tax auditors, it ultimately fails to support legally meaningful tax assessments due to fundamental mismatches between software engineering abstractions and taxation concepts.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a massive, global software company as a giant kitchen where thousands of chefs (software teams) are cooking different parts of a single, complex meal (the software product). Each chef belongs to a different branch of the family living in different countries.
Here is the problem: In the real world, if a chef in Sweden uses a secret sauce recipe owned by a chef in Germany, tax authorities in Germany might say, "Hey, that's a transaction! You're using someone else's intellectual property, so you need to pay a fee for it." This is called "implicit licensing." The tricky part is that software is invisible; you can't see the "sauce" being passed around, so tax officials often don't know these transactions are happening.
This paper is about a team of researchers trying to build a map to help tax officials see these invisible transactions.
The Map They Built
The researchers created a very simple, "deliberately minimal" map of the software kitchen. Instead of showing every single ingredient or the taste of the food, the map only shows four things:
- The Dish: What specific software part is being used?
- The Chef: Who owns that part?
- The Connection: Who is using whose part? (The "dependency").
- The Location: Where does that chef live?
They tested this map on a real, huge software system with over 2,500 parts and 16,000 connections.
The Taste Test (The Study)
The researchers didn't just guess if the map was good; they showed it to four real-life tax experts (two auditors who check the books, and two advisors who help companies file them). They asked, "Can you use this map to figure out where taxes might be owed?"
What the Experts Said
The experts gave a "mixed but hopeful" review, which can be broken down into three main points:
1. The Map is a Great Starting Point (The "Flashlight")
The experts loved the map as a way to start a conversation. Before this, they had to guess or ask vague questions like, "Who uses what?" The map gave them a concrete, fact-based list of who is using whose code across borders. One expert said it was like having an "objective starting point" rather than relying on people's memories, which can be fuzzy. It successfully lit up the dark corners of the kitchen where cross-border usage was happening.
2. The Map Has Blind Spots (The "Blurry Edges")
However, the map wasn't perfect.
- The "Who Owns This?" Confusion: In software, "ownership" might mean "the team that fixes bugs." In tax law, "ownership" means "the legal entity that holds the rights." The map used the software definition, but the tax experts kept trying to translate it into the legal definition, which didn't always match up.
- The "Missing Addresses" Problem: About half the time, the map couldn't say exactly which country a specific team was in (because they were remote or the data was messy). The experts said, "If we don't know where the chef is, we can't tax the sauce." Without a clear address, the map loses its power for an official audit.
- The "Counting" Trap: The map showed lines connecting chefs, and the thickness of the line showed how many times they used each other's code. The experts warned: "Just because a line is thick doesn't mean the sauce is expensive." A team might use a tiny, cheap piece of code a million times, or a huge, valuable piece of code just once. The map couldn't tell the difference between "frequent use" and "high value."
The Final Verdict
The paper concludes that this software map is useful, but not a complete solution.
Think of it like a rough sketch of a crime scene. It tells the detective (the tax auditor) exactly where the suspects were standing and who was talking to whom. It's a fantastic tool to start the investigation. But the sketch cannot tell the detective how much money was stolen, who legally owns the money, or what the final verdict should be.
The researchers found that while software architecture can make the structure of these hidden deals visible, it cannot, on its own, provide the legal and economic answers needed to calculate the actual taxes. The map exposes the "what" and "where," but the tax experts still need to bring their own legal knowledge to figure out the "how much" and "why."
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.