Chapter 15 - The Global Tax Portfolio

15.1 - The Purpose of the Portfolio
15.2 - The Stakeholders
15.3 - Mandated Constraints
15.4 - Naming Conventions and Terminology
15.5 - Relevant Facts and Assumptions
15.6 - The Scope of the Work
15.7 - Domain Data Model and Data Dictionary
15.8 - The Scope of the Products
15.9 - Functional Requirements
15.10 - Non-Functional Requirements
15.11 - Portfolio Issues

To Part I (Chapter 1 - 2 - 3 - 4) _ II (5 - 6 - 7) _ III (8 - 9 - 10 - 11 - 12 - (no 13)) _ IV (14 - 15) _ V (Annexes) _ VI (References)

Introductory Remarks

For an ICT initiative of significant size, that seizes all potential benefits of an information exchange architecture (as part of a Societal Architecture) it is recommended that a business requirements document be created as part of the portfolio communications plan.

In this example we apply chapters of the Volère template.

Explanations for the completion of each section can be found at the template pages. In this chapter the sections are applied at different levels in the chain from portfolio to program, project or iteration.

The second version of this e-book was published short after the Ad Hoc Committee accepted the draft Terms of Reference for a United Nations Framework Convention on International Tax Cooperation (#UNTaxConvention). For that occassion, I also created the LinkedIn Group Friends of the #UNTaxConvention (by renaming an older group). I hope to raise awareness for the use of societal architecture in the International Tax Cooperation portfolio. The current version of this chapter serves to illustrate the potential of such a portfolio.

15.1 - The Purpose of the Portfolio

To the chapter

15.1a - The User Business and Background of the Portfolio Effort

Inefficiencies in the international tax landscape, dominated by thousands of bilateral treaties, have been described by Thuronyi (2001):

“It has become apparent, however, that the bilateral nature of this treaty network involves inherent flaws which have become more serious as the network has grown. The treaty network has become cumbersome and inflexible and, in many instances, has spawned opportunities for tax avoidance.”

The perspective of national tax administrations is covered in great detail in Borja et al (eds, 2020).

Slowly, the international community is adopting multilateral elements in international treaties. One example of these is the Two-Pillar Solution to Address the Tax Challenges of the Digitalisation of the Economy.

These as well as other changes to the international tax landscape over the last ten years, make it timely to consider what implications these developments may have for the way international tax rules are administered by national tax administrations.

While international tax policy design has resulted in many common and co-ordinated rules, the tax administration framework is still more inward looking.

In the international corporate tax landscape there is a need for simple, collaborative, and digital administration of common rules and an international tax information exchange architecture.

National tax administrations and corporations must improve timeliness through real-time data availability and incorporating compliance by design.

The changing tax landscape matters also for developing countries and for the UN initiatives in this area. Witness of this is the recent resolution on the Promotion of inclusive and effective international tax cooperation at the United Nations. The topics of this resolution and the immediate intended deliverable are shown in Figure 15.1.

Figure 15.1: Topics in the international tax cooperation resolution
Figure 15.1: Topics in the international tax cooperation resolution

In a report to the G7 Finance Ministers and Central Bank Governors, the OECD (2022) upon request of the German G7 Presidency, has focussed on the further strengthening of international tax-cooperation, and recommendations for further action.

This report aims to assist developing countries in implementing the Two-Pillar Solution and builds upon a set of recommendations from the report Tax Co-operation for the 21st Century, OECD Report for the G7 Finance Ministers and Central Bank Governors.

Seen from the perspective of the CPIM, the ArchiMate implementation and migration viewpoint may look as in the figure below.

Figure 15.2: The Global tax portfolio
Figure 15.2: The Global tax portfolio

A wide range of taxes exist already as can be seen in enumeration 5153 - Duty or tax or fee type name code in the next figure.

Figure 15.3: The tax landscape as represented using EDIFACT data-elements
Figure 15.3: The tax landscape as represented using EDIFACT data-elements

The Two-Pillar solution does especially target MNE’s, yet we also include other businesses and households in the viewpoint because there are some impacts for them as well. At the same time the approach can be illustrated for all parties, and prepare also for the communication to them.

Figure 15.4: Global Tax programs for MNE's
Figure 15.4: Global Tax programs for MNE’s

To the section

15.1b - Goals of the Global Tax Steward

The Global Anti-Base Erosion Rules (GloBE) are a key component of a plan to ensure that large multinational enterprise pay a minimum level of tax on the income arising in each of the jurisdictions where they operate.

GloBE can be seen as one program in the global tax portfolio, one that targets at MNE’s.

More specifically, the GloBE Rules provide for a co-ordinated system of taxation that imposes a top-up tax on profits arising in a jurisdiction whenever the effective tax rate, determined on a jurisdictional basis, is below the minimum rate.

Broader target: #sdt171

Figure 15.5: Goals of the global tax adminstration steward
Figure 15.5: Goals of the global tax adminstration steward

To the section

15.1c - Goals of a Domestic Tax Administration Program

Modify the domestic tax rules, filing procedures, systems and processes such that tax administration can fill its role in the Two-Pillar solution and align processes and filing requirements with international resources. Thus making compliance easy and low risk for all taxpayers, from natural persons to MNE’s.

Figure 15.6: Goals of a Domestic Tax Administration
Figure 15.6: Goals of a Domestic Tax Administration

To the section

15.1d - Goals of the MNE tax director tax compliance program

Implement the new rules for compliance with tax rules, filing procedures, systems and processes such that tax administrations of all branches are supported in their tax interactions with the national jurisdictions where they operate, and the mother organization complies with and benefits from international standards in the area.

Figure 15.7: Goals of the MNE tax director tax compliance
Figure 15.7: Goals of the MNE tax director tax compliance

To the section

15.1e - Goals of the MNE branch tax division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework. Contribute national reports on transactions and to the MNE tax division.

See also Figure 15.7.

15.1f - Goals of a business tax division

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework.

See also Figure 15.7.

15.1g - Goals of an income tax payer

Adapt their processes in support of their tax interactions with the national jurisdictions to the evolving global and domestic tax administration framework.

See also Figure 15.7.

To the section - To the chapter

15.2 - The Stakeholders

To the chapter

15.2a. The Client

The tax administrations of over 135 jurisdictions which joined the ground breaking plan to update key elements of the international tax system which is no longer fit for purpose in a globalised and digitalised economy.

15.2b. The Customer

Tax administrations, MNE’s whose tax filing and payments are affected by the Global Anti-Base Erosion Rules, and all taxpayers.

15.2c. Other Stakeholders

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.2d. The Hands-On Users of the Product

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.2e. Personas

Fraudsters as well as people and companies, including MNE’s, that want to avoid paying their fair share of taxes are negative stakeholders that must be taken into consideration.

15.2g. User Participation

(To be completed)

15.2f. Priorities Assigned to Users

Requirements of households, poor households in particular, must always have the highest priority as they have the least capabilities to compensate for poorly designed solutions.

15.2h. Maintenance Users and Service Technicians

(To be completed)

To the section - To the chapter

15.3 Mandated Constraints

  • 15.3a - Solution Constraints: make as much as possible use of open-source technologies and public standards. For an indicative list of such technologies, check the DIKSHA Open-Source Softwares and specifications. DIKSHA or Digital Infrastructure for Knowledge Sharing is India’s national school education platform. EDIFACT is an example of a public standard.
  • 15.3b - Implementation Environment of the Current System
  • 15.3c - Partner or Collaborative Applications: with which other applications will the solutions interact?
  • 15.3d - Off-the-Shelf Software
  • 15.3e - Anticipated Workplace Environment
  • 15.3f - Schedule Constraints
  • 15.3g - Budget Constraints
  • 15.3h - Enterprise Constraints

At the portfolio level it is meaningful to list solution constraints, recommended implementation environments, off-the-shelf software and partner or collaborative applications made available publicly, or in the portfolio, schedule and enterprise constraints.

Anticipated workplace environment, schedule, budget and enterprise constraints should typically be elaborated at the program or project level.

Figure 15.8: EIRA's simplified technical view - infrastructure
Figure 15.8: EIRA’s simplified technical view - infrastructure

Contemporary digital solutions eco-systems involve an extensive technology stack as is illustrated by the simplified technical view - infrastructure and technical view - application of the 3rd version of the European Interoperability Reference Architecture (EIRA) (currently in its 5th version).

Figure 15.9: EIRA's simplified technical view - application
Figure 15.9: EIRA’s simplified technical view - application

To the section - To the chapter

15.4. Naming Conventions and Terminology

To the chapter

15.4a - Glossary of All Terms, Including Acronyms, Used by Stakeholders involved in the Portfolio

At the portfolio level this chapter should include all the terms of the (multi- and bi-lateral) treaties with which alignment is pursued.

This glossary is best provided online.

It should also include the names of technical reference materials such as, for instance, those of the EDIFACT standard, the Open PM² Methods, and the European Interoperability Reference Architecture (EIRA):

To the section

15.4b - Abbreviations

Acronym Meaning
APAs Advance Pricing Agreements
ATAF African Tax Administration Forum
BEPS Base Erosion and Profit Shifting
CRS Common Reporting Standard
FTA Forum on Tax Administration
G20 Group of 20
G7 Group of 7
GVS Government Verification Service
ICAP International Compliance Assurance Program
IMF International Monetary Fund
IT Information Technology
MAP Mutual Agreement Procedure
MNE Multinational Enterprise Group
OECD Organization for Economic Co-operation and Development
PAYE Pay As You Earn
TADAT Tax Administration Diagnostic Assessment Tool
TIWB Tax Inspectors Without Borders
UNDP United Nations Development Program
VAT Value Added Tax
WBG World Bank Group
CE Constituent Entity
ETR Effective Tax Rate
GloBE Global Anti-Base Erosion
IFRS International Financial Reporting Standards
JV Joint Venture
MNE Multinational enterprise
UPE Ultimate Parent Entity

15.4c - Forms and Templates

Forms used to report events or file taxes.

Templates for frequently used communications.

To the section - To the chapter

15.5 - Relevant Facts and Assumptions

  • Relevant Facts
  • Business Rules
  • Assumptions

The reasoning that is made here is that the portfolio provides conceptual models of a wide range of facts and business rules as captured in a sufficiently expressive conceptual domain model.

Because this document is intended as “portfolio requirements”, those facts, business rules and assumptions are expressed in the following chapters.

The programs and projects seeking support from the portfolio would then list (some of) the portfolio’s initial relevant facts, business rules and assumptions, and they would add facts, business rules and assumptions that are specific to their scope of work.

To the chapter

15.6 - The Scope of the Work

The typical topics in this chapter include:

To the chapter

15.6a - The Current Situation

Differentiate it for the various portfolio stakeholders.

To the section - To the chapter

15.6a.1 - The Current Situation for the Global Tax Steward

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6a.2 - The Current Situation for the Domestic Tax Administration

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6a.3 - The Current Situation for the MNE tax director

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6a.4 - The Current Situation the MNE branch tax division

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6a.5 - The Current Situation for the Business Tax Division

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6a.6 - The Current Situation for an income tax payer

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6b - The Context of the Work

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6c - Work Partitioning: Business Events

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.6d - Specifying the Business Use Cases (BUC)

This content is not available in the sample book. The book and its extras can be purchased from Leanpub at https://leanpub.com/socarch.

15.7 - Domain Models and Data Dictionary

In the domain model we build upon a number of EDIFACT segments, as depicted in Figure 15.20 to capture information about:

  • parties as modelled in Figure 2.9 Classes of agents Chapter 2.5.5
  • collaborations in Sociotope and Technotope as modelled in Figure 2.10 Chapter 2.5.6
Figure 15.20: Some relevant EDIFACT Segments
Figure 15.20: Some relevant EDIFACT Segments

Note that the EDIFACT segments can be applied in a much wider range of interactions as already covered by the EDIFACT messages. Moreover, their variability as reflected in the enumerations, supports the application in a very wide range of new situations, as will be illustrated for one very particular case, the PAYED collaboration. The reader is encouraged to explore the use cases he or she is familiar with, by using the techniques illustrated here.

To the chapter

15.7a - Conceptual Domain Model

The conceptual domain model is one of the key assets that a portfolio can share to the participating parties. For the Global Tax Portfolio, it would typically include the classes of agents, the range of possible collaborations, and the tax name codes that are within the portfolio’s scope (See EDIFACT enumeration 5153, depicted in Figure 15.3 of section 15.1a - The User Business and Background of the Portfolio).

To the section - To the chapter

15.7b - Domain Data Model

The domain data model is based on the Conceptual Domain Model and is an area where international standards are required.

EDIFACT and the tax initiatives of the OECD pay attention to such standards.

It is recommended that the portfolio provide these standards as shared specifications and as shared models in open source tools.

A header and a table for each relevant domain object, possibly to be supplemented with a UML model of the object and its relations to other key domain objects.

Field name Description
Name The name of the business object
Description The meaning of the BO; relevant characteristics
Business Rules What rules govern the creation, maintenance and access classification of the business object
Actors The actors that are interacting with the business object
Non-functional requirements Description of, or references to relevant non-functional requirements.
Portfolio Issues Description of, or references to relevant portfolio, program or project issues.

To the section - To the chapter

15.7c - Data Dictionary

A list as part of the chapter, or as a separate excel, or a report based on the UML model.

A lot of content can be included in the models that are published in open source tools, so that they are available to all professionals that could be involved in the programs, projects and iterations of the portfolio.

For examples, see Ag Data Commons: Data Dictionary - Examples.

To the section - To the chapter

15.8 - The Scope of the Product

To the chapter

15.8a - Product Boundary

A use case diagram identifies the boundaries between the users (actors) and the product you are about to build (this is sometimes called “the system”).

You arrive at the product boundary by inspecting each business use case and determining, together with the appropriate stakeholders, which part of the business use case should be automated (or satisfied by some sort of product) and which part must be done by the user.

This task must take into account:

There is a Product Use Case for each part of the business use case that must be automated.

The parts of the business use case that must be done by users must be addressed in the training and user documentation (Issue – Training and User Documentation ) by means of narratives and illustrations that explain the sequence of user and system tasks.

15.8b - Product Use Case Table

A table of all the Product Use Cases that must be developed or modified in the portfolio, program, project or iteration.

15.8c - Individual Product Use Cases (PUC’s)

Usually product use cases are explained in more detail in a use case template, or in a UML Use Case diagram. Quite often they are fully specified in a dedicated document.

Include references if available.

The key benefit of having these use cases documented in modeling tool such as Modelio 5.1 is that changes in one of the aspects, for instance the information flows, are easily reflected in all views in which those changes have an impact. Moreover, the entire model can be navigated on the basis of dependencies between aspects.

The Modelio 5.1 use case diagram is illustrated in Annex 11 - The integration of process and information modeling in Modelio 5.1.

To the section - To the chapter

15.9 - Functional Requirements

Functional requirements are the fundamental or essential subject matter of the product. They describe what the product has to do or what processing actions it is to take.

In the CPIM approach, as a major share of functional requirements has been incorporated in the description of the context of the work, the business use cases, the data model and the product use cases, the focus in this chapter is on functional requirements that haven’t been captured yet in the previous specifications.

For each functional requirement a heading and a table, with as possible content at least:

  • a number #FR001,…
  • a name or title,
  • a priority (MOSCOW)
  • a description (with source and fit criterion)
  • references to the impacted business events, business use cases, data elements and product use cases.

Notice that business events, business use cases, data elements and product use cases will also include references to the functional requirements that must be considered during their design and implementation.

Further detail about a specific requirement can be supplemented in function of the “debate around the requirement”, and the degree to which the requirement will be met following the different iterations.

To the chapter

15.10 - Non-Functional Requirements

For each non-functional requirement a heading and a table, with at least for example:

  • a number #NFR01,…
  • a name or title,
  • a type - see Annex 2 - Types of Non Functional Requirements for possibilities
  • a description (with source and fit criterion)
  • references to the impacted business events, business use cases, data elements and product use cases.

Notice that business events, business use cases, data elements and product use cases will also include references to or information about the non-functional requirements that must be considered during their design and implementation.

One set of NFRs that is very relevant at the portfolio level are the Usability and Humanity Requirements which include the interface languages of a system.

It should be easy to add new languages to an interface that is intended to the public.

There exist specific interface design patterns that centralize the terms used in the interface in one or more tables that include internal codes and map these to terms in the languages for which the interface has been adapted. Such a pattern is illustrated in the elements as illustrated in Figure 15.21.

Figure 15.21: A design pattern for a multilingual interface
Figure 15.21: A design pattern for a multilingual interface

To the chapter

15.11 - Portfolio Issues

For each portfolio issue a heading and a table, with at least:

  • for example, a number PI 01,…
  • a name or title,
  • a type - see Annex 3 - Types of Issues in Portfolios, Programs, Projects and Iterations for possibilities
  • a description
  • references to the impacted business events, business use cases, data elements and product use cases: those parts of the requirements specification will also include references to the issues that must be considered during their design and implementation.

Further detail can be supplemented in function of the type and impact of the issue and the degree to which the issue will be resolved in programs, projects or iterations.

A minimal set of issues would include:

  • PI 01 – Training and User Documentation
  • PI 02 - Step-by-step migration plan

To the chapter

Up next

Annex 1 - Stakeholder Classes