Tax with SAP S/4HANA: Configuration and Determination (SAP PRESS) [New ed.] 1493222457, 9781493222452

Citation preview

SAP PRESS is a joint initiative of SAP and Rheinwerk Publishing. The know-how offered by SAP specialists combined with the expertise of Rheinwerk Publishing offers the reader expert books in the field. SAP PRESS features first-hand information and expert advice, and provides useful skills for professional decision-making. SAP PRESS offers a variety of books on technical and business-related topics for the SAP user. For further information, please visit our website: http://www.sap-press.com. Jawad Akhtar Business Partners in SAP S/4HANA: The Comprehensive Guide to Customer-Vendor Integration 2022, 353 pages, hardcover and e-book www.sap-press.com/5468 Aylin Korkmaz Financial Reporting with SAP S/4HANA 2022, 707 pages, hardcover and e-book www.sap-press.com/5416 Stoil Jotev Configuring SAP S/4HANA Finance (2nd Edition) 2021, 738 pages, hardcover and e-book www.sap-press.com/5361 Christian van Helfteren Configuring Sales in SAP S/4HANA (2nd Edition) 2022, 905 pages, hardcover and e-book www.sap-press.com/5401 Jawad Akhtar, Martin Murray Materials Management with SAP S/4HANA: Business Processes and Configuration (2nd Edition) 2020, 939 pages, hardcover and e-book www.sap-press.com/5132

Michael Fuhr, Dirk Heyne, Nadine Teichelmann, Jan Walter

Tax with SAP S/4HANA® Configuration and Determination

Dear Reader, Certain events are annual calendar staples—birthdays, anniversaries, and holidays— year in and year out. And yet, I often find myself unprepared for them. For example, for some folks it’s natural to purchase birthday presents weeks or months in advance to leave plenty of time to wrap the gift, find a card, and plan the occasion. Not me: Even with the best of intentions, I find the weeks have flown fly by and I’m left frantically searching the web for the perfect gift and paying extra for express shipping to ensure speedy delivery. Don’t get me started on anniversaries and holidays. Another annual guarantee is taxes. There’s even an unofficial holiday to cement them in your calendar: Here in the United States, Tax Day rolls around every April, marking the date by which income tax returns must be sent to the federal government. This annual event, though, is one I’m always prepared for, since last-minute tax filing can cause much more serious headaches than spending $10 for express shipping. In the business world, taxes are more than an event on the calendar. Managing tax data for an organization means configuring indirect and direct taxes, fulfilling reporting requirements, and performing monitoring activities. The tax function touches on data spread throughout your SAP S/4HANA system—and that’s where this book comes in. In these pages, you’ll get the information you need for managing tax with SAP S/4HANA to ensure your business is fully prepared for year-round tax compliance. What did you think about Tax with SAP S/4HANA: Configuration and Determination? Your comments and suggestions are the most useful tools to help us make our books the best they can be. Please feel free to contact me and share any praise or criticism you may have. Thank you for purchasing a book from SAP PRESS! Megan Fuerst

Editor, SAP PRESS [email protected] www.sap-press.com Rheinwerk Publishing • Boston, MA

Notes on Usage This e-book is protected by copyright. By purchasing this e-book, you have agreed to accept and adhere to the copyrights. You are entitled to use this e-book for personal purposes. You may print and copy it, too, but also only for personal use. Sharing an electronic or printed copy with others, however, is not permitted, neither as a whole nor in parts. Of course, making them available on the Internet or in a company network is illegal as well. For detailed and legally binding usage conditions, please refer to the section Legal Notes. This e-book copy contains a digital watermark, a signature that indicates which person may use this copy:

Imprint This e-book is a publication many contributed to, specifically: Editor Megan Fuerst Acquisitions Editor Emily Nicholls Copyeditor Julie McNamee Cover Design Graham Geary Photo Credit iStockphoto: 1200200147/© kontekbrothers Layout Design Vera Brauner Production E-Book Graham Geary Typesetting E-Book SatzPro, Germany We hope that you liked this e-book. Please share your feedback with us and read the Service Pages to find out how to contact us. The Library of Congress has cataloged the printed edition as follows: Names: Fuhr, Michael (Financial adviser) author. Title: Tax with SAP S/4HANA : configuration and determination / Michael Fuhr, Dirk Heyne, Nadine Teichelmann, and Jan Walter. Description: 1st Editon. | Boston (MA) : Rheinwerk Publishing, 2022. | Includes index. Identifiers: LCCN 2022024031 | ISBN 9781493222452 (hardcover) | ISBN 9781493222469 (ebook) Subjects: LCSH: SAP HANA (Electronic resource) | Taxpayer compliance. | Tax administration and procedure. Classification: LCC HJ2319 .F84 2022 | DDC 336.2/91--dc23/eng/20220708 LC record available at https://lccn.loc.gov/2022024031

ISBN 978-1-4932-2245-2 (print) ISBN 978-1-4932-2246-9 (e-book) ISBN 978-1-4932-2247-6 (print and e-book) © 2022 by Rheinwerk Publishing, Inc., Boston (MA) 1st edition 2022

Contents Preface .......................................................................................................................................................

13

1

Introduction to Taxes with SAP S/4HANA

17

1.1

The Tax Function ....................................................................................................................

17

1.1.1 1.1.2

SAP S/4HANA as a Unique Occasion for Tax Functions ............................ Challenges and Requirements ...........................................................................

17 18

The Tax Operating Model and SAP S/4HANA ...........................................................

22

1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6

IT Infrastructure and Architecture .................................................................... Tax Data Management ......................................................................................... Tax Processes ........................................................................................................... Tax Talents ................................................................................................................ Governance and Organization ........................................................................... Tax Business Case ..................................................................................................

23 24 26 27 28 29

Taxes with SAP S/4HANA ..................................................................................................

30

1.3.1

What’s New? ............................................................................................................

30

1.3.2

SAP Solutions for Global Tax Management ..................................................

36

Getting Started with SAP S/4HANA ..............................................................................

47

1.4.1 1.4.2 1.4.3

Deployment Alternatives ..................................................................................... Migration Strategies .............................................................................................. SAP Activate Project Methodology ...................................................................

47 48 51

End-to-End Processes ...........................................................................................................

55

1.5.1 1.5.2

Tax Processes ........................................................................................................... Business Processes .................................................................................................

55 58

1.6

Summary ...................................................................................................................................

60

2

Indirect and Direct Tax Requirements

61

2.1

Indirect Tax ...............................................................................................................................

61

2.1.1 2.1.2 2.1.3

Global Indirect Tax Systems ............................................................................... Taxable Events ......................................................................................................... Tax Exemptions .......................................................................................................

61 68 70

2.1.4

Grouping ...................................................................................................................

72

1.2

1.3

1.4

1.5

7

Contents

2.1.5 2.1.6 2.1.7

Transaction Types .................................................................................................. Standard Reporting Requirements ................................................................... Digital Reporting Requirements ........................................................................

74 76 80

Direct Taxes ..............................................................................................................................

86

2.2.1 2.2.2 2.2.3 2.2.4 2.2.5

Base Erosion and Profit Shifting ........................................................................ Base Erosion and Profit Shifting 2.0 ................................................................. Standard Audit File for Tax .................................................................................. Financial Reporting Standards ........................................................................... Tax-Relevant Reporting Requirements ...........................................................

86 88 91 93 93

2.3

Summary ...................................................................................................................................

95

3

Basic Settings in SAP S/4HANA

97

3.1

Financial Accounting ............................................................................................................

97

2.2

3.1.1 3.1.2 3.1.3 3.1.4

3.2

Tax Codes .................................................................................................................. Tax Accounts ............................................................................................................ Plants Abroad ........................................................................................................... Exchange Rates .......................................................................................................

97 116 119 126

Sales and Distribution and Materials Management ..............................................

133

3.2.1 3.2.2 3.2.3

Tax Classifications .................................................................................................. Tax Identification Numbers ................................................................................ Tax Determination with Pricing ........................................................................

133 145 156

Integration of SAP Modules in Tax Determination ................................................

160

3.3.1 3.3.2

Materials Management and Financial Accounting .................................... Sales and Distribution and Financial Accounting ........................................

160 163

3.4

Smart Forms .............................................................................................................................

170

3.5

Summary ...................................................................................................................................

173

4

Indirect Tax Determination in SAP S/4HANA

175

4.1

Condition Logic in SAP .........................................................................................................

175

4.1.1 4.1.2 4.1.3 4.1.4

Price Calculation Procedure ................................................................................ Condition Types ...................................................................................................... Access Sequence ..................................................................................................... Condition Tables .....................................................................................................

176 181 184 187

4.1.5

Access Requirements ............................................................................................

197

3.3

8

Contents

4.2

Indirect Tax Determination in Purchasing .................................................................

198

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5

Electronic Data Interchange versus Purchase Info Records ..................... Purchase Order ........................................................................................................ Invoice Posting ........................................................................................................ Customization Scenarios ..................................................................................... Solutions for Procurement ..................................................................................

198 200 201 202 204

Indirect Tax Determination in Sales ..............................................................................

208

4.3.1 4.3.2 4.3.3

Sales Order ................................................................................................................ Invoice ........................................................................................................................ Customization Scenarios .....................................................................................

208 212 215

Special Indirect Tax Transactions ...................................................................................

217

4.4.1 4.4.2 4.4.3

Chain Transactions/Drop Shipments .............................................................. Internal Stock Transfers ....................................................................................... Special Payment Processes ..................................................................................

217 227 235

4.5

Summary ...................................................................................................................................

249

5

Indirect Tax Engines and Add-Ons

251

5.1

SAP Condition Logic ..............................................................................................................

251

5.2

Add-Ons .....................................................................................................................................

253

5.3

Tax Service with SAP ............................................................................................................

253

5.4

External Tax Engines ............................................................................................................

256

5.5

Decision Support for Vendor Selection ........................................................................

258

5.6

Summary ...................................................................................................................................

260

6

Custom Coding for Indirect Taxes

261

6.1

ABAP Basics for Indirect Tax .............................................................................................

262

6.1.1 6.1.2 6.1.3

User Exits, Customer Exits, and Business Add-Ins ....................................... Objects ....................................................................................................................... Includes, Functions, Subroutines, and Programs .........................................

262 263 264

6.1.4

ABAP Statements ....................................................................................................

265

User Exits for Tax Determination in Sales ..................................................................

266

6.2.1 6.2.2 6.2.3

267 274 276

4.3

4.4

6.2

Sales Orders .............................................................................................................. Invoices ...................................................................................................................... Additional Enhancements ...................................................................................

9

Contents

6.3

Customer Exits for Tax Determination in Purchasing ...........................................

280

6.3.1 6.3.2 6.3.3 6.3.4

Identifying Customer Exits .................................................................................. EXIT_SAPLMEKO_001 ........................................................................................... EXIT_SAPLMEKO_002 ........................................................................................... Additional Enhancements ...................................................................................

281 284 287 288

6.4

Summary ...................................................................................................................................

289

7

Direct Taxes in SAP S/4HANA

291

7.1

Direct Tax Basics ....................................................................................................................

291

7.1.1 7.1.2

End-to-End Process for Direct Taxes ................................................................ Direct Tax Organizational Structures and Master Data ............................

292 294

Organizational Structures .................................................................................................

295

7.2.1 7.2.2 7.2.3 7.2.4

Ledger ......................................................................................................................... Company Code ........................................................................................................ Chart of Accounts ................................................................................................... Withholding Tax .....................................................................................................

295 310 312 316

Master Data .............................................................................................................................

317

7.3.1 7.3.2 7.3.3

Business Partner ..................................................................................................... General Ledger Account ....................................................................................... Asset ...........................................................................................................................

318 319 321

7.4

Tax Tagging ..............................................................................................................................

322

7.5

Direct Tax Data Analytics and Monitoring .................................................................

326

7.5.1 7.5.2 7.5.3

SAP Tax Compliance .............................................................................................. Embedded Analytics .............................................................................................. Comparative Review .............................................................................................

328 329 331

Direct Tax Filing and Reporting .......................................................................................

332

7.6.1 7.6.2

333 337

7.2

7.3

7.6

7.7

7.8

10

SAP Profitability and Performance Management ....................................... SAP Document and Reporting Compliance ...................................................

Direct Tax Planning with SAP Analytics Cloud .........................................................

340

7.7.1 7.7.2 7.7.3

Direct Tax Planning Scenarios ............................................................................ Map Fiscal Application Scenarios ...................................................................... Implement Tax Scenarios ....................................................................................

341 342 344

Summary ...................................................................................................................................

347

Contents

8

Managing Transfer Prices in SAP S/4HANA

349

8.1

Operational Transfer Pricing ............................................................................................

349

8.1.1 8.1.2 8.1.3 8.1.4 8.1.5

350 350 350 351 355

8.2

Tax Transfer Prices ................................................................................................. Management Transfer Prices ............................................................................. Operational Transfer Prices ................................................................................ Transfer Pricing Process ....................................................................................... Challenges and Requirements ...........................................................................

Transfer Price Calculation ..................................................................................................

357

8.2.1 8.2.2 8.2.3

Cost-Plus Method in SAP S/4HANA .................................................................. Resale-Minus Method in SAP S/4HANA .......................................................... SAP Profitability and Performance Management .......................................

358 361 363

8.3

Transfer Price Determination ...........................................................................................

364

8.4

Transfer Price Monitoring and Adjustments .............................................................

364

8.4.1 8.4.2 8.4.3 8.4.4

Extend Universal Journal ..................................................................................... Derivation and Validation ................................................................................... Indirect Cost Allocation Limitations ................................................................. SAP Profitability and Performance Management .......................................

365 368 369 369

Transfer Price Reporting and Simulation ....................................................................

371

Transfer Price Testing and Compliance .......................................................................

373

8.6.1 8.6.2

Transaction Matrix ................................................................................................ Country-by-Country Reporting ..........................................................................

374 375

8.7

Summary ...................................................................................................................................

377

9

Tax Reporting in SAP S/4HANA

379

9.1

Worldwide Tax Reporting Requirements ...................................................................

379

9.1.1 9.1.2 9.1.3 9.1.4

The Five Fingers of Tax Administration .......................................................... Maturity of Tax Reporting Requirements ...................................................... Tax Record Evidence Requirements ................................................................. Global Tax Reporting Compliance Models .....................................................

380 381 383 384

Standardized Tax Reporting in SAP ...............................................................................

385

9.2.1 9.2.2

385 394

8.5 8.6

9.2

9.3

Standard Report for Value-Added Tax Returns ............................................ Standard Reports for EC Sales List ....................................................................

SAP Document and Reporting Compliance for SAP S/4HANA ..........................

398

9.3.1

398

Setting Up Compliance Reporting ....................................................................

11

Contents

9.3.2 9.3.3

9.4

Setting Up EC Sales Reporting ........................................................................... Electronic Document Processing .......................................................................

407 408

Summary ...................................................................................................................................

412

10 Tax Monitoring in SAP S/4HANA

413

10.1 Why Monitor Tax? .................................................................................................................

413

10.1.1 10.1.2 10.1.3

Compliance Risks .................................................................................................... Efficiency Improvements ..................................................................................... Cash Flow Optimization .......................................................................................

414 415 416

10.2 Tax Monitoring Requirements ........................................................................................

417

10.3 Tax Control Framework ......................................................................................................

419

10.4 SAP Solutions for Indirect Tax Monitoring .................................................................

424

10.4.1 10.4.2 10.4.3 10.4.4

SAP S/4HANA Embedded Analytics .................................................................. SAP Analytics Cloud ............................................................................................... SAP BW/4HANA ...................................................................................................... SAP Tax Compliance ..............................................................................................

424 425 426 426

10.5 Monitoring with SAP Tax Compliance .........................................................................

429

10.6 Summary ...................................................................................................................................

438

Appendices

439

A

Europe .........................................................................................................................................

441

B

India .............................................................................................................................................

461

C

North America .........................................................................................................................

465

D

The Authors ..............................................................................................................................

473

Index ..........................................................................................................................................................

475

Service Pages ..................................................................................................................................... Legal Notes .........................................................................................................................................

 I  I

12

Preface Welcome to this comprehensive guide to tax in SAP S/4HANA. In these pages, you’ll find information on indirect and direct tax, including fundamental concepts, step-bystep instructions, and best practices.

Objective of This Book We wrote this book to support you with a practical guideline to prepare, realize, and succeed with your SAP S/4HANA implementation project and during your ongoing deployment of SAP S/4HANA from the tax perspective. Our intention was to minimize theoretical content to the necessary extent to have a certain comfort about the current challenges and opportunities that can be addressed during SAP S/4HANA implementations (planned or ongoing implementation projects) or deployments (after go-live). The major part of this book therefore comprises practical solution proposals to be applied to your projects. During the development of this book, our experiences, best practices, and customized client solutions formed part of the content. Solution proposals aren’t intended to be copied to your SAP S/4HANA systems (or other IT systems) without application of a proper IT process/project (analysis, design, realization, testing, go-live), but we hope you'll be inspired to pursue your own solutions by the proposals and experiences captured in this book.

Important Note We cannot take responsibility for the correct deployment or application to any other ERP system than our SAP S/4HANA test system that was the basis for this book.

As a consequence of the high demand of tax talents on one hand and the emerging need of digital tax solutions on the other, tax communities are seeking a higher influence on tax legislation, tax administration, tax reporting, tax determination, and tax compliance management. Cross-company and cross-industry teams are an important resource for thought leadership and the development of value-added solutions. We are happy to see more and more tax communities that initiate important discussions and actions toward the new normal of tax. The strategic positioning in the tax sector is an important focus area for corporations and professional services firms to keep pace with ongoing developments.

13

Preface

With this book, we also want to contribute to a constantly growing community of tax professionals with the focus of successfully running value-added tax (VAT) technology solutions in your SAP S/4HANA landscape and that of your customers. We want you to concentrate on your business, so we’ve written this book in a very practical style with many examples and guided solution proposals. Finally, we hope that many of you are inspired to start or continue your tax technology career and join our community of practitioners in tax functions, advisory practices, and tax solution developers. For those of you who have already taken this step, this book can be a helpful resource when taking the next steps toward refining your skills. We can’t wait to see the future of the community and the creators of our next-generation topics and solutions.

Readers of This Book All who are interested in tax technology and curious about possible solutions for typical tax challenges in SAP S/4HANA may find inspiration, information, examples, and motivation in this book to apply to individual goals, challenges, and ideas. Tax functions, tax practitioners, and SAP S/4HANA project managers will find reasonable approaches as sources for their own projects in this book. This book can be of use to IT colleagues, tax process experts, and those who engage in accounting, controlling, and finance for specific topics concerning taxes with SAP S/4HANA. Solution providers can find many use cases to include in their solution and to show to their clients during requests for proposals, discussions, and then actual proposals. Newcomers in tax (tech) teams can use this book as a compendium that supports their personal growth and tax careers. Please let us know your reading experience and inspire us to constantly improve ourselves and our solutions. We are happy to receive feedback—no matter of which kind.

Structure of This Book This book is divided into the following 10 chapters: 쐍 Chapter 1: Introduction to Taxes with SAP S/4HANA

This chapter introduces the tax function in SAP S/4HANA, describes the tax operating model, and explores the SAP solutions for global tax management. It also provides the high-level information you need to get started with SAP S/4HANA, including deployment, migration, and the SAP Activate methodology, as well as takes a look at the relevant end-to-end processes for tax.

14

Preface

쐍 Chapter 2: Indirect and Direct Tax Requirements

This chapter introduces indirect and direct tax in a general context. Starting with indirect tax concepts such as tax systems, events, exemptions, and reporting requirements, the chapter then discusses core direct tax concepts such as Base Erosion and Profit Shifting (BEPS), Standard Audit File for Tax (SAF-T), and reporting. 쐍 Chapter 3: Basic Settings in SAP S/4HANA

This chapter teaches you to set up your tax-relevant settings in SAP S/4HANA. It provides step-by-step instructions to set up financial accounting, sales and distribution, and materials management settings for tax while also explaining the integration of SAP modules in tax determination. Finally, the chapter takes a look at the smart forms functionality. 쐍 Chapter 4: Indirect Tax Determination in SAP S/4HANA

This chapter walks step by step through indirect tax determination in SAP S/4HANA. It starts with the condition logic setup and then explains how to perform indirect tax determination in both purchasing and sales. You’ll also learn about special indirect tax transactions. 쐍 Chapter 5: Indirect Tax Engines and Add-Ons

This chapter briefly touches on other tax engines and add-ons that are available for indirect tax. It introduces SAP's tax service and external tax engines. Decision support considerations are also covered here. 쐍 Chapter 6: Custom Coding for Indirect Taxes

This chapter explains custom coding options for indirect taxes. It introduces fundamental ABAP concepts and then explores the available user exits for tax determination in both sales and purchasing. 쐍 Chapter 7: Direct Taxes in SAP S/4HANA

This chapter walks through direct taxes in SAP S/4HANA step by step, starting with setting up the organizational structures and master data. Then, the chapter explains direct tax analytics and monitoring, tax filing and reporting, and tax planning with SAP Analytics Cloud. 쐍 Chapter 8: Managing Transfer Prices in SAP S/4HANA

This chapter explains transfer pricing in the tax context. It begins with a discussion of operational transfer pricing and then explains the functionality available for calculating and determining transfer prices. This chapter also discusses monitoring, reporting, and testing options for transfer prices. 쐍 Chapter 9: Tax Reporting in SAP S/4HANA

This chapter discusses worldwide tax reporting requirements for both direct and indirect taxes. It then explains standardized tax reporting using key SAP reports. Finally, this chapter walks through setting up SAP Document and Reporting Compliance for SAP S/4HANA and discusses electronic document processing options.

15

Preface

쐍 Chapter 10: Tax Monitoring in SAP S/4HANA

This chapter introduces tax monitoring requirements and the tax control framework. It explores indirect tax monitoring solutions such as embedded analytics, SAP Analytics Cloud, SAP BW/4HANA, and SAP Tax Compliance. It then discusses monitoring with SAP Tax Compliance in more detail.

Acknowledgments All authors and contributors to this book are experienced tax technology advisors and part of fantastic teams. This big “Thank you” goes out to all of our team members. Without you, we would never have completed this book! We all had the pleasure to work together with our clients on many projects and have had many discussions that form the basis for this book. Without all these common projects, this book would not exist. We therefore would like to thank all of our clients for challenging and trusting us. Writing this book reminded us why we have chosen our profession and why it fulfills us day by day with satisfaction to keep on rocking. By the way, being an author turned out to be a profession itself that could be the subject of another book. There are only rarely such sectors in the world where things are moving faster these days and where finding and realizing practical and scalable technology solutions is all the more satisfying. We are very much looking forward to further being part of the tax practitioner community and working toward compliance and efficiency.

16

Chapter 1 Introduction to Taxes with SAP S/4HANA To begin our journey into tax with SAP S/4HANA, we’ll explain how direct and indirect taxes work in a global context, as well as how these requirements have been met with SAP solutions.

This first chapter is about current challenges of tax functions and their implications to the tax target operating model. We describe in a nutshell what a tax target operating model can look like and discuss in detail the importance of tax processes and tax data management. Afterward we focus on essential SAP S/4HANA topics with a link to taxes, that is, what's new about SAP S/4HANA for tax, and which deployment alternatives and implementation methods are available. Finally, we walk through the SAP Activate methodology for tax functions.

1.1 The Tax Function In this section, we’ll provide some initial context around the tax function. We’ll see how SAP presents new opportunities in the tax space, and we’ll consider relevant challenges and requirements.

1.1.1 SAP S/4HANA as a Unique Occasion for Tax Functions Let’s begin with a brief history of SAP, as shown in Figure 1.1. SAP introduced SAP ERP in 2004 as an upgraded version of the already existing enterprise resource planning (ERP) software called SAP R/3. Eleven years later, SAP S/4HANA was announced in 2015 by SAP, and some of the first adoptions of SAP S/4HANA started in 2015.

17

1

Introduction to Taxes with SAP S/4HANA

SAP R/2 Mainframe 1972

SAP R/3 Client/Server

SAP ERP mysap.com SAP ERP 6.0

1992

2004

SAP HANA In-Memory

2011

Suite on SAP HANA SAP ERP on SAP HANA with SAP Fiori UX

2013

SAP S/4HANA Digital Core

2015

SAP S/4HANA Intelligent ERP with SAP Business Technology Platform (SAP BTP; Previously SAP Cloud Platform)

2018

Figure 1.1 SAP Software History

Assuming an ERP software lifecycle takes roughly 10 to 15 years on the average in an enterprise, ERP software implementation projects are unique opportunities once in a decade for tax functions to integrate tax requirements and connect with most of the tax-relevant stakeholders in the company. Typically, business processes managed with the help of the ERP system and outside the ERP system are also under review in such implementation projects and can be subject to further improvements from a tax perspective as well. Therefore, we recommend making use of this opportunity from a tax perspective, ensuring there's a tax seat at the table of the SAP S/4HANA implementation project and having a budget for internal and external costs related to the tax workstream. In Section 1.4.3, we’ll cover the detailed tax agenda during the SAP Activate method in an SAP S/4HANA implementation project.

1.1.2 Challenges and Requirements Tax functions are currently subject to change driven by digitization and more complex tax requirements than ever before. The fourth industrial revolution, also known as the digital revolution or Industry 4.0, affects the tax function by making tax-relevant processes and data digital and available in real time, at the same time. The areas and triggers of the change can be structured in three different parts, which we’ll discuss in the following sections: 쐍 Digital tax administration 쐍 Value creation 쐍 Risk management

Digital Tax Administration One trigger is the digital tax administration that is currently driving the digitalization of tax functions. Tax administrations across the globe have intensified their demand

18

1.1

The Tax Function

for data to gain transparency and tax revenue. Especially indirect taxes become more and more popular and an emerging source of revenues for governments. Indirect taxes used to be the main source of income for jurisdictions. A deviation between the amount of indirect taxes to be collected and the amount actually collected is called a value-added tax (VAT) gap. One of the main reasons for the demand of higher transparency of tax administrations is to close the VAT gap. For example, in the European Union (EU), there is a yearly VAT gap of 134 billion euros. This amount equals to more than 10% of the total income of all EU member states (see the study "VAT Gap in the EU. Report 2021"). As a consequence, tax reporting obligations and mandatory e-invoicing are completely disrupting reporting processes of taxpayers on a global scale. Within the next 5 to 10 years, we’ll see an exponential increase of digital reporting requirements that results in (nearly) global coverage. That means there will be fragmented global obligations to be met simultaneously that are running in the IT systems and/or processes of the taxpayers. Due to the growing demand in terms of transparency, the level of digitalization of the tax authorities enormously changed during the past decade. Previously, tax administrations relied on nondigital documents to proof the periodical and aggregated tax reporting and statutory accounts. With taxpayers facing more and more digital recordings and digital disruptions, tax authorities also make use of digital measures and therefore force tax functions to keep pace with this development. Given current discussions of mandatory e-invoicing on a global scale to improve transparency and fight indirect tax fraud, the role of the tax authorities turned from acting reactively to being a driver of the digitization of taxpayers. Let’s consider a few examples of how tax is being digitized to produce more data and more transparency: 쐍 Mandatory e-invoicing

Mandatory e-invoicing systems across Europe with invoice exchange by tax administration (e.g., in Italy since 2019, in France starting July 2024). 쐍 Real-time reporting

Continuous tax reporting in a near real-time frequency (e.g., the Suministro Inmediato de Información (SII) in Spain since 2017). 쐍 Standard Audit File for Tax (SAF-T)

Periodic filing of a SAF-T in many European countries (e.g., Poland since 2018, Romania in 2023). These requirements lead to an increased amount of data to be filed and to a higher filing frequency and data interrogation. As a consequence, taxpayers need to prepare and monitor the requested data. Due to the number of single transactions, automation is the only way to manage the demands of the tax authorities and to avoid routine penalties. There is also upside potential as a higher degree of automation throughout the economy leads to more efficiencies

19

1

Introduction to Taxes with SAP S/4HANA

to be realized by enterprises. The tax reporting process itself becomes, to a large extent, an IT process with a real-time impact on business processes and financial processes (e.g., treasury). For example, mandatory e-invoicing leads to electronic customer invoices that need to be cleared by the tax authority (given a clearance e-invoicing model applies) before transfer to the customer. Tax-driven invoice requirements are thereby essential for a running business process to receive cash from the customer and satisfy customer experiences. At the same time, companies can reduce the environmental impact by no longer printing paper invoices.

Value Creation The next trigger is the changing role of the tax function within an organization. The role of the tax function today is a strategic business partner role that is connected to its stakeholders within and outside the organization. In addition to external challenges, internal topics are also driving change within tax functions. Many tax teams are hit by a shortfall of resources and budget restrictions. The time that is available for the allocation to tasks of tax team members is currently subject to change, as shown in Figure 1.2. The percentages are average values that may differ between organizations.

Decision Support 10%

Control

Reporting

Transaction Processing

10%

40%

40%

IT Enablement 0% Tax as Strategic Business Partner

Value-Driven Decision Support

Control

Reporting

Transaction Processing

30%

10%

25%

15%

IT Enablement 20%

Figure 1.2 Tax as Strategic Business Partner

The focus of tax management in organizations should be value driven, but there are several challenges the tax function encounters that take up time: 쐍 Generally speaking, the majority of time (up to 80%) in a tax function’s day is typi-

cally used for tax reporting and transaction processing. Depending on the number of reporting entities, tax compliance tasks, spreadsheet-based analysis with manual

20

1.1

The Tax Function

data collection and limited automation for tax reporting, and filing of tax returns can be time consuming. Even user-friendly tax reporting software is only as good as the ERP/legacy system source data integrity and quality allows. 쐍 During transaction processing tasks, the tax function supports the core business of an

organization. Without visibility and access to tax data with integrated software solutions, communication is based on emails, phone calls, or even handwritten messages. 쐍 Very often, the tax function is no expert in fixing IT-indicated root causes. Especially

with regard to ERP systems, the tax function is used to having only limited access and capacity to engage in IT processes that are necessary for tax data management. 쐍 The more time used for reporting and transaction processing, the less time is avail-

able for a conceptual change and an enablement of proper tax data management and processing. This can be a frustrating situation. Carefully planned and successfully realized tax-integrated SAP S/4HANA projects can create momentum to heavily improve the portion of value-driven decision support for the business (e.g., 10%–30%; refer to Figure 1.2) and the stake of tax in IT enablement (up to 20%). Further project results can lead to the following improvements: 쐍 One single data source

One single data source for tax-relevant data available and extractable for self-service reporting. 쐍 Automation of compliance and reporting

Fully automated process for real-time tax reporting and periodic compliance and reporting. 쐍 Tax data recording and monitoring

Enable proper tax data recording, automated tax decisions, and tax data monitoring. These improvements are value drivers for the entire organization.

Risk Management Tax risk management is one of the major concerns of the tax department. Especially in an environment of business disruption, logistical uncertainties, and a global pandemic, the tax function is in an unprecedented time and in a totally changed working environment. Adequate and effective tax compliance management systems and tax control frameworks can help the tax function identify, valuate, and manage tax risks. Especially in Germany and in more and more countries in Western Europe, tax compliance management systems are implemented in businesses to improve the procedural situation in case there are identified exceptions from the tax law. Tax-integrated SAP S/4HANA projects can support the building and improvement of operationalized tax compliance management systems to avoid tax-indicated risks

21

1

Introduction to Taxes with SAP S/4HANA

such as incorrect invoices; overreporting/underreporting of tax, interest, and penalty exposure; and customs issues that lead to breaks in the supply chain.

1.2 The Tax Operating Model and SAP S/4HANA Tax functions have to keep pace with the developments and adjust their processes, systems, and ways of working. A tax operating model is an approach to establish a common vision and a strategy for the tax function. The alternative way is to improve isolated parts of the tax function such as a single tax type (transfer pricing) technology solution or process. This can result in partial improvements and fragmented success in comparison to the prior status. In our experience, several single, smaller steps are better than none, but more consistent is an overall strategy covered by a tax operating model. (We’ll discuss transfer pricing scenarios in more detail in Chapter 8, however.) An SAP S/4HANA implementation project is an appropriate opportunity for a tax function to kick-start or to reframe the tax operating model as all important parts of the tax operating model can be designed, adjusted, and supported during the project. Figure 1.3 shows a possible tax operating model. This summarizes a holistic approach to manage the most important areas of a target operating model of a tax function.

Tax Value Drivers: Compliance, Cash, Efficiency

Governance and Organization

Talents

Tax Compliance Management System

Outsourcing Processes

Systems

Tools IT Infrastructure and Architecture

Database

Data

Figure 1.3 Tax Operating Model

The tax operating model consists of several major areas that we’ll discuss in the following sections: IT infrastructure and architecture (including tax data management), tax

22

1.2

The Tax Operating Model and SAP S/4HANA

processes, tax talents, and governance and organization. We’ll also explore the value drivers for an overall tax business case as a framework for the tax operating model.

1.2.1 IT Infrastructure and Architecture The basement of a tax operation is an appropriate IT infrastructure and architecture for tax purposes that consists of systems, database(s), tools, and data. For some organizations, SAP S/4HANA is the single system IT infrastructure. It comes with an ERP environment, an SAP HANA in-memory database, tools (e.g., SAP Document and Reporting Compliance), and all tax-relevant data. This is an exceptional example as most businesses are organized with more complexity, including external legacy systems and interfaces. For example, Figure 1.4 shows a possible structure of a data model in the course of a Central Finance approach.

Application Layer

Tax Data Marts Reporting

Central Tax Data Warehouse

Compliance

Analytics

Planning

Data Mart 3 (Analytics)

Data Mart 4 (Planning)

Tax Data Marts Data Mart 1 (Reporting)

Data Mart 2 (Compliance)

Transformation (Aggregation, Filtering, Sorting)

Central Finance

Data Lake Tax Ledger

Chart of Accounts

Tax Tagging WHT, Tax Accounts

Standardization, Harmonization, Enrichment (Chart of Accounts, Tax Ledger, Tax Tagging)

Legacy System

Data Sources

SAP R/3

SAP S/4HANA

CSV

XLS

TXT

Figure 1.4 Central Finance Tax Data Model

In the IT landscape in this example, tax-relevant data is interfaced and streamlined from recording in the legacy systems through the Central Finance instance aggregation level and a central tax data warehouse to the application layer, where the data is used and processed in tax applications (e.g., a tax reporting solution). From different legacy systems, data needs to be standardized to enable aggregation on the Central Finance

23

1

Introduction to Taxes with SAP S/4HANA

level and to ensure interoperability in the following layers. An example is financial accounting data that is recorded in two different source systems (SAP ERP system and SAP S/4HANA system) and subject to different charts of accounts. The standardization requires both a technical mapping between the two different ERP versions and an account mapping to ensure the correct accounting rules are applied. Once the data is standardized in the Central Finance instance, it can be further processed. In the central tax data warehouse, the data is prepared for the final purpose of use; for example, the accounting data is structured in a tax data model that allows tax reporting for the jurisdiction in scope of this IT landscape. The tax reporting tool in the application layer uses the data warehouse for the tax reporting software that allows filing of tax returns. There is a two-way data flow between these layers: In the tax reporting software, new data can be produced (e.g., filing protocols) and stored back to the tax data warehouse level, or changes to the accounting data made in the tax reporting software that need to be reflected are transferred to the source systems as well.

1.2.2 Tax Data Management The sample structure in Figure 1.4 has shown how important tax data management is to ensure the data is of the right quality to fulfill the requirements from a tax and finance perspective in an efficient way. In this section, we’ll provide a more granular view on tax data management and introduce concrete methods to work with tax data. Figure 1.5 distinguishes between different types of data. During strategic tax data management, the organizational data elements, the master data, and the transactional data needs to be set up according to the tax requirements that result from the business transactions and applicable tax rules. As a result, data elements are defined and set up. Organizational Elements ƒ Used to define the company structure from the viewpoint of an application ƒ Represent a framework of the SAP system (for example, controlling areas, company code, sales organization, etc.)

Data Elements Chart of accounts (tax accounts)

Data Elements Company code

Business partner (vendor/supplier)

Trading partner

Transaction types

Transactional Data ƒ Short-term, process-related data, which is assigned to master data ƒ Individual postings are known as transactional data

Data Elements Capture of receipt according to field status group

Date of invoice

Posting date of invoice

Tax liabilities

Amount

Receipt description

Tax expense

Currency

Financial assets

Tax receivables

Equity

Tax provisions

Figure 1.5 Tax Data Types

24

Master Data ƒ Data, which remains unchanged for a longer period of time ƒ Master data contains information, which is usually repeatedly used even across different components ƒ For example, vendor, cost center, cost elements, activity types

1.2

The Tax Operating Model and SAP S/4HANA

Operational tax data management brings these data structures to life and enables proper processing and use of the tax data. Tax data management in SAP S/4HANA can be approached from an operational angle in the following steps: 1. SAP data fields originating from business processes such as sales, procurement, logistics, or finance are put in a tax-relevant context. In terms of SAP S/4HANA, the relevant functionalities are sales and distribution, materials management, and financial accounting. 2. Now SAP data turns into tax-relevant information via interpretation from a tax point of view. 3. The connection of single pieces of tax-relevant information results in a tax-relevant transaction. This can be a tax-relevant sale of goods between two or more independent parties (at arm’s length). 4. A tax-relevant transaction categorized automatically into a transaction type is the next level of tax data management. Along the different tax types, that is, VAT or direct tax, different transaction types are relevant. Transaction types are, for example, a two-party end customer sale for indirect taxes or a nondeductible expense for direct taxes. 5. Tax base amounts, tax amounts, exception categories, and potentials for the taxrelevant system settings can be derived from tax data. 6. Tax requirements can be defined and managed on the basis of this approach. Strategic tax management (from tax requirements to the tax data) and operational tax management (from tax data to tax requirements) are enabled for the tax function.

Tax Data Structures in SAP Tax data structures in SAP follow a data model that includes master data and transactional data. With the help of Transaction SE16, SAP tables that contain tax data can be extracted and analyzed. To get an overview of the most relevant tax data structures, the Data Retention Tool (DART) catalog, which is provided with SAP S/4HANA, can be very useful. This interface is also used by tax auditors during audit procedures to enable data provision. The DART catalog summarizes DART segments that consist of SAP tables and data fields as the most granular part of the DART interface. Especially if you search for data fields that can be used in different SAP tables, this provides very useful guidance to identify the correct SAP tables to build a tax data model.

25

1

Introduction to Taxes with SAP S/4HANA

1.2.3 Tax Processes During SAP S/4HANA implementations, tax requirements are collected according to the end-to-end business processes. Therefore, tax functions need to understand and define their requirements on a data element level for all tax types that are relevant in the respective business processes. Typical end-to-end processes can have relevance for different tax types, as shown in Table 1.1. We’ll discuss these end-to-end processes in more detail in Section 1.5. End-to-End Process

Indirect Tax

Record-toreport

X

Order-to-cash

X

Procure-to-pay

X

Plan-to-ship

X

Direct Tax

X

Transfer Pricing

X

Withholding Tax (WHT) X

X X

X

X

Table 1.1 End-to-End Processes

It’s essential to collect all tax requirements along the business processes and tax reporting processes. During SAP S/4HANA implementations, tax has to define or adjust business processes from a tax perspective and define user stories from a tax function (operational) perspective. According to the SAP Activate methodology (see Section 1.4.3), there is no other time to integrate tax requirements in SAP S/4HANA. The tax function needs to have a seat at the table when cross-workstream workshops are conducted for the sake of requirement gathering and definition of user stories. These workshops need to be well prepared by the tax function. We recommend following a data-based approach supported by tax analysis software and the right source data. There are scalable solutions available to structure and analyze tax data if SAP source data already exists from the previous setup, such as tax data analysis based on sales and distribution, materials management, and financial accounting data, to identify and classify tax-relevant transactions and their mapping to tax codes (indirect taxes) or accounts (direct taxes, WHT). With the help of historical data, interviews and workshops are much more efficient. Information collected during the workshops can be validated directly with existing data. Furthermore, workshops can be used to clarify data and process exceptions during the analysis.

26

1.2

The Tax Operating Model and SAP S/4HANA

RISE with SAP RISE with SAP offers a subscription-based methodology to guide customers on the way to SAP S/4HANA and SAP S/4HANA Cloud. Different components such as business process integration contain predefined structures and processes to be used during implementation projects and to be deployed after go-live in an integrated way.

Tax type lifecycles are very useful structures to ensure all requirements are collected properly along the business processes. Figure 1.6 shows a typical tax type lifecycle from the indirect tax perspective that covers a strategic dimension (e.g., operating model effectiveness), indirect tax determination, indirect tax monitoring, indirect tax reporting, and indirect tax audit/controversy. This structure can be applied to all tax types and business processes that are part of the tax operating model.

Tax Process

Order-to-Cash Procure-to-Pay

VAT/GST Lifecycle Indirect Tax Planning

Management of Data Quality

Financial Planning and Analysis

Tax Determination

Indirect Tax Reporting

Tax Audits and Controversy

Record-to-Report

Figure 1.6 Indirect Tax Lifecycle

1.2.4 Tax Talents A tax operating model requires the right competencies in the tax function. Establishing appropriate working conditions is also key to attracting and retaining tax talents. Based on the company culture, the tax function needs to define and establish an environment that motivates and challenges the team members. The tax function must have a place for each talent to bring in unique competencies and to develop a career according to the expectations of the team member and the company. Keeping in mind that working conditions are very individual and therefore not subject to this book, the generally required competencies and profiles are as follows: 쐍 Tax technology hybrids

Experienced hybrids that unite tax backgrounds, related technology experiences (e.g., data analytics and SAP user knowledge), and project management skills.

27

1

Introduction to Taxes with SAP S/4HANA

쐍 Tax advisors

Tax advisors and tax requirement specialists (e.g., transfer pricing experts, transaction specialists, real estate specialists). 쐍 IT experts

IT experts with strong coding skills, as well as database skills in SQL and SAP HANA. 쐍 Process experts

Process experts, for example, with operational expertise in logistics. 쐍 Tax compliance officers

Tax compliance officers to manage the tax control framework, including workflows, mitigation tasks, and improvements/changes. 쐍 Leaders

Leadership competencies to support integration and transformation for tax technology topics in the core business and support team building and communication to tax function stakeholders. Given the challenging market for talents with these profiles, this task is very essential and a success factor for a tax function. In addition to intelligent and useful tax IT software and hardware solutions, the key is to have the right people on board and to establish a good team within the tax function and with the stakeholders of the tax function.

1.2.5 Governance and Organization The area of governance and organization as part of the tax operating model covers guidance for how possible tasks with regard to SAP S/4HANA implementation projects can be managed by the responsible tax function leadership. The main governance topics are as follows: 쐍 Clear and focused articulation of tax needs following an overall goal for tax such as

a maximum value contribution to the business 쐍 Before the SAP S/4HANA project, checking for optimization potential to realize the

best starting point possible for an SAP S/4HANA transformation 쐍 Reviewing and updating the tax control framework, including documentation and

controls 쐍 Identifying and installing tax resources into the SAP S/4HANA project for better

knowledge, skills, and project impact for tax topics Organizational questions include the following: 쐍 How does the SAP S/4HANA implementation impact the finance operating model? 쐍 What are the changing roles and responsibilities between finance and tax?

28

1.2

The Tax Operating Model and SAP S/4HANA

쐍 What skills are needed to integrate SAP S/4HANA processes and functionalities into

the work ethics of a tax function? 쐍 What are the off- or near-shore opportunities for tax activities, for example, for the

tax reporting process?

1.2.6 Tax Business Case The tax business case delivers the underlying principles for a tax operating model. The goal is to establish a value-driven environment for all parts of the tax operating model. Figure 1.7 shows three areas of the business case: risk management, cash potentials, and efficiencies. Based on business experiences and depending on the maturity of organizations, there are various upside potentials of a value-driven business case for the entire organization.

Better Calculate and Manage the Transfer Prices and Cash Positions Leading to Better Tax Planning and Foreign Exchange Management

Mitigating Tax and Compliance Risk

Fewer Provisions for Potential Penalties Reduction of Penalties and High Defense Costs

Fewer Compliance Costs Predictive Tax Insights

Reducing Cash Leakage

Improving Efficiency

Increased Level of Control of the Effective Tax Rate and Tax Position

Improved Operational Efficiency

Decrease in Tax Reporting Time

Fewer Human Errors and Reduction of Administrative Costs Due to Higher Level of Automation of the Tax Processes

Optimization of Customs Duties Reduction of Time for Maintenance and Human Intervention in the Calculation of Required Taxes

Figure 1.7 Tax Business Case

A typical business case calculation for the integration of SAP Tax Compliance (with deemed fictional values) as an operational tax compliance management system is shown in Table 1.2.

29

1

Introduction to Taxes with SAP S/4HANA

Investment Side

Savings Side (Value per Year)

One-Time Costs

Recurring Costs

쐍 One-time software license costs (700k)

쐍 Yearly software license (70k)

쐍 Implementation costs, including an indirect tax data check repository and workflow design delivered and maintained by the tax advisor (300k)

쐍 Yearly license cost for data check repository (including medium maintenance package) (50k)

쐍 Compliance cost savings (55,000 accounts payable and accounts receivable invoices per year) and an error rate of 0.5% before and .25% after the implementation (450k) 쐍 Efficiency gains due to saved time for mitigation tasks and business process efficiencies (150k) 쐍 Cash opportunities based on earlier VAT deduction and foreign input VAT refund (80k)

Table 1.2 Business Calculation Example

The duration of the amortization of the one-time amount is between one and two years. Even the recurring costs are offset by the yearly savings, although this effect may flatten a bit due to learning effects. That way, you can show and calculate the value contribution of the tax function with this high-level example calculation.

1.3 Taxes with SAP S/4HANA In this section, you’ll learn about new functionalities in SAP S/4HANA for tax. We’ll discuss key features like the Universal Journal and then explore SAP solutions for global tax management.

1.3.1 What’s New? To begin, you’ll find out what new functionality is available in SAP S/4HANA and what impact it has on tax management. Most of the innovations are general with impacts on taxes, but there are also some functionalities for taxes based on demand from taxoriented SAP users.

Simplification List The SAP S/4HANA simplification list isn’t a new functionality but rather a reference document where you can find the SAP S/4HANA-related advancements of familiar SAP

30

1.3

Taxes with SAP S/4HANA

transactions. For some transactions, SAP Fiori apps are now available, and others were simply replaced or suspended. You can find the simplification list at http://s-prs.co/ v549500. The SAP S/4HANA simplification list covers several different releases and is constantly maintained by SAP. You can also find details in related SAP Notes that are published in addition to the SAP simplification list. It covers components, master data, additional information, and—if relevant—different sector solutions. The simplification list collects new functionality and/or changed functionality and has the style and degree of details comparable to SAP Notes but without detailed customizing settings. You’ll find this helpful for your SAP S/4HANA project especially in the case of a familiar transaction you don’t want to miss in your future tax data management setup.

Example An important example is the SAP S/4HANA Intrastat functionality. SAP decided to manage international trade processes with SAP Global Trade Services (SAP GTS) in the course of the SAP S/4HANA upgrade. SAP GTS is an additional module to be licensed separately. Selected international trade functionalities are provided with foreign trade as part of materials management in SAP S/4HANA core functionalities; however, in the simplification list, all Intrastat transactions are listed that are no longer available with SAP S/4HANA. Especially in the earlier SAP S/4HANA release 1511, this was one of the major changes and issues during implementation projects.

SAP Fiori User Interface In terms of user-friendliness, the new SAP Fiori 3 user interface opens up new ways of working with SAP S/4HANA. New functions include solutions for integrated internal and external data processing and evaluation, as shown in Figure 1.8. Tax-related functionalities are accessible intuitively via SAP Fiori tiles. In addition, SAP Fiori enables their use on mobile devices and the mapping of role-based functions. Especially for home office and remote work, these are very useful functions. As shown in Figure 1.8, SAP S/4HANA solutions come with their own SAP Fiori tiles such as the Run Compliance Reports app in the case of advanced compliance reporting (replaced by SAP Document and Reporting Compliance). But if you want to create your own SAP Fiori apps and tiles, you can use the SAP Fiori launchpad content manager. The SAP Fiori launchpad content manager simplifies the creation and adaptation of business catalogs. You can use it both to explore existing content and to create your own catalogs by copying existing ones and adapting them to your needs.

31

1

Introduction to Taxes with SAP S/4HANA

Figure 1.8 SAP Fiori Tiles

Another tool is the SAP Fiori launchpad application manager, which serves to manage the application and technical catalogs. The SAP Fiori app Manage Launchpad Spaces and Pages is available to manage a homepage that allows users to structure the layout of a page using drag and drop. Furthermore, SAP CoPilot supports SAP users with multilingual voice input and offers functions for managing and organizing tasks.

Universal Journal The SAP HANA in-memory database technology and the revised architecture of the core components in the finance area of SAP S/4HANA enable the Universal Journal, which combines data from previously different sources (financial accounting and management accounting) in one single SAP data table. Individual line items are now the basis for the balance sheet instead of balances that were separately stored. In SAP S/4HANA, the Universal Journal is the new home for all postings from internal and external accounting, stored as a common database table. Accounting and controlling data combine in table ACDOCA, as shown in Figure 1.9. The table name includes AC for accounting, DOC for documents, and A for actuals. The table combines the document information from bookkeeping, asset accounting, cost accounting, and the Material Ledger. Cost element and financial accounting accounts are synchronized. Therefore, each controlling posting also generates a financial accounting document. In addition, due to the harmonization and enrichment of the data, there is no need to reconcile financial accounting with the subledgers: 쐍 Financial accounting (general ledger) 쐍 Profitability analysis

32

1.3

Taxes with SAP S/4HANA

쐍 Controlling 쐍 Asset accounting 쐍 Material Ledger

Nevertheless, the original tables remain as database views (e.g., tables BSEG or COEP), which isn’t equal to primarily database storage. The standard reports and transactions previously used in SAP ERP by customers can continue to be used. This also plays a role in the area of tax reporting and data provisioning, especially data generated from table BSET or table BSEG. The tax data for the accounting document remains updated in table BSET. In addition to table ACDOCA, table BKPF for the header data also remains in place. It’s also possible to implement additional fields (customer-specific fields) for special tax purposes to use them for reporting. As trial balances have been omitted, it’s also possible to navigate from the balance sheet down to the level of the individual items and view detailed information for tax validations. General Ledger Ledger

Company

Account

Profit Center

Company

Account/ Cost Element

Profit Center

Amount 1

Amount 1

Profitability Amount 2

Amount 3

…

Operating Concern

Market Segment

…

Material

Customer Fields

…

Universal Journal (Table ACDOCA) Ledger

Amount 2

Management Accounting Controlling Area

Cost Element

Amount 1

Amount 2

Amount 3

Coding Block

Fixed Asset

Market Segment

Asset Accounting Coding Block

…

Controlling Area

Cost Element

Material Ledger Amount 1

Controlling Area

Cost Element

Amount 1

Virtual Compatibility Views

Figure 1.9 Universal Journal

Material Ledger Information related to materials management is stored in the Material Ledger. Material movements are managed in table MATDOC. The header data of the material document MKPF and the line item data of table MSEG were transferred to table MATDOC. As you can see in Figure 1.10, you can choose between different Material Ledger types and currency types. With the Material Ledger, you can use parallel currencies (maximum three currencies for mapping the stocks), have parallel evaluations running (e.g., for transfer pricing purposes), and optionally use the actual cost for externally procured and internally created materials (instead of having either the moving average price or standard price).

33

1

Introduction to Taxes with SAP S/4HANA

Overall, the Material Ledger increases the transparency of all material movements and thus of the company stock.

Figure 1.10 Material Ledger Settings

Business Partner Although it’s not completely new, one major innovation in SAP S/4HANA is the business partner concept that was introduced also on the financial accounting level. The business partner concept enables master data unification, which leads to fewer redundancies, less maintenance effort, and higher data quality. Every organization has different business-to-business (B2B), business-to-consumer (B2C), business-to-government (B2G), or business-to-tax (B2T) relationships. A business partner of each nature can be both a customer and a supplier in one person or in one organization. The business partner concept replaces some parts of the vendor and customer master records that were originally maintained separately. Irrespective of the business partner’s classification (customer/vendor), a unique business partner number is assigned to it. However, the central business partner represents the leading master data object. In the background, the central business partner continues to work with two other master data objects (customers and accounts payable). Relevant SAP table names usually start with BP. Whenever business partner data is maintained, the synchronization only takes place in one direction: business partners to customer/supplier master data. With regard to tax data management, some points are important to mention: 쐍 General data can be used in several business partner roles. 쐍 Different addresses of a business partner can be maintained. 쐍 Central maintenance of business partner data can be used by different SAP compo-

nents (in particular by creating different roles). Figure 1.11 shows the maintenance of the business partner (here, as a customer’s organization). In the Billing view, the customer tax classification is set up. In this case, as you can see in the Output Tax table at the bottom of the screen, it’s a customer liable to taxes which represents tax classification 1 in the country Germany.

34

1.3

Taxes with SAP S/4HANA

Figure 1.11 Business Partner (Transaction BP)

Transaction BP can be used to maintain all business partner data. Further information on Transaction BP is stored in the simplification list as mentioned earlier in this section. The documentation shows which transactions are replaced by Transaction BP. For example, the former Transaction FK03 for displaying the vendor was transferred to Transaction BP. The same applies to the transaction codes for maintaining customers, debtors, suppliers, and creditors. In connection with the concept of the central business partner, a few classifications are of importance. A new business partner is maintained or created using the person, organization, or group options, corresponding to whether the business partner is a single individual, a single organization, or a group of organizations.

35

1

Introduction to Taxes with SAP S/4HANA

1.3.2 SAP Solutions for Global Tax Management SAP solutions for global tax management help companies to manage indirect tax compliance, efficiency, and costs based on SAP technology. The SAP solution landscape for tax includes tax determination, calculation, reporting, and compliance. SAP S/4HANA implementation projects are major opportunities to discuss, select, and integrate the solutions with core business processes on a global scale to cover the ever-changing global tax requirements across all tax types and jurisdictions. In the following sections, we’ll cover details about SAP solutions for global tax management in SAP S/4HANA.

Tax Capabilities Tax functions have the responsibility to ensure tax compliance and enable management decisions from a tax point of view (tax planning) by following a value-driven approach based on cost efficiency and cash optimization. SAP solutions for global tax management support tax functions to fulfill their responsibility. In Figure 1.12, you can see the tasks and working results of the tax functions regarding all tax types in the scope of the tax and finance function, for example: 쐍 Automated and compliant tax reporting for direct and indirect tax purposes 쐍 Rule-based data quality and tax risk management system

Digital Administration Integration

Automated and Compliant Tax Reporting

Proactive Transfer Price Management

Operational Transfer Pricing

SAP S/4HANA Organizational Structure

Rule-Based Data Quality and Tax Risk Management System

Real-Time Segmented P&L and Balance Sheet Reporting in Line with Value Chain

Tax Model and Model Compliance

Automated Customs Controls and Calculations

Enhanced Withholding Tax Calculations

Indirect Tax Determination

Direct Tax

Tax Risk Control Framework

Automated Tax Depreciation

Finance

SAP S/4HANA

Indirect Tax

Tax Accounting and Reporting

Global Trade

Intercompany Accounting

Figure 1.12 SAP S/4HANA Tax Capabilities

Advanced Customs and Trade Analytics

Improved Intercompany Reconciliation

Digital Tax Administration Integration

Predictive Tax Planning

Real-Time Insights in Tax-Relevant Data

Withholding Taxes

Future of Tax Customs and Trade

36

Tax Master Data

1.3

Taxes with SAP S/4HANA

쐍 Automated tax depreciation for direct tax purposes 쐍 Improved intercompany reconciliation for group indirect taxes 쐍 Real-time insights in tax-relevant data for all tax types

SAP solutions for global tax management are partly dependent on SAP HANA data structures (e.g., SAP Tax Compliance) and partly already available in the SAP core components as standard functionality (e.g., indirect tax determination based on sales and distribution/materials management condition logic). Figure 1.13 shows an overview of SAP solutions for global tax management, which you’ll see in more detail throughout this book. Currently in SAP S/4HANA Cloud Only

Tax Controls with SAP Tax Compliance

Partner Content

Automatically Identify and Correct Noncompliant Data, Address Root Causes Checks and Tax Validation Rules Built-In Tax Determination and Integration with Partner Tax Engines

Internal Controls

TimeDependent Taxes

End-to-End Business Processes Communication to Authorities and Business Partners

Online VIES Validation

User -Friendly Access for Tax Users and Registration for Embedded Indirect Taxation Analytics Abroad (RITA)

Tax Transactions and Analytics

Real-Time Reporting with

Periodic Reporting with

SAP Document Compliance and Reporting for SAP S/4HANA Manage All Mandates from E-Documents to Statutory Reporting for a Seamless Transition to Continuous Transaction Controls Worldwide Additional Regulations

Figure 1.13 SAP Solutions for Global Tax Management

Tax Solution Grouping To cover a strategic tax scenario where the tax function is able to do proper online filings, fulfill external reporting obligations, continuously monitor the tax-relevant data, and save and archive tax-relevant data according to the requirements, an additional layer of tax applications is necessary to enhance the digital core functionalities of SAP S/4HANA. SAP S/4HANA solutions can be grouped into core functionalities, apps, and external solutions, as shown in Figure 1.14. Depending on the deployment model of the tax solution, either a transformation or implementation project is necessary (SAP add-on tax determination enablement project).

37

1

Introduction to Taxes with SAP S/4HANA

Core SAP Configuration of SAP Digital Core Solutions within SAP Digital Core

SAP Apps Configuration of SAP Applications and Solutions on SAP Technology

External Solutions for SAP Solutions Built to Integrate with SAP

Core SAP SAP S/4HANA Managed Services Solutions and Applications Leveraging SAP Business Technology Platform

SAP Applications

Transformation Transform Tax Operations through SAP and SAP -Enabled Applications

External Solutions for SAP

Figure 1.14 SAP S/4HANA Solution Overview

The digital core comprises, for example, master data and tax determination based on condition logic in sales and distribution, materials management, and financial accounting. SAP apps can be grouped as solutions based on SAP technology, such as SAP Tax Compliance and SAP Document and Reporting Compliance. They aren’t part of the SAP core but have a high level of integration into SAP core processes. Both of these groups are at the heart of SAP solutions for global tax management. The third group of solutions is the emerging area of external solutions for SAP. The level of integration to SAP core processes comes in a wide variety depending on the technology, maturity, and quality of the external solution. There are solutions without integration to SAP that still work with SAP data (e.g., tax data analytics solution with an SAP data model and DART data extraction), as well as solutions with an application programming interface (API) connection or a connector technology, such as remote function calls (RFCs) or web services (e.g., real-time analytics solution with a web interface). Furthermore, third-party solutions can be fully integrated into SAP as add-ins or boltins and work with SAP core technology (e.g., condition technique).

Tax Determination Tax determination in SAP S/4HANA is supported by different solutions to respond to the various requirements that exist in different jurisdictions. On the one hand, SAP’s internal built-in tax calculation is available, and on the other hand, external tax calculations can be connected to SAP. For both, SAP native configuration, including SAP master data, needs to be set up accordingly. Let’s start with SAP’s internal built-in tax calculations. Based on customer and material master data and further SAP parameters, SAP’s condition technique is used for tax

38

1.3

Taxes with SAP S/4HANA

determination in accounts receivable and accounts payable processes in different SAP functionalities (i.e., sales and distribution and materials management). The tax determination automation is applicable to customer orders/invoices or purchase orders based on the following: 쐍 Customer/material master data 쐍 Condition technique

Furthermore, the tax determination automation is applicable to vendor invoices based on the following: 쐍 Combination of workflow solutions and latest technologies 쐍 Extensions in SAP partner solutions (e.g., OpenText vendor invoice management

[VIM]) Based on SAP’s internal built-in tax calculations, the availability level of the necessary and correct SAP tax determination parameters is originally located in SAP or linked to SAP directly. The full integration with all transactional processes creates a single source of truth. Now, let’s consider external tax calculation, which specifically applies to the United States, Puerto Rico, Canada, and Brazil. For jurisdictions with a high volatility of tax rates and a high complexity of tax rules, SAP supports the integration with external partners to enable accurate determination using tax rates that are continuously updated according to the latest changes. Integrated partner solutions have the advantage that tax rate changes and maintenance are (mostly) covered by the responsible solution provider depending on the contracted responsibility. As long as the solution provider is SAP-certified, a robust and well-established integration to SAP is given. With regard to the jurisdictions in the United States, Puerto Rico, and Canada: 쐍 SAP S/4HANA Cloud supports API integration (Canada still under investigation). 쐍 On-premise SAP S/4HANA, SAP HANA Enterprise Cloud, and SAP S/4HANA Cloud,

private edition, support the RFC interface. For Brazil: 쐍 SAP S/4HANA Cloud supports integration via SAP Integration Suite. 쐍 On-premise SAP S/4HANA, SAP HANA Enterprise Cloud, and SAP S/4HANA Cloud,

private edition support internal determination only. Other third-party integrations aren’t supported. For more details, see SAP Note 1497956.

Time-Dependent Tax Codes The tax code is the most important indirect tax data in SAP. The technical name of a tax code in SAP always consists of two digits.

39

1

Introduction to Taxes with SAP S/4HANA

Since time dependency has been introduced by SAP S/4HANA Cloud on the level of the tax code, the SAP S/4HANA Cloud table for tax codes has been extended for two columns, Valid From and Valid To, as shown in Figure 1.15.

Figure 1.15 Validity Periods of Time-Dependent Taxes

SAP S/4HANA Availability Currently, time dependency is only available for SAP S/4HANA Cloud. As of release 2202, time-dependent tax calculation is available in 35 countries: Austria, Belgium, China, Czech Republic, Denmark, Finland, France, Germany, Hungary, India, Indonesia, Ireland, Italy, Japan, Luxembourg, Malaysia, Mexico, Netherlands, New Zealand, Norway, Philippines, Poland, Romania, Saudi Arabia, Singapore, Slovakia, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Thailand, United Arab Emirates, United Kingdom. SAP has also indicated on its roadmap that time-dependent tax calculation is likely to come for on-premise as well. A strong indicator for this is that SAP has already created S tables for it and tested the functionality (refer to SAP Note 3071737).

The validity period is linked to the tax code itself and to the VAT return field mapping. Especially during the COVID-19 pandemic measures of temporary tax rate changes, we’ve seen the standard VAT rate going down for six months in Germany from 19% to 16%. During that time, the VAT return field of the standard VAT rate changed and had to be reflected in the standard rate tax code and respective VAT return mapping table in case of a filing based on Transaction FOTV.

40

1.3

Taxes with SAP S/4HANA

In countries/regions where time-dependent tax calculation is active, certain tax rates are effective within user-specified timeframes to allow an adaption to current or planned changes to tax rates. Figure 1.16 shows the boxes to consider for the setup of tax codes based on time-dependent taxes.

Figure 1.16 Configuration of Time-Dependent Taxes

In case of changes to tax rates, new tax codes had to be created, and many SAP tables had to be maintained. In countries/regions where time-dependent tax calculation is active, you can simply maintain existing tax rates. Based on tax rate validity periods to be added, tax rate changes can be reflected in the setup of existing tax codes. When the new validity periods start, all the line item calculations automatically use the valid tax rate. Time-dependent tax calculation clearly saves tax codes and therefore reduces the tax rate maintenance in financial accounting, sales and distribution, and materials management, which also prevents inconsistencies between sales and finance documents. The following two ways are available to activate time-dependent taxes depending on whether the country/region solution in SAP S/4HANA Cloud has been activated: 쐍 Target country/region not previously activated

Time-dependent taxes are active as soon as the target country/region is activated. 쐍 Target country/region previously activated

Existing custom-created and transactional data needs to be migrated. With time-dependent tax calculation activated, tax codes can be created and maintained.

41

1

Introduction to Taxes with SAP S/4HANA

Customer Responsibility For countries/regions where time-dependent tax calculation is active, the SAP customer creates and maintains the tax codes rather than contacting the service for expert configuration. With time-dependent tax calculation in place, tax codes and tax rates are standard SAP reference content. It’s the responsibility of the SAP user to comply with the current legal requirements and to create, update and maintain the tax code settings according to legal requirements.

Time-dependent tax calculation must be activated in both the quality and production systems to enable transports from the quality system to the production system on the basis of the SAP solution builder project released. Changes made to the tax configuration in the quality system are transported automatically to the production system. No change or deletion is possible after transfer. SAP doesn’t currently support the deletion of tax codes. A retroactive maintenance of tax rates leads to the deletion of any later tax rates that need to be recreated in chronological order. Therefore, a system check is in place (can be switched off upon a request to the service center) to prevent such modifications. For additional important information regarding the activation of time-dependent taxes, refer to SAP Notes 2809073, 2818970, 2819322, and 2937776. The maintenance of tax codes for a foreign country or region isn’t possible with timedependent tax calculation activated. For a Dutch company code, for example, foreign tax codes can’t be added to account for VAT registrations. Setting up foreign tax codes to time-dependent tax calculation doesn’t allow connections to the relevant foreign registration, business, and tax processes, including reporting requirements, currencies, and exchange mechanisms.

Registration for Indirect Taxation Abroad Registration for Indirect Taxation Abroad (RITA) enables a tax registration country/ region that is different from the company code country/region. Typically, this setup is needed if no company code is created for the foreign presence. With RITA, taxable transactions in foreign countries/regions are registered for indirect tax reporting and tax payments.

SAP S/4HANA Availability RITA is currently available for SAP S/4HANA Cloud. For the time being, productive use isn’t yet possible as it’s only available in the SAP S/4HANA Cloud test system environment (see SAP Note 2907372 for more information). Countries/regions where RITA is enabled include Austria, Belgium, Finland, France, Germany, Ireland, Italy, Netherlands, and Spain.

42

1.3

Taxes with SAP S/4HANA

It’s important to note that RITA can’t be used where a foreign company code is set up to cover a fixed establishment abroad. Generally, in connection with the requirement of a company code, RITA isn’t an option. The requirement of a company code needs to be checked carefully. The condition type GRWR (statistical value) is used in the pricing procedure to calculate the statistical indirect tax values abroad. Note that the routine number 008 must be replaced with routine number 091 in the Requirement field of the pricing procedure. This is also valid for the use of self-created pricing procedures. For more information on condition types, routines, and pricing procedures, see Chapter 4.

Online Validation Service The online validation service (using VAT Information Exchange System [VIES]) is the solution for automated and SAP-integrated online validation of business partner VAT ID information for SAP ERP and SAP S/4HANA. This functionality supports European indirect tax compliance for member states as valid VAT ID information is a prerequisite for tax exempt intra-community supplies of goods (for details, refer to Chapter 2). Figure 1.17 shows the VIES homepage of the European Commission, where you can validate EU VAT numbers.

Figure 1.17 VIES VAT Number Validation Homepage

With a search engine owned by the European Commission, VIES validates VAT IDs of business partners operating in EU member states. The legal requirement is based on

43

1

Introduction to Taxes with SAP S/4HANA

the VAT Directive 112/2006 updated by the Council Directive (EU) 2018/1910. Furthermore, local validations are possible, for example, the validation of tax numbers and bank accounts of Polish business partners against the tax payers e-register (published daily by Polish tax authorities). Extensibility options are available to validate any business partner attribute based on local requirements. VIES integrates with business partner maintenance and the sales/ billing process.

Availability The solution is available for all SAP deployment alternatives (SAP S/4HANA, SAP S/4HANA Cloud, Central Finance, and SAP ERP). SAP is currently working on further developments to integrate this service with all other applications.

SAP Tax Compliance SAP Tax Compliance is an end-to-end tax monitoring solution that covers data along the whole tax lifecycle in SAP and outside of SAP. From risk-adjusted control scenarios to workflow-based mitigation task lists, and based on machine learning components to reduce the manual effort, this solution reduces effort for tax exception handling and generates a high value added for tax functions as an integral part of the organization. SAP Tax Compliance allows you to replicate data centrally on an SAP HANA database or use the ERP data directly (or hybrid) to centralize and automate tax checks, perform remediation, and improve the quality of tax data. As part of a tax control framework, SAP Tax Compliance automates tax controls for streamlined compliance and provides the following: 쐍 Firm-wide centralized checking rules (not limited to tax checks) 쐍 Ability to apply controls to 100% of relevant transactions due to high performance

based on in-memory technology and depending on the risk profile of checks 쐍 One central platform with full integration into processes by replication of SAP exter-

nal data sources 쐍 Automation supported by machine learning to reduce manual intervention 쐍 Continuous monitoring of exceptional tax postings 쐍 Use of SAP workflow for alert notification and orchestration 쐍 Audit-proof remediation trail 쐍 Simulations of scenarios possible 쐍 Repository of issues to improve processes and minimize noncompliance risk

SAP Tax Compliance uses navigation targets (via SAP Fiori) to jump directly from exceptional documents into the SAP S/4HANA system to directly execute analysis

44

1.3

Taxes with SAP S/4HANA

steps based on source data. An example of the Release Supplier Invoice task in SAP Tax Compliance is shown in Figure 1.18.

Figure 1.18 SAP Tax Compliance Task

Additionally, SAP Tax Compliance can be linked to SAP Document and Reporting Compliance, which allows you to integrate exceptions directly in the reporting process and enables a streamlined processing of tax monitoring and reporting along the tax lifecycle. The clear value added for the tax function and the broader organization is to connect the pieces necessary to enable an automated internal tax control/compliance framework (no spot checks). At the same time, this connection needs to be carefully adapted by the organization to maximize efficiencies. We’ll discuss SAP Tax Compliance further in Chapter 10.

SAP Document and Reporting Compliance With SAP Document and Reporting Compliance, tax functions can manage e-invoicing, real-time reporting, and statutory reporting on a global scale. The solution is a combination of the features originally available via SAP Document Compliance and SAP solutions for advanced reporting and compliance. SAP Document and Reporting Compliance integrates the tax reporting process in SAP S/4HANA to manage the end-to-end process from data extraction, data aggregation, monitoring, exception handling, filing, and payment. Figure 1.19 shows an example monitoring screen displaying Advanced Compliance Reports. In general, the part of SAP Document and Reporting Compliance formerly known as SAP solutions for advanced compliance reporting covers periodic/statutory reporting requirements (e.g., VAT return, European Commission (EC) Sales List, WHT report) and

45

1

Introduction to Taxes with SAP S/4HANA

tax reporting requirements (e.g., SAF-T). The part of SAP Document and Reporting Compliance formerly known as SAP Document Compliance (or eDocument) covers continuous transaction controls (CTC; e.g., X-Rechnung, FatturaPA) for several jurisdictions.

Figure 1.19 SAP Document and Reporting Compliance

To close our discussion of SAP Document and Reporting Compliance, let’s consider a few key features of the solution: 쐍 Enables standardization, efficiency, and automation 쐍 Provides transparency on compliance status and fulfills audit trail requirements 쐍 Reduces ongoing compliance costs 쐍 Supports the transition from periodic statutory reporting to CTC 쐍 Ensures consistency between real-time business document submissions and statu-

tory reports 쐍 Facilitates reconciliation between internal records and records available on tax

authorities’ platforms For further details about SAP Document and Reporting Compliance, refer to Chapter 9, Section 9.3.

46

1.4

Getting Started with SAP S/4HANA

1.4 Getting Started with SAP S/4HANA Now that we’ve discussed tax in the context of SAP S/4HANA, it’s time to consider your first steps toward your migration/implementation project. In this section, we’ll discuss your deployment options, migration approaches, and the SAP Activate methodology for your implementation project. The tax function typically has limited influence over decisions about migration strategy and deployment. That is why an overall tax (technology) strategy is very important and needs to be included in the discussion. The migration strategies and deployment alternatives should allow the organization to be tax compliant considering the available capacities and technologies of the tax function. Tax consumes a big portion of data in operational and finance processes and therefore needs to be involved in the SAP S/4HANA implementation. The SAP S/4HANA migration can help realize data-driven tax management and improve data availability and quality in the IT landscape touched by the SAP S/4HANA migration. In addition, you should define whether and to what extent additional tools such as SAP Tax Compliance or SAP Document and Reporting Compliance will be implemented and used. The bill of materials (BOM) can be leveraged for tax solutions as well and should be discussed as early as possible also from the tax side. Remember the tax operating model we discussed in Section 1.2? All the integral parts of the tax operating model are relevant here. The clearer the vision of the tax operating model, the better an SAP S/4HANA project can be used to realize and fund it.

1.4.1 Deployment Alternatives SAP S/4HANA can be deployed in the cloud or on-premise. You can also use SAP S/4HANA in the form of a hybrid operating model (i.e., parts on-premise and parts in the cloud). Let’s provide a brief overview of both options: 쐍 SAP S/4HANA

On-premise SAP S/4HANA is the deployment alternative of choice for all companies that have deep supply chain processes (logistics) and production or manufacturing sites that need a comprehensive range of functions and want to adapt them with the flexibility to have all customizing and/or enhancements options. Currently, most deployments are on-premise. 쐍 SAP S/4HANA Cloud

SAP S/4HANA Cloud is a software as a service (SaaS) offering. SAP’s strategy is to bring more and more SAP clients to the cloud. The SAP S/4HANA Cloud deployment can either be private (single-tenant) with SAP S/4HANA Cloud, private edition, or public (multitenant) with SAP S/4HANA Cloud.

47

1

Introduction to Taxes with SAP S/4HANA

SAP S/4HANA Cloud, private edition, is suitable for companies that want to combine the scope and expandability of an on-premise solution with an SaaS solution. SAP S/4HANA Cloud, private edition, offers the full range of functions of SAP S/4HANA and full access to Customizing. Industry solutions and languages can be fully used. However, modifications to the SAP source code aren’t possible. The alternative cloud edition is SAP S/4HANA Cloud. This is the SaaS offering with the lowest flexibility. This form of provision is a possible solution for companies that can work completely with predefined, standardized processes. This edition is at the core of a SaaS solution as it will realize the highest degree of scalability for SAP.

Availability Considerations Due to the SAP roadmap of tax-relevant solutions such as RITA, you should carefully check whether or not the available functionality as of go-live already covers the legal requirements for the organization as (semi-/automated) workarounds are difficult or impossible to realize in SAP S/4HANA Cloud.

1.4.2 Migration Strategies There are different migration strategies for SAP S/4HANA. Figure 1.20 represents the alternative implementation options as part of the SAP S/4HANA strategy, which we’ll discuss further in the following sections. Category

System Conversion

Initial Situation

Transitioning Approach

SAP S/4HANA

SAP ► ►

SAP ERP SAP Business Suite

Scenario of Implementation

Brownfield via Software Update Manager (SUM)

►

► ►

SAP ►

New Implementation

► ► ►

SAP ERP SAP Business Suite AnyDB Non-SAP Systems

SAP S/4HANA Greenfield

► ► ► ►

SAP ERP SAP Business Suite AnyDB Non-SAP Systems

Figure 1.20 Brownfield/Greenfield/Hybrid

48

► ► ► ►

SAP Selective Data Transition

Existing Business Processes to a New Platform Technical Conversion Including Customizations and Data

Starting from Scratch Migrate Existing Data Reengineering Process Simplification

SAP S/4HANA Hybrid

► ►

Example: Different ERP Systems Selective Greenfield/Brownfield

1.4

Getting Started with SAP S/4HANA

New Implementation versus System Conversion The new implementation (also called greenfield) approach summarizes implementation projects starting from scratch based on SAP S/4HANA best practices and industry solutions. The SAP system is completely reimplemented, and processes are remodeled extensively. This approach is preferred when there are no longer upgradeable or very inhomogeneous ERP systems in place and when clear optimization or digitization intentions are on the agenda due to external or internal reasons (e.g., M&A activity or a digitally disrupted business model). A system conversion (also called brownfield) approach means to transfer existing processes from the SAP ERP system to the SAP S/4HANA system with the intention to keep the existing setup as far as possible. An adoption to new SAP HANA data structures and functionalities may be necessary as well in this scenario. This approach is chosen if your company has already had a transformation project or if the organization is running on a simple and stable number of functionalities. In practice, mixed forms of both approaches can be found as most companies want to get a return on past investments but also enable the best environment to have a futureproof system setup for the next investment decade. If several ERP systems are in use, the first step is often to select a leading system and upgrade it to SAP S/4HANA as a pilot or template project. The other systems are either merged or rolled in afterwards. This is known as the selective data transition approach.

Central Finance In the case of highly fragmented and complex ERP landscapes in particular, a Central Finance implementation is an alternative approach. Figure 1.21 shows a possible Central Finance landscape. With the help of Central Finance, companies can centralize their heterogeneous and distributed IT and SAP system landscape (SAP and non-SAP) and link it to one SAP S/4HANA system. Legacy Systems SAP ERP

Central Finance

Finance Reporting

SAP S/4HANA Finance Consolidation

Analysis

Tax and Legal

(e.g., SAP BPC)

(e.g., SAP Analytics Cloud)

(e.g., Tax Systems)

Oracle

JD Edwards

SAP S/4HANA Finance is implemented, and transactions from multiple sources are replicated to enable harmonized global financial information reporting.

SAP S/4HANA SAP S/4HANA Finance

SAP S/4HANA Sales

SAP S/4HANA Asset Management

SAP S/4HANA HR

SAP S/4HANA Supply Chain

SAP S/4HANA R&D

Figure 1.21 Central Finance

49

1

Introduction to Taxes with SAP S/4HANA

In most cases, finance transformations are based on the Central Finance approach. Logistic or production flows aren’t decisive for this approach as mainly finance-related data is centralized and connected via Central Finance. An important step for Central Finance projects is the stage when parts of the company or group are running on a leading Central Finance instance with independent postings and payments only in the Central Finance instance. If there is no more synchronization with the source systems, the tax requirements of the leading Central Finance instance need to be reflected in the same way as for brownfield or greenfield implementations to have a tax-compliant setup. As Central Finance is often the first step of an SAP S/4HANA migration, the system can later be fully migrated to the SAP S/4HANA platform.

Template Approach The 1,000 biggest SAP customers are multinational organizations that moved or will move to SAP S/4HANA with a multiple country scope and multiple systems, including legacy systems. Many of them already moved or at least planned the move to SAP S/4HANA. Introducing at least one central SAP S/4HANA system for multiple countries and subsidiaries poses a challenge for companies and tax functions as project timelines are often slim, sprints are intensive and time-consuming, and the know-how isn’t equally distributed throughout SAP S/4HANA projects between organizations, solution integrators, and tax (technology) consultants. Therefore, a template approach can support a successful project as central definitions, design principles, processes, and harmonized master data are available for the template and rollouts as well and don’t need to be redesigned for each rollout. Only deviations need to be reflected during the rollout period. It’s important to define one or more template countries to be able to localize the tax requirements that are available. In general, the template should cover most of the taxrelevant processes and transaction categories to have a significant template character. In terms of the tax setup, a template transaction matrix can be used containing the same or at least comparable transaction categories and all relevant tax parameters to classify all relevant transactions. Furthermore, a central tax code repository based on a unified approach ensures a compliant, consistent, and efficient way to set up and maintain tax codes for the template and the rollouts. This methodology is valid for all tax types throughout the template and rollouts. In a global tax template, all generally applicable requirements should be defined across countries for each tax type. Legal requirements of the national companies extend the range of functions of the template to a local tax template.

50

1.4

Getting Started with SAP S/4HANA

1.4.3 SAP Activate Project Methodology The SAP Activate implementation methodology is a project guidance approach with a set of tools, templates, and processes to support customers and consultants. The methodology accommodates all SAP modules and project complexities ranging from a single pilot project to larger complex transformation. In this section, we spotlight tax requirements covered by the SAP Activate methodology along the project phases, as shown in Figure 1.22. Discover

Prepare

Explore

Realize

Project Management Start

Project Initiation

Stop

Application Value and Scoping

Security Implementation

Integration Design

Testing

Analytics Design

Analytics Configuration

Test Planning

Test Preparation and Execution

Sandbox Setup/ Conversion

Development Setup/ Conversion

Quality Assurance System Setup/Conversion

Sizing and Scalability Verification

Sizing Technical Architecture and Infrastructure Definition

Operations and Support

Custom Code Quality Integration Implementation

Technical Design

Operations Impact Evaluation

IT Infrastructure Setup

Operations Implementation

Operations Readiness

Task/Activity

Figure 1.22 SAP Activate Methodology

Discover SAP Activate-driven SAP S/4HANA implementations start with the discover phase. During this phase, the tax function should create or have a strategy for their digital transformation in line with the company’s strategy for their SAP S/4HANA transformation. Refer to Section 1.2 for more details. The outcome of the discover phase can be leveraged within an organization to build a business case for an SAP S/4HANA implementation project. With a business case, a quantitative measure is in place to calculate the value added of digital, automated, and data-driven tax management surrounded by an up-to-date tax

51

Operate Solution

Custom Code Impact

Handover Support Organization

Product Enhancements

Transition Preparation

Transition Planning

Data Migration and Verification

Hypercare

Data Migration Design

Integration Validation DVM Configuration and Execution

Dress Rehearsal

Data Volume Management (DVM) Design

Production Cutover

Design Review

Cutover Preparation

Security Design Gap Validation

Prototype

Strategic Planning

Configuration

UX Activation and Design

Extensibility

Trial System Provisioning

Learning Realization

Fit-to-Standard Analytics and Design

Activate Solution

Data Management

Quality Gates

Closing

Improve and Innovate Solution

Application Design and Configuration

Technical Architecture and Infrastructure

Go Live

QG5

Organizational Change Management

Learning Design

Team Enablement

Analytics

Run

QG4

QG3

Execution/Monitoring/Controlling

Solution Adoption

Integration

Deploy

QG2

QG1

1

Introduction to Taxes with SAP S/4HANA

operating model. Saved compliance costs, efficiency gains, and cash potentials are compared to a cost case based on reasonable tax solutions that cover tax determination, monitoring, and reporting tasks of the tax function. When the savings, gains, and cash advantages exceed the implementation costs, the tax business case is advantageous.

Prepare During the prepare phase, the requirements gathering for the jurisdictions in scope starts to collect all requirements according to applicable transaction scenarios. A draft version of process flows helps to structure tax-relevant processes. A preliminary fit-to-standard analysis takes place to be ready for the prepare phase and prepare workshop material for design workshops. A first workshop for key design decisions with the tax function can be conducted if the expected complexity of the tax integration scenario is higher. During the prepare phase, decisions need to be made for support on additional products (e.g., external tax engine). This decision is important as follow-up questions can already be answered and planned for accordingly: 쐍 Decision of involvement of external partners (e.g., third-party tax solution provider) 쐍 Involvement of implementation partner (if not done by solution provider) 쐍 Development of project plan for the explore phase

Explore During the explore phase, design workshops are conducted to result in a business process design for tax that include solutions for the tax requirements. Part of these discussion are fit-gap sessions to identify and process gaps for the future model. Crossworkstream workshops are held to cover topics with dependencies on other workstreams. For example, the tax determination parameter for chain supplies sits within the logistics or order management processes. All findings and solutions are documented in the tax business process document (BPD). An alignment with external solution providers happens throughout all the preceding steps.

Realize Depending on the capabilities of tax functions, the tax lead is still with the tax department during the realize phase. The following tasks are relevant for the tax function: 쐍 Development of system adjustments (reports, interfaces, conversions, enhance-

ments, forms, and workflows [RICEFWs]) – Functional specifications – SAP coding

52

1.4

Getting Started with SAP S/4HANA

– Unit testing – Quality review – Show and tell (implementation team, central team, potential handover to SAP or ABAP architect) 쐍 Testing

– Execution of functional tests and documentation of test results – Insertion of the program code in the documentation for system enhancements – Transport system adaptation from development system to test system 쐍 Implementation of tax determination logic

– Set up of primary VAT determination parameters – Set up of condition types, access sequences, and condition records – Linking components of the tax determination logic – Adaption of migration concept 쐍 Master data management

– Setup of tax codes – Validation of invoice forms – Check and align with other workstreams and other master data – Adaption of migration concept 쐍 Reporting and monitoring

– Tax monitoring configuration – Tax reporting configuration 쐍 Documentation and quality of build activities 쐍 Project management office (PMO) alignment cross-workstream

The testing activities are very important to prepare the go-live and to ensure the tax setup is working correctly and as expected. At this stage in the realize phase, future users can already be trained with the help of the existing tax-relevant setup. Further steps summarize the central tasks during that phase: 1. Draft testing matrices for the countries in scope 2. Support testing cycles in case of exceptions 3. Training users to use the testing matrix, testing meetings, update testing statistics for all tax-relevant processes and countries in scope 4. Creation of test cases (end-to-end integration test, user acceptance test) in SAP S/4HANA 5. Deployment of testing matrix (SAP S/4HANA testing report implementation, testing data extraction)

53

1

Introduction to Taxes with SAP S/4HANA

6. Population of testing matrices 7. Review of testing results based on testing matrices 8. Workarounds to fix exceptions 9. Approval and confirmation of testing results by the tax team

Deploy The deploy phase ensures the readiness for production, including dress rehearsal and cutover activities. The go-live is a special day where the whole project turns into operational mode. In the morning of the go-live, we typically wake up very curious and excited to see how the tax setup is working, even though we’re confident with the setup after months of work and positive test results. After the go-live, the hypercare period starts. Typically, hypercare is just a short time period after go-live to limit the duration of the implementation project and enable standard processes (e.g., changes requests for tax rate changes) to enter into the productive period. That is why hypercare topics should be addressed very clearly with a time schedule according to the remaining hypercare phase to make sure the topics are solved before the run phase. In practice, we’ve experienced tax-related hypercare topics in all past projects. These activities mostly result from open items during the testing without material consequences for a compliant tax setup. For example, the testing of a transaction category was limited to one out of two countries because of an identical setup. This can save time and resources during the tax testing cycle but needs to be addressed as a measurement category during hypercare to ensure completeness and compliance of the tax setup.

Run In the run phase, the implementation cycle is over, and the maintenance period starts. This has been drawn already in the tax business case with underlying assumptions. The organization needs to adopt the operational tax control framework with its responsibilities and the tax-related solutions and applications based on well-prepared training sessions during earlier phases. In the context of a build, measure, and learn lifecycle, measuring starts with the run phase. This is the time to measure results, for example, based on test routines in the tax monitoring solution to keep track of the compliance level of accounts payable postings. In case of deviations from expected results, mitigation workflows will support the learn phase and complete the build for any remaining or unprecedented exceptions.

54

1.5

End-to-End Processes

1.5 End-to-End Processes SAP S/4HANA transformations are structured according to the business processes, that is, procure-to-pay, order-to-cash, and record-to-report. End-to-end scenarios describe all process steps that are subject to practical application in the ERP and IT landscape. However, depending on industry-specific characteristics, modified scenarios are also possible. The tax function needs to understand all tax-relevant steps within the end-to-end scenarios and the business processes behind them, and then needs to integrate their requirements accordingly. To structure the tax input to the business processes, the tax function defines the requirements according to tax end-to-end scenarios across the relevant tax types as a prerequisite for an SAP S/4HANA project integration and to support PMO activities with regard to tax. Before we explain the tax implications and tasks in the end-to-end business processes, we need to describe the typical phases of an end-to-end tax process.

1.5.1 Tax Processes The end-to-end tax process can be divided into four phases across tax types: data recording and tax determination, data analysis and monitoring, compliance and statutory reporting, and tax planning. We’ll discuss each in the following sections, starting with the processes for indirect tax and then taking a look at direct tax.

Tax Data Recording and Tax Determination The most granular tax element is tax-relevant data. The tax requirements define what kind of data is necessary to determine the right tax consequence. In general, tax decisions are processed based on data and tax rules. Let’s take the example of an intra-community purchase of goods of a German company code received in Germany. The requirements for this case were captured in a tax determination matrix, as shown in Table 1.3. The correct result was calculated based on a rule that combines tax-relevant data from different process steps. It’s thus important to maintain correct master data in order to receive and read digital invoice information, to combine and collect the relevant data elements in the tax data model, and to have a rule in place that is up to date according to the latest tax requirements.

55

1

Introduction to Taxes with SAP S/4HANA

Data Elements

Available Data/Documents in SAP S/4HANA

Rule Set for Tax Determination

쐍 Transaction category: accounts payable direct purchase

쐍 Purchase order

쐍 Tax departure country: NL

쐍 Goods receipt

쐍 Determine the transaction category: direct purchase (two parties involved)

쐍 Tax destination country: DE

쐍 Supplier invoice

쐍 Tax rate: 19% (input VAT and output VAT)

쐍 Payment

쐍 Supplier name: Supplier 1

쐍 Supplier master data 쐍 Material master data

쐍 Tax code 쐍 Financial posting

쐍 Supplier address: Supplier Street 1, Supplier City, Netherlands 쐍 Supplier domestic VAT ID: NL123456789 쐍 Supplier foreign VAT ID: BE123456789 쐍 Ship-from country: Belgium 쐍 Ship-to country: Germany 쐍 Plant of goods receipt: Germany

쐍 Determine the ship-from country by taking the first two digits of the VAT ID of the supplier on the invoice: BE 쐍 Determine the ship-to country from the receiving plant assigned to the German company code in the company code master data: DE 쐍 Material tax indicator: standard VAT rate 19% 쐍 Rule result: Intracommunity purchase of goods in DE 19%

Table 1.3 Tax Determination Matrix Example

Tax Monitoring and Data Quality The tax monitoring process will ensure that the tax-relevant data is complete and correct and will prepare proper tax reporting. In our example, we could apply several data checks based on the collected data: 쐍 Check the foreign VAT ID of the Dutch supplier by comparing the master data with

transaction data. 쐍 Compare the calculated tax amount based on invoice data and the tax rate from the

tax code settings with the posted tax amount. 쐍 Check if the supplier has used multiple tax codes during this month.

These monitoring actions aren’t just detective controls to identify anomalies during the reporting process; they also help to prevent systematic exceptions due to master data incompleteness and rule set mistakes. During monitoring, you can make optimal use of the possibilities of the data model in SAP S/4HANA (e.g., core data services [CDS] views). Important solutions that are used in

56

1.5

End-to-End Processes

this area are SAP Tax Compliance and SAP S/4HANA embedded analytics, which are explained in more detail in Chapter 10.

Tax Reporting The next phase is tax reporting, which is important to fulfill the tax filing obligations during the right timing and in the right quality to avoid negative impacts on the duration and the quality of the tax reporting process. In our example, we have to ensure the right mapping between the tax code and the VAT return field in the first step. In the next step, the tax reporting process needs to fulfill the legal requirements of the digital processing of a VAT return. Because no paper form is allowed, you must ensure that you transfer the data in the right data format by using the right interface to the tax authorities. In this case, you can either use the SAP interface to the tax authorities for the SAP core functionalities (Transaction FOTV), or you can use SAP solutions such as SAP Document and Reporting Compliance for statutory reporting as a processing solution to create a VAT return and to submit the report to the tax authorities.

Tax Planning Tax planning can include the estimation and calculation of a target effective tax rate for direct tax purposes (in accordance with pillar two, or Global Anti-Base Erosion [GloBE], minimum taxation regulations). The interdisciplinary approach of tax planning is to structure the operating model and supply chain to end up with destination status where indirect tax, direct tax, and transfer pricing follow a common logic, for example, in a branch model where the branches act as low-risk distributors with a buysell structure (flash title) to avoid high margins in foreign branches and to enable a centralized approach for tax management. Ideally, the branches are equal from an indirect and direct tax perspective to enable a reconciliation of indirect and direct taxes.

Direct Tax Having looked at indirect taxes, let’s now take a look at the direct tax lifecycle in Figure 1.23. The direct tax lifecycle also consists of four parts: tax reporting, tax declaration, tax audits, and management. In the tax reporting practice, there is a clear focus on the areas of indirect taxes and income taxes. The statutory reporting includes further tasks for tax functions that cover determination of current and deferred taxes together with the annual report, for example, regarding tax risks. Tax reporting is often based on procedures of initial direct and indirect tax-related tax registration, which are important to be compliant and to enable the declaration of VAT and the VAT deduction in our sample case in Germany.

57

1

Introduction to Taxes with SAP S/4HANA

Tax Reporting

Statutory (Group) Accounts before Taxes

Tax Declarations

Tax Balance Sheet (Status Year End)

Tax Calculation

Deferred Taxes

Tax Balance Sheet (Status Tax Declaration)

Tax Declaration E-Balance CbCR

Tax Assessments

Notes (Tax)

Tax Audits

Tax Audit Request Provisions

Tax Audit Findings Summary (Tax Balance Status, Tax Audit)

Tax Declaration Adjustments

Adjusted Tax Assessments

Controversy/Appeals

Management

Compliance-Status Tax Filing Deadlines

Reporting of Tax Risks

Tax Provisions and Payments

Tax Planning

Tax Compliance Management System

Figure 1.23 Direct Tax Lifecycle

Automation potentials include the use of tax ledgers, the SAP implementation of the EBalance taxonomy, tax determination for direct taxes (tax tagging), or the extended WHT function, which we detail in Chapter 3, Section 3.1.1.

1.5.2 Business Processes In the following sections, we’ll discuss the most important business processes in practice with high tax relevance in the end-to-end scenarios of sales, production, and finance.

Procure-to-Pay The procure-to-pay scenario bundles the business processes of purchasing from the request and execution of an order to the receipt of deliveries or services and the processing of the invoice receipt to the payment run (see Figure 1.24). Procure-to-pay processes are especially subject to automation as the highest potential for efficiency gains and cash optimization occurs here. See Chapter 4, Section 4.2.5, for an overview of procure-to-pay solutions. Along the procure-to-pay process, a lot of tax-relevant data is recorded: 쐍 Business partner (vendor, supplier) 쐍 Material type 쐍 Material group 쐍 Procurement type 쐍 Order quantity 쐍 Terms of delivery/Incoterms 쐍 Terms of payment

58

1.5

End-to-End Processes

쐍 Conditions (gross prices, discounts, freight costs, taxes) 쐍 Account assignment type (assets, cost centers, production orders) 쐍 Purchasing organization (beneficiary company code) 쐍 Plants (place of delivery/place of supply)

This data covers requirements for all tax types, indirect taxes (VAT deduction), WHT (suspension certificates), transfer prices (target margin), and income taxes (benefit in kind).

Procure-to-Pay

Prepurchase Activities

Procure

Logistics Execution

Purchasing

Purchase Request

Purchase Order

Order-to-Cash

Goods/Service Receipt

Goods Receipt

Invoice Posting

Payment

Payment

Pay

Corporate Income Tax WHT VAT Customs Transfer Pricing

Figure 1.24 Procure-to-Pay Process

Order-to-Cash The order-to-cash scenario specifies the business processes of sales from the contact to account receivables with tax-relevant impacts for all tax types (see Figure 1.25). During the order-to-cash process, SAP S/4HANA records tax-relevant data for all tax types, for example: 쐍 Business partner (customer) 쐍 Material type 쐍 Order quantity 쐍 Terms of delivery/Incoterms 쐍 Conditions (gross prices, discounts, freight costs, excise taxes) 쐍 Delivery plant (place of delivery/place of performance)

59

1

Introduction to Taxes with SAP S/4HANA

Order-to-Cash

Procure-to-Pay

Presales Activities

Contact

Forecast-to-Manufacture

Order Processing

Inquiry

Quotation

Sales Order

Logistics Execution

Record-to-Report

Shipping

Delivery

Billing

Transfer Order

Billing Document

Accounts Receivable

Manage VAT/WHT Determination

Manage WHT Recording

Tax Tagging

Direct Tax Manage VAT/WHT Compliance

Indirect Tax

Manage VAT Determination

Transfer Pricing Tax Controversy

Tax Guidelines

Tax CMS

Compliance Management

Manage Tax Data Continuous Monitoring

Manage ProcessIntegrated Controls Manage VAT Monitoring

Figure 1.25 Order-to-Cash Process

Record-to-Report The record-to-report scenario includes tax reporting activities and statutory accounts activities. Some of the activities that are relevant mainly for income taxes are as follows: 쐍 Identification of temporary differences based on deviating commercial law/tax rec-

ognition and valuation regulations/tax accounting 쐍 Review of tax items for tax effects from previous years (true-ups) 쐍 Determination of current taxes in the individual financial statements of the current

financial year 쐍 Assessment and approach of tax risks with regard to future tax audits 쐍 Arm’s length compliant control of transfer prices through continuous monitoring

1.6 Summary In this chapter, we’ve examined the opportunities of introducing SAP S/4HANA for your company from a tax perspective. In addition to explaining the project procedure and first insights into relevant SAP components and products, we also provided an overview of the necessary transformation roadmaps given to the tax department and its target operating model. We presented the main topics of people, data, processes, and control in the target operating model and worked out important challenges with the transformation requirements. In the next chapter, we’ll move on to our core tax topics: indirect and direct tax requirements.

60

Chapter 2 Indirect and Direct Tax Requirements This chapter introduces indirect and direct tax concepts across different geographies, without the focus on SAP S/4HANA. It will provide a highlevel insight into the different types of tax systems as well as an overview of relevant parameters for both indirect and direct taxation.

Now that we’ve introduced the tax function in SAP S/4HANA, in this chapter, we’ll briefly move away from SAP to explain core concepts in the areas of indirect and direct tax. These requirements are the foundation for your tax activities in SAP S/4HANA, so it’s important to understand the global context before getting started in the system. In this chapter, we’ll start with indirect tax requirements. We’ll cover key concepts such as indirect tax systems, events, reporting requirements, and more. We’ll then take a look at direct tax requirements.

2.1 Indirect Tax Indirect taxes are levied on goods and services instead of profit or income like in direct taxes. We’ll discuss general indirect tax requirements in the following sections. We’ll start by exploring the global indirect tax systems and then move on to taxable events, exemptions, grouping, transaction types, and standard and digital reporting requirements (DRRs).

2.1.1 Global Indirect Tax Systems Worldwide, countries have established systems to levy taxes on goods and services. These taxes are independent of the income or profit generated and are usually covered by the final consumer of the goods or services. However, the responsibility for the collection and payment to authorities regularly lies with the provider of the goods or services. Indirect taxes are charged at different institutional levels such as federal, state, municipal, or even city. In some jurisdictions, multiple levels can charge taxes on the provision of goods or services at the same time.

61

2

Indirect and Direct Tax Requirements

Throughout the development of indirect taxes, different types of systems for levying indirect taxes have been developed. We’ll give an overview of the major types that are globally relevant in the following sections.

Particular Indirect Taxes The focus of this section is on general indirect taxes charged on goods and services. Many countries have also established laws for indirect taxes on special types of goods and services such as tobacco, alcohol, or energy. These are either charged instead of the regular indirect tax or as an additional tax.

European Union Harmonized Value-Added Tax System Value-added tax (VAT) is an indirect tax calculated on the taxable amount, usually defined as the full amount paid (or must be paid) to obtain the goods or services. The VAT is added on top of the net price. At every step of the supply of goods or services reaching the final customer, VAT is calculated. However, unlike sales tax, VAT can be deducted as an input tax. The VAT is collected in a staged collection process. Let’s consider the example of VAT shown in Figure 2.1. In this example, the involved parties before the final customer pay VAT but can deduct it at the same time, making it neutral from a cash perspective. For example, the wholesaler has to pay 20 € VAT to the manufacturer who then pays it to the government as the collector of VAT. The wholesaler can deduct the paid VAT as an input tax. This logic is implemented in the whole chain, except for the final customer. In total, the government collects the 32 € (20% VAT on the final net price of 160 €) but along the whole chain in different stages: 20 € from the manufacturer + 4 € from the wholesaler + 8€ from the retailer = 32 € Government

20 €

120 €

Manufacturer

32 € −24 € 8€

24 € −20 € 4€

(100 Net + 20 VAT)

192 €

144 €

Wholesaler

Retailer (120 Net + 24 VAT)

(160 Net + 32 VAT)

Customer

Figure 2.1 Example with 20% VAT

Beginning in 2007, the VAT Directive 2006/112/EC came into force for all European Union (EU) member states (as of the year 2022 for a total of 27 member states). It

62

2.1

Indirect Tax

replaced the Sixth Directive, which was established in 1977 to create a structure of the VAT system within the EU. In the introduction of the Sixth Directive, the goal is stated as follows: The common system of VAT should, even if rates and exemptions are not fully harmonized, result in neutrality in competition, such that within the territory of each Member State similar goods and services bear the same tax burden, whatever the length of the production and distribution chain. – Council Directive 2006/112/EC on the common system of value added tax Many of the general regulations are defined in the VAT Directive and must be implemented into the national VAT laws of the member states. In many areas, the VAT Directive acts as a guideline and the member states can apply derogations (or even exceptions) in their local implementation of the directive. The tax rate is a simple example of one of these derogations as the VAT Directive only defines the minimum standard VAT rate at 15%. Furthermore, member states can implement reduced VAT rates for certain goods and services, which can be below the rate of 15%. One of the main benefits and specialties of the harmonized VAT system within the EU is the treatment of intra-EU cross-border transactions. For both goods and services, these are simplified when comparing them to non-EU cross-border transactions. To reduce the obligation of tax registration in many countries, the reverse charge mechanism was established for business-to-business (B2B) transactions. Mainly, this consists of the intra-community supply of goods as well as the reverse charge mechanism for services. The recipient of the goods or services must pay the VAT to the tax authorities instead of, as usual, the supplier. The sale of goods from one EU member state to another member state (B2B) is tax exempt for the seller, and the recipient has a taxable acquisition.

Example The Italian manufacturing company ABC sells a machine from their Italian plant to the shoe manufacturing company XYZ in France. ABC transports the goods from Italy to France. ABC has a tax-exempt intra-community supply and doesn’t have to pay (or declare) any VAT in Italy. XYZ has an intra-community acquisition in France and must pay and declare French VAT. At the same time, XYZ can deduct the input VAT in their VAT return, making it a non-cash effective transaction for XYZ.

With the European Commission (EC) Sales List and due to the harmonized system, the EU can using a system for monitoring cross-border transactions to reduce tax evasion. In the periodic EC Sales List, a business must report all intra-community transactions (goods and services) by customer VAT ID. Compared to newer systems with transactional real-time reporting as explained in Section 2.1.7, it only guarantees a reduction of tax evasion on a very high level. However, the EC Sales Lists are based

63

2

Indirect and Direct Tax Requirements

on communication across national borders, which is unique compared to regular regulations that focus only on national tax revenue.

Other VAT Systems Many countries across the globe have implemented a VAT system in the past decades. For example, China implemented a VAT system in 1994, and, as of 2009, both the VAT Provisional Regulations and the VAT Implementing Rules came into effect. The system is like most VAT systems where VAT is deductible as input VAT and only the final consumer pays VAT. Comparable to the EU, the member states of the Gulf Cooperation Council (the Kingdom of Saudi Arabia, the United Arab Emirates, the Sultanate of Oman, the State of Qatar, the Kingdom of Bahrain, and the state of Kuwait) have established a similar framework to ease transactions between the different member states. As the rules aren’t binding, not all regulations have been implemented into the national laws. Compared to other countries worldwide, the VAT rate set by the Gulf Cooperation Council of 5% is very low. Saudi Arabia increased this rate to 15% as of January 1, 2020, due to the COVID-19 pandemic as well as a strong decline in oil prices at the time.

Goods and Services Tax Jurisdictions Countries that have goods and services tax (GST) jurisdictions follow the same approach as the VAT system to indirect taxation of goods and services. Both VAT and GST jurisdictions are regularly based on the Organization for Economic Cooperation and Development (OECD) International VAT/GST Guidelines. The OECD guidelines don’t differentiate between VAT and GST and summarize both acronyms in the same category: The terms “value added tax” and “VAT” are used to refer to any national tax by whatever name or acronym it is known such as Goods and Services Tax (GST) that embodies the basic features of a value added tax, i.e. a broad-based tax on final consumption collected from, but in principle not borne by, businesses through a staged collection process, whatever method is used for determining the tax liability. – OECD International VAT/GST Guidelines 2017 India is a country where a difference between VAT and GST can be made. Until 2017, India had a VAT system for the sale of goods that differed by state. In 2017, a unified GST system, combining different indirect taxes into one with one unified tax rate system, went into force for all of India. Excise taxes, VAT, and service taxes all fall under the one common GST system. Both in GST and VAT jurisdictions, there are two different approaches to defining the amount a business needs to pay in the staged collection process. All countries defined under VAT jurisdictions use the invoice-credit method. Japan, globally seen as a GST

64

2.1

Indirect Tax

jurisdiction with its consumption tax, uses the subtraction method (planned to change to invoice-credit method as of 2023). Both methods are defined in Table 2.1. Invoice-Credit Method

Subtraction Method

쐍 Transaction based.

쐍 Entity based.

쐍 A supplier charges VAT/GST for each supply and creates an invoice that is sent to the recipient of the goods or services.

쐍 An entity has to take the VAT/GST calculated on allowable purchases and subtract it from the VAT/GST on taxable supplies.

쐍 The recipient can credit the input tax based on the invoice against the output tax that they charge for their own sales.

쐍 It’s not relevant if the entity has a tax invoice to be able to deduct the input tax.

Table 2.1 Comparison Invoice

Sales Tax Jurisdictions Whereas VAT/GST aim at eliminating the cascading effect by collecting the tax at every stage of value gained, sales tax is a single-layer tax that only taxes the last step when the final consumer purchases the goods or services. Let’s consider the example shown in Figure 2.2, in which the different stages from manufacturer to final customer are shown. The sales tax is paid only at the end by the end consumer. In total, the government collects the 32 € (same as in VAT example) but only at the end and not along the whole chain at different stages. Government

32 €

100 €

Manufacturer

192 €

120 €

Wholesaler

Retailer

(160 Net + 32 Sales Tax)

Customer

Figure 2.2 Example with 20% Sales Tax

The United States has the globally most well-known sales tax jurisdiction. It’s a very complex system, especially regarding tax determination in enterprise resource planning (ERP) systems. Some of the factors that make up the complex US sales tax system are listed here: 쐍 Level of taxing authorities

Sales taxes aren’t charged on a federal level, but only on a state, municipality, and city level. Every state has different regulations on who charges and collects the taxes.

65

2

Indirect and Direct Tax Requirements

45 of the 50 states have implemented at least one general state tax. In several of these states, there are additional local taxes to be considered. For example, Illinois has a standard sales tax rate of 6.25% with an additional local tax rate of 0% to 5.25% (as of February 2022). The taxes are collected by the supplier of the goods and services and then need to be distributed to both the state authority as well as to the local authority (if applicable). With 50 different states, the list of different tax rates and collecting authorities becomes very exhaustive. Because there are so many different tax rates, the chance of a change of the rates is very high. If a company does business in many states and implements one ERP system, an automated solution should be implemented to cover these difficulties. 쐍 Sales versus use tax

Additionally, many states have also implemented a use tax. Use tax tries to ensure that consumers don’t go from a high sales tax state to a state with a lower sales tax rate to purchase goods. If this does happen, a use tax is charged. 쐍 Seller privilege tax versus consumer tax

The states have implemented two different rules concerning the liability of the tax payment. No matter which method the state implemented in their local regulations, the seller is always the party responsible for paying the tax to the relevant authorities. While in the seller privilege tax (SPT), the seller doesn’t need to state the sales tax on the invoice, in states where consumer tax (CT) is implemented, the sales taxes need to be stated on a tax invoice. In addition, the liability for SPT lies solely with the seller, whereas for CT, both the seller and the consumer can be held liable for the taxes, and taxes can be collected from either party. Another country that uses sales taxes is Malaysia. After having a GST plan for three years, in 2018, the sales and service tax (SST) plan was reinstated. Like the sales tax in the United States, it’s a single-layer tax imposed only on one layer of the value chain. However, the point of sales taxation isn’t at the final step on the consumer level but at the first step, the manufacturer. This is atypical for indirect taxes as the consumer never sees the tax amount levied on goods.

Special Indirect Tax Jurisdictions So far, we’ve covered indirect tax systems with VAT, GST, and sales tax jurisdictions that are implemented globally in many countries. There are a few countries which have special indirect tax jurisdictions that are extraordinary jurisdictions and don’t follow a similar approach or base their legislation on the OECD International VAT/GST Guidelines. In this section, we give only a brief overview of one special indirect tax jurisdiction and its peculiarities: Brazil. The Brazilian indirect tax system is known for being the most complicated one in the world, and we can therefore only give high-level insight here. In general, Brazil has a

66

2.1

Indirect Tax

VAT system for the manufacturing and sale of goods. There are different types of taxes that are levied for the different types of transactions: 쐍 IPI

Imposto sobre Produtos Industrializados (IPI) is a tax on manufacturing and importing of industrial products. The rates can vary from 0% to 300% for luxury goods such as cigarettes. The rates are to be found in a table where all goods are listed (table of taxes on industrialized products). This makes an implementation in an ERP system very difficult as there are no general standard/reduced rates as in many other countries. It’s important to note that IPI rates may vary from time to time, depending on the economic goals of the government. Therefore, it’s very important to keep the ERP system up to date. If an IPI rate is reduced, the application will be immediate. If an IPI rate is increased, the application will be 90 days after the enactment of the law. 쐍 ICMS

Imposto sobre Circulaçao de Mercadorias e Serviços (ICMS) is a tax on the circulation of goods as well as transportation and communication. Based on the state level, the rates differ by states with federal regulations only for the interstate transactions with minimum and maximum rates of 7% and 12%, depending on the original state and destination state, and 4% for all interstate transactions of imported goods. 쐍 PIS/COFINS

Program of Social Integration (PIS)/Contribution for the Financing of Social Security (COFINS) is a tax charged for social security reasons in additional to the other taxes. The rates differ based on the system the entity uses. The total tax rate is either 9.25% (noncumulative) or 3.65% (cumulative). The lower tax rate of 3.65% in the cumulative system (Lucro Presumido system, which is on presumed profit for income taxes) means that the company isn’t allowed to deduct input taxes. This depends on the activity of the company: Turnover from service of communication, transportation of people, and health services, for example, are taxed by the cumulative system even if the company isn’t under the Lucro Presumido system. 쐍 ISS

Imposto Sobre Serviços (ISS) is a tax on services and is collected by the municipalities. It isn’t part of the regular VAT system. The tax rate can be determined by the municipality and must lie between 2% and 5%. 쐍 ICMS-ST and PIS/COFINS-Monofásico

The Substituição Tributária (ICMS-ST) and PIS/COFINS-Monofásico concentrate taxation of all production and distribution stages at the level of the industry, having them prepay the tax for the whole chain. The other players on the chain won’t be able to credit ICMS. The calculation is complex and can vary from state to state and from industry to industry.

67

2

Indirect and Direct Tax Requirements

The taxable basis in Brazil is, unlike other countries, not based on the gross amount of goods and services provided. They use the gross-up mechanism, and the final price received is the taxable basis. Let’s consider the example shown in Figure 2.3. In both methods, we assume that the price the customer is paying is 120.00 and the tax rate is 20%. In the general VAT calculation, the taxable basis is the net amount (100.00), meaning the VAT of 20.00 is added on top of the net amount. In Brazil, the taxable basis is the gross amount of 120.00 resulting in a VAT of 24.00. So, although the price and the tax rate are the same, the payable VAT differs. General Brazilian VAT Calculation

Tax Amount 24.00 Price = Taxable Basis 120.00

General VAT Calculation

20% Tax

20% Tax

Tax Amount 20.00 Price 120.00

Net Costs

Taxable Basis 100.00

Figure 2.3 Comparison: Brazil versus Standard VAT Calculation with a 20% Tax Rate

Brazil differentiates between a commercial invoice and a tax invoice. Tax invoices can only be issued in the Portuguese language, in BRL currency, and electronically, making it difficult for foreign entities to establish global processes. For PIS/COFINS however, no invoice must be issued as the monthly amount due will be paid based on generated turnover.

2.1.2 Taxable Events The first question that needs to be answered to determine if indirect taxes apply is whether the event is taxable. Otherwise, it would be considered nontaxable or outside the scope of indirect taxes. A taxable event is defined differently in every jurisdiction. However, when looking at the OECD International VAT/GST Guidelines as well as different jurisdictions, there are general principles that are followed. Regularly, three main categories of taxable events are implemented: 쐍 Supply of goods

One type of a taxable event is the supply of goods. This is incorporated in every indirect tax jurisdiction. A differentiation is often made between tangible and intangible goods as well as movable and immovable property. The transfer of ownership and the right to dispose of the goods is the simplest definition for the supply of goods. Japanese law defines it as the “supply of assets” to incorporate both tangible and intangible assets into one category. Intangible goods such as intellectual property,

68

2.1

Indirect Tax

patents, software, and so on are more difficult to grasp as these are assets that can’t be physically transferred from one entity to another. For certain regulations regarding the supply of goods, see Section 2.1.5. 쐍 Supply of services

A supply of services is everything that isn’t a supply of goods. Some examples are postal services, telecommunication services, and labor services (e.g., repair, replacement, and processing of goods). There are special cases, for example, transportation services, which can fall under the different regulations of goods (Brazil) or services (China) or have a special regulation for taxation altogether (EU). Some jurisdictions have a catalog of services to differentiate tax rates or tax exemptions accordingly. 쐍 Importation of goods

Importation of goods is defined as the transfer of goods from outside the borders to inside the borders of a country’s tax jurisdiction. One key factor is that importation of goods usually crosses a “controlled” border where custom clearance is required. In the case of EU countries, importation is a transfer of goods from outside EU borders. Other jurisdictions, such as in Russia or the countries of the Gulf Cooperation Council, also have specific definitions for the regions where the transfer of goods is considered an import. The importation of goods as a taxable event ensures the destination principle of indirect taxation (see Figure 2.4). When looking at the place of taxation for international trade, either the country of origin or the country of destination (final consumption) can be an option to avoid double taxation. Only the destination principle can ensure a neutrality of international trade. Origin Principle

Destination Principle

Country A 20% Tax (Origin)

Manufacturer 100.00 Net + 20.00 Tax

Manufacturer 100.00 Net + No Tax

Country B 15% Tax (Destination)

Manufacturer 100.00 Net + 15.00 Tax

Manufacturer 100.00 Net + 15.00 Tax Retailer From A: 120.00 From B: 115.00

Import Tax 15.00 Tax Retailer From A: 115.00 From B: 115.00

Figure 2.4 Origin versus Destination Principle (Simplified)

In the example in Figure 2.4, the retailer located in Country B purchases the same thing from Country A (import) as well as from Country B (local purchase). Here, the neutralizing effect of the destination principle is displayed. In the case where the destination principle is applied, the retailer pays the same price whether the goods are purchased locally or from abroad. The tax is neutral when comparing the differ-

69

2

Indirect and Direct Tax Requirements

ent manufacturers. In the origin principle, the manufacturer from Country A with a higher tax rate will have a disadvantage compared to the local manufacturer in Country B. For importation in the United States and a sales tax jurisdiction, no sales tax is generally imposed. Sales and use tax are only applied when the goods come to rest and are sold to the final consumer. As there is no sales tax until the last step of the supply chain, the neutrality of the indirect tax is also valid in the United States. In addition to the three main categories, there are two further categories that supplement the definitions of taxable events: 쐍 Self-supply, gifts, and so on

Self-supply, gifts, and so on are also deemed to be taxable events in many jurisdictions. If goods are supplied for free as a gift, they can still be considered a taxable supply (often certain thresholds apply). In addition, the use of self-manufactured goods for individual consumption will be treated as a taxable event as the goal of indirect taxes is to tax the final consumption of goods. For those countries that don’t treat self-supply or gifts as taxable supplies, the input credit needs to be reversed. Creating a global approach for how to handle the individual treatment of supply of goods without consideration within a multinational cooperation is difficult. 쐍 Intrastate acquisitions

Intrastate acquisitions aren’t considered an importation of goods as they don’t cross any customs borders. In territories such as the EU or the Gulf Cooperation Council or in countries where VAT/GST is on a state level (e.g., Brazil or India), the intrastate acquisitions are considered a taxable event. The basis is also the destination principle stated under the definition of the importation of goods.

2.1.3 Tax Exemptions As already determined in Section 2.1.2, the first step is to determine if the event is taxable or nontaxable (i.e., out of scope of indirect taxes). For example, in most jurisdictions, damage compensations (e.g., contractual penalties) are nontaxable. For something to be taxable, a compensation or an exchange of services is necessary. For damage compensation, only one party is taking care of repairing or compensating for damages that have occurred without receiving any compensation. After the event has been deemed taxable, it can still be considered tax exempt, meaning that in general, the transaction falls under the indirect tax law, but there are certain rules laid down by the law that make it exempt from taxation. This section provides an overview of the different types of tax-exempt transactions most indirect tax jurisdictions have. We’ve divided the exemption types into the following four main categories, but there are of course many more and some very specific tax exemptions in individual countries:

70

2.1

Indirect Tax

쐍 Export and intra-community supplies

As described in Section 2.1.2, the importation of goods as well as the acquisition of intra-community transactions are taxable events. For the destination principle (see Figure 2.5) to have the desired effect, exports and intra-community supplies must be declared as tax exempt. For example, the supply of a machine is a taxable event when selling it locally within one’s own jurisdiction. However, if the machine is sold cross-border as an export, then it’s still a taxable event but exempt from taxes. Supply of Goods or Services

Taxable

Nontaxable

Tax Exempt

Liable for Taxes Place, Rate, etc.

Figure 2.5 Distinction between Nontaxable and Tax-Exempt 쐍 Public interest

This is a very broad category of tax exemptions and can include, among other things and depending on the jurisdiction, the following types of supplies and services: – Education: Educational courses are often tax exempt. Certain criteria need to be met such as approval by authorities of the curriculum or a minimum of two sessions for it to be considered a “course.” Other countries only allow certain official institutions and not private education services to benefit from the tax exemption. – Social security: Payments and activities for social security but also care for refugees, community activities, or food and lodging of homeless or people in need, for example, are mostly treated as tax-exempt transactions. – Medical care: This frequently includes medical services from doctors, midwives, dentists, and so on, as well as delivery of blood and organs. The services are often exempt when they are for maintaining health, preventing disease, or treating illnesses. 쐍 Financial, insurance, and postal activities

Services such as provision of loans or insurances and often postal services are taxexempt transactions. 쐍 Sale and rental of immovable property and land

Other transactions that are often exempted from indirect tax are the sale of immovable property or the supply of land.

71

2

Indirect and Direct Tax Requirements

The question arises regarding what the benefits are of implementing rules of tax exemption in an indirect tax jurisdiction. The indirect tax exemptions are primarily implemented to avoid double taxation (e.g., due to the obligation to pay real estate transfer tax, insurance tax, lottery tax) or for public interest reasons (medical treatment costs, renting out living space). However, in some cases, it might make sense to be able to make the event liable for taxes and have a waiver of a tax exemption with the option for taxation. For example, this is established in the EU VAT Directive (Article 137) as an option for several types of transactions. The most prominent example is when the taxable person has the right to opt for taxation in the sale and rental of immovable property and land. The benefit of waiving the tax exemption is the option to deduct input taxes. Most jurisdictions restrict the deduction of input taxes when the purchases are made for tax-exempt transactions. The idea of indirect taxes (VAT/GST) being a pass-through item on a B2B level would otherwise be invalid.

2.1.4 Grouping A few countries around the globe have implemented tax groups for indirect taxes as a means of simplification. Several countries in Europe have implemented VAT groups in their local legislation. Other jurisdictions also use the simplification, including Australia, Ghana, Norway, Saudi Arabia, Singapore, and the United Kingdom. Some countries require a mandatory grouping of entities for indirect taxation purposes (e.g., Germany and Austria), and others use a voluntary tax grouping (e.g., Poland or Italy). In general, these groups consist of two or more entities that meet certain criteria and are therefore treated as one taxable entity to tax authorities. The criteria that need to be met differ from country to country. Typical criteria are the following links between the entities: 쐍 Financial link

One of the legal persons controls another legal person by being able to make majority decisions. 쐍 Economic link

The controlled company is economically integrated into the company of the controlling company if they support or complement each other. The two companies must be sufficiently closely intertwined economically. 쐍 Organizational link

The interdependence of personnel is given, for example, when the managing director of both companies is the same person. The benefit of grouping the entities for the taxpayer is a reduction of compliance tasks, as often only one return needs to be submitted to tax authorities. In the example shown in Figure 2.6, if each of the four entities needed to submit a tax return, the formation of a tax group would reduce the number of tax returns by 50%.

72

2.1

Indirect Tax

Group Parent

Subsidiary

Subsidiary

Subsidiary

Legend: Nontaxable Transactions within Tax Group

Taxable Transactions

Tax Group

Figure 2.6 Example of a Tax Group and Taxability of Transactions

Additionally, the intra-group transactions of a tax group are usually nontaxable because the tax authorities treat the group as one legal entity (see Figure 2.7). A tax group can therefore have a beneficial cash effect when output tax needs to be paid earlier than the input tax is deductible. The negative cash effect, that is, if no tax group is possible, is caused by timing differences when one entity of the group must pay taxes earlier as the other entity receives the input tax (see Figure 2.7). Note that not all jurisdictions have the rule that intra-group transactions are nontaxable. Example: Subsidiary A provides services for 100.00 net to Subsidiary B. The standard tax rate is 20%. With Tax Group Subsidiary A

Subsidiary B

100.00 Net No Tax Involved

Without Tax Group Subsidiary A

Tax is paid at time of supply.

Subsidiary B

100.00 Net + 20.00 Tax

Input tax is received with invoice.

120.00 Gross Cash Effect

0.00

−20.00

Possible Timing Difference

+20.00

Figure 2.7 Cash Benefit of Tax Grouping for Intra-Group Transactions

Although there are benefits from an organizational standpoint with a reduction of tax compliance tasks as well as a possible positive cash effect, there are also downsides. When submitting tax returns for several entities as one, the amounts need to be aggregated possibly from different ERP systems. In addition, reconciling the tax payments across the tax group can become highly complex and increase manual work for the finance teams involved.

73

2

Indirect and Direct Tax Requirements

2.1.5 Transaction Types Along with the standard cases stated in previous sections, some special scenarios can lead to special tax treatments or higher complexity. Every jurisdiction has its own peculiarities. In this section, we’ll show some specific examples of certain indirect tax transaction types. Alongside the description, we’ll lay out the challenges that come with the transaction type.

Chain Transactions Chain transactions refer to the form of delivery of goods in which the goods are delivered to the buyer directly from the manufacturer without touching the dealer's warehouse. The dealer only performs an intermediary function. This transaction type where there are several parties involved is often also referred to as drop shipping or ABC contracts. With the high increase in e-commerce transactions, the term drop shipping is always used in this respect when it comes to chain transactions. The example shown in Figure 2.8 is the simplest form of a drop shipment. Company C orders goods from Company B (second leg). As Company B doesn’t have them in stock, they order the goods from Company A (first leg). The delivery of the goods goes directly from Company A to Company C. The indirect tax laws state that each leg of the chain transaction is regarded as a separate supply.

Company B Invoice

Invoice Order

Order

Company A

Company C

Direct Delivery from A to C

Figure 2.8 Overview Standard Chain Transaction

If all transactions/legs of the chain transaction are within one tax jurisdiction (i.e., within one country or, in case of the United States, within one state), they are all taxable and will be taxed locally. As soon as more than one country is involved, the taxation can become more complex. In the preceding example, this would be the case if Company A is in one country and Company B and C are in another country. Company A has the direct delivery from one country to another. The question arises if the transaction between A and B as well as the transaction between B and C are tax-exempt as an export or as intra-community supply. Within the EU, only one transaction in a chain can be tax exempt. All the other ones will be taxed locally in one of the member states. Dependencies are the VAT ID number used as well as the responsibility of transport (in the example: does Company A transport the goods or does Company C pick up the goods?). Based on these (and a few more)

74

2.1

Indirect Tax

dependencies, the EU VAT directive defines where the taxable transaction is. Defining the taxable and tax-exempt transactions in these chains is tricky and needs to be evaluated. Furthermore, there are special simplification rules such as intra-community triangulation where three parties from three different countries are involved. Here the EU has created a construct to avoid a registration obligation of the party in the middle of the triangle. Simplified, in the example shown in Figure 2.9, Company A makes a taxexempt intra-community supply to Company B in Denmark. The Danish Company B then has an intra-community triangulation sale without VAT to Company C. Finally, Company C will be liable for VAT in Hungary as an intra-community acquisition. Company B in Denmark can make this transaction in the middle with solely a Danish registration and without having any reporting obligations in either France or Hungary.

Intra-Community Supply Company A (France)

Company B (Denmark)

Triangulation Company C (Hungary)

Direct Delivery from France to Hungary

Figure 2.9 Example Standard EU Triangulation

Next, let’s consider drop shipping in the United States. Whether sales tax is applicable depends on several factors, including the locations of the three parties, the taxability of the goods, and where the seller or supplier has nexus. Nexus is defined as the obligation to collect sales tax in the United States. Usually, the customer will pay sales tax to the seller. The seller remits the tax to the state. The seller then provides a resale exemption certificate to the supplier. This certificate will exempt the supplier from paying taxes and needs to be kept as proof. But like the EU, there are several different and additional constellations based on certain criteria. Chain transactions with special treatment like these usually only exist in jurisdictions where tax exemptions apply to cross-border transactions. In many other countries, there are no special regulations for chain transactions, and each leg of a chain will be taxed accordingly. However, keep in mind that while setting up indirect tax processes, chain transactions and their tax treatment need to be analyzed to avoid double taxation, registration obligations, compliance tasks, and a complex ERP setup. See Chapter 4, Section 4.4.1 for more information.

Tooling To produce special parts, suppliers sometimes must create special tools or molds, for example. Although the costs for these tools is charged to the customer, only the final part is delivered to the customer. The tools remain with the supplier. Cases where

75

2

Indirect and Direct Tax Requirements

the delivery of the manufactured special part is shipped to another EU country are regularly billed as tax-exempt intra-community supplies. For the costs of the special tools that remain with the supplier, it’s questionable where and how these are taxed. Some legislations have set up special regulations that should be reviewed in detail before setting up the processes for indirect taxes. The challenge from an indirect tax perspective is for cross-border transactions. The issue is whether the legislation requires the costs for the tools to be a local taxable transaction, which would create extra costs or even registration requirements for the purchaser of the goods. To avoid this, laws often simplify this issue, and the costs for tooling will lead to the same tax treatment as the original sale of goods. While this can simplify some areas, such as tax reporting and registration obligations, it can create complexity in areas where goods movement needs to be reported alongside with the tax exemption of cross-border sales. As no goods are physically moved, the supplier doesn’t have a proof of delivery for the tax exemption.

Work Delivery In this section, we’ll focus on the EU and the regulations of work supply and work performance. A work delivery is a supply which consists of the processing of goods that don’t belong to the supplier. Like tooling and chain transactions, this becomes especially relevant when looking at cross-border transactions. To differentiate between a normal supply from work supply or work performance, Table 2.2 shows an example based on selling a table to a B2B customer. Normal Supply

Work Supply

Work Performance

A furniture store sells a table to a restaurant.

A carpenter makes a table and sources the wood herself and sells it to a restaurant.

A carpenter makes a table with wood provided by the customer and sells it to a restaurant.

Table 2.2 Differentiation between Normal Supply, Work Supply, and Work Performance

If an entrepreneur carries out a taxable event that contains both elements of a supply and a service, it must be checked whether it’s a work supply or a work performance. The delimitation not only has an impact on determining the correct place of performance or tax exemption but also determines who is liable for the VAT of the supply. Errors in the assessment can lead to significant VAT consequences for both the entrepreneur providing the supply and for the recipient.

2.1.6 Standard Reporting Requirements To make sure entrepreneurs are correctly paying their indirect taxes, reporting requirements to tax authorities have been established. These differ in periods and

76

2.1

Indirect Tax

complexity based on the country. In general, the higher the tax gap (taxes legally to be paid versus taxes actually paid) is in a country, usually the higher the reporting requirements will be. Meaning, in countries with a low tax gap, less information in a lower frequency needs to be reported to tax authorities (e.g., annual tax return with basic revenue information). If the tax gap in a country is very high, the tax authorities will request detailed information very regularly (e.g., live reporting with transactional data). In this section, standard reporting requirements are the regular monthly/quarterly/annual tax returns that need to be submitted to tax authorities. For details on digital tax reporting, such as e-invoicing, see Section 2.1.7. Table 2.3 shows a list of the filing frequencies of several countries for regular standard indirect tax reporting. As you can see, the standard filing frequency is monthly. Although the monthly filing frequency is the most common, taxpayers can often reduce the frequency of filing obligations if certain revenue thresholds aren’t met. Sometimes this is automatic and sometimes must be requested by tax authorities. Country

Filing Frequency

Country

Filing Frequency

Argentina

Monthly

India

Monthly*

Australia

Monthly*

Indonesia

Monthly

Belgium

Monthly*

Ireland

Bimonthly

Brazil

Monthly*

Israel

Monthly*

Bulgaria

Monthly

Kazakhstan

Quarterly

Canada

Monthly

Kenya

Monthly

Chile

Monthly

Korea

Quarterly

Colombia

Bimonthly*

Latvia

Monthly*

Costa Rica

Monthly

Lithuania

Monthly

Czech Republic

Monthly*

Luxembourg

Monthly*

Denmark

Semiannually

Malaysia

Bimonthly

Egypt

Monthly

Malta

Monthly*

Estonia

Monthly

Mexico

Monthly

France

Monthly

Netherlands

Quarterly*

Germany

Monthly*

New Zealand

Monthly*

Greece

Monthly*

Norway

Bimonthly

Hungary

Quarterly*

Pakistan

Monthly*

Table 2.3 Filing Frequency for Standard VAT/GST Reporting Obligations in 2022

77

2

Indirect and Direct Tax Requirements

Country

Filing Frequency

Country

Filing Frequency

Panama

Monthly

Sweden

Monthly*

Philippines

Monthly

Switzerland

Quarterly

Poland

Monthly*

Thailand

Monthly

Romania

Monthly

Tunisia

Monthly

Russia

Quarterly

Turkey

Monthly*

Serbia

Monthly*

Ukraine

Monthly*

Singapore

Quarterly

United Kingdom

Quarterly*

Slovenia

Monthly*

United States

Monthly*

South Africa

Monthly*

Uruguay

Monthly*

Spain

Monthly*

Venezuela

Monthly*

Sri Lanka

Monthly*

Vietnam

Monthly*

*Based on revenue thresholds or applications to tax authorities, a different filing frequency can also apply.

Table 2.3 Filing Frequency for Standard VAT/GST Reporting Obligations in 2022 (Cont.)

In every country, electronic filing is possible. In some countries, the tax authorities have restricted the submission to solely electronic format, while in others the submission of paper tax returns is still possible. The information to be provided in indirect tax returns is usually the following: 쐍 Total value of sales 쐍 Output tax 쐍 Input tax

This is then broken down into different complexities. A simple tax return such as in the United Kingdom or in Ireland consists only of a couple of boxes with this information. Other countries such as Poland or Germany require more detailed information: 쐍 Taxable revenue split by different tax rates 쐍 Output tax split by different tax rates 쐍 Tax-exempt revenue with input tax deduction 쐍 Tax-exempt revenue without input tax deduction 쐍 Intra-community acquisitions split by different tax rates 쐍 Reverse-charge revenues

78

2.1

Indirect Tax

쐍 Input tax for invoices 쐍 Input tax for intra-community acquisitions 쐍 Import tax

These items are usually more high-level summarized information that taxpayers report to tax authorities. In countries where there is no transactional reporting (e.g., Standard Audit File for Tax [SAF-T] for VAT in Poland), this is the main information the tax authorities receive. They base their audits and information requests on this information. Furthermore, to supplement the standard monthly indirect tax reporting, there are other more transactional-based reports such as sales lists or Intrastat. Some countries require local sales lists where invoices are listed and provided to tax authorities on a monthly basis. Additionally, within the EU, there are requirements such as the EC Sales List (see also Section 2.1.1 for more information) or Intrastat reporting. Intrastat (intracommunity trade statistics) is a mandatory reporting requirement in all EU countries to collect statistics on the intra-community movement of goods. With the Intrastat declarations, the actual goods movement between member states of the EU (dispatches and arrivals) is statistically recorded by the Federal Statistical Office. The tax authorities of member states and the statistical authorities often share the information to monitor the reporting obligations. One important piece of information as the result of almost every indirect tax return is the payment or refund. These are also handled differently in each country. In case of a payment, it’s usually due with the filing of the tax return. When it comes to obtaining a refund due to higher input tax compared to output tax, it’s handled very differently. Few tax authorities just pay the refund amount to the taxpayer. Often a carryforward to the next period, an official refund request, or an audit result before receiving the refund. Even within the EU with a unified tax system, the reporting requirements as well as the payment and refund mechanisms differ extremely. Once a tax return has been submitted, it generally should not be altered. However, the reality in companies is that mistakes happen, systems have errors, or new information becomes available that leads to the necessity of amending a tax return. The method of amendment can be one of the following, among others: 쐍 Correcting the old tax return with an informal letter to tax authorities 쐍 Resubmitting a tax return with new figures 쐍 Submitting an official correction form provided especially for these cases from tax

authorities 쐍 Including the changes in the current tax return and commenting to tax authorities 쐍 Including the changes in special available boxes in the current tax return

79

2

Indirect and Direct Tax Requirements

Usually, an amendment is possible until the final assessment (after an audit) or up to a certain number of years laid down by law. The submission of amendments will most likely lead to interest payments to tax authorities if the payable increases.

2.1.7 Digital Reporting Requirements In this section, we’ll discuss DRRs, which are a synonym for transaction-based reporting (TBR) and e-invoicing. TBR can either be periodic (periodic transaction controls [ PTC]) or continuous (continuous transaction controls [CTC]). Many tax authorities in the world are currently planning or realizing one of these measures to increase transparency and close VAT gaps. In addition, the digitization itself is a driver for these measures as taxpayers are seeking efficiency gains and automation in their tax reporting processes. In this section, we’ll discuss current ongoing developments on the level of the EU commission and leading CTC-focused organizations such as European E-invoicing Service Providers Association (EESPA) or the Pan-European Public Procurement OnLine (Peppol) network: 쐍 Legal EU requirements for DRRs

Per the European Commission (EC), member states can impose obligations other than VAT returns by virtue of Article 273 of the VAT Directive. These obligations are meant to ensure the VAT collection is done correctly and to prevent fraud. They may only be imposed provided the obligations don’t interfere with other VAT principles, don’t make a distinction between cross-border and domestic transactions, don’t cause border formalities, and don’t add invoicing requirements in addition to those already imposed in Chapter 3 of the VAT Directive. Article 273 also allows member states to introduce their own requirements for TBR (e.g., business transaction reports, tax and accounting data, etc.) in addition to or joined with VAT returns. 쐍 E-invoicing

The introduction of mandatory e-invoicing doesn’t allow members states to use the derogation of Article 273 as invoice recipients need to accept the use of e-invoicing (Article 232). A member state must request a derogation from the directive under Article 395 instead to pave the way for mandatory e-invoicing. This approval is subject to the unanimous agreement of the council based on a proposal from the commission. Business-to-government (B2G) transactions are based on a totally different framework. 19 member states are required by the e-invoice directive to enable their public administrations to accept structured e-invoices according to the European standard. Furthermore, the taxable persons issuing e-invoices during B2G transactions must use the standard provided by the e-invoicing directive. However, some member states still have provincial B2G areas where B2G e-invoicing is not yet mandatory.

80

2.1

Indirect Tax

쐍 Recapitulative statements

Recapitulative statements include EC Sales (and Purchase) Lists or VAT Information Exchange System (VIES) listings and cover intra-EU transactions. Articles 262–271 of the directive cover requirements for recapitulative statements. Remember, TBR and e-invoicing requirements were subject to national rules instead. According to these provisions, every VAT registered trader is obliged to report recapitulative statements that contains aggregated details of the taxable persons to whom intra-community supplies of goods and cross-border supplies of services subject to a reverse charge (Article 196) have been performed. The DRRs can be distinguished by the following: 쐍 PTCs

PTC-based VAT reporting, in which transactional data is reported aggregated to tax authorities at regular intervals. 쐍 CTCs

Electronic submission of transactional data before, during, or shortly after the actual exchange of the transactional data between the parties, including e-invoicing requirements. PTC and CTC requirements include key specifications, as shown in Table 2.4: 쐍 VAT listings

This requirement is a list of transactions with information about the base values and business partners, as well as other VAT-relevant data usually mentioned on an invoice (VAT ID). The submission sequence is typically monthly or quarterly, comparable with the VAT return filing frequency. 쐍 SAF-T

As mentioned earlier, SAF-T reporting is a specific form of TBR based on the OECD’s standard that was developed for tax auditing and accounting purposes to deliver information on direct and indirect taxes. The majority of adaptions mandated a SAFT standard locally as the format through which tax and audit information, including on VAT transactions, is to be submitted to tax authorities on a periodic basis or on demand. Poland is an example where SAF-T replaced standard VAT reporting obligations as the VAT return. 쐍 Real-time reporting

The taxpayer is obliged to transmit transactional data in (near) real-time after the transaction took place. Required data contains invoice data but not the invoice itself. An example is Spain with the obligation to report the invoice (and more information) within four days after the invoice was issued.

81

2

Indirect and Direct Tax Requirements

쐍 E-invoicing

E-invoicing is the exchange of electronic invoices (structured, machine-readable data) between business partners (economic point of view) as part of a business transaction. The exchange can be centralized through a public fiscal portal or decentralized through certified private service providers. Tax administrations are seeking transparency during this process and companies usually seek efficiencies. Periodic Transaction Controls (PTC)

Continuous Transaction Controls (CTC)

VAT listing

Real-time

SAF-T

E-invoicing

Table 2.4 Digital Reporting Requirements

As shown in Figure 2.10, 12 EU countries have introduced TBR or e-invoicing measures. Many other countries inside and outside the EU are currently working on the introduction of TBR or e-invoicing mechanisms. Therefore, the European Commission started an initiative to figure out if and how harmonization throughout the EU would be possible. In October 2022, a proposal is expected regarding what the future of DRRs could look like in the EU. Countries that are close to the introduction of TBR and e-invoicing mechanisms are expecting input or influence for their local next steps of introduction. Legend: Mandatory clearance e-invoicing Real-time reporting SAF-T reporting Transactional VAT listings Forthcoming reporting requirement No reporting requirement Non-EU countries

Figure 2.10 DRR Landscape in the EU (Source: EU Commission)

Based on the study European Commission’s action plan, “VAT in the Digital Age,” (http://s-prs.co/v549501), we summarized drivers, problems, and effects of the emerging requirements within the EU with regard to DRRs in Figure 2.11.

82

2.1

Drivers

Wide discretion accorded to member states on digital reporting requirements (art. 273) Lack of EU guidance on digital reporting requirements

Indirect Tax

Problems

Effects

Fragmented regulatory framework

Legal uncertainty and high compliance costs for MNCs and e-service providers

Suboptimal fight against domestic and intra-EU VAT fraud

Losses of revenues for EU member states and the EU

Legal obstacles to introduce mandatory e-invoicing Optional introduction of digital reporting requirements (art. 273) Compliance costs of digital reporting requirements Limited effectiveness of reporting tools for intra-EU transactions

Figure 2.11 Drivers, Problems, and Effects (Source: EU Commission)

E-invoicing/CTC systems are designed from a local perspective and for local use. But despite differences, there are common character traits that allow us to summarize them into the following categories, as shown in Figure 2.12: 쐍 Interoperability model 쐍 Real-time invoice reporting model 쐍 Clearance model 쐍 Centralized exchange model 쐍 Decentralized exchange model

The following explains the commonly used zones in Figure 2.12 that aid in understanding the CTC models: 쐍 Regulation

This is the playground of the tax administration as an example of a governmental body. The local tax administration provides the data and processing requirements. Preferably, in the future, these requirements will equal commonly used standards. The data definition includes invoice data as a full data set or a subset thereof.

83

2

Indirect and Direct Tax Requirements

쐍 Standardization

Standardization is one of the key requirements for the interoperable use of data. In this zone, certified service providers exchange invoices based on technical standardization. Such standardized technical formats are available and are developed and maintained by standards development organizations. 쐍 Non-standardization

This is the zone for exchange activity between invoice issuer and invoice recipient as economic operators. The activity isn’t subject to regulation or standardization. Interoperability

Software solution*

Real-time reporting

Clearance

Centralized exchange

Decentralized CTC and exchange

Government

Government

Government

Government

Software solution

Supplier

Software solution

Software solution

Software solution

Software solution

Software solution

Software solution

Software solution

Software solution

Supplier

Buyer

Supplier

Buyer

Supplier

Buyer

Supplier

Buyer

Buyer

Decentralized exchange without real-time reporting via network of certified vendors

Reporting of transactional data to CTC platform in near-real time to exchange

Validation by CTC platform in near-real time to exchange and validation post reception

Transactions in validated and exchanged by CTC platform

Decentralized exchange with validations and reporting via network of certified vendors

Peppol, Finland

Hungary, South Korea

Chile, Mexico

Italy, Turkey

EESPA, Peppol

*Software solution could be the ERP vendor, service provider, EDI provider, workflow solution, or even the taxpayer if it has passed the necessary certification.

Legend:

Non-standardized

Standardized

Regulated

Figure 2.12 CTC Category Design (Source: Expert Group)

As shown in Table 2.5, there are currently five different models that we want to shine a light on in the following list: 쐍 Interoperability model

This is the efficiency model, which is also known as the four-corner model. The four corners stand for the invoice issuer and the invoice recipient with their respective certified service providers. Standardization between the certified service providers leads to an efficient exchange of invoices in an agreed document format and exchange methodology. No tax authority or regulated zone is in place in this model. This is one of the reasons why we find this model in countries such as Finland, with a relatively small VAT gap. Nevertheless, during audits, tax administrations and taxpayers benefit from the transparency of data. 쐍 Real-time invoice reporting model

This model is based on invoice information (additional information possible) that is reported to a tax authority without any exchange between business partners or certified service providers and no forwarding by the tax authorities. From a taxpayer’s perspective, this is an additional reporting burden without efficiency gains. From a tax authority’s perspective, this model can lead to increased transparency. 쐍 Clearance model (variations possible)

In this model, the tax authority has a clearance function and no forwarding or

84

2.1

Indirect Tax

exchange function depending on the variant of the model. The issuer of the invoice needs clearance of an invoice by the tax administration to be able to issue the invoice to the invoice recipient. Here we see no standardization zone, which means no standardization through certified service providers between the tax authorities and the business operators. 쐍 Centralized exchange model

Similar to the just mentioned clearance model, there is no standardization zone in this model, meaning that the tax authority determines the document format and exchange methodology. This fact can lead to a variety of different requirements from country to country. It differs from the clearance model by the exchange function of the tax administration portal. Based on the way data is exchanged between the invoice issuer and the invoice recipient through the tax administration portal, this model is called the v-model. 쐍 Decentralized CTC and exchange model (DCTCE)

“Decentralized” means that the data validation and exchange is managed by certified service providers instead of only the one alternative of a public fiscal platform (the government CTC platform is released of a heavy technical burden). All zones are in place in this model: the standardized zone for the central governmental platform, the non-standardization zone for the business operators, and the regulated zone for the certified service providers following a predefined minimum technical standard. With this approach, existing industry Electronic Data Interchange (EDI) standards can be continued after an implementation of the DCTCE model. Interoperability Model

Real-Time Invoice Reporting Model

Clearance Model

Centralized Exchange Model

Decentralized Exchange Model

쐍 Network of certified or private service providers

쐍 Tax reporting of invoice data or a subset thereof

쐍 Transfer of invoice details to tax authorities

쐍 Invoice transfer regulated and limited

쐍 Unified data format

쐍 Near real-time after invoice issue

쐍 Clearing of invoice

쐍 Central regulated exchange platform as single exchange instance

쐍 Invoice exchange not unified

쐍 Possible extension to further details referring to different data source (e.g., payment information)

쐍 After clearing: nonstandardized or regulated transfer of invoice

쐍 Data validation by the platform

쐍 Central regulated exchange platform and additional channels of standardized exchange through certified service providers 쐍 Invoice validation by the platform

Table 2.5 CTC Category Characteristics (Source: Peppol, FAU Nuremburg)

85

2

Indirect and Direct Tax Requirements

2.2 Direct Taxes In addition to indirect taxes, managing direct taxes is one of the tax function’s key activities. Compared to indirect taxes, direct taxes are basically levied and paid at the level of the taxable entity or group of entities. Major direct taxes include income tax, corporate income tax, and withholding tax (WHT) as a special form of levy. In this book, we’ll focus on corporate income tax and WHT. Direct taxes are usually calculated by applying a tax rate on the taxable profit. As local tax legislation significantly varies from country to country in terms of tax rate and provisions for determining the taxable income, fulfilling of global direct tax requirements is a complex and time-consuming task. This not only applies to local tax filings such as tax returns but also cross-border filing obligations such as Base Erosion and Profit Shifting (BEPS), including country-by-country-reporting (CbCR) or SAF-T. Last but not least, significant external financial reporting requirements according to Generally Accepted Accounting Principles (GAAP) or International Financial Reporting Standards (IFRS) exist. In the following sections, we’ll provide a basic overview of global direct tax filing requirements. In addition, further direct tax filing obligations occur on the local level; however, these requirements are beyond our scope.

2.2.1 Base Erosion and Profit Shifting BEPS has been set up as a framework by the countries of the OECD and other countries to improve international tax standards and reduce harmful international tax competition. This has been driven by the fact that global companies, in contrast to small and medium-sized enterprises (SMEs), minimize their tax burden through aggressive tax planning and may harm competition among companies. Thus, the main purpose of the BEPS project was to turn to a taxation at the place of entrepreneurial activity and economic value creation. In addition, the project intended to improve transparency between tax administrations and enable an exchange of information on tax rulings. In October 2015, the OECD published the results of the project combined with an action plan of 15 recommendations to be implemented by the involved countries. The action points are summarized as follows: 쐍 Action 1: Addressing the tax challenges of digitalization 쐍 Action 2: Neutralizing the effects of hybrid mismatch arrangements 쐍 Action 3: Strengthening controlled foreign company (CFC) rules 쐍 Action 4: Limiting base erosion via interest deductions and other financial pay-

ments

86

2.2 Direct Taxes

쐍 Action 5: Countering harmful tax practices more effectively, taking into account

transparency and substance 쐍 Action 6: Preventing treaty abuse 쐍 Action 7: Prevent the artificial avoidance of permanent establishment (PE) status 쐍 Action 8–10: Assuring that transfer pricing outcomes are in line with value creation 쐍 Action 11: Developing methods and regulations to obtain data on profit cutting and

profit shifting 쐍 Action 12: Developing disclosure regimes for aggressive tax planning 쐍 Action 13: Guidance on transfer pricing documentation and CbCR 쐍 Action 14: Improving administrative cooperation in mutual agreement and arbitra-

tion proceedings 쐍 Action 15: Developing a multilateral instrument

As the measures defined with BEPS are comprehensive and complex, we’ll focus in this book on one requirement, CbCR, as defined in action 13, to provide an example for an important direct tax reporting requirement arising from BEPS. Transparent taxation of global enterprises can only be ensured if tax authorities receive the necessary information. In BEPS action 13, standardized documentation requirements in the area of transfer pricing for global enterprises were agreed upon so that tax administrations receive required information and global enterprises can fulfill their documentation obligations in accordance with a uniform standard. For this purpose, a documentation standard has been developed that includes three reporting requirements: 쐍 A master file providing an overview of the multinational company’s business activ-

ities and its transfer pricing policy 쐍 A local file covering country-specific documentation of the taxpayer’s specific busi-

ness transactions with related parties 쐍 CbCR

The CbCR is intended to provide all tax administrations concerned with an overview of the global distribution of income and taxes, as well as certain indicators of the geographical distribution of economic activity among the various countries. The CbCRs are automatically exchanged across tax administrations if the involved states have entered into a corresponding agreement under international law. As a consequence, the following tax data based on the consolidated financial statements of the group needs to be submitted to local tax authorities by the reporting taxpayer: 쐍 Sales revenue and other income from transactions with related parties 쐍 Sales revenue and other income from transactions with unrelated parties 쐍 Total of sales and other income as defined in the first two points

87

2

Indirect and Direct Tax Requirements

쐍 Income taxes paid during the financial year 쐍 Income taxes paid and accrued in the financial year for that financial year 쐍 Profit for the year before income taxes 쐍 Shareholders’ equity 쐍 Retained earnings 쐍 Number of employees 쐍 Tangible assets

As you can see, it’s essential to structure your ERP data in a way that the required tax data can be obtained.

2.2.2 Base Erosion and Profit Shifting 2.0 Although the states involved in BEPS have taken the aforementioned actions, there are remaining risks that may cause an adverse global taxation of multinational companies. In the light of new evolving digital business models, a fundamental reform of the world tax order is currently being discussed. To address the remaining BEPS risks, states are currently working on additional actions particularly addressing the fair taxation of the digitized economy. The project includes two pillars, which we’ll discuss in the following sections: 쐍 Pillar one: Address the reallocation of taxation rights of the largest and most profit-

able corporations in the world. 쐍 Pillar two: Address the remaining BEPS risks by introducing a global effective mini-

mum tax to quit aggressive tax structuring and harmful tax competition.

Pillar One The first pillar deals with the reallocation of taxing rights over business income. The proposal seeks to revise nexus and profit allocation rules in favor of market jurisdictions based on the unified approach. The measures under pillar one are intended to expand the taxing rights of market jurisdiction through the following mechanism taking into account two amounts: 쐍 Amount A: Allocation of additional taxing rights to market jurisdictions via a for-

mulaic apportionment of residual profits of a multinational enterprise (MNE) group 쐍 Amount B: A fixed remuneration for certain defined marketing and distribution

activities taking place physically in the market jurisdictions While amount B is embedded in the existing international tax order, amount A establishes a new nexus and profit allocation rules. The application of amount B requires a physical presence (i.e., subsidiary or PE) while amount A enables jurisdictions to tax inscope MNEs irrespective of physical presence.

88

2.2 Direct Taxes

Let’s take a closer look at amount A. Amount A constitutes the central response to the tax challenges of the digitalization by reallocating a part of the residual profit of a MNE. The new taxing right will provide for an additional allocation of taxing rights to market jurisdictions through a formulaic profit split, establishing a new nexus for in-scope MNEs to enable taxation in market jurisdictions where MNEs participate in the economy of a jurisdiction with significant economic activity but without physical presence. Amount A applies to automated digital services and consumer-facing businesses. For the new nexus, the unified approach defines the generation of sales in a market jurisdiction over a period of years as the primary indicator for a significant economic activity. For this purpose, sales will be accounted for regardless of whether the sales are generated via direct distribution through a physical presence or via a group or thirdparty sales partner in the market jurisdiction. The new nexus will be designed as a standalone treaty provision in addition to the definition of the PE according to the OECD model convention. Within the current system, profit is allocated to physical presence. Therefore, the profit allocation rules need to be revised to enable a profit allocation regardless of whether taxpayers maintain a marketing or sales presence (PE or subsidiary) in the market jurisdiction or conduct their business through independent parties. Under pillar one, MNEs will apply, in principle, the existing transfer pricing system (supplemented by amount B). Amount A will apply only to MNE groups with automated digital services and consumer-facing activities that exceed a certain turnover (i.e., $750 million) and profitability and de minimis tests. Given amount A is applicable, it’s determined as a combination of the profit split and formulaic apportionment method: 1. The total profits of the MNE group are identified using consolidated financial accounts. 2. The routine profit is identified via approximation through an agreed-upon profitability level. The deemed routine profit is excluded from reallocation to market jurisdictions. 3. The nonroutine profit, that is, the profit above a certain level of profitability, is split through the formulaic apportionment into nonroutine profits attributable to market jurisdictions and nonroutine profits that arise through other factors. 4. The deemed nonroutine profits attributable to market jurisdictions are allocated to market jurisdictions based on sales, given that the nexus test in the market jurisdiction is met. Meanwhile, amount B works in the existing system, that is, requires physical presence and complements the arm’s length principle. It provides for the taxation of marketing and sales functions in the market state. With the objective of minimizing disputes, this will be done by means of a fixed remuneration for baseline marketing and sales activities in the source state. The design is yet to be determined. The fixed remuneration will

89

2

Indirect and Direct Tax Requirements

be designed as a guaranteed minimum return, a safe harbor with a rebuttable presumption, a traditional safe harbor, or a risk assessment approach. The fixed remuneration will be set regionally or specific to the industry.

Pillar Two The policy rationale of pillar two, also referred to as Global Anti-Base Erosion (GloBE) proposal, is to tackle the remaining BEPS challenges and to disincentivize profit shifting and tax competition by establishing a globally effective minimum taxation of corporate profits. The underlying assumption is that digital business models and globalized corporate structures enable profit shifting to low-tax countries and, therefore, justify limiting tax competition to a certain minimum level. The proposal intends to preserve the sovereignty of jurisdictions to set tax rates by providing jurisdictions with tools to tax profits where other jurisdictions apply low effective taxation or don’t exercise their taxing right. The GloBE proposal comprises four interrelated rules: 쐍 Income inclusion rule

The income inclusion rule, which is understood as a supplement to CFC rules regimes, will allow the taxation of a proportionate share of low-taxed profits of a foreign subsidiary in the jurisdiction where the parent corporation is headquartered. The income inclusion rule will work as a top-up to a minimum rate, thereby ensuring a minimum level of taxation. Generally, this approach doesn’t prevent jurisdictions from setting their own tax rates, but it provides for a “right to tax back” if other jurisdictions reduce their tax rates below a certain level. The minimum tax rate will be designed as a blended fixed rate. To compute the tax rate, financial accounts can serve as a basis. 쐍 Switch-over rule

To ensure that the income inclusion rule covers foreign branches, a switch-over rule will be implemented. The switch-over rule will apply to the income of foreign PEs and allow the jurisdiction where the corporation is domiciled to apply the credit method instead of the exemption method if the income isn’t subject to tax or taxed at a low rate. Consequently, the income of the foreign PE is attributed to the parent corporation and thus subject to taxation in the state of residence. 쐍 Undertaxed payments rule

The undertaxed payments rule will address payments to related foreign corporations aimed at reducing domestic tax. Under this rule, the deduction of certain types of payments will be denied if the payments haven’t been subject to a minimum level of taxation. In such cases, the tax will thus be levied on the company’s profit before the deduction of the said harmful payment. 쐍 Subject to tax rule

The undertaxed payments rule will be supplemented by a subject-to-tax rule, which

90

2.2 Direct Taxes

subjects a payment to WHT and denies benefits arising from double taxation agreements for certain types of income if the payment isn’t taxed at a minimum rate. The subject to tax rule will generally apply between related parties but may also be extended to unrelated parties for interest and royalties according to Article 11 and 12 of the OECD model convention. The implementation of such a rule will entail a comprehensive amendment of the worldwide double taxation treaties.

2.2.3 Standard Audit File for Tax Tax authorities perform tax audits based on accounting records to check whether related tax obligations have been met. This becomes much more complex if multinational companies are subject to different tax legislations in each country of a tax audit and the company potentially uses different ERP systems across the globe. The purpose of a tax audit is to check whether a business has paid the correct tax at the right time, in accordance with local tax legislation. The tax auditor needs to obtain and evaluate the required audit evidence to determine whether a tax return is correct or not. Audit evidence is usually obtained based on parallel compliance and substantive testing procedures taking into account the information made available through accounting records and source documents. While the audit approach is significantly impacted by audit policies issued by local tax authorities, the audit strategy mentioned before is basically comparable. Compliance testing based on the internal control framework of the company to ensure that entries are properly authorized and completely and correctly recorded in the ERP system builds the first essential element of an effective audit approach. If compliance testing is deemed ineffective, substantive audit procedures have to be set up as a second element. The increasing use of electronic files leads to more challenges for tax audits as tax auditors need to gain a substantial understanding of the taxpayers’ ERP landscapes. This is in contrast to the former practice of focusing audit procedures on, for example, supporting paper documents. Thus, the use of ERP-based audit approaches provides the necessary methodology to perform a future proven tax audit. It’s clear that a tax auditor should have ready access to ERP data to perform substantive audit procedures. As a consequence, the OECD Committee on Fiscal Affairs (CFA) has defined SAF-T. Based on SAF-T, tax auditors are able to test electronic accounting data in a structured and standardized way to identify tax risks or errors in the accounting records. SAF-T is designed in a way that tax auditors can access the accounting data in an easily readable format irrespective of the size of the business ranging from SMEs to MNEs using standard audit software. The implementation of SAF-T enables companies to provide ERP data for use by internal and external auditors in their compliance programs. As ERP data can be provided

91

2

Indirect and Direct Tax Requirements

electronically, the request for paper files will become more and more obsolete. Eventually, tax auditors will have the option to perform audit procedures remotely, which may also reduce the cost of tax audits both for tax authorities and businesses. SAF-T basically enables the audit of accounting transactions on the line level. This means that errors in accounting can be identified and quantified in an early phase of a tax audit so that tax authorities can staff resources more efficiently. In addition, potential audit areas can be identified right at the beginning of a tax audit. SAF-T can be used by more than just tax authorities; it also provides the basis to perform ongoing audit procedures by the entities subject to a future tax audit. Thus, businesses can benefit from SAF-T to check and ensure e-audit readiness prior to a tax audit and improve their own internal control framework. SAF-T has been designed to collect data from various areas of companies’ accounting records such as the following: 쐍 General ledger

– Journals accounts 쐍 Accounts receivable

– Customer master files – Invoices – Payments 쐍 Accounts payable

– Supplier master files – Invoices – Payments 쐍 Fixed assets

– Asset master files – Depreciation and revaluation 쐍 Inventory

– Product master files – Movements To enable globally consistent and highly automated audit processes, SAF-T aims for an easy-to-read, widely and internationally used file format. The current XML definition of the SAF-T format exactly addresses this requirement and should be considered as the reference file format when thinking about respective requirements during an SAP S/4HANA transformation.

92

2.2 Direct Taxes

2.2.4 Financial Reporting Standards Additional direct tax requirements arise from external financial reporting obligations according to US-GAAP and IFRS. The objective of the financial reporting is to provide useful information to investors and other stakeholders to enable business decisions. Taxes on income become relevant because the tax position presented in financial reporting usually can’t be directly linked to the financial position without further explanation. This is due to temporary or permanent differences in accounting for financial and tax purposes. While accounting for financial purposes focuses on a true and fair view of the financial position, accounting for tax purposes mainly considers tax policy-related aspects such as acceleration of tax collection by tax authorities through early taxation of profits or providing incentives such as accelerated depreciations of certain assets. In addition, financial reporting usually refers to global consolidated group financials, whereas tax position is determined on the single entity level based on local tax provisions. For example, financial reporting standards require an entity to recognize a current tax liability (asset) for unpaid (overpaid) taxes for current and prior periods and a deferred tax liability (asset) for all temporary differences between the tax base of an asset or liability and its carrying amount in the financial position statement. Tax liabilities (assets) for the current and prior periods are measured at the amount expected to be paid to (recovered from) the taxation authorities using the tax rates that have been (substantively) enacted by the end of the reporting period. A deferred tax liability arises if an entity will pay tax if it recovers the carrying amount of another asset or liability, and a deferred tax asset arises if an entity will pay less tax if it recovers the carrying amount of another asset or liability or has unused tax losses or unused tax credits. Thus, to align financial and tax positions, further information must be provided on how the tax position has been determined. This mainly includes the calculation of current and deferred taxes, preparation of notes and disclosures, or the reporting of tax risks for group reporting purposes.

2.2.5 Tax-Relevant Reporting Requirements Although the specific requirements differ from reporting to reporting scenario, there is a significant intersection with respect to the basic tax information that is relevant for each of the described scenarios. Following are some important direct tax-relevant reporting requirements across the scenarios with a basis in ERP: 쐍 Split into intra- and extra-group revenues 쐍 Information on taxable income, including nondeductible business expenses and

tax-exempt income 쐍 Statutory-to-tax adjustments in accounting 쐍 Split into material and immaterial assets

93

2

Indirect and Direct Tax Requirements

쐍 Tax relevant movements in equity accounts (capital contributions, dividends paid,

etc.) 쐍 Tax receivables and liabilities 쐍 Tax expense 쐍 Tax cash flow/taxes paid across jurisdictions 쐍 Taxable income across jurisdictions 쐍 Taxes paid across jurisdictions 쐍 Deferred taxes 쐍 Nominal and effective tax rate 쐍 Tax rate reconciliation 쐍 Tax forecast 쐍 Tax loss carryforwards 쐍 Tax risks 쐍 Entity structure

The higher the complexity of direct tax requirements, the more important is a global, standardized approach of managing direct taxes. One of the key building blocks for a respective approach is a harmonized tax data model that can be achieved by establishing your ERP as a single source of truth for direct tax data. In this respect, SAP S/4HANA can support a wide range of direct tax activities along the end-to-end process covering data capturing and tax determination, analysis and monitoring, tax filing and reporting, and forecast and planning. Among others, these activities include the following: 쐍 Implementing a tax ledger to provide a harmonized single source of truth across

parallel accounting standards from group reporting to statutory reporting to accounting for taxes and centralizing tax data 쐍 Setting up a tax-enabled chart of accounts to reflect the data granularity required for

compliance and reporting purposes 쐍 Standardizing postings on tax accounts by adding tax attributes such as tax period,

tax type, and tax authority for tax management reporting purposes 쐍 Tax tagging by adding tax attributes to other tax-relevant business transactions

across multiple tax reporting requirements 쐍 Implementing the extended WHT function to automate WHT determination and

improve respective filing processes 쐍 Introducing tax forms to capture tax data in a standardized format 쐍 Defining tax data marts, tax reports, and interfaces to make tax data available and

build connectors to global tax authorities 쐍 Setting up integrated tax controls (preventive) to ensure tax data quality 쐍 Performing tax data analytics (detective) to check for e-audit readiness

94

2.3

Summary

The aforementioned ERP requirements provide the basis to fulfill relevant tax filing and reporting requirements. In Chapter 7, we’ll describe in detail how SAP S/4HANA can support you in this regard.

2.3 Summary In this chapter, you gained an overview of fundamental characteristics of indirect tax and direct tax systems in the most relevant regions of the world with regard to SAP S/4HANA implementations. We covered standard periodic indirect tax reporting and transaction-based reporting requirements. Further, we discussed the principles of direct tax systems and their impact on tax requirements of legal entities and individuals. We think it’s important to have at least a rough idea of the tax requirements of regions and jurisdictions in the scope of your SAP S/4HANA transformation project as this is the key indicator for complexity and efforts to be expected during the project. In the next chapter, we’ll get to work in SAP S/4HANA by configuring the basic settings for tax.

95

Chapter 3 Basic Settings in SAP S/4HANA In the previous chapters, you’ve learned about direct and indirect taxes and their implications on the organizational structure in SAP S/4HANA. Now, we’ll dive deeper into the individual tax-relevant settings in SAP S/4HANA, as well as their connections and interrelations.

This chapter will cover the basic settings and customizing opportunities in SAP S/4HANA. The finance settings in SAP S/4HANA form the basis for tax accounting. We’ll cover tax codes, tax accounts, exchange rates, and the plants abroad setting. In sales and distribution and materials management, the settings described in this chapter are the basis for indirect tax determination and enable enriching master data with taxrelevant indicators. Finally, we’ll cover the integration between the individual functionalities for tax.

3.1 Financial Accounting SAP S/4HANA consists of several key functionalities (also referred to as modules). Of these functionalities, for tax, finance is extremely relevant. Accounting documents in financial accounting are the basis for most tax reporting. Thus, all settings relevant for tax reporting are done in financial accounting: the definition of all tax-relevant transactions in form of tax codes, the configuration of tax accounts to fit the company’s needs, settings related to registrations or establishments abroad, and the configuration of exchange rates in compliance with the respective jurisdictional requirements. SAP also offers special settings in financial accounting for complex jurisdictions such as Brazil, Argentina, Hungary, South Korea, and many others. Due to the strong localization of these solutions, we wanted to mention them but won’t cover them in detail.

3.1.1 Tax Codes In a simplified way, the tax treatment of a business transaction is captured inside a tax code. A tax code generally contains a tax rate, description, tax account, and further taxrelevant information for a certain scenario. In SAP S/4HANA, there are tax codes for withholding tax (WHT), output tax (sales), and input tax (purchasing). Additionally,

97

3

Basic Settings in SAP S/4HANA

we’ll look into tax procedures for indirect tax as they form the basis for the tax code structure.

Tax Codes for Withholding Tax As you’ve learned earlier, WHT is a tax that is withheld from the payment remitted to the supplier. WHT can be divided into two categories: basic and extended. Basic Withholding Tax WHT codes are significantly different from indirect tax codes. They are created centrally on a country-by-country basis. To reach the settings for WHT, use Transaction SPRO, and follow path Financial Accounting • Financial Accounting Global Settings • Withholding Tax • Withholding Tax • Calculation • Maintain Tax Codes. You’ll arrive at the screen shown in Figure 3.1.

Figure 3.1 Withholding Tax Codes

To create a new WHT code, click the New Entries button. To view an existing WHT code, double-click the tax code, or highlight it and click on the Details icon to reach the screen shown in Figure 3.2. Following are the most relevant settings that must be made for WHT codes: 쐍 Off.WH Tax Code

This field contains the official WHT code as it exists in the respective tax return of the country. 쐍 Withholding tax base amount calculation

The calculation of the WHT base amount consists of two settings: Percentage Subject to Tax and the Net base for tax contributions indicator. The Percentage Subject to Tax determines what percent of the tax base amount is to be used for the calculation of WHT. In the example in Figure 3.2, the entire amount (i.e., 100%) of the amount is subject to WHT calculation.

98

3.1

Financial Accounting

The Net base for tax contributions indicator lets you control whether the amount including indirect tax or the amount excluding indirect tax is to be used for the calculation. 쐍 Withholding Tax Rate

This field contains the WHT rate to be withheld, reported, and paid for the WHT code. 쐍 Reduced Rate

For cases where a reduced rate is applicable, this field contains the reduced WHT rate.

Figure 3.2 Withholding Tax Code Details

To post the WHT, the debit and credit accounts for Transaction type QST must be defined. To do so, execute Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Withholding Tax • Withholding Tax • Posting • Define Accounts for Withholding Tax. You’ll arrive at the screen shown in Figure 3.3, where you enter the Credit and Debit accounts for the WHT assignment. In the example, the Debit and Credit account is the same. When clicking the Posting Key button, you can also view the posting keys assigned to the debit and credit transactions. In SAP standard, these are predefined as posting key 40 (debit entry) for debit and 50 (credit entry) for credit. Save your changes.

99

3

Basic Settings in SAP S/4HANA

Figure 3.3 Accounts for Withholding Tax

Extended Withholding Tax The extended WHT provides a much larger scope of defining WHT matters in SAP S/4HANA. The main difference of the extension is that it’s now possible to book the WHT based on a combination of WHT type and WHT tax code. Before you get started with extended WHT in SAP S/4HANA, it must be activated for your company code. To activate the extended WHT functionality, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Withholding Tax • Extended Withholding Tax • Company Code • Activate Extended Withholding Tax. You’ll arrive at the screen shown in Figure 3.4, where you can click the checkbox in the Ext.WTax column next to your company code to set it active. Generally, the decision to use the extended WHT functionality should be made at the time of setup. You can migrate from the basic WHT to extended WHT, but once you activate extended WHT for a company code, you can’t deactivate it.

Figure 3.4 Activate Extended WHT

To reach the first step—the definition of the WHT types—as shown in Figure 3.5, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Extended Withholding Tax • Basic Settings • Withholding Tax Type • Define Withholding Tax Type for Payment Posting. In the overview, double-click the tax type (WTax Type) you want to view or edit, or click New Entries to create a new tax type.

100

3.1

Financial Accounting

Figure 3.5 Define Withholding Tax Type

Withholding Tax Type for Invoice Posting Alternatively, the WHT type can also be defined for invoice posting. The difference is the timing: A WHT type for payment posting will post the WHT at time of payment, while the WHT type for invoice posting will post the WHT at time of invoice. The choice of which to use here mainly depends on the legal requirements of the jurisdiction.

Double-click the WHT type to see the details of the WHT type shown in Figure 3.6. The WHT type contains the following characteristics for the calculation of the tax base amount: 쐍 Base amount

The radio buttons under this heading determine from which value the tax base amount is taken. For example, if Net Amount is chosen, the system uses the net amount as the base amount to calculate the WHT amount. If Tax Amount is chosen, the tax amount is used as the base amount for calculating the WHT. 쐍 Rounding Rule

The rounding rule determines the way the WHT is rounded. For details on the differences between the rounding rules, refer to Chapter 4, Section 4.1.2. 쐍 Cash discount

The radio buttons under Cash discount define whether the WHT is applied before the cash discount (W/tax pre c/dis), or if cash discounts are applied before the WHT (C/disc pre W/tx). 쐍 Accumulation type

The No Accumulation radio button is used when WHT is calculated. If accumulation is active, that is, the radio button is set to any other option, the accumulated WHT base amount in the current period is added to the WHT base amount. 쐍 Control

These checkboxes enable the control of the WHT type, for example, whether the tax base amount and tax amount can be entered manually.

101

3

Basic Settings in SAP S/4HANA

Figure 3.6 Define Withholding Tax Type: Details

Using Withholding Tax in Sales and Distribution To use WHT in sales and distribution, the WHT type/WHT tax code model is automatically translated into a WHT condition type/WHT tax code model. This enables the representation of WHT per customer and material. A condition type must be assigned to the WHT type. You can reach the setting for this by using Transaction SPRO and following menu path Financial Accounting • Financial Accounting Global Settings • Extended Withholding Tax • Basic Settings • Withholding Tax Type • Assign Condition Type to Withholding

102

3.1

Financial Accounting

Tax Type. As shown in Figure 3.7, you can assign the Condition type that was defined in sales and distribution to the financial accounting WHT type (WTax Type).

Figure 3.7 Assign Condition Type to WHT Type

As mentioned before, the second half of the extended WHT functionality in SAP comprises the WHT codes. For the settings, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Extended Withholding Tax • Basic Settings • Withholding Tax Code. In the overview, double-click the tax code you want to view or edit, or click New Entries to create a new tax code. The settings shown in Figure 3.8 are very similar as in the basic WHT: You can enter the official WHT code used for reporting (Off. W/Tax Key), the base amount percentage subject to tax (Base amount), and the WHT rate (WTax Rate). The official WHT code is the code issued by the financial authorities for a certain reporting field or, in this example, for a certain form in which the code is to be reported.

Figure 3.8 Extended WHT Tax Codes

Additionally, the extended WHT functionality provides settings for exemption reasons. To access them, execute Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Extended Withholding Tax • Basic Settings • Define Reasons for Exemption. To create new exemption reasons, click on

103

3

Basic Settings in SAP S/4HANA

New Entries. The exemption reasons are entirely open in their design. A classic example of an exemption reason is a certificate of exemption, as shown in Figure 3.9.

Figure 3.9 WHT Exemption Reasons

Finally—and similarly to the basic WHT functionality—the assignment of accounts is required. You can reach the settings by using Transaction SPRO and following menu path Financial Accounting • Financial Accounting Global Settings • Extended Withholding Tax • Posting • Accounts for Withholding Tax • Define Accounts for Withholding Tax to Be Paid Over. As shown in Figure 3.10, accounts are defined on a combination of Withholding tax type and Withholding tax code. On the screen, you enter the credit and debit accounts in their corresponding columns for the WHT assignment. In this example, the debit and credit accounts are the same. When you click the Posting Key button, you can also view the posting keys assigned to the debit and credit transactions. In SAP standard, these are predefined as posting key 40 (debit entry) for debit and 50 (credit entry) for credit. Don’t forget to save your changes.

Figure 3.10 Extended WHT Accounts

Country-Specific Settings There are more country-specific settings for WHT that we haven’t mentioned. SAP offers predefined additional settings for many countries, such as India, Ireland, South Korea, Argentina, Brazil, Colombia, Mexico, Qatar, Great Britain, and the public sector in Spain.

104

3.1

Financial Accounting

Tax Procedures for Indirect Tax As the indirect tax is calculated differently in different countries, tax codes for indirect tax are assigned to a certain tax procedure. The tax procedure contains all information required to define the calculation of indirect tax. This calculation is based on condition types. To reach the settings for the tax procedures, as shown in Figure 3.11, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Check Calculation Procedure • Define Procedures.

Warning! It’s strongly recommended not to change the condition types and tax procedures that come with the SAP standard. Generally, SAP provides hotfixes for changes in regulations that can be installed into the system without the need to adapt the standard. However, should you need to change a tax procedure or condition type, you can copy one of the standard tax procedures and adapt it to your needs.

To view or edit a certain tax procedure, click on the procedure to highlight it, and then double-click the Control Data folder on the left-hand side. This will take you to the screen shown in Figure 3.12, which displays the condition types for the tax procedure. The tax procedure defines the condition types to be used for the calculation of indirect tax within the tax code. This tax procedure must be assigned to a country to be used. To reach the configuration for this, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Assign Country to Calculation Procedure. To make the assignment, enter the tax procedure in the Proc. (procedure) column in the respective line for the country. In the example in Figure 3.13, tax procedure TAXCN is assigned to country China. This means that for the creation of an indirect tax code with China, tax procedure TAXCN will automatically be used.

Tax Procedures without Plants Abroad Generally, the tax procedure is triggered by the country of the company code, meaning that without activating plants abroad, only one tax procedure can be used within a company code. We’ll go into more detail on the functionality of plants abroad in Section 3.1.3. If the plants abroad setting isn’t activated, SAP recommends creating a new tax procedure TAXEUR, which contains the tax specifications for all countries in scope. For more details, also refer to SAP Note 63103.

105

3

Basic Settings in SAP S/4HANA

Figure 3.11 Tax Procedures

Figure 3.12 Condition Types for Tax Procedure TAXCN

106

3.1

Financial Accounting

Figure 3.13 Assign Tax Procedures to Countries

Preassigned Tax Procedures Some countries have predefined tax procedures that are also preassigned to the country. Note that there are also countries where SAP offers multiple tax procedures, depending on the tax calculation approach taken by the customer: with or without jurisdiction codes.

In certain countries, the indirect tax calculation differs between regions, that is, jurisdictions. To reach the settings for the creation of tax jurisdictions, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Specify Structure for Tax Jurisdiction Code. You’ll arrive at Figure 3.14, where you can define the structure of the tax jurisdiction code per tax procedure with jurisdiction code. Those shown are delivered with the SAP best-practice installations for the respective countries. To create a new structure for tax jurisdiction codes, click on New Entries.

Figure 3.14 Tax Jurisdiction Code Structure

107

3

Basic Settings in SAP S/4HANA

The length (Lg) is defined on the first, second, third, and fourth levels in the hierarchy within the tax jurisdiction code structure. Indicator Tx In defines whether taxes are determined on a line-by-line basis or on the header level.

Example The jurisdiction codes of tax procedure TAXUSX are defined as follows: 쐍 Two digits for the state code (e.g., Alaska = AK) 쐍 Three digits for the county code (e.g., area code 907 = Anchorage County) 쐍 Four digits for the city code (e.g., ANCH = Anchorage)

The length of the columns for the state code, county code, and city code should be defined to match the length of the customer master level in the Customer: Tax Data tab.

Multiple Tax Procedures Notice how there are two tax procedures for both Brazil and the United States. One of the tax procedures is used for indirect tax determination inside the SAP system, and the other is used for external indirect tax determination. For example, tax procedure TAXUSX is used with the external tax engine Vertex. For details on external tax determination solutions, see Chapter 7.

To define the tax jurisdiction codes themselves, use Transaction SPRO, and follow path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Define Tax Jurisdictions. You’ll arrive at the screen shown in Figure 3.15, where you can see the result of the structure you designed for the tax jurisdiction codes.

Figure 3.15 Define Tax Jurisdiction Codes

108

3.1

Financial Accounting

When installing the best practice for a country with tax jurisdictions, SAP provides several jurisdiction codes that you can use. To define new jurisdiction codes, click the New Entries button, and enter the jurisdiction code in the format you defined in the step before as well as a description. If you deviate from the defined format, SAP will issue an error message asking you to correct the format. There are two indicators you can apply as required for the jurisdictions: DiN and TxN. Indicator DiN determines that the discount base amount is the net value; that is, the sales tax isn’t part of the discount calculation. Indicator TxN is the opposite and defines that the base amount for sales tax calculation is indeed reduced by the discount.

Tax Codes for Indirect Tax As we explained at the beginning of this section, the tax code is a crucial setting for tax, even more so for indirect tax in SAP S/4HANA. We’ll discuss tax code design, maintenance, and reporting dates for indirect tax in the following sections. Tax Code Design To determine the appropriate number of tax codes, consider the following: 쐍 Indirect tax rate

In SAP S/4HANA, a tax code can only have exactly one indirect tax rate. Therefore, there must be one tax code per indirect tax rate. SAP has recently started rolling out time-dependent taxes functionality for on-premise SAP S/4HANA. In SAP S/4HANA Cloud, this functionality is already available. Historically, it wasn’t possible to change the indirect tax rate of a tax code in an audit-proof way. Therefore, when changing the tax rate, the tax rate of past transactions was also changed, even if the tax rate on those transactions had been correct. This led to the need to create new tax codes every time a tax rate was changed in a jurisdiction. As you may be aware, there are jurisdictions where such tax rate changes are very frequent, leading to a high number of tax codes that may become obsolete rather quickly. Time-dependent taxes make it possible to change the tax rate of the tax code in an audit-proof and history-proof manner. 쐍 Reporting in the periodic indirect tax return

The SAP best practice approach is to create at least one tax code for each business transaction that must be reported in different fields of the indirect tax return. For example, there should be one tax code for tax exempt domestic supplies of certain goods and one for tax exempt cross-border supplies, if these two transactions are to be reported separately. 쐍 Reporting in the annual return

In addition to the periodic indirect tax return, it may be useful to also differentiate between cases where a transaction must be reported differently in the annual return. For example, in Ireland, domestic purchases are to be reported in field T2 of the VAT3 value-added tax (VAT) return. However, in the return of trading details (RTD) in the

109

3

Basic Settings in SAP S/4HANA

annual return, there is a differentiation of purchases for resale (to be reported in field R1 of the RTD) and not for resale (to be reported in field R2 of the RTD). 쐍 Real-time reporting

With real-time reporting becoming more popular in jurisdictions worldwide, often the transaction must be reported at the time of issuing an invoice. Such reporting generally contains a large amount of information, including a mapping of the tax code of the transaction to a nature code of the real-time reporting obligation. There should be enough tax codes to enable the reporting of all relevant nature codes in the real-time reporting requirements.

Nature Code Nature code is code that’s defined by the tax authorities to show the nature of a transaction. Nature code is usually alphanumerical and describes, for example, standard sales, reduced-rate sales, or the reason for tax exemption.

For example, in Spain, all taxable transactions must be reported in the Immediate Supply of Information or Suministro Inmediato de Información (SII)) with a code explaining the cause of exemption. As this reporting must be automated because it’s in real time, this mapping must be available. 쐍 Exemption reasons on the invoice

In many jurisdictions, an explanation—the exemption reason—must be printed on the invoice if no indirect tax is applied. Often, it’s useful to trigger the printing of the invoice text via the tax code. For example, if all requirements are fulfilled, an export from Germany is tax exempt. Such must be indicated on the invoice, for example, with the following text: “Export supply is tax exempt according to Art. 146 (1) a, b Directive 2006/112/EC”. Maintain Tax Codes To maintain tax codes for indirect tax, use Transaction SPRO, and follow path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Calculation • Define Tax Codes for Sales and Purchases. Alternatively, you can use Transaction FTXP. In the popup, enter the country for which you want to create the tax code. On the following screen, enter the two-digit alphanumeric code defined as a tax code (e.g., Tax Code C1 in Figure 3.16). If the tax code was already created, SAP will lead you straight to the view shown in Figure 3.16. Here, you can see the settings of the tax code. These settings are triggered by the settings made earlier in the tax procedure—you’ll recognize the condition types for tax procedure TAXCN. The tax type was entered in the Properties settings, which we’ll discuss next. To maintain the tax code, enter the appropriate rate in the relevant line under Tax Percent. Rate. In the example, we’re creating a tax code for output VAT in China, so the tax rate is entered in the Output Tax line.

110

3.1

Financial Accounting

Figure 3.16 Tax Code Settings: General

Reverse Charge You can also create tax codes for reverse charge. Reverse charge generally means that the recipient of a certain good or service is liable for indirect tax, in contrast to transactions where usually the supplier is the party responsible to pay and collect the indirect tax on the transaction. Usually, the indirect tax that is due on the transaction can instantly be deducted by the liable party. To create a reverse charge tax code, simply enter the output tax amount in a line for output tax and the corresponding deductible tax in a line for input tax. While doing this, it’s important to keep the From Lvl column in mind because it determines from which Level the amount is deducted for the input tax. In the example in Figure 3.16, if we entered the deductible input tax in the Input tax line, the amount would be deducted from Level 100—the tax base amount. Therefore, we would enter “-13,000” in the line. If we created a tax code for service tax, we would enter the output tax in the Service Tax Cred. CN line and the deductible input tax in the Service Tax Deb. CN line. Note how the debited amount is calculated from level 300 instead of level 100. Therefore, we would enter “-100,000” in the line to deduct 100% of the output tax from level 300.

If the tax code is new, SAP will prompt you with the popup shown in Figure 3.17. In the Properties overview, enter the description of the Tax Code. This description should be concise and should explain the nature of the underlying transaction for which this tax code will be used. It should, for example, contain the country and type of transaction, for example, “China - 13% Output VAT”. An alternative could be “CN Output VAT standard rate”. For tax-exempt or nontaxable tax codes, it sometimes makes sense to include a more detailed description or even a reference to the underlying legal code.

111

3

Basic Settings in SAP S/4HANA

For example, a tax code for local reverse charges due to the supply of construction supplies in Germany could be called “DE – Local RC - §13b(2)Nr.4”.

Figure 3.17 Tax Code Settings: Properties

In the Properties settings, there are more options: 쐍 Tax Type

Differentiates output tax (A) from input tax (V). This is also relevant for the assignment of tax accounts to a tax code; for example, it should not be possible to assign an output tax code to an input tax account. 쐍 CheckID

Determines that an error message is populated if the tax amount isn’t correct at the time of booking. If the indicator isn’t set, a warning message appears in place of the error message. 쐍 EU Code/Code

Determines that a tax code must be taken into consideration for the European Commission (EC) Sales List/EC Purchase List. The EC Sales and Purchase Lists are reporting requirements that show the flow of invoices and payments between European Union (EU) member states. There are several indicators: – Blank: Not EU relevant. – 1, 3, 4, M, H: Output tax codes with a tax rate of 0% with relevance for the EC Sales List. – 5, 6, 7, 8: Input tax codes for EU acquisitions or reverse charge with relevance for the ESL (6 is only relevant for Hungary). – 9: Input tax codes for acquisition tax. This code is relevant when you define a tax code for which you know that the total of the individual conditions (percentage rates) must result in exactly 0. For example, this code would be used for tax codes for an EU acquisition. – A: Input tax codes for reverse charge that aren’t relevant for the EC Sales List. – B: Tax codes that aren’t EU tax codes and don’t need to produce a balance of zero.

112

3.1

Financial Accounting

Special EU Codes There are additional EU codes for Spain and Poland for very special types of transactions. If these are relevant to you and/or to better understand the EU Code setting and its significance, we recommend SAP Notes 2402710, 732750, and 1619948. 쐍 Target Tax Code

Can be defined, for example, for deferred tax. It creates a relationship between two tax codes; that is, bookings with one tax code can at some point in time be converted into the other tax code. Note that if a tax code has a reference to a target tax code, an interim deferred tax account should be used. The tax can be deferred from the original tax code to the target tax code—and with it, from the interim tax account to the final tax account—with report RFUMSV50 or by using Transaction S_AC0_ 52000644. You’ll find more details on deferred taxes and how to run report RFUMSV50 in SAP Note 1800344. 쐍 Tol.per.rate

Defines the percentage rate that is accepted as tolerance between a calculated tax value and an entered tax value. 쐍 Reporting Cntry

Only available if Plants Abroad is active (see Section 3.1.3). It specifies in which jurisdiction tax base amounts and indirect tax amounts must be reported. 쐍 Inactive

Marks a tax code as inactive. This is important, as tax codes should never be deleted from an audit perspective. Marking the tax code as Inactive will make booking a transaction with the tax code impossible. 쐍 MOSS TaxRepCtry

The SAP best practice approach is to create at least one tax code for each business transaction that must be reported in different fields of the indirect tax return.

Taxes with MOSS Mini One Stop Shop (MOSS) is a special scheme in the EU where taxes can be paid in the country of residence even if the transaction happened abroad. This is especially useful for small companies providing electronic services or e-commerce.

Furthermore, it’s necessary to enter the tax account for the tax code. To maintain the tax accounts, click on the Tax accounts button at the top of the tax code maintenance screen (not shown in Figure 3.16). You’ll be prompted for a chart of accounts as shown in Figure 3.18. Enter your chart of accounts (Chart of Accts) here, and press (Enter).

113

3

Basic Settings in SAP S/4HANA

Figure 3.18 Enter Chart of Accounts for Tax Code

Then, you’ll be able to enter the respective tax account, as shown in Figure 3.19. An account must be assigned for every active line. In the example, we only need to enter an account for output tax. If we were creating, say, a reverse charge tax code where we’re booking input and output tax simultaneously, we would need to add one input tax account and one output tax account.

Figure 3.19 Maintain Tax Accounts for Tax Code

Tax Reporting Date The tax reporting date (technical field VATDATE) is the date on which the indirect tax is due or must be reported to the tax authorities. In the SAP standard, it’s generally identical to the posting date or document date. However, it can also be adapted to match your needs. (For more information, refer to SAP Note 1232484.) To change the tax reporting date, you must first activate it in the global settings of the company code. To reach this overview, use Transaction OBY6, Transaction SM30 with view V_001_B, or Transaction SPRO, and follow path Financial Accounting • Financial

114

3.1

Financial Accounting

Accounting Global Settings • Global Parameters for Company Code • Enter Global Parameters. Double-click the company code you want to activate the tax reporting date for. On the bottom of the Processing parameters box, as shown in Figure 3.20, you’ll find the Tax Reporting Date Active checkbox to select.

Figure 3.20 Processing Parameters

Warning! After activating this checkbox, every tax-relevant accounting document that contains a tax code must have a valid date in field VATDATE. If it’s not tax relevant, this date will be empty.

The actual determination of the tax reporting date is realized in SAP S/4HANA via a predelivered business add-in (BAdI). To check the status of the BAdI, go to path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Define and Check Tax Reporting Date in the configuration menu. In Figure 3.21, you can see that the enhancement implementation of VATDATE_VALUES_DEFAULT_ SAP is available.

Figure 3.21 BAdI Implementation for Tax Reporting Date

115

3

Basic Settings in SAP S/4HANA

To check the enhancement implementation itself, use Transaction SE19, and enter the name of the BAdI into the Enhancement Implementation field. There are two preimplemented methods: VATDATE_DETERMINE and VATDATE_CHECK. They can be used to determine and check the tax reporting date, respectively. Enabling the tax reporting date also enables you to use a different date for the determination of the exchange rate. To change the exchange rate determination for the company code for which you activated the tax reporting date, use Transaction OBC8 or Transaction SM30 with view V_001_V. When choosing Tax Crcy Translation 5: Exchange Rate Determination According to Tax Reporting Date, as shown in Figure 3.22, the exchange rate for the company code will be determined based on the tax reporting date.

Figure 3.22 Exchange Rate Determination

3.1.2 Tax Accounts To avoid incorrect bookings into expense or revenue accounts, tax-relevant settings can be made in the general ledger accounts. To maintain settings in general ledger accounts, use Transaction FS00 or menu path Financial Accounting • Financial Accounting Global Settings • General Ledger Accounting • Master Data • G/L Accounts • G/L Account Creation and Processing • Edit G/L Account (Individual Processing) • Edit G/L Account Centrally. Tax-relevant settings are found in the Control Data tab, as shown in Figure 3.23. The most relevant field is the Tax Category. This indicator determines multiple things. First, it determines whether the account is tax relevant. An account is tax relevant if it has a tax category assigned. This then means that booking with a tax code is allowed or even mandatory. Second, you can limit the type of tax code that can be used; for example, an input tax code should not be used for a booking to an output tax account.

116

3.1

Financial Accounting

Figure 3.23 Tax Settings in a General Ledger Account

Figure 3.24 shows an extract of the available tax categories for the general ledger account that you can see by using the (F4) search help. Generally, groups of tax codes and all tax codes of the tax procedure assigned to the company code are available. Choosing a tax code as the tax category means that only bookings with that tax code can be made to the account.

Figure 3.24 Tax Categories in a General Ledger Account

Usually, groups of tax codes are used as the tax category rather than a distinct tax code. Groups + (Only output tax allowed) and – (Only input tax allowed) define that only output tax and input tax are allowed, respectively. These groups identify this by the tax type—A for output tax and V for input tax as defined in the tax code.

117

3

Basic Settings in SAP S/4HANA

For explicit tax accounts (i.e., accounts to which the indirect tax is booked), tax categories < (Input Tax Account) and > (Output Tax Account) should be chosen. If a tax category is assigned to a general ledger account, a tax code must be used. If you want to define an account that allows bookings with and without a tax code, you can set the indicator Posting without tax allowed (refer to Figure 3.23). There may be situations where you want to assign multiple tax codes to a certain account. This is possible by following menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Posting • Assign Country and Tax Code to G/L Accounts and choosing your chart of accounts (refer to SAP Note 2469831). Then, navigate to the G/L A/c Tax Code folder, and enter the G/L Account, Country, and Tax Code you want to assign to the account. If this table, as shown in Figure 3.25, is maintained, the system checks whether the tax code is admissible for every creation of an accounting document.

Figure 3.25 Assign Country and Tax Code to General Ledger Account

VAT Accounts Generally, there is no limit on the number of tax accounts that can be created. However, in our experience, we usually recommend creating the following VAT general ledger accounts: 쐍 Output VAT An account for output VAT. 쐍 Input VAT An account for deductible input VAT. 쐍 Import VAT An account to post import VAT. This usually follows a different process than the booking of input and output VAT. Generally, the tax-relevant document for the import is the customs notice, which is either connected to another SAP module, such as SAP Global Trade Services (SAP GTS), or is posted manually. 쐍 Nondeductible VAT An account for nondeductible input VAT that can be used for all input transactions with indirect tax that can’t be deducted. Here, there are two options:

118

3.1

Financial Accounting

– Account key NVV: Distribute to relevant expense/revenue items. Nondeductible VAT is automatically added to expenses/revenue (no separate account necessary). – Account key NAV: Separate line item. Booking onto a separate account (separate account necessary). 쐍 VAT payable

Define if the VAT payable should be posted automatically.

3.1.3 Plants Abroad The plants abroad feature can enable an organization to use plants as representations of indirect tax registrations in other countries. To begin our discussion, we first need to understand the relevance of plants in SAP S/4HANA. A schematic overview is shown in Figure 3.26.

Central organization of financial reporting Company Code FR Central organizational units Sales Organization FR

Purchasing Organization FR

Local organizational units

Storage Location

Plant CH

Plant NL

Plant FR

Storage Location

Storage Location

Figure 3.26 SAP Organizational Setup for Plants Abroad

Company codes mostly represent legal entities in SAP. Sales and purchasing organizations are organizational units that are responsible for the sales or purchase of goods and services. They hold the pricing and contract information for sales and purchases, such as tax codes. Plants are units that hold inventory or business equivalent. Plants define the primary source for evaluation of the departure country and determine generally the start/departure country for the transport. Plants can either be assigned to the company code directly or via a sales organization. A storage location is a separate physical location to store inventory in a plant.

119

3

Basic Settings in SAP S/4HANA

When moving your own goods cross-border, certain reporting requirements apply. Inside the EU, these types of transactions lead to a combination of an EU supply of goods and EU acquisition of goods, which must be reported. Outside the EU, there is an export in the departure country, followed by an import in the destination country. The plants abroad feature is especially useful for situations where there is one legal entity with indirect tax registrations in several countries and establishments (e.g., warehouses) in several countries. For the implementation and impacts, refer to SAP Note 10560. Be aware that plants abroad isn’t a necessary prerequisite for automatic postings to the the EC Sales List and Intrastat within the EU, and extraction of the SAP standard report for tax on sales and purchases, RFUMSV00 (see Chapter 9, Section 9.2.1), can also be done on the tax code level to resemble an extraction on the reporting country level. Table 3.1 shows a summary of the benefits and downsides of activating plants abroad. It can give some guidance on the decision, but should always be evaluated on a case-bycase basis. Benefits of Activating Plants Abroad

Downsides of Activating Plants Abroad

쐍 Tax codes are assigned to a certain reporting country. 쐍 Indirect tax-relevant bookings are assigned to a reporting country via the tax code.

쐍 Other settings are necessary after activation (e.g., maintenance of VAT IDs of registrations abroad, maintenance of reporting country in the tax code).

쐍 Settings for discounts (small discounts on the invoice amount usually granted if the invoices are paid in a certain time frame) or currencies are possible on the reporting country level, not only on the company code level.

쐍 In standard, the setting is only foreseen to be used for inside the EU. This can be quickly adapted by setting the indicator for billing relevance on such deliveries to Relevant for Billing.

쐍 You can choose the reporting country while using the programs to create the VAT return or the EC Sales List.

쐍 The setting can’t be used if branches/registrations abroad are separate legal entities.

쐍 Functionality is provided for booking crossborder stock transfers, including pro forma invoices, supply, and acquisition in the respective countries.

쐍 SAP recommends creating your own company codes for permanent establishments (refer to SAP Note 1707438) in countries where a selfstanding financial statement or Standard Audit File for Tax (SAF-T) file at level of the permanent establishment must be submitted.

쐍 The setting is activated/deactivated per company code in financial accounting configuration.

쐍 Similar configuration is also possible with profit centers or business areas in SAP S/4HANA.

쐍 Alternative solutions are very complex and require significant customizing (e.g., using separate company codes instead of plants abroad).

쐍 The setting is only designed for countries without jurisdiction codes (refer to SAP Note 1929128).

쐍 Reporting in different currencies is supported.

Table 3.1 Pros and Cons of Activating Plants Abroad

120

3.1

Financial Accounting

Example Company S with headquarters in Romania is registered for VAT in Romania, Slovenia, and Slovakia, and it has a warehouse in each country as well. The company is now considering activating plants abroad. As company S moves its own stock between the warehouses and sells locally in each country it’s registered in, there are several benefits of activating plants abroad: association between tax codes and the reporting country, automatic conversion into the local currency (especially relevant as Romania doesn’t use the euro as their currency), automatic tracking for the EC Sales List and Intrastat, and automatic use of its own correct VAT ID on transactions.

We’ll walk through the activation, setup, and relevant scenarios for plants abroad in the following sections.

Activation and Setup To activate plants abroad, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Plants Abroad • Activate Plants Abroad. On the screen, check the Plants Abroad Active box, and save to activate the functionality (see Figure 3.27).

Figure 3.27 Activate Plants Abroad

After activating plants abroad, the SAP standard table for country data will receive four additional fields: the country currency, the exchange rate type, and two fields to determine the tax base amount in relation to discounts. These two fields can be used to determine whether cash discounts are deducted from the tax base amount and whether the tax amount should be considered for calculating discounts.

Warning! The settings made on a country basis when the plants abroad feature is activated will overrule the settings made for the company code.

Settings for these indicators per country, as shown in Figure 3.28, can be made with Transaction OBY6 or through menu path Financial Accounting • Financial Accounting

121

3

Basic Settings in SAP S/4HANA

Global Settings • Global Parameters for Company Code • Enter Global Parameters. Double-click on the respective company code you want to make these settings for. Two settings are important here: Tax base is net value (technical field XMWSN) and Discount base is net value (technical field XSKFN). When activating Tax base is net value, the tax base amount is reduced by the discount. When activating Discount base is net value, the base amount for discounts doesn’t contain indirect tax.

Figure 3.28 Country Settings for Company Code

The activation of the indicators depends on the respective requirements in the jurisdiction. Overall, the following scenarios can apply: 쐍 No indicator activated: gross tax base and gross discount base.

The tax base isn’t reduced by the discount, and the discount contains indirect tax. 쐍 Only discount base is net value indicator activated: gross tax base and net dis-

count base. The tax base isn’t reduced by the discount, and the discount doesn’t contain indirect tax. 쐍 Both indicators activated: net tax base and net discount base.

The tax base is reduced by the discount, and the discount doesn’t contain indirect tax.

122

3.1

Financial Accounting

쐍 Only tax base is net value indicator activated: net tax base and gross discount

base. This setting is only permitted for jurisdiction codes, as it means that the tax base is reduced by the discount and the base amount for the discount contains indirect tax. To make further settings related to the company code and for plants abroad, use Transaction SPRO and go through menu path Financial Accounting • Financial Accounting Global Settings • Global Parameters for Company Code • Maintain Additional Parameters. As you’ve learned, plants abroad is a global setting that will affect all company codes. Setting a flag for Plants Abroad Not Required on the company code level, as shown in Figure 3.29, enables you to deactivate this global setting for individual company codes.

Figure 3.29 Maintain Additional Parameters for Company Code

Value-Added Tax Registration After activating plants abroad, you can enter the VAT registration number for the respective VAT registrations abroad. To do so, use Transaction SPRO, and follow menu path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Plants Abroad • Enter VAT Registration Number for Plants Abroad. When on this screen, double-click on the combination of company code and country, or click New Entries to create a new VAT registration. In the screen shown in Figure 3.30, enter the VAT registration number (VAT Reg. No.) and a description for the Company Name.

Figure 3.30 Enter Foreign VAT Registration Numbers

123

3

Basic Settings in SAP S/4HANA

Domestic VAT Registration Number Note that the domestic VAT registration number of the headquarters isn’t maintained here. Instead, it’s maintained in the company code global settings.

If there are indirect tax registrations abroad, companies commonly transfer their own goods between these countries. This requires several settings and a specific process from an indirect tax determination perspective. First, condition records must be created for conditions WIA1, WIA2, and WIA3. A WIA invoice (i.e., an invoice for the posting of internal stock transfers that is relevant for indirect tax reporting) will contain these three condition types: 쐍 WIA1

This condition type contains the input tax in the country of destination. Therefore, condition type WIA1 may, for instance, determine a tax code with 21% indirect tax for an intra-community acquisition of goods in the Netherlands. 쐍 WIA2

This condition type contains the output tax in the country of departure. For example, the WIA2 condition type may determine a tax code with 0% indirect tax for an intra-community supply of goods. 쐍 WIA3

This condition type then contains the output tax in the country of destination. Therefore, the amount determined in condition type WIA1 is booked into another line with a negative amount, and the intra-community acquisition is reported and deducted at the same time.

Cross-Border Movements If you’re using different tax procedures for the different countries of your registration, it’s necessary to create the respective input tax codes for cross-border movements of the company’s own goods in the tax procedure of the outgoing country. For example, in a stock transfer of own goods from Italy to France, the tax procedure for Italy must contain the tax codes for an Italian intra-community supply of goods as well as an intra-community acquisition of goods in France. For reporting purposes, the reporting country is entered in the properties of the tax code.

Non-EU Stock Transfers As mentioned, the plants abroad functionality is generally designed for stock transfers of own goods inside the EU. However, you also can use it for stock transfers of own goods to, from, and between non-EU countries. To do so, use Transaction VOV7 or

124

3.1

Financial Accounting

follow menu path Sales and Distribution • Sales • Sales Documents • Sales Document Item Define Item Categories in the configuration menu. The SAP standard item category (ItCa column) for stock transfer items is NLN, as shown in Figure 3.31.

Figure 3.31 Maintain Item Categories

Double-click on the relevant item category for stock transfers. To automate indirect tax postings for cross-border movements of own goods to non-EU countries, you need to set the billing relevance of the item category to relevant for billing. In SAP standard, this is set to J (Relevant for deliveries across EU countries). When setting it to A (Deliveryrelated billing document), as in the example in Figure 3.32, it becomes billing relevant for all countries.

Figure 3.32 Maintain Billing Relevance for Item Category

Warning! Keep in mind that the billing and reporting processes need to be adapted per the local requirements of the jurisdiction. It may be necessary to adapt the pricing procedure relevant for the creation of the WIA invoice for certain countries to ensure that there is no reverse charge posting for non-EU countries, but an input tax posting on the indirect tax input side is triggered. Keep in mind that this setting will affect all company codes in the system.

Furthermore, an additional Reporting Cntry field will become available for each tax code, as shown in Figure 3.33.

125

3

Basic Settings in SAP S/4HANA

Figure 3.33 Tax Code Settings for the Tax Reporting Country

The reporting country of the tax code is essential if you want to use the Tax Reporting Country functionality in the SAP standard report for the advance return for tax on sales and purchases (report RFUMSV00), as shown in Figure 3.34. Additionally, the Nat.Crcy Instead of Local Crcy checkbox becomes available after activating plants abroad. This enables you to extract the report in the local currency in which it must be reported, even if the original transaction was in a different currency. Referring back to the example, this means that we could extract the indirect tax return for Romania in Romanian leu, even if the invoice was posted in euro.

Figure 3.34 Report RFUMSV00 with Plants Abroad

3.1.4 Exchange Rates Most jurisdictions require companies to report indirect taxes in the currency of the country. When receiving or sending invoices in different currencies, a translation of the amount must be made—usually to a certain date with the rate of a certain institution, such as the federal reserve bank.

126

3.1

Financial Accounting

In the following settings, we’ll explain how to set up and maintain exchange rates. You’ll also see how they work in sales.

Basic Settings Generally, the system uses the currency maintained as company code currency in path Enterprise Structure • Definition • Financial Accounting • Edit, Copy, Delete, Check Company Code. From the popup submenu that appears, you choose Edit Company Code Data. The overview is shown in Figure 3.35.

Figure 3.35 Company Code Settings

As we’ve mentioned in Section 3.1.3, reporting in other currencies than the company code currency is only possible when plants abroad is activated. You can also assign multiple currencies to one company code via two methods. The first method is to assign a currency on the company code level. As you can see in Figure 3.36, this is limited to a maximum of two additional currencies. The first currency is always the company code currency, while the second currency is usually the group currency. For example, if a legal entity in the United Kingdom belongs to a group from the United States, the group currency may be USD. The third local currency can be chosen freely. However, the setting is limited by currency types. We’ve already explained the company code currency and group currency. Other standard currency types are the hard currency (assigned at country level), index-based currency (for high inflation), or global company currency (assigned to a company or internal trading partner). To reach the configuration, use Transaction OB22 or Transaction FINSC_LEDGER or follow menu path Financial Accounting • Financial Accounting Global Settings • Ledgers • Ledger • Define Settings for Ledgers and Currency Types. In the overview, choose the ledger you want to customize, and then navigate to the company code settings for the ledger. Double-click the company code you want to customize. In this overview, as shown in Figure 3.36, you can see three currencies that can be freely defined by using the indicator in the Crcy type field. In the example, there are only two defined—a company code currency (indicator 10) for company code 1010 and a group currency (indicator 30). For each of the company codes, an exchange rate type can be assigned in the

127

3

Basic Settings in SAP S/4HANA

ExRateType field. The SAP standard is exchange rate type M. However, as you’ll learn a little later in this chapter, you also can define new exchange rates for special legal requirements that can be assigned here. Further important fields are the Currency itself, the source currency type (Srce Crcy), and the translation date type (TrsDte Typ). The currency maintained in the example is EUR. The source currency type defines which currency is used as the basis for translation. Generally, the transaction currency is used as a basis for the calculation here, as using another currency (e.g., the group currency) can lead to exchange rate differences. Finally, the translation date type defines which date is used for the translation. Here, you have the option between document date, posting date and translation date. Translation date is the default value, but it may be necessary to use another date depending on the legal requirements.

Figure 3.36 Additional Local Currencies for the Company Code

In the second option, the additional local currency is maintained only for the advance return on sales/purchases. To reach the configuration, as shown in Figure 3.37, use menu path Financial Accounting • General Ledger Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Activate Alternative Local Currency for Advance Tax Return. Select the Alternative Local Crcy Active? checkbox.

128

3.1

Financial Accounting

Figure 3.37 Activate Alternative Local Currency for Advance Tax Return

After the activation, you can assign a currency and exchange rate type to the combination of company code and selection program via Financial Accounting • General Ledger Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Specify Alternative Local Curr. for Advance Tax Return. Click on New Entries to create a new line with your company code. Program Name RFUMSV00 is the standard report for the advance return for tax on sales/purchases. In the example in Figure 3.38, company code 1010 is using Polish zloty (PLN) as the additional currency, for example, due to an indirect tax registration and corresponding reporting requirements in Poland.

Figure 3.38 Specify Alternative Local Currency

Both options are only possible if there is only one additional currency. If more currencies are relevant, it may be a good starting point to think about activating plants abroad.

Maintain Exchange Rates To translate currency amounts from the foreign currency to another currency, such as the official in-house or group currency, the exchange rate must be maintained in the system. Maintenance of the exchange rates as in the example in Figure 3.39 can be reached either through Transaction OB08 or menu path SAP NetWeaver • General Settings • Currencies • Enter Exchange Rates in the SAP Reference IMG. In this list, you can see the maintained exchange rates by exchange rate type and date. In the example, we see a daily exchange rate maintained for the exchange rates from HKD to EUR. The exchange rate type (ExRt) is B (standard translation at selling rate) and for each day— shown by the ValidFrom date—an exchange rate is entered. For the indirect quotation that is used here, we’re converting the company code currency EUR to the other currency by defining the cost of one unit of local currency in units of foreign currency. In the example, that means 0.84970 HKD equals 1 EUR. With direct quotation, the other currency HKD would be converted to EUR by defining the cost of one unit in foreign currency in local currency. Generally, these work hand in hand, and only one needs to be defined.

129

3

Basic Settings in SAP S/4HANA

Figure 3.39 Currency Exchange Rates

You can maintain different exchange rates with different exchange rate types for the same period. In practice, exchange rates are often automatically uploaded. Program RFIMPNBS offers the possibility to import exchange rates from an XML file provided by the European Central Bank (refer to SAP Note 1286897). Program RFTBFF00 makes it possible to read exchange rates from market data. In many jurisdictions, the prescribed exchange rate is different from the exchange rate used for accounting. SAP Note 730466 offers guidance on the usage of a different exchange rate type for the advance return for tax on sales/purchases. Generally, there are four steps involved: 1. Activate plants abroad For details on this step, refer to Section 3.1.3. 2. Define exchange rates To reach the configuration for defining exchange rates, use Transaction OB07 or follow menu path SAP NetWeaver • General Settings • Currencies • Check Exchange Rate Types. Click on New Entries to create a new exchange rate type by entering the abbreviation in the ExRt column and the description in the Usage column. In the example in Figure 3.40, we’ve created a new exchange rate for the HMRC daily rate that will be used for exchange rate calculations in Great Britain.

Figure 3.40 Create New Exchange Rate

3. Assign the new exchange rate to the country In the SAP NetWeaver configuration, choose General Settings • Set Countries • Define Countries in mySAP Systems. Double-click the respective relevant country. In the Exch. Rate Type field, as shown in Figure 3.41, enter the newly created exchange rate.

130

3.1

Financial Accounting

Figure 3.41 Assign New Exchange Rate to Country

4. Set tax conversion rules In the configuration, use Transaction SPRO, and go to menu path Financial Accounting • Financial Accounting Global Settings • Global Parameters for Company Code • Enter Global Parameters. In the overview, choose the company code where the new exchange rate type is relevant. In the Processing parameters box, as shown in Figure 3.42, enter 1 (Manual exchange rate entry possible) in the Tax Crcy Translation field. If you have a company code where the exchange rate is generally determined based on a date other than the pricing date, this is the point to make that change.

Figure 3.42 Set Tax Currency Translation Rules for the Company Code

Exchange Rates in Sales First, it’s important to mention that the relevant date for the exchange rate is the pricing date. The pricing date itself depends on the sales document type. The settings for the sales document types can be found under path Sales and Distribution • Sales • Sales Documents • Sales Document Header • Define Sales Document Types in the SAP Reference IMG. In the Requested delivery date/pricing date/purchase order date area, as shown in Figure 3.43, you can find the proposed pricing date based on the requested delivery date (Prop.f.pricing date). If this field is empty, the system suggests the system date—that is, today’s date—as the pricing date. Alternatives are A (requested delivery date), B (valid-from date), and C (contract start).

131

3

Basic Settings in SAP S/4HANA

Figure 3.43 Pricing Date Settings

Additional settings can be made in the condition type for sales (refer to Chapter 4, Section 4.1.2) or in the copying control (refer to Chapter 4, Section 4.3.2). To reach these settings, use Transaction V/06 or Transaction SPRO followed by menu path Sales and Distribution • Basic Functions • Pricing • Define Condition Types • Set Condition Types for Pricing. Among other settings, the condition type offers the setting Pricing Date in the Control Data 2 section, as shown in Figure 3.44. The default setting is blank, that is, the pricing date from the pricing date field PRSDT in structure KOMK or from date of services rendered for tax and rebates. Other options include the date of services rendered, billing date, price date, creation date, or order date. As these settings are made on the condition level, you can have different pricing dates for different conditions. For example, you could calculate the net price based on the creation date to include certain time-dependent rebates and the tax pricing date based on the invoice pricing date.

Figure 3.44 Condition Type Pricing Date

The copying control responsible for the transmission of data between different sales documents can be reached via Transaction SPRO followed by menu path Sales and Distribution • Billing • Billing Documents • Maintain Copying Control for Billing Documents. In the copying control, as shown in Figure 3.45, you can maintain the pricing exchange rate type at the item level at the time of data transmission between a preceding document such as a sales order or delivery note and the billing document. This setting has priority over the setting of the condition type, if filled. The standard setting is blank, with other options to copy the exchange rate determination from the sales order or match it to the accounting rate, billing date, pricing date, current date, or date of services rendered.

132

3.2 Sales and Distribution and Materials Management

Figure 3.45 Exchange Rate for Copying Control

Warning! This setting only has an influence on the exchange rate calculation on the billing document. The exchange rate in financial accounting is always based on the posting date.

3.2 Sales and Distribution and Materials Management There are several settings in the sales and distribution functionality and materials management (purchasing) functionality that influence tax determination both on the input and output side. Some of these settings are related to master data, and others are related to tax determination and pricing itself. In this section, we’ll cover tax classifications and further settings related to master data, as well as the relevance of indirect tax determination as a part of pricing.

3.2.1 Tax Classifications Tax classifications are the basis for indirect tax determination. They are indicators that describe a certain characteristic of a product, customer, vendor, or even taxable transaction. We’ll discuss the different tax classifications in the following sections.

Material Maintaining correct master data for the material is a crucial step in achieving correct and reliable automatic indirect tax determination. The material tax classification in

133

3

Basic Settings in SAP S/4HANA

sales and distribution and the tax indicator for material in materials management define which tax rate is applicable and is used in pricing to calculate the relevant indirect taxes. Material Tax Classification in Sales and Distribution The material tax classification (technical field TAXM1) is a crucial indicator in sales and distribution. It’s maintained in the material master data via Transaction MM02 on the sales organization level. After executing the transaction, enter the number of the material you want to maintain, and press (Enter). You’ll be asked to enter some details about the plant, sales organization, and distribution channel; when finished, press (Enter) again. You’ll find the tax data for the output side of the material in the Sales: sales org. 1 tab, as shown in Figure 3.46.

Figure 3.46 Maintain Material Tax Classification for Material

At the bottom of Figure 3.46, you can see the Tax data table view of the material tax classifications of the material we’ve chosen as an example. For Country Germany with condition type TTX1, this material has a Tax classification of 1 (Full tax). This means that per our definition, the product is subject to the regular VAT rate in Germany. The same product can be subject to different indirect tax rates in different countries. Consider a

134

3.2 Sales and Distribution and Materials Management

scenario such as children’s clothing, which is subject to the regular VAT rate in Germany, but subject to a zero rate in Ireland. To differentiate this, you can assign a material tax classification of 1 (Full tax) to country Germany and a tax classification of, for example, 4 (Zero rate) for Ireland. This way, the same material can be used to determine different indirect tax rates in different jurisdictions.

Displayed Entries in Table View The entries shown in the Tax data table view for materials are influenced by the plants that are available for the sales organization in table TVKWZ and the company code. To check or maintain this relation, use Transaction OVX6.

The material tax classifications available can be maintained via Transaction SPRO, followed by path Sales and Distribution • Basic Functions • Taxes • Define Tax Relevancy of Master Records • Maintain Tax Relevance for Materials. As shown in Figure 3.47, the SAP standard offers four material tax classifications for MWST or TTX1: Exempt, in VATreturn; Full tax; Reduced Tax; and Low Tax. Material tax classification Exempt, in VATreturn can be used for products exempt of indirect tax, Full tax for products subject to the regular indirect tax rate, and the other two for the respective reduced tax rates applicable. You can create new material tax classifications using the New Entries button.

Figure 3.47 Maintain Material Tax Classifications

If you’re using a different tax category, that is, condition type for tax determination, you’ll need to add material tax classifications as well. Best practice is to create as many material tax classifications as there are different indirect tax rates or other characteristics of the material that may lead to a different indirect tax treatment. For example, we usually recommend creating a new material tax classification for services as these often have a different place of supply. The condition type TTX1 listed in the overview in Figure 3.47 as Tax Categ., similarly to the tax procedure that you’re already familiar with, must be assigned to a country. For details, refer to Section 3.2.3.

135

3

Basic Settings in SAP S/4HANA

Material Tax Classification in Materials Management Similar to the sales side, the tax indicator for material (technical field TAXIM) on the purchasing side is also maintained in the material master data—but this time in the Purchasing tab of Transaction MM02, as shown in Figure 3.48. You’ll also notice how there is only one field for the material tax indicator (Tax ind. f. material) rather than multiple for different countries as there was for the output side. This indicator is only related to the plant you’re currently editing the material for—so Plant 1010 in Germany in the example. Reverting back to the example of children’s clothing, this means that we would enter tax indicator material 1 (Full tax) here, and indicator 4 (Zero rate) for the Irish plant.

Figure 3.48 Maintain Tax Indicator for Material in the Material Master

Tax Indicator Material for Nonstock Items Some material master settings don’t permit entering a tax indicator for material. For instance, if the material is defined as a nonstock item, the field may not be available. If you still want to do tax determination via condition technique for these products, you can define a new item category group or create a new condition table, which also includes the material group as a definition of the product.

To use a tax indicator for a material, it must be defined first. To check the available tax indicators for a material or to define new ones via New Entries, follow menu path Materials Management • Purchasing • Taxes • Set Tax Indicator for Material. Figure 3.49 shows an example of defined material tax indicators. The indicators must be defined by destination country and have an indicator and a description. In the example, we have three indicators for Germany: 0 (Exempt), 1 (Full tax), and 2 (Reduced Tax). For

136

3.2 Sales and Distribution and Materials Management

consistency, it’s useful to maintain the same tax indicators for materials on the purchasing side as there are material tax classifications on the sales side.

Figure 3.49 Maintain Tax Indicators for a Material

Customer The customer tax classification (technical field TAXK1 during pricing, technical field KNVI-TAXKD in master data) contains information about the characteristics of a certain customer. It indicates the respective VAT treatment applicable to the customer per tax departure country and follows the same logic as the VAT ID determination of a customer (refer to Section 3.2.2). The customer tax classification is maintained on the customer master level. To reach the customer master data, use either Transaction XD02 and enter the customer you want to maintain, or use Transaction BP and choose the business partner you want to maintain. Note that the sales and distribution customer number and the number of the business partner aren’t always the same: In SAP S/4HANA, the business partner can be linked to a supplier number and a customer number at the same time. Choose the Customer business partner role and click on the Sales and Distribution button at the top of the screen to maintain the customer master data for sales and distribution. You’ll find the setting in the Billing tab. At the bottom of Figure 3.50, you can see the Output Tax table view of the customer tax classifications. This table view follows the same rules as the Tax data table for the material master data and can be maintained via Transaction OVX6. For Country Germany, this customer has a tax classification of 1 (Liable for Taxes). This means that per our definition, the customer is subject to VAT in Germany. The same customer can be subject to different indirect tax treatments in different jurisdictions. Such characteristics can be defined with the customer tax classification.

Example Consider a scenario such as construction services. In the EU, construction services are usually subject to reverse charges. This means that if a customer is proven to be a construction provider, they are liable to pay the indirect tax on a transaction rather than

137

3

Basic Settings in SAP S/4HANA

the supplier. The customer may be provided with products not only by a plant inside the EU but also by a plant outside the EU where such a reverse charge regulation isn’t applicable.

Figure 3.50 Maintain Customer Tax Classification for Customer

Similar to the material tax classifications, customer tax classifications can be maintained via Transaction SPRO and following path Sales and Distribution • Basic Functions • Taxes • Define Tax Relevancy of Master Records • Maintain Tax Relevance for Customers. You’ll arrive at the screen shown in Figure 3.51. SAP standard offers two customer tax classifications for MWST or TTX1: Tax Exempt for any customer that is exempt from tax and Liable for Taxes for standard customers. You can create new customer tax classifications via the New Entries button. If you’re using a different tax category, that is, condition type for tax determination, you’ll need to add customer tax classifications for that tax category as well. As this overview in the customer master is populated automatically with the tax categories defined for the country, you’ll be able see your custom condition type, for example, ZTX1, in this overview instead of TTX1. Best practice is to not use customer tax classifications for characteristics that can also be determined otherwise. For example, it’s not necessary to create a customer tax classification specifically for EU customers, as this is already determined by the customer master data, goods movement, and many other parameters during tax determination. However, depending on the jurisdiction, it may make sense to add other customer tax classifications, such as construction providers, which may be subject to the reverse charge mechanism.

138

3.2 Sales and Distribution and Materials Management

Figure 3.51 Maintain Customer Tax Classifications

Customer Tax Classification in Materials Management There are no customer tax classifications in materials management. To use sales and distribution customer tax classifications for indirect tax determination in materials management, you can find some pointers in Chapter 4, Section 4.2.4, and Chapter 6, Section 6.2.

Examples To better understand the impact of customer and material tax classifications in sales and distribution, let’s look at three examples. In our first example, a German company code is supplying a standard product via their German sales organization to a German customer. The product has a material tax classification of 1 (Full tax), and the customer has a tax classification of 1 (Liable for Taxes). During tax determination in pricing, these characteristics are taken automatically from the material and customer master data and considered for the determination of a tax code with the 19% regular tax rate by using a condition record, as shown in Figure 3.52. For more details on condition records and tax determination itself, refer to Chapter 4, Section 4.1.

Figure 3.52 Customer and Material Tax Classifications for a Standard Rate Product

139

3

Basic Settings in SAP S/4HANA

In our second example, the same German company is supplying a reduced rate product to the same customer. The product has a material tax classification of 2 (Reduced Tax), and the customer has a tax classification of 1 (Liable for Taxes). During tax determination in pricing, these characteristics are taken automatically from the material and customer master data and considered for the determination of a tax code with the 7% reduced tax rate by using a condition record, as shown in Figure 3.53.

Figure 3.53 Customer and Material Tax Classifications for a Reduced Rate Product

In our third example, the same German company is supplying a standard rate product to another customer, which is an embassy and generally exempt from German VAT. The product has a material tax classification of 1 (Full tax), and the customer has a tax classification of 0 (Tax Exempt). During tax determination in pricing, these characteristics are taken automatically from the material and customer master data and considered for the determination of a tax code with the 0% reduced tax rate by using a condition record, as shown in Figure 3.54.

Figure 3.54 Customer and Material Tax Classifications for Exempt Customer

140

3.2 Sales and Distribution and Materials Management

Plant The tax indicator plant (technical field TAXIW) is relevant for pricing on the purchasing side. It determines whether a plant is standard and taxable, or tax exempt. Such tax exemptions are generally relevant for free ports or customs warehouses. To define tax indicators for plants, use Transaction OMKM or follow menu path Materials Management • Purchasing • Taxes • Set Tax Indicator for Plant. You’ll arrive at the screen shown in Figure 3.55, where you can maintain the tax indicators for your plants. In the example, we have two indicators for plant country Germany: 0 (Exempt) and 1 (Taxable). If you want to enter new tax indicators or maintain new countries not available yet, use the New Entries button, and enter the country, indicator, and description to do so.

Figure 3.55 Maintain Tax Indicator for Plants

After maintaining the tax indicators for plants, you can assign the indicators to the respective plants by either using Transaction OMKN or following menu path Materials Management • Purchasing • Taxes • Assign Tax Indicators for Plant. The example in Figure 3.56 shows plant 1010 in Germany where you assign tax indicator 1 (Taxable).

Figure 3.56 Assign Tax Indicator to Plant

Import Like the tax indicator for plants, the tax indicator import (technical field TAXIL) is only relevant on the purchasing side. It describes whether a purchase refers to a local or cross-border transaction. There are three values that can be determined: 0 (No import), which refers to a domestic purchase; 1 (Import), which refers to a cross-border purchase not within the EU; and 2 (Import within the EC), which refers to an EU intra-community acquisition.

141

3

Basic Settings in SAP S/4HANA

Unlike the master data indicators, this indicator is determined automatically from function ME_FILL_KOMP_PO. If tax departure and tax destination country are equal, tax indicator import 0 is determined. If tax departure country and tax destination country aren’t equal, tax indicator import 2 is determined, if the tax departure country is within the EU. If not, tax indicator import 1 is determined. For this determination, the tax departure country is essential. The tax departure country in purchasing is generally determined by the country of the supplier, unless the role of goods supplier is maintained for said supplier. In that case, the tax departure country is determined by the country of the goods supplier.

Account Assignment The tax indicator for account assignment defines whether an item effected via a certain auxiliary account is subject to indirect tax or not. This makes it possible to calculate indirect tax in purchasing depending on the use of a certain procurement process. Such a differentiation may be useful when the indirect tax on purchases depends on the reason for a certain purchase—resale, certain assets, and so on. To define tax indicators for account assignment, use Transaction OMKL or follow menu path Materials Management • Purchasing • Taxes • Set Tax Indicator for Account Assignment. You’ll arrive at the screen shown in Figure 3.57, where you can view and maintain the tax indicators for account assignment. In the example, there are two tax indicators for account assignment for country Germany: 0 (Exempt) and 1 (Taxable). If you want to enter new tax indicators, or maintain new countries not available yet, use the New Entries button and enter the country, indicator, and description to do so.

Figure 3.57 Maintain Tax Indicator for Account Assignment

After maintaining the tax indicators for account assignment, you can assign the indicators to the respective account assignment categories by either using Transaction OMKO or following menu path Materials Management • Purchasing • Taxes • Assign Tax Indicators for Account Assignment. In Figure 3.58, you can see an example of the assignment: for account key K and destination country Germany, we assigned tax indicator 1 (Taxable).

142

3.2 Sales and Distribution and Materials Management

Figure 3.58 Assign Tax Indicator to Account Assignment Category

Examples To better understand tax indicators and classifications for the purchasing side, let’s take a look at some examples. In the first example, shown in Figure 3.59, a Swedish company purchases goods from a Finnish vendor. The goods are subject to the regular VAT rate (i.e., tax indicator material 1 (Full tax) is maintained in the material master data) and are supplied from Finland to a standard warehouse in Sweden (i.e., tax indicator plant 1 (Taxable) is maintained for the receiving plant). The system automatically determines import indicator 2 (Import within the EC) because both the departure and destination country are EU countries. Provided that all other requirements are met, this transaction qualifies as an intra-community acquisition of goods, and an acquisition tax code is determined.

Figure 3.59 Tax Indicators Purchasing: Example 1

In the second example, shown in Figure 3.60, a Swedish company purchases goods from a Swedish vendor. The goods are subject to the regular VAT rate (i.e., tax indicator material 1 (Full tax) is maintained in the material master data) and are supplied to a standard warehouse in Sweden (i.e., tax indicator plant 1 (Taxable) is maintained for the receiving plant). The system automatically determines import indicator 0 (No import) because both the departure and destination country are the same. This is a domestic purchase of goods subject to domestic VAT in Sweden, and a standard Swedish input tax code is determined.

Figure 3.60 Tax Indicators Purchasing: Example 2

In the third example, shown in Figure 3.61, a Swedish company purchases goods from a vendor in the United States. The goods are subject to the regular VAT rate (i.e., tax indicator material 1 (Full tax) is maintained in the material master data) and are supplied from the United States to a standard warehouse in Sweden (i.e., tax indicator plant 1

143

3

Basic Settings in SAP S/4HANA

(Taxable) is maintained for the receiving plant). The system automatically determines import indicator 1 (Import) because the departure and destination country are different and not both EU countries. This is an import subject to import VAT in Sweden, and a standard Swedish import tax code is determined.

Figure 3.61 Tax Indicators Purchasing: Example 3

In the fourth example, shown in Figure 3.62, a Swedish company purchases goods from a vendor in the United States. The goods are subject to the regular VAT rate (i.e., tax indicator material 1 (Full tax) is maintained in the material master data) and are supplied from the United States to a customs warehouse in Sweden (i.e., tax indicator plant 0 (Exempt) is maintained for the receiving plant). As the goods are delivered to a customs warehouse, the transaction is outside the scope of VAT in Sweden, and an outside scope of VAT tax code is determined.

Figure 3.62 Tax Indicators Purchasing: Example 4

In our fifth and final example, shown in Figure 3.63, a Swedish company purchases goods from a vendor in the United States. The goods are samples with no commercial value and therefore outside the scope of VAT (i.e., tax indicator material 0 (Exempt) is maintained in the material master data) and are supplied from the United States to a standard warehouse in Sweden (i.e., tax indicator plant 1 (Taxable) is maintained for the receiving plant). This is a transaction outside the scope of VAT, and an outside scope of VAT tax code is determined.

Figure 3.63 Tax Indicators Purchasing: Example 5

Vendor: Withholding Tax For WHT, you can assign information on WHT types, WHT codes, and exemptions to vendors. This is relevant for automatic WHT determination. The customer tax classification is maintained on the customer master level. To reach the customer master data, you can use Transaction XK02 and enter the customer you

144

3.2 Sales and Distribution and Materials Management

want to maintain, or you can use Transaction BP and choose the business partner you want to maintain. Note that the sales and distribution customer number and the number of the business partner aren’t always the same: In SAP S/4HANA, the business partner can be linked to a supplier number and a customer number at the same time. Choose business partner role Supplier (Fin.Accounting) (New) and click on the Company Code button at the top of the screen to maintain the customer master data for sales and distribution. You’ll find the setting in the Vendor: Withholding Tax tab. In the example in Figure 3.64, transactions with the vendor are subject to WHT for licenses (WHT type C1). The according WHT code (WTax Code) is W3 (WHT license 10%). The recipient type (Rec.Type) is JP (legal person) in contrast to NP (natural person). Additionally, an exemption of 5% is applicable from 2020 to 2022 due to a valid exemption certificate (Exmpt.Resn [exemption reason] AB).

Figure 3.64 Maintain Withholding Tax in Vendor Master Data

3.2.2 Tax Identification Numbers A tax identification number (or tax ID) is a unique identifier of a certain person—natural or legal—within the context of tax. Most jurisdictions have strict rules on these tax ID numbers: for business-to-business (B2B) transactions, the tax ID of the customer must generally be valid and printed on the invoice. In certain countries, such as India, a legal entity can have multiple tax IDs for different regions (if you have customers with multiple tax IDs in different regions of India, refer to SAP Note 2514392). You may also have requirements in regions such as Europe where the validity of the VAT ID number is required for tax exemptions on cross-border transactions. To begin, it makes sense to give a short overview of the business partner roles in sales and distribution. There are three relevant roles for the determination of the tax ID: 쐍 Sold-to party

The sold-to party is the customer to whom the goods are sold. 쐍 Ship-to party

The ship-to party is the customer to whom the goods are shipped—the recipient of

145

3

Basic Settings in SAP S/4HANA

the goods. This may be the same as the sold-to party or payer but can also be another party, especially in a chain transaction. 쐍 Payer

The payer is the customer paying the invoice. In practice, the payer and sold-to party are usually the same. Sometimes, the payer is more accurate as they may be the entity receiving the invoice. Inside a group structure, for example, the parent company may receive certain invoices for child companies.

Bill-to Party Another relevant role is the bill-to party: the party receiving the invoice. In practice, this is usually the payer or the sold-to party. SAP standard doesn’t allow you to determine the tax ID based on the bill-to party.

In the following sections, we’ll discuss how to maintain tax IDs. We’ll also cover key settings and considerations for VAT IDs.

Maintain Tax IDs The customer and vendor tax IDs are maintained on the business partner master data level. (For maintenance of your own tax IDs, refer to Section 3.1.3.) To maintain the tax ID of a business partner, once again use either Transaction XD02 and enter the customer you want to maintain or use Transaction BP and choose the business partner you want to maintain. Note that the sales and distribution customer number and the number of the business partner aren’t always the same: In SAP S/4HANA, the business partner can be linked to a supplier number and a customer number at the same time. As shown in Figure 3.65, choose business partner role Business Partner (Gen.) from the Display in BP role dropdown, and click on the Identification tab to maintain the tax ID numbers. Note that the tax IDs available here aren’t limited to EU VAT IDs, but also cover a large number of other tax IDs for many countries. One business partner can have multiple tax IDs, but never two that are the same. This means our customer in the example in Figure 3.65 could have a Hungarian VAT ID, a Hungarian tax ID number, and a Romanian VAT ID, but not two Hungarian VAT IDs. To review or maintain the preprogrammed validation of tax IDs, you can maintain them via Transaction OY17 or Transaction SPRO, followed by menu path SAP NetWeaver • General Settings • Set Countries • Set Country-Specific Checks. Double-click on the country you want to review. In the Formal checks area, as shown in Figure 3.66, the Length of a certain number and a corresponding Checking rule can be defined. There are nine relevant checking rules available, but we’ll focus on the more complex Checking rule 9 (Check against country-specific edit format) as the others are predefined format checks with self-explanatory descriptions. To use this country-specific check format, it’s important that the Other data checkbox at the bottom left is ticked.

146

3.2 Sales and Distribution and Materials Management

This checkbox enables the system to perform the corresponding check routines on the tax number via the programs assigned in view V_TFKTAXNUMTYPE as described next.

Figure 3.65 Maintain Tax ID of Business Partner

Figure 3.66 Tax ID Checking Rules

147

3

Basic Settings in SAP S/4HANA

If a certain tax ID isn’t available, you can maintain it via Transaction SM30. In the Table/View field, as shown in Figure 3.67, enter V_TFKTAXNUMTYPE, and click the Maintain button.

Figure 3.67 Maintain Tax Number Categories: Transaction SM30

You’ll find that many tax number categories—the equivalent to a certain type of tax number in a jurisdiction—are already available, as shown in Figure 3.68. For those that aren’t available, SAP may offer an SAP Note (e.g., SAP Note 2998790 for the VAT ID in Northern Ireland). To add a new tax number category, click the New Entries button, and enter the Tax Number Category, Name, and Funct.Name. The function name is the underlying proofing function used for the validation of the tax number, as well as the basis on which checks such as length, format, check sums, and gaps for each country are made. Occasionally, these rules change or must be adapted due to certain regulatory changes. One example of such a change is the introduction of new dummy VAT IDs in Europe for the Intrastat report on chain transactions where the VAT ID for the recipient of goods isn’t known. Via Transaction SM30 in the V_TFKTAXNUMTYPEC field table/view, you can maintain duplicate checks for tax IDs. When a new tax ID for a customer or vendor is created, the systems checks whether this tax ID is already maintained in the system for a different customer. Depending on the master data setup, this may be useful as tax IDs are generally unique.

Online Validation SAP also allows you to implement an online validation both on the master data level and transactional level. For details, refer to SAP Notes 2976739 and 2975262.

148

3.2 Sales and Distribution and Materials Management

Figure 3.68 Maintain Tax Number Categories

Value-Added Tax ID Determination The customer’s VAT ID number is necessary for many reasons inside the EU. If your company isn’t registered for VAT inside the EU, the determination of the customer tax classification may be relevant for you still. Generally, the VAT ID is required to perform tax exempt intra-community supplies and B2B services in the EU, fulfill invoice requirements (e.g., local or EU supplies), and fulfill reporting obligations (e.g., EC Sales List). To meet these obligations, usually the VAT ID of the customer for the place of supply is required. Determination Rules For the determination of the customer VAT ID, five different determination rules are provided by SAP: 쐍 Rule blank

The rule when the field is blank or empty follows a hierarchical set of rules to determine the VAT ID: – Priority 1: First, it validates whether the payer has a VAT ID maintained in its master data. If the payer isn’t the same customer as the sold-to party, then the VAT ID and customer tax classification are taken from the payer according to the tax country of destination. – Priority 2: Second, if the payer is the same as the sold-to party or doesn’t have a VAT ID, the system validates if the ship-to party has a VAT ID maintained in its master data when the sold-to has no VAT ID. In this case, the VAT ID and customer tax classification are taken from the ship-to party. – Priority 3: Third, if the payer and sold-to are the same and the ship-to party doesn’t have a VAT ID, the system tries to take the VAT ID and customer tax classification from the sold-to party.

149

3

Basic Settings in SAP S/4HANA

Warning! Despite this being SAP’s default rule, we strongly recommend using either rule A or B, which we’ll discuss next. There are several downsides to the blank rule, such as incomplete master data maintained in the system for ship-to parties in chain transactions. This is often the case, as the ship-to party isn’t the initial customer’s direct customer but the customer of a customer and the only known information is the delivery address. Additionally, there are scenarios where this rule would lead to the determination of an incorrect VAT ID. For example, the priority rule ignores the possibility that sold-to party and ship-to party may be different and that the sold-to party has a VAT ID in the country of destination. From the point of VAT, this VAT ID should be preferred; however, the system prefers the VAT ID of the ship-to party in this scenario. For example, say a Spanish customer (sold-to party and payer in SAP) orders goods for his Belgian customer (ship-to party in SAP). The Spanish customer is registered for VAT in both Spain and Belgium, and the Belgian ship-to party has no VAT ID. In this case, the Spanish VAT ID is chosen by the system despite a Belgian VAT ID being available. 쐍 Rule A

If rule A is set, the VAT ID and customer tax classification are generally taken from the sold-to party according to the tax country of destination. 쐍 Rule B

If rule B is set, the VAT ID and customer tax classification are generally taken from the payer according to the tax country of destination. 쐍 Rule C

Rule C corresponds to the standard priority rule except that if the second case doesn’t apply, the sold-to party and ship-to party aren’t the same, and the soldto party has a VAT ID of the tax determination country, the VAT ID of the sold-to party for the tax determination country is determined rather than the VAT ID of the residence country. 쐍 Rule D

If rule D is set, the VAT ID and customer tax classification are generally taken from the ship-to party according to the tax country of destination. The rule for the determination of the VAT ID and customer tax classification can be maintained on the sales organization level via Transaction SPRO and menu path Sales and Distribution • Basic Functions • Taxes • Maintain Determination of Value-Added Tax Registration Number. Figure 3.69 shows the different rules that can be assigned to the sales organization.

150

3.2 Sales and Distribution and Materials Management

Figure 3.69 Assign VAT ID Determination to Sales Organization

Determination Extensions Often, the VAT ID determination rules within SAP standard aren’t enough to accurately depict the reality of how complex VAT ID determination can be. For this, SAP offers user exits in programs V05EZZRG (extension for rule B [payer]) and V05EZZAG (extension for rule A [sold-to party]) as described in SAP Note 91109. We commonly see such extensions for the following cases: The payer or sold-to party does have a VAT ID for their country of residence, but not for the tax destination country. In SAP standard, the VAT ID of the country of the payer or sold-to party would not be taken into account, that is, there would be no VAT ID determined and the system would apply domestic VAT as a safety measure. For the supply of goods, in contrast to the SAP standard behavior, the VAT ID of the country of residence of the payer or soldto party should be considered if the payer or sold-to party doesn’t have a VAT ID for the tax destination country. According to this validation routine, the system first checks whether there is a VAT ID of the payer or sold-to party in the tax destination country. If there is, it’s taken from the respective table. If the VAT ID of the payer or sold-to party isn’t determined in the first standard validation step, the system will try to pick the VAT ID from the country of residence of the payer or sold-to party. A further adaption we’ve implemented before is for a case where the payer or sold-to party have no VAT ID in the country of destination and are resident outside the EU. Thus, no EU VAT ID is available in the country of residence. However, this doesn’t mean that a transaction can’t be an intra-community supply of goods from the perspective of the supplier if the payer or sold-to party is registered for VAT in another EU country that isn’t the tax destination country. Such a transaction may qualify as an EU triangular deal. In this case, a check should be made for an EU VAT ID in the customer master data.

151

3

Basic Settings in SAP S/4HANA

Determination Examples In this section, we’ll provide an overview of the different results depending on the chosen VAT ID determination example. Note that while the VAT ID is already considered during the sales order pricing, the final VAT ID determination only happens in the billing document. Now, let’s walk through the examples: 1. Rule , priority 1 In this example, as shown in Figure 3.70, the payer has a VAT ID of the tax destination country maintained in its master data and isn’t the same business partner as the sold-to party.

Figure 3.70 Rule Blank, Priority 1: Business Partners

To see the VAT ID that was determined for the billing document, click on the Display Header Details button in the header part of the billing document. In the Taxes section under the Header Detail tab, as shown in Figure 3.71, you’ll find details of the tax destination country, customer tax classification, determined VAT ID and country of VAT ID, as well as the details regarding the business partner of the transaction from which the VAT ID originates (Origin Sls. Tax No.). In this case, the result is the choice of VAT ID from B (Payer).

Figure 3.71 Rule Blank, Priority 1: Result

2. Rule , priority 2 In this example, shown in Figure 3.72, the payer and the sold-to party are the same entity. They don’t have a VAT ID in the country of destination. The ship-to party has a VAT ID in the country of destination.

152

3.2 Sales and Distribution and Materials Management

Figure 3.72 Rule Blank, Priority 2: Business Partners

The result is the choice of VAT ID from A (Ship-to party), as shown in Figure 3.73.

Figure 3.73 Rule Blank, Priority 2: Result

3. Rule , priority 3 In this example, shown in Figure 3.74, the payer and sold-to party are the same, and the ship-to party doesn’t have a VAT ID in the country of destination.

Figure 3.74 Rule Blank, Priority 3: Business Partners

The result is the choice of VAT ID from C (Sold-to party), as shown in Figure 3.75.

153

3

Basic Settings in SAP S/4HANA

Figure 3.75 Rule Blank, Priority 3: Result

4. Rule , VAT ID of the tax departure country In this example, the foreign customer (ship-to party, payer, and sold-to party) only has a VAT ID of the tax departure country. In Figure 3.76, you can see the maintained VAT ID of the business partner on the master data level.

Figure 3.76 Rule Blank, VAT ID of the Departure Country: Business Partner

For the system, this is the same as not determining a VAT ID at all, as shown in Figure 3.77. This happens because, for the system, it’s not possible to determine a VAT ID of the tax destination country or of the foreign residence (in the example, Austria) of the business partner.

Figure 3.77 Rule Blank, VAT ID of Departure Country: Result

154

3.2 Sales and Distribution and Materials Management

5. Rule B, VAT ID from tax destination country As described earlier, with rule B, the VAT ID is generally determined from the business partner role payer. The VAT ID of the sold-to party and ship-to party is never considered. Figure 3.78 shows the business partners of this example.

Figure 3.78 Rule B, Default: Business Partners

The default rule is that the VAT ID is determined from the tax destination country. In Figure 3.79, you can see that the tax number was determined from the role B (Payer) and the determined VAT ID itself.

Figure 3.79 Rule B, Default: Result

6. Rule B, VAT ID from residence country If there is no VAT ID available for the country of destination, the VAT ID of the country of residence of the payer should be considered. In Figure 3.80, you can see that the ship-to party and, therefore, the country of destination, is no longer France, but Czech Republic.

Figure 3.80 Rule B, VAT ID from Residence Country: Business Partners

Note that we’ve implemented the instructions of SAP Note 91109 with effect on this example. This isn’t SAP standard behavior. In Figure 3.81, you can see that the tax destination country differs from the country of the VAT registration number. Additionally, you’ll notice that the origin of the VAT ID is from D (Payer (KNAS segment)). This means that it was taken from the payer, but not for the country of destination.

155

3

Basic Settings in SAP S/4HANA

Figure 3.81 Rule B, VAT ID from Residence Country: Result

7. Rule B, No VAT ID If the payer doesn’t have a VAT ID at all, and the goods movement is inside the EU, the system uses a safety measure and applies domestic indirect tax. In Figure 3.82, the payer is from the United States and therefore doesn’t have a European VAT ID. The goods are being shipped to another EU country.

Figure 3.82 Rule B, No VAT ID: Business Partners

This is due to the access requirement for cross-border supplies not being fulfilled. For details on access requirements, refer to Chapter 4, Section 4.1.5. In Figure 3.83, you can see that the system tried to determine the VAT ID from partner role B (Payer), but there was no VAT ID available.

Figure 3.83 Rule B, No VAT ID: Result

3.2.3 Tax Determination with Pricing In SAP S/4HANA, every item considered during pricing—so the net price, surcharges, discounts, and also indirect tax or WHT—is represented by a condition type. Each type of tax must be represented by a condition type as well.

156

3.2 Sales and Distribution and Materials Management

In the following sections, we’ll discuss settings for indirect tax determination and WHT determination in pricing scenarios.

Indirect Tax Determination Indirect tax is a transactional tax. For each sales and purchase transaction, whether it’s subject to indirect tax and the tax rate need to be determined. During pricing in SAP S/4HANA, this process of determining the correct indirect tax on the transaction can be automated: For each sale or purchase, indirect tax is calculated as a part of the price, together with the net value of the invoice and any surcharges or discounts. Most jurisdictions only have one type of indirect tax, such as VAT or goods and services tax (GST). However, there are also jurisdictions that have multiple types of indirect tax. In these jurisdictions, the indirect tax is often determined and accumulated on several levels, for example, on the federal, state, and city levels. For countries where there is only one type of indirect tax, you’ll find that the standard condition type for indirect tax is MWST or TTX1, depending on the SAP version you’re using. For countries where there are multiple indirect taxes, multiple condition types must exist. These condition types are assigned to the respective country via Transaction SPRO, followed by menu path Sales and Distribution • Basic Functions • Taxes • Define Tax Determination Rules. In the overview shown in Figure 3.84, the condition type is represented by the tax category (Tax Categ.). This tax category is assigned to the respective country in an n-to-n relationship. One country can have multiple tax categories, and one tax category can also be assigned to multiple countries. When assigning multiple tax categories to one country, such as for the example of Canada, a sequence (Seq.) must be added, which determines the hierarchy of the multiple indirect taxes.

Figure 3.84 Assign Condition Type to Country

In Figure 3.84, Australia, for example, only has one tax category: MWST. This means that for sales issued by an Australian sales organization, one type of indirect tax will be

157

3

Basic Settings in SAP S/4HANA

determined using condition type MWST. In contrast, Canada has three tax categories, CTX1, CTX2, and CTX3. This is due to the special indirect tax system in Canada, where the federal government imposes a base tax (GST). Depending on the province, a provincial tax (PST) is added. The combination of this is known as harmonized sales tax (HST). Therefore, there are three tax categories for Canada: CTX1 for GST, CTX2 for PST, and CTX3 for the combination of both (HST). In SAP naming, this is shown as PST (Base+GST) Cdn. For each item in the sales order, invoice, or purchase order, a pricing procedure is used. This pricing procedure should include the tax category defined previously, depending on the supplying country. In the example, for country Australia, one condition type— MWST—is determined. In Figure 3.85, you can see an example of the pricing conditions determined in a sales document—in this case, a sales order. As tax determination happens on the item level, this tab can be accessed by double-clicking on the item in the sales order and navigating to the Conditions tab. At the top of the Pricing Elements table, you can see the price condition type PPR0, followed by down payment condition type YZWR and condition type MWST for indirect tax.

Figure 3.85 Pricing Example for a Sales Document

As a condition type can only be linked to one access sequence, there may be situations where you’ll need to create a new condition type for jurisdictions with only one indirect tax. For more details on condition types and access sequences, see Chapter 4, Section 4.1.

158

3.2 Sales and Distribution and Materials Management

Example Company A is a resident of South Africa using standard condition type MWST with the standard condition tables, as it’s sufficient for their needs. While they are in the course of integrating a recently acquired group, company B in Great Britain, into their SAP S/4HANA system, they realize that the current setup isn’t sufficient for indirect tax determination in Great Britain. Company A decides that company B will receive their own condition type and access sequence to fit their more complex needs. Table 3.2 shows an example. Note, however, that this isn’t a best practice recommendation and is only meant to illustrate how the need for different condition types for different company codes may arise. Company A – South Africa

Company B (Same Group as A) – Great Britain

쐍 Condition type: MWST

쐍 Condition type: ZMWS

쐍 Access sequence: MWST

쐍 Access sequence: ZMWS

쐍 Condition table A002: Domestic tax

쐍 Condition table A368: Domestic tax with region

쐍 Condition table A011: Export tax

쐍 Condition table A002: Domestic tax 쐍 Condition table A011: Export tax

Table 3.2 Different Condition Types for Company Codes

In this case, there would be two different pricing procedures for these two countries. The pricing procedure for company A would include condition type MWST, and the pricing procedure for company B would include condition type ZMWS. This is possible within the SAP standard. If you require two different condition types for the same country, there will be coding involved. For details on this, see Chapter 6.

Withholding Tax Determination In comparison to indirect tax determination, there are some differences regarding WHT determination in SAP. For WHT determination in sales and distribution, the WHT isn’t considered via condition records as it is for indirect tax. Instead, the WHT value at the time of invoice posting is based on the WHT type and tax code as maintained on the customer master level. You’ve learned about WHT types in Section 3.1.1. To use WHT during pricing, it must be assigned to a condition type.

159

3

Basic Settings in SAP S/4HANA

3.3 Integration of SAP Modules in Tax Determination In the previous sections, you’ve learned about the basic settings in financial accounting, sales and distribution, and materials management. However, these modules are rarely involved in the sales or purchasing process alone. This section will describe the interactions between the modules with relation to tax.

3.3.1 Materials Management and Financial Accounting The input process from beginning to end in SAP is often referred to as procure-to-pay. This term combines all procurement-relevant processes, beginning at the requisition until the payment of the procured goods or services. Figure 3.86 shows a schematic overview of the process.

Materials Management Purchase Requisition

Purchase Order

Proposed indirect tax determination

Financials Goods Receipt

Incoming Invoice

Accounting Document

Payment Request

Payment Run

Final indirect tax assignment

Figure 3.86 Schematic Overview of SAP S/4HANA Purchasing Process for Indirect Tax

Generally, the procure-to-pay process in SAP begins in materials management with a purchase requisition. The purchase requisition is an internal request to procure certain goods or services. Therefore, it already contains tax-relevant data: the goods or services that are to be procured and the requesting plant. This plant is the tax destination country. After this purchase requisition is approved, a purchase order can be created from it. The purchase order is the external request to procure certain goods or services and contains—in addition to the information contained in the purchase requisition—information about the vendor, expected pricing, and purchasing organization. The purchase order is usually the place where the initial tax determination happens if you’re using purchase info records or condition techniques for your indirect tax determination on the input side. For more details on the purchase order and tax determination in materials management, see Chapter 4, Section 4.2. Now you’ve requested the goods or services from your vendor. As they supply the goods to you, you’ll have a goods receipt: a notification from the logistics workstream confirming the receipt of the goods you’ve ordered. Note that there are certain things for which a goods receipt isn’t required, such as services.

160

3.3

Integration of SAP Modules in Tax Determination

Having received the goods or service you’ve ordered via your purchase order, you’ll also receive an invoice from your vendor for their supply. When entering this invoice into your system, you can create a reference to a purchase order. This enables you to copy over the tax code that was determined on the purchase order. From this incoming invoice, an accounting document is created automatically. Note that there is no determination of a tax procedure while entering the incoming invoice. For incoming invoices posted in materials management, the tax procedure of the purchasing company code is used in all cases.

Example Let’s look at the example shown in Figure 3.87. Company E, a Spanish company code with a tax registration in Spain and in Portugal, is purchasing goods from a supplier in Spain. The tax code on the incoming invoice is always posted with the tax procedure of the country of the company code, TAXES. Supplier Spain

Plant of company E in Spain

Plant of company E in Portugal

Tax procedure TAXES Tax code V1 – Domestic purchase of goods in Spain

Tax code PI – EU acquisition of goods in Portugal

Figure 3.87 Example of Tax Procedure Determination in Procure-to-Pay

This leads to the need for creating every tax code of plants in other countries—in this example, Portugal—for the country of the company code. This means that for country ES, there will exist a tax code with Reporting Cntry (reporting country) PT, as shown in Figure 3.88.

Figure 3.88 Workaround for Tax Procedure Determination in Procure-to-Pay with Plants Abroad

161

3

Basic Settings in SAP S/4HANA

When creating a posting for an incoming vendor invoice in materials management via Transaction MIRO, you’ll notice that there are two dates available, as shown in Figure 3.89: the Invoice date and the Posting Date. The invoice date is the date printed on the invoice and is usually the date when the vendor has issued the invoice or supplied the goods or service. The posting date is the date when the invoice was entered into the system.

Figure 3.89 Procure-to-Pay Document Dates in Materials Management

During the creation of the accounting document, as shown in Figure 3.90, via Transaction FB03, the invoice date is copied into the Document Date field. The posting date is copied to the Posting Date field of the accounting document.

Figure 3.90 Procure-to-Pay Document Dates in Financial Accounting

This is important to keep in mind, as the standard reports in SAP related to indirect tax are mostly based on the posting date rather than the document date. The reporting date can be checked also in the accounting document itself by reviewing the tax reporting date. To do so, click on the header icon at the top of the accounting document to arrive at the screen shown in Figure 3.91, which shows the Tax Reporting D field. For more details on the tax reporting date, refer to Section 3.1.1.

Figure 3.91 Procure-to-Pay Document Dates in Financial Accounting: Header

162

3.3

Integration of SAP Modules in Tax Determination

In addition to the tax code, the tax ID number of the vendor may also be transferred from materials management to financial accounting. However, this is only the case when the tax ID number of the vendor is entered in the posting of the incoming invoice. If it wasn’t entered, the field will remain empty. Via Transaction MIRO, the Rep. Country field in Figure 3.92 only refers to the country of the tax ID number of the vendor and has no indirect tax relevance.

Figure 3.92 Procure-to-Pay Tax ID Number in Materials Management

This number is copied to financial accounting at the item level. To see the tax ID number of the vendor in financial accounting, double-click on the line item in the accounting document via Transaction FB03, and then click on the Additional Data button. You’ll arrive at the screen shown in Figure 3.93, where you can view the VAT Reg. No. field.

Figure 3.93 Procure-to-Pay Tax ID Number in Financial Accounting

3.3.2 Sales and Distribution and Financial Accounting The output process from beginning to end in SAP is often referred to as order-to-cash. This term combines all sales-relevant processes, beginning at the sales order (“order”) until the receipt of the payment (“cash”). Figure 3.94 shows a schematic overview of the process.

163

3

Basic Settings in SAP S/4HANA

Sales and Distribution

Sales Order

Preliminary indirect tax determination

Outbound Delivery

Financials Picking / Packing

Post Goods Issue

Billing

Accounting Document

Receive Payment

Report

Final indirect tax assignment

Figure 3.94 Schematic Overview of SAP S/4HANA Sales Process for Indirect Tax

The order-to-cash process generally starts with a sales order. In practice, the sales orders are rarely entered into the system manually but rather interfaced, for example, via an ordering tool or online shop. In the sales order, the preliminary pricing includes indirect tax determination, which is generally necessary as the customer expects an estimate of what their order will cost. Following a sales order related to the supply of goods, there is an outbound delivery, including picking, packing, and posting of goods issue. Such a logistics process isn’t generally required for the supply of services, as they aren’t tangible and aren’t located in a warehouse. Depending on whether the billing process is delivery related or not—that is, whether the billing process is related to a supply of goods or service—the invoice is created either directly from the sales order or from the outbound delivery. The SAP standard foresees delivery-related invoicing for the supply of goods. There are several benefits to this, including ensuring that the goods have actually been dispatched before invoicing, having an invoicing date closer to the actual date of supply, and considering potential changes at the time of delivery (e.g., change of delivery address to a different country). Inside the billing document, the final pricing and indirect tax determination occur based on a defined pricing procedure and determined condition record. The condition record and respective to-be-determined tax code are defined in a condition table in relation to the tax departure country. This tax departure country is usually the country of the supplying plant. For more details, see Chapter 4. Additionally, the final customer tax classification and tax number determination happens on the billing document level. From the billing document in sales and distribution, an accounting document in financial accounting is automatically created. The tax code is transferred to financial accounting. As for the transfer from materials management to financial accounting, there is no determination of a tax procedure while posting a billing document. The tax procedure of the selling company code is used.

164

3.3

Integration of SAP Modules in Tax Determination

Example Let’s stay with the example of company E, a Spanish company code with a tax registration in Spain and in Portugal. Company E also sells goods to customers in Spain. The tax code on the billing document is always posted to financial accounting with the tax procedure of the country of the company code, TAXES, as shown in Figure 3.95.

Plant of company E in Spain

Plant of company E in Portugal

Tax procedure TAXES Tax code A1 – Domestic sales of goods in Spain

Tax code PA – EU supply of goods

Customer Spain

Figure 3.95 Example of Tax Procedure Determination in the Order-to-Cash Process

This leads to the need for creating every tax code of plants in other countries—in this example, Portugal—for the country of the company code. This means that for country ES, tax codes with reporting country PT will exist.

There is also the possibility of using country-independent tax procedures, such as TAXEU for all countries in the EU. This may be beneficial for cases as described in the example when tax codes may otherwise need to be created twice—especially when plants abroad is active and the field reporting country is used. This country-independent tax procedure will then need to be assigned to all relevant countries. You may have already noticed that there are condition types in sales and distribution and condition types in financial accounting that look oddly similar—such as MWST in sales and distribution and MWAS in financial accounting. Both are required to calculate indirect tax in SAP S/4HANA. In sales and distribution, the condition type is used to reference an access sequence that is executed hierarchically to find a condition record—a match of which tax code to apply on the transaction for the available characteristics. The view shown in Figure 3.96 can be accessed by double-clicking on the item in the sales document and navigating to the Conditions tab. There, click on the Analysis button and expand the output tax condition TTX1. After double-clicking the condition, you’ll see the determined condition record. In the example, a tax code was determined for the combination of tax departure country Germany (DE), customer tax classification 1 (Taxable), and material tax classification 1 (Taxable).

165

3

Basic Settings in SAP S/4HANA

Figure 3.96 Condition Types in Sales and Distribution

In financial accounting, the condition type is used as a calculation rule. For example, the tax code maintenance screen shown in Figure 3.97 (accessed via Transaction FTXP) shows that condition type MWAS calculates as 19% of the tax base amount.

Figure 3.97 Condition Types in Financial Accounting

In sales and distribution, several dates are relevant and aren’t all transferred to financial accounting: 쐍 Billing date

The billing date (technical field FKDAT), as shown in Figure 3.98, is the date on which the billing document is processed and booked for accounting purposes. If an invoice date is defined, the system generally proposes the billing date from the invoice date calendar, for example, for milestone billings or periodic billings.

Figure 3.98 Order-to-Cash Billing Date in Sales and Distribution

166

3.3

Integration of SAP Modules in Tax Determination

The value from the Billing Date field in sales and distribution is copied to the Document Date field in financial accounting, as you can see in Figure 3.99. The posting date in financial accounting is the date of creation of the financial accounting document. This is generally the date when the accounting document is created, that is, when the billing document is released to accounting.

Figure 3.99 Order-to-Cash Billing Date (Document Date) in Financial Accounting 쐍 Invoice date

The invoice date (technical field FBUDA) should generally be the date of supply. If no invoice date is defined in the invoice date calendar, then the system will use the actual goods issue date as the invoice date for delivery-related billings, and the sales order date will be used for order-related billings. For services, the system proposes the invoice date as the date of services rendered. The invoice date can be found on the item level of the billing document in the Item Detail tab in the Serv. Rendered field, as shown in Figure 3.100.

Figure 3.100 Order-to-Cash Invoice Date and Pricing Date in Sales and Distribution

167

3

Basic Settings in SAP S/4HANA

쐍 Created-on date

The created-on date (technical field ERDAT) is the date on which the record was created, that is, the date on which the document was entered in the system. This field can be seen on the header level of the billing document as shown in the example in Figure 3.101.

Figure 3.101 Order-to-Cash Created-On Date in Sales and Distribution 쐍 Pricing date

The pricing date (technical field PRSDT) determines date-related pricing elements, such as condition records and exchange rates. Generally, the system uses the date at the time of document creation. When the pricing date is changed, the pricing for the entire document is recalculated. For example, you may want to use a pricing date in the past for a credit note that refers to a document relating to a period prior to a tax rate change. The Pricing Date can also be found on the item level of the billing document in the Item Detail tab, as shown previously in Figure 3.100. The pricing date determination can be adjusted on the condition level via the settings for condition types with Transaction V/06. The usual setting, as in the example in Figure 3.102, is rule blank (Standard (KOMK-PRSDT; tax and rebate KOMK-FBUDA). This means that if there is an invoice date FBUDA determined based on the logic described earlier, this is preferred for tax conditions. If not, the document pricing date—generally the date of document creation—is used. Other options for the determination of the pricing date that can be assigned on the condition level are rule A (Date of services rendered (KOMK-FBUDA)), B (Price date (KOMK-PRSDT)), C (Billing Date (KOMK-FKDAT)), D (Creation Date (KOMK-ERDAT)), and E (Order Date (KOMKAUDAT)).

Figure 3.102 Pricing Date for the Condition Type

168

3.3

Integration of SAP Modules in Tax Determination

Additionally, the determined tax ID number you can see in Figure 3.103 is transferred from the billing document in sales and distribution to the accounting document in financial accounting. For details on the tax ID number determination of the customer, refer to Section 3.2.2.

Figure 3.103 Order-to-Cash Tax ID Number in Sales and Distribution

This number is copied to financial accounting on the item level. To see the tax ID number of the vendor in financial accounting, double-click on the line item of the accounting document—either accessed via the document flow of the sales document or via Transaction FB03—and then click on the Additional Data button. This will lead you to the view in Figure 3.104, where you can see the VAT Reg. No. of the customer.

Figure 3.104 Order-to-Cash Tax ID Number in Financial Accounting

169

3

Basic Settings in SAP S/4HANA

For WHT, tax can be withheld during payment (financial accounting method) or during invoice posting (sales and distribution method): 쐍 Financial accounting method of WHT

During payment, a WHT line is determined in the sales document and then captured in financial accounting at the time of payment posting. The WHT won’t be shown in pricing of the sales and distribution document. 쐍 Sales and distribution method of WHT

During invoice posting, WHT is determined in the sales document at the time of invoice posting. This means that despite being part of a sales and distribution process and being reflected in a condition record, the WHT amount is calculated as maintained at the customer master level and not based on the condition technique. After determining the WHT type, the system posts the determined value in financial accounting as a WHT code.

3.4 Smart Forms As a cross-component functionality relevant for indirect tax, we want to briefly introduce smart forms. The smart forms functionality is one of the SAP standard options to generate PDF outputs, such as invoices, delivery notes, or purchase orders. Smart forms consist of three central elements: the form itself, the report populating the form, and the output type. The smart form can be viewed and edited via Transaction SMARTFORMS. We’ll look at one of the standard forms provided by SAP, LB_BIL_INVOICE, in Figure 3.105.

Figure 3.105 Smart Form Screen

When clicking the Display button, you arrive at the smart form itself, as shown in Figure 3.106. It’s basically a grid that holds different data fields and information. It can be created via drag and drop. The fields in the form are filled by a report. In SAP standard, for example, this is report SD_INVOICE_PRINT01 for the billing document.

170

3.4

Smart Forms

Figure 3.106 Smart Form LB_BIL_INVOICE

The functionality that links the smart form and report to fill it can be viewed and edited via Transaction NACE. In the overview shown in Figure 3.107, choose the application you’re looking for. In the example, we want to look at the invoice layout in application V3 (Billing). After selecting the application, click the Output types button at the top of the screen.

Figure 3.107 Application for Output Types

On the next screen, select the OutputType—here, we’re choosing the SAP standard output type RD00 for the invoice (see Figure 3.108). Choose Processing routines on the lefthand side.

Figure 3.108 Output Types

171

3

Basic Settings in SAP S/4HANA

There, you can see the Program for the print output and the smart form it should fill, as shown in Figure 3.109. The FORM routine field refers to the routine inside the program responsible for the output. Usually this is ENTRY. If you’re using a custom program, this may be different (e.g., if you want to use a form routine for an interface such as Electronic Data Interchange [EDI]).

Figure 3.109 Processing Routines for Output Types

In the billing document itself, accessed via Transaction VF03, on the top of the screen, choose Billing Document • Issue Output To. In the popup shown in Figure 3.110, choose the output type—here, RD00—and click the Print Preview icon. The invoice printout will be generated.

Figure 3.110 Billing Document: Issue Output

172

3.5

Summary

3.5 Summary As this chapter demonstrated, the basic settings for tax in financial accounting, materials management, and sales and distribution are numerous and can serve a multitude of both legal requirements and business models. Therefore, it’s extremely relevant to understand the requirements of the relevant jurisdictions for your company and the requirements of the business to design your SAP system with the best fit possible. There may be decisions such as standardizing the system settings over all company codes or ensuring that there are no interdependencies between the different company codes with influence on all tax-related settings. The design of the tax codes depends on such a decision, as do the number of customer and material tax classifications. Despite the design of such a uniform SAP concept possibly making the project more complex, we highly recommend considering it due to the maintenance benefits. In the next chapter, we’ll turn our attention to indirect tax determination in SAP S/4HANA.

173

Chapter 4 Indirect Tax Determination in SAP S/4HANA So far, we’ve discussed the basic settings in financial accounting related to tax, such as tax codes, and the basic settings in sales and distribution/ materials management related to tax, such as tax classifications. Leveraging this knowledge, we’ll take a deeper look into indirect tax determination in SAP S/4HANA in this chapter.

Setting up indirect tax determination is one of the most important tax-related settings in your SAP S/4HANA system. Depending on your business, you may have several hundred or even several thousand taxable transactions per day. This makes it impossible to evaluate each transaction manually and can have dire consequences if a setting is wrong. Imagine a scenario in which a setting with an incorrect validity date or wrong tax code causes the wrong tax rate to be applied to hundreds of invoices per day. This would result in a high manual correction effort and potentially high fines by tax authorities. Understanding the tax determination process and ensuring the correct setup in accordance to the respective legal requirements of your jurisdictions should be a central part of your SAP S/4HANA implementation. In this chapter on indirect tax determination, you’ll learn about the logic for indirect tax determination for both the sales and purchasing side. It includes condition techniques on the sales side within sales and distribution, and the choice between condition techniques or purchase information records on the purchasing side within materials management.

4.1 Condition Logic in SAP Indirect tax determination in SAP is based on condition logic (also known as the condition technique). This type of logic is always used in the order-to-cash process for sales processes and can be applied to the procure-to-pay process for indirect tax determination on the purchase order. This condition logic is built in a hierarchical manner, as shown in Figure 4.1. The pricing procedure or price calculation procedure is the overall structure that contains multiple condition types—one of them a condition type for tax. Each condition type contains an access sequence. This access sequence holds one

175

4

Indirect Tax Determination in SAP S/4HANA

or more condition tables. The access to these condition tables is controlled by the access requirements.

Price Calculation Procedure (KALSM)

Condition Types (KSCHL)

Access Sequence (KOZGF)

Condition Table

Condition Table

Access Requirements

Condition Table

Figure 4.1 Schematic Overview of Condition Logic in Indirect Tax Determination

In this section, we’ll walk through the setup of each component in this condition logic hierarchy.

4.1.1 Price Calculation Procedure The price calculation procedure, or pricing procedure, aggregates the relevant condition types into a hierarchical structure. This hierarchical structure determines the price calculation elements, for example, price, surcharges, discounts, and any type of transactionrelated indirect tax. SAP comes with several predefined pricing procedures for both sales and purchasing. To begin, execute Transaction V/08 or follow menu path Sales and Distribution • Basic Functions • Pricing • Pricing Control • Define and Assign Pricing Procedures, and choose the relevant pricing procedure. You’ll arrive at the screen shown in Figure 4.2, where, in this example, you can see an extract of one of the SAP standard pricing procedures for sales, procedure RVAA01. The equivalent on the purchasing side can be reached via Transaction M/08 or menu path Materials Management • Purchasing • Conditions • Define Price Determination Process • Set Calculation Schema – Purchasing. As mentioned, this list is hierarchical, meaning that the price calculation procedure is calculated starting with the condition type of the Step with the lowest number until it reaches the end of the price calculation procedure. The alphanumerical abbreviations, for example, MWST (Output Tax), are called condition types, and will be explained in Section 4.1.2.

176

4.1 Condition Logic in SAP

Figure 4.2 Pricing Procedure RVAA01

Generally, each condition type references the amount of the step preceding it. For instance, condition type MWST uses the amount calculated from all steps above it as the tax base amount. However, you can reference a condition type in the Fro… (from reference step for percentage conditions) column, as shown in steps 901 to 905. These steps calculate the rebate directly from reference step 400, the Rebate Basis. Further settings for each condition type referenced in the price calculation procedure can be made in the checkboxes, as shown in Figure 4.3: 쐍 Manual

If checked, the condition is only included in the price determination if it’s entered manually or if it’s transferred from an external process (e.g., a sales pre-system). This isn’t a recommended setting for condition type MWST (Output Tax), as this condition should always be calculated automatically during pricing. Entering it manually will make it possible to not have a tax condition at all, or to enter the amount manually. This increases the risk of human error on such a complicated process as indirect tax determination.

177

4

Indirect Tax Determination in SAP S/4HANA

쐍 Required

If checked, the condition is made mandatory when the system carries out pricing. This is a very much recommended setting for condition type MWST (Output Tax) and maintained as such in the SAP standard pricing procedure RVAA01. If no condition record for condition type MWST is found, the document will have an error (Pricing error: Mandatory condition MWST is missing) and be incomplete.

Condition Records A condition record is the representation of a certain set of parameters that lead to a tax code, that is, the tax treatment of a transaction.

Making condition type MWST required has several benefits: – As indirect tax must always be part of pricing, for example, due to legal or regulatory obligations, for information to be printed or submitted on the invoice, the condition type for tax should also always be part of pricing. – The condition type avoids nondesirable or incorrect scenarios. For example, from a business perspective, it may not be possible to render a service from a certain plant. By not maintaining the indirect tax determination for this scenario, an error would occur during pricing instead of such an unrealistic scenario going out to the customer. – Missing master data is identified. As you’ll learn later in Section 4.1.4, the condition technique is based on several parameters, including an indicator in the customer and material master data. If this indicator isn’t maintained, it may point toward general issues with the master data. 쐍 Statistics

This indicator makes a condition type statistical, which means you can include another condition type without altering the value of the pricing procedure. A taxrelated statistical condition type is GRWR (statistical value), which is used in the Intrastat report. 쐍 Relevant for Account Determination

This indicator defines whether a statistical price condition is relevant for account determination. It may become relevant when using profitability analysis. The goal of this checkbox is to enrich the management reporting functionality. For example, you may want to gain more information about the frequency of warranties, the amount of surcharges or rebates applied, or about delivery cost.

Figure 4.3 Checkboxes in the Price Calculation Procedure

178

4.1 Condition Logic in SAP

Further settings for each condition type maintained in the price calculation procedure include the following (refer to Figure 4.2): 쐍 Print T… (print type)

The print type controls the output of conditions when printing documents such as sales orders or invoices. Generally, the following print types are available: – : The condition line isn’t printed. – X: The condition line is printed at the item level. – S: The condition line is printed in the totals block. Condition lines that represent a tax condition are always printed in the totals block with print type S.

Warning! SAP also offers alternative print types. These can’t be mixed with the standard print types X and S, as the system will only take into account the standard print types. These alternative print types can be used if you want to add some logic to the printing. For example, alternative print type D offers to print only if the value isn’t zero and isn’t the value of the predecessor. When using the alternative print types, X can be replaced with a and S can be replaced with A. 쐍 Subtotal

This indicator controls in which fields condition amounts or subtotals are stored in the pricing procedure. If the same fields are used to store different condition amounts, the system summarizes the individual amounts. For example, in Figure 4.2, the total amount of freight cost of condition types HD00 and KF00 is stored in field KOMP-KZWI4 via Subtotal indicator 4. 쐍 Requir… (requirement)

When set, the condition type is only taken into account once the requirement is fulfilled. Condition type MWST (Output Tax) has requirement 10 referenced in the SAP standard. Requirement 10 verifies that either the supplying plant in the sales document is set or the tax departure country is set.

Plant and Tax Departure Country In the SAP standard indirect tax determination in sales and distribution, the tax departure country is generally determined from the country of the suppling plant. Therefore, if the plant isn’t set, the tax departure country also can’t be set.

179

4

Indirect Tax Determination in SAP S/4HANA

쐍 Alt. Ca… (routine for alternative calculation of condition amount)

It’s also possible to calculate the condition amount of a condition type with a formula. A good example is condition type DIFF (Rounding Off), which rounds the calculated price to a certain format. For example, a number with several decimals can be rounded to a currency value with only two decimals. 쐍 Alt. Cn… (routine for alternative calculation of condition base value)

Next to the condition amount, a formula can be used to determine the condition base value for a certain condition as well. For the example with condition type DIFF (Rounding Off), the condition base value is set to routine 4 (Net value + Tax). This means that for rounding, the net value including calculated tax will be considered. 쐍 Accou… (account key)

This abbreviation determines the type of general ledger account this transaction is booked into. Account key MWS for condition type MWST (Output tax) is the key for sales on tax or purchases. 쐍 Accruals

The abbreviation in the Accruals field is a key that identifies types of general ledger accounts for accruals or provisions.

Pricing Procedures There are different pricing procedures in the SAP standard for different countries. This is especially relevant for countries with more than one type of indirect tax. For example, one of the SAP standard pricing procedures for the United States, RVAAUS, contains three types of indirect tax: state sales tax, county sales tax, and city sales tax. Furthermore, different pricing procedures may serve different purposes. Pricing procedure RVWIA1 is used only for internal stock transfers related to the plants abroad functionality (see Chapter 3, Section 3.1.3) and contains three condition types for indirect tax: output tax in the country of departure, input tax in the country of destination, and output tax in the country of destination.

The price calculation procedure is triggered via a combination of parameters: sales area (sales organization, distribution channel, division), document pricing procedure, and customer pricing procedure. This mapping, as shown in Figure 4.4, can be maintained by using Transaction SPRO and following the SAP configuration menu Sales and Distribution • Basic Functions • Pricing • Pricing Control • Define and Assign Pricing Procedures. The combination of sales organization, distribution channel, and division is called a sales area. Let’s break down these pieces: 쐍 Sales organization

The central organizational unit responsible for the sale of certain products or services. It may equal the company code or the legal entity, but one legal entity or company code may also have more than one sales organization.

180

4.1 Condition Logic in SAP

쐍 Distribution channel

The way in which the product or service reaches the customer, for example, wholesale, retail, or intercompany sales. 쐍 Division

A way of grouping materials (i.e., products or services). The document pricing procedure specifies a pricing procedure for a certain kind of sales document. As mentioned earlier, pricing procedure RVWIA1 is used for stock transfers. Therefore, the pricing procedure is triggered through document pricing procedure B (Plants Abroad), as shown in Figure 4.4.

Figure 4.4 Determination of Pricing Procedure

The customer pricing procedures are maintained on the master data level of the customer. For example, a pricing procedure may be different for private customers or business customers, as the business customer receives certain discounts or surcharges while the private customer doesn’t. To create a new combination to determine the pricing procedure, click on New Entries, and enter the Sales Organization, Distribution Channel, Division, Document Pricing Procedure, Customer Pricing Procedure, and Pricing Procedure that should be determined for this specific combination of parameters.

4.1.2 Condition Types Condition types represent certain parts of the pricing that contribute to finding the final price of a sales or purchasing document. You can see some examples by referring to Figure 4.2: NETP (Net Price), BO03 (Customer Rebate), or MWST (Output Tax). To reach the configuration for condition types in sales and distribution, you can use either Transaction V/06 or Transaction SPRO and follow menu path Sales and Distribution • Basic Functions • Pricing • Pricing Control • Define Condition Types. Similarly, to reach the configuration for condition types in purchasing, you can use either Transaction M/06 or Transaction SPRO and follow menu path Materials Management • Purchasing • Conditions • Define Price Determination Process • Define Condition Types. Then, double-click the condition type you want to view or edit.

181

4

Indirect Tax Determination in SAP S/4HANA

In Figure 4.5, we’ve selected condition type MWST to edit. To create a new condition type, the best practice approach is copying a condition type that already exists and is similar to the one you want to create. You can do this by selecting the condition type you want to copy—usually the one closest to what you’re trying to achieve with your new condition type—and then using the menu path Edit • Copy As. This then copies the condition type and leads you to the overview where you can make your changes. Alternatively, you can also use the New Entries button to create a condition type from scratch. A condition type must be included in a pricing procedure to be used. Generally, a condition type will also have an access sequence assigned. For example, condition type MWST has access sequence MWST assigned. For more details on the relevance of access sequences, refer to Section 4.1.3. As mentioned in this example, using condition type DIFF (Rounding Off), which rounds the calculated price to a certain format, you can use formulas to determine the value of a condition type instead of an access sequence.

Figure 4.5 Condition Type Settings: MWST

Let’s start with the settings in the Control data 1 section of Figure 4.5. First, you’ll define which type of pricing the condition type represents. This setting is called the condition class (Cond. class). Although SAP offers several predefined condition classes here, we’ll only cover a few that are most relevant for indirect tax: 쐍 A (Discount or surcharge)

This condition class indicates that this condition type is a surcharge to or discount of the initial price, for example, a customer rebate.

182

4.1 Condition Logic in SAP

쐍 B (Prices)

This condition class indicates that the condition type is a price, for example, the net price. 쐍 D (Taxes)

This condition class indicates that the condition type is a tax. Next, the calculation type (Calculat.type) determines the calculation of the condition value. For condition type MWST, calculation type A (Percentage) is used, as the indirect tax is generally calculated as a percentage of the price. Another calculation type relevant for indirect tax includes B (Fixed Amount), which is used in the condition type for nondeductible input value-added tax (VAT). There are also other calculation types, for example, for materials, which depend on the quantity, weight, or volume. Setting condition category (Cond. category) groups all condition types of a certain category. Condition type MWST has condition category D (Tax) assigned, while a condition type for nondeductible input tax would have condition category N (Input Tax non Deductible) assigned. Finally, the Rounding rule is of some significance for indirect tax. Most condition types have rounding rule (Commercial). For commercial rounding, the values will be rounded down to the nearest full number, that is, the lower number, if below 5, and the higher number, if above 5.

Example For example, 22% of 196.51 is 43.2322. With commercial rounding, the resulting indirect tax value would be 43.23.

There are some country best practices where you’ll come across condition types for indirect tax with other rounding rules: A (Round-Up) or B (Round-Down). For round-up rounding, the values will always be rounded up to the next full number. For rounddown rounding, the values will always be rounded down to the next full number.

Example For example, 22% of 196.51 is 43.2322. With round-up rounding, the resulting indirect tax value will be 43.24. With round-down rounding, the resulting indirect tax value will be 43.23.

Next, in the Group condition section, you can see a Group cond. indicator that determines whether the system calculates the condition value by taking all related items of the business document into account. For indirect tax, this means that the system will calculate the condition amount on the header and item level and will compare the

183

4

Indirect Tax Determination in SAP S/4HANA

values. The RoundDiffComp field and the GrpCond.routine checkbox aren’t relevant because they relate only to conditions with a scale value (e.g., mass discounts). In the Changes which can be made section, for the Manual entries setting, you can see indicator D (Not possible to process manually). This is a recommended standard setting for tax condition types, as manually changing the condition value of an indirect tax condition will lead to errors. Therefore, it can only be calculated by the system and can never be changed manually. Lastly, condition types for indirect tax are configured as an item condition. This means that the indirect tax is calculated on the item level instead of the header level. Checking the Item condition indicator is important, as a sales order or invoice may include materials with different indirect tax rates associated to them, making it necessary to calculate on the position level.

Standard Condition Type SAP has also introduced standard condition type TTX1 with access sequence TTX1 for indirect tax. This access sequence includes condition table 165 (Export Taxes Depending on the Billing Category) instead of condition table 078. See Section 4.1.4 for more information on condition tables.

4.1.3 Access Sequence Access sequences determine the sequence of accesses to condition tables. Each access sequence must contain at least one condition table. The condition tables inside the access sequence are always ordered from most specific to least specific, which is important because the access sequence is hierarchical. The SAP S/4HANA system will go through all condition tables in the access sequence, searching for a matching condition record. To reach the configuration for access sequences in sales and distribution, you can use Transaction V/07 or Transaction SPRO, followed by menu path Sales and Distribution • Basic Functions • Pricing • Pricing Control • Access Sequences • Set Access Sequences. To reach the configuration for access sequences in purchasing, you can use Transaction M/07 or Transaction SPRO, followed by menu path Materials Management • Purchasing • Conditions • Define Price Determination Process • Define Access Sequences. If you take a look at Figure 4.6 and Figure 4.7, you see the SAP standard access sequences for indirect tax for output tax (MWST) and input tax (0003), respectively. The No. field on the left determines the order in which the condition tables are tried by the access sequence. Next, the Tab field includes the number of the condition table.

Naming Condition tables in SAP start with an “A” (e.g., A002), but this letter is omitted in the access sequence.

184

4.1 Condition Logic in SAP

Figure 4.6 Access Sequence: MWST

Figure 4.7 Access Sequence: 0003

The Requiremnt field includes the access requirement for a condition table. For details, refer to Section 4.1.4. Finally, the Exclusive indicator determines whether the system should keep going through the following condition tables to find another more preferable match, or whether it should stop searching if there was a condition record found in a certain table.

Example If the Exclusive indicator isn’t set, a predetermination can be made in condition table A078 (Departure Country/Destination Country) for cross-border supplies. Condition table A011 (Export Taxes) is more specific, as it includes two more indicators apart from the departure and destination country. Therefore, if a match is found in the more specific table A011, this is preferred and results in two matching condition records and two lines of indirect tax at the item level.

The standard access sequence MWST (Tax on Sales or Purchases) for indirect tax determination in sales and distribution contains three condition tables in the SAP standard delivery: 쐍 Table A078 (Departure Country/Destination Country)

This condition table contains only two fields: the tax departure country and the tax destination country. It has access requirement 8 (export business) assigned. 쐍 Table A002 (Domestic Taxes)

This condition table contains three fields: the tax departure country, the customer tax classification, and the material tax classification. It has access requirement 7 (domestic business) assigned.

185

4

Indirect Tax Determination in SAP S/4HANA

쐍 Table A011 (Export Taxes)

This condition table contains four fields: the tax departure country, the tax destination country, the customer tax classification, and the material tax classification. It has access requirement 8 (export business) assigned. The standard condition table 0003 (Tax Classification) for indirect tax determination in materials management contains the following five condition tables in the SAP standard delivery. The names of the condition table already describe the existing fields. Note how there is no access requirement assigned to the condition tables. This means the system doesn’t pre-differentiate between, for example, domestic and cross-border transactions, as it does for indirect tax determination in sales and distribution. 쐍 Table A088 (Taxes: Material, Plant, Acc. Assignment, Origin and Region) 쐍 Table A094 (Taxes: Material, Plant, Origin and Region) 쐍 Table A087 (Taxes: Plant, Account Assignment, Origin and Region) 쐍 Table A086 (Taxes: Material, Plant and Origin) 쐍 Table A080 (Taxes: Material)

Extend Standard Functionality In most regions, it’s very uncommon to keep the SAP standard settings for access sequences in indirect tax determination as they don't cover all relevant requirements. There are several scenarios that make it necessary to extend the standard SAP functionality. To name an example, any supplies to special regions, such as Northern Ireland or the Canary Islands from Europe, make it necessary to include the destination region. For details on typical extensions to the SAP standard functionality, refer to Section 4.2.4 (purchasing) and Section 4.3.3 (sales).

To add a new condition table to the access sequence, click the New Entries button at the top of the screen (not shown) to arrive at the screen shown in Figure 4.8. Enter the number of the condition table you want to add (Ta…), as well as the number identifying in which sequence it belongs (No.). If an access requirement or exclusivity are applicable, set these as well in the Requirement and Exclusive columns.

Figure 4.8 Add a Condition Table to the Access Sequence

186

4.1 Condition Logic in SAP

Then, select the line, and double-click the Fields subfolder on the left-hand side of the screen. This enables you to assign the respective fields of the pricing communication structures to the condition table, as shown in Figure 4.9. The pricing communication structures KOMK (communication header for pricing structure) and KOMP (communication item for pricing structure) contain the accumulated data from different tables for pricing—both in sales and distribution and in materials management. Assigning the correct field of the pricing structures to your condition table is crucial as this will have a direct impact on which values are used for tax determination.

Figure 4.9 Assign Fields to the Condition Table

Generally, SAP will prefill these fields. However, and especially if you’ve created a custom field to include in your condition table, you may need to mark the line and use the Field catalog button at the bottom of the screen to choose the correct source value field.

4.1.4 Condition Tables Condition tables contain key fields that enable the determination of a tax code for a certain combination of parameters. For the tax user and for every SAP S/4HANA implementation project, including indirect tax determination, condition tables are a very central point of the tax determination. Therefore, it’s crucial for everyone to understand the functionality that comes with condition tables. In this section, we’ll explain the condition tables available for sales and distribution and for purchasing. We’ll also walk through how to create a new condition table and assign your own data fields. You’ll also recognize the tax classifications and indicators you’ve already learned about in Chapter 3, Section 3.2.1.

187

4

Indirect Tax Determination in SAP S/4HANA

Sales and Distribution As mentioned in Section 4.1.3, the SAP standard access sequence MWST (tax on sales or purchases) for indirect tax determination in sales and distribution contains three example condition tables. These condition tables have different fields assigned to them. The key fields for each table are as follows: 쐍 Table A078 (Departure Country/Destination Country)

– Tax departure country (data field ALAND, pricing field KOMK-ALAND) – Tax destination country (data field LLAND, pricing field KOMK-LAND1) 쐍 Table A002 (Domestic Taxes)

– Tax departure country (data field ALAND, pricing field KOMK-ALAND) – Customer tax classification (data field TAXK1, pricing field KOMK-TAXK1) – Material tax classification (data field TAXM1, pricing field KOMP-TAXM1)

Condition Table A002 Condition table A002 only has the tax departure country as a key field, as it’s only relevant for domestic transactions. Therefore, the tax departure country and tax destination country will always be the same, and the additional field isn’t required. 쐍 Table A011 (Export Taxes)

– Tax departure country (data field ALAND, pricing field KOMK-ALAND) – Tax destination country (data field LLAND, pricing field KOMK-LAND1) – Customer tax classification (data field TAXK1, pricing field KOMK-TAXK1) – Material tax classification (data field TAXM1, pricing field KOMP-TAXM1)

Purchasing In Section 4.1.3, you already learned that access sequence 0003 (tax classification) for indirect tax determination in materials management contains five example condition tables. These condition tables have different fields assigned to them. The key fields for each table are as follows: 쐍 Table A088 (Taxes: Material, Plant, Acc. Assignment, Origin, and Region)

– Tax indicator: material (data field TAXIM, pricing field KOMP-TAXIM) – Tax indicator: plant (data field TAXIW, pricing field KOMP-TAXIW) – Tax indicator: account assignment (data field TAXIK, pricing field KOMP-TAXIK) – Tax indicator: import (data field TAXIL, pricing field KOMP-TAXIL) – Tax indicator: region (data field TAXIR, pricing field KOMP-TAXIR) 쐍 Table A094 (Taxes: Material, Plant, Origin, and Region)

– Tax indicator: material (data field TAXIM, pricing field KOMP-TAXIM)

188

4.1 Condition Logic in SAP

– Tax indicator: plant (data field TAXIW, pricing field KOMP-TAXIW) – Tax indicator: import (data field TAXIL, pricing field KOMP-TAXIL) – Tax indicator: region (data field TAXIR, pricing field KOMP-TAXIR) 쐍 Table A087 (Taxes: Plant, Account Assignment, Origin, and Region)

– Tax indicator: plant (data field TAXIW, pricing field KOMP-TAXIW) – Tax indicator: account assignment (data field TAXIK, pricing field KOMP-TAXIK) – Tax indicator: import (data field TAXIL, pricing field KOMP-TAXIL) – Tax indicator: region (data field TAXIR, pricing field KOMP-TAXIR) 쐍 Table A086 (Taxes: Material, Plant, and Origin)

– Tax indicator: material (data field TAXIM, pricing field KOMP-TAXIM) – Tax indicator: plant (data field TAXIW, pricing field KOMP-TAXIW) – Tax indicator: import (data field TAXIL, pricing field KOMP-TAXIL) 쐍 Table A080 (Taxes: Material)

– Tax indicator: material (data field TAXIM, pricing field KOMP-TAXIM)

Create a Condition Record To create a condition record in sales and distribution, use Transaction VK11. In purchasing, you can use Transaction MEK1. When creating a condition record, the condition type for which the condition record is to be created must be entered because the same condition table can be used for multiple condition types.

Example For the plants abroad functionality, the SAP standard condition table A011 (Export Taxes) can be used. The condition types for plants abroad are WIA1, WIA2, and WIA3.

Additionally, choosing the correct condition type will prompt you with a popup, as shown Figure 4.10, to choose for which condition table you want to enter the condition records. After choosing the condition table, click the green checkmark icon, and then you can enter the condition record.

Figure 4.10 Create the Condition Record

189

4

Indirect Tax Determination in SAP S/4HANA

The example in Figure 4.11 shows the condition record for indirect tax determination on a sales document with the following: 쐍 Country

The tax departure country is DE (Germany), so the goods movement starts in Germany. 쐍 Dest. Ctry

The tax destination country is Canada (CA), so the goods movement ends in Canada. 쐍 TaxCl1Cust

The customer tax classification is 1, meaning the customer is a standard, taxable customer. 쐍 TaxCl.Mat

The material tax classification is 1, meaning the product sold is a standard, taxable material. This combination of parameters leads to the determination of Tax Code A0 with a tax rate of 0% for an export of goods from Germany.

Figure 4.11 Create a Condition Record: Export Taxes

Create a Condition Table As we clarified before, the standard condition tables often don’t suffice to depict and differentiate all business transactions subject to indirect tax. To reach the configuration for condition tables in sales and distribution, use Transaction V/03 or Transaction SPRO, and follow menu path Sales and Distribution • Basic Functions • Pricing • Pricing Control • Condition Tables and Field Catalog • Create Condition Table. To reach the configuration for condition tables in materials management, use Transaction M/03 or Transaction SPRO, and follow menu path Materials Management • Purchasing • Conditions • Define Price Determination Process • Maintain Condition Tables. Then, enter the number of the table you want to create. There is also the option to copy a table by entering the original table number in the Copy from Condition Table box. To create a new condition table, the desired fields are selected from the Field Catalog as shown on the right side of Figure 4.12.

190

4.1 Condition Logic in SAP

Figure 4.12 Create Condition Table

The settings in Figure 4.13 can be reached by clicking on the Technical View button. They are important to determine the selection screen when creating condition records. Anything selected as an item field (Item Fld) will be part of the condition table, while everything not selected will be part of the selection screen. You can see the example of this earlier in Figure 4.11. The best practice approach is to choose one or two fields, usually the tax departure country, as the selection field. This makes maintaining the condition records much easier, as you can enter into the table once and enter multiple parameters, rather than filling the selection graphical user interface (GUI) for each different set of parameters.

Figure 4.13 Create a Condition Table: Technical View

Depending on the requirements you have, you may want to create a new data element to include in your new condition table. To do so, go to Transaction SE11. We’ll walk through the data you can add to your condition table in the following sections. Create a Domain If you’re creating a data field that already has a domain, that is, there is a data type you can use, you can skip the creation of a domain.

191

4

Indirect Tax Determination in SAP S/4HANA

Example You want to create a data element to contain the country of the sold-to party. The domain for this data element is LAND1 (country key). In comparison, if you want to create a data field that functions as an indicator with defined values of some sort (e.g., is a country a European Union (EU) country or not), you need to create a domain to define the data type.

To create a domain, choose Domain on the Transaction SE11 screen, as shown in Figure 4.14. Enter the name of the domain. Be aware that it’s best practice to start custom settings and configurations with a “Z”. Click the Create button. In the example, we’re creating an indicator for associating a country to a certain customs union with a defined value range. For details on this enhancement, see Chapter 6, Section 6.2.

Figure 4.14 Create the Domain

On the next screen, shown in Figure 4.15, give a Short Description in the header, and then add the Data Type for your domain in the Definition tab. In this example, you’re creating a domain for the purpose of storing an indicator with information on the association to a customs union. Therefore, choose Data Type CHAR (Character String) with length (No. Characters) of 1. You’ll also need to assign a development package in the Properties tab or during the save prompt, which is a structure that stores repository objects. All developments are stored in such a development package or subpackage. Next, navigate to the Value Range tab, as shown in Figure 4.16. To define a limited range of values for the domain, you can define the fixed values by adding them in the table and giving them a description.

192

4.1 Condition Logic in SAP

Figure 4.15 Create Domain: Definition

Figure 4.16 Create Domain: Value Range

Save your domain by clicking Save at the bottom of the screen (not shown), and then activate your domain by clicking the Activate (wand) icon at the top of the screen, as shown in Figure 4.17.

Figure 4.17 Activate the Configuration

193

4

Indirect Tax Determination in SAP S/4HANA

Create a Data Element After you’ve created a domain, or if there is already a domain available that describes the data type you need, you can go ahead and create a data element. Go to Transaction SE11 again, and this time enter the name of your element in the Data type field (see Figure 4.18). Click the Create button and choose Data element in the popup.

Figure 4.18 Create Data Element

On the next screen, shown in Figure 4.19, enter a short description and the relevant Domain. Here, you’re using the domain just created. Note how the domain defines the data type and length of the data element being created.

Figure 4.19 Add the Domain to the Data Element

You’ll also need to assign a development package in the Attributes tab or during the save prompt. Save and activate as you did in the previous section. Add a Data Element to a Structure Depending on whether the new data element is a header or position field, it must now be added to structure KOMKAZ or KOMPAZ, respectively. These structures are available for customer modifications to the pricing communication header and item.

Warning! It’s very important to use KOMKAZ or KOMPAZ instead of appending items to structures KOMK or KOMP directly. Table KOMK and table KOMP are system tables, while KOMKAZ and KOMPAZ are dedicated structures for customer modifications on the pricing communication header and item.

To append data elements to the customer modification structures for the pricing communication, an append structure containing the fields must be created. This append

194

4.1 Condition Logic in SAP

structure can contain multiple fields for one purpose, thus making it easier to append additional fields, for instance, for indirect tax determination purposes. To reach structure KOMPAZ or KOMKAZ, use Transaction SE11, and enter the structure name into the field database table. In this example, you’re appending the field to structure KOMPAZ, as it refers to the tax destination country as an item field. At the top of the screen, click the Append Structure button, and either choose a fitting append structure, or click the Create icon to get to the popup shown in Figure 4.20.

Figure 4.20 Create a Append Structure for Structure KOMPAZ

Create a new append structure with name “ZITX_DETERMINATION_FIELDS”. After entering the Append Name and clicking the green checkmark, you’ll arrive at the screen shown in Figure 4.21. In this append structure—for now—a Short Description, the newly created Component ZXEGLD, and the newly created Component Type (i.e., the domain) are added.

Figure 4.21 Append Structure Fields

Save and activate the append structure following the same steps as previous sections. If you go back to the KOMPAZ structure, you should now be able to add this append structure via the Append Structure button. Your final result should look something like Figure 4.22.

195

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.22 Structure KOMPAZ with the Append Structure

Add Data Element to Field Catalog Furthermore, your new data element must be added to the field catalog in the price determination menus of sales and distribution and of materials management to use it inside a condition table. A field catalog defines the fields that can be used during pricing. To do so, use Transaction OMKA or Transaction SPRO, followed by menu path Sales and Distribution • Basic Functions • Pricing • Pricing Control • Condition Tables and Field Catalog • Change Field Catalog. Click the New Entries button, and enter the name of your new field, as shown in Figure 4.23. Press (Enter) and save by clicking the Save button on the bottom-right corner (not shown).

Figure 4.23 Add the Field to the Field Catalog

Materials Management and Sales and Distribution Structures KOMK and KOMP are used for materials management and for sales and distribution alike. Therefore, the field catalog is also universal for both modules. You can use the path and transaction code given earlier for both modules, or you can use path Materials Management • Purchasing • Conditions • Define Price Determination Process • Extend Field Catalog for Condition Tables in the SAP configuration menu to reach it from the materials management settings.

Populate Data Field during Pricing Finally, your new field must be populated with a value during pricing. If this step is skipped, the field may exist in a condition table but can never have a value.

196

4.1 Condition Logic in SAP

For details on how to populate the data field within USEREXIT_PRICING_PREPARE_TKOMK or USEREXIT_PRICING_PREPARE_TKOMP to use the value during pricing and tax determination, see Chapter 6, Section 6.2.1.

4.1.5 Access Requirements Access requirements can be understood as a “door opener.” They define a requirement that must be fulfilled to access a condition table. Access requirements are routines that contain ABAP code and can be created via Transaction VOFM, followed by the path Requirements • Pricing. In the SAP standard, two access requirements are relevant for the indirect tax condition tables. They regulate the relation between the tax departure country and tax destination country, and include a check for the VAT ID. The reason behind this is that inside the EU, a valid VAT ID must be present to apply a tax exemption for cross-border supplies. Let’s take a look at both relevant access requirements: 쐍 Access requirement 7

Access requirement 7 is assigned to condition table A002 (Domestic Taxes) in access sequence MWST. This access requirement contains the following checks: – Tax departure country isn’t empty. – Tax destination country isn’t empty. – If both tax departure and tax destination country are part of the EU, and the VAT ID of the customer is empty, the requirement is fulfilled. – If the tax departure country equals the tax destination country, the requirement is fulfilled. The access requirement is fulfilled if the tax departure country and tax destination country are the same or if no VAT ID of the customer exists. 쐍 Access requirement 8

Access requirement 8 is assigned, for example, to condition table A011 (Export Taxes) in access sequence MWST. This access requirement contains the following checks: – Tax departure country isn’t empty. – Tax destination country isn’t empty. – The tax departure country doesn’t equal the tax destination country. – If, for a tax condition, both tax departure and tax destination country are part of the EU, and the VAT ID of the customer is empty, the requirement isn’t fulfilled. The access requirement is fulfilled if the tax departure country and tax destination country aren’t the same. For EU countries, there is a check for the VAT ID—if no VAT ID of the customer exists, the access requirement isn’t fulfilled. The check whether the countries are part of the EU is made via the indicator XEGLD in the country data table T005.

197

4

Indirect Tax Determination in SAP S/4HANA

Exception Check Both access requirements 7 and 8 were extended due to the Northern Ireland regulations of Brexit. They now also include an exception check for the region. Nevertheless, they still follow the same logic.

4.2 Indirect Tax Determination in Purchasing There are two options to automate indirect tax determination in purchasing apart from the condition technique. After reading this section, you’ll be able to establish which is the best option for you and your company or project. In the following sections, we’ll take a deeper look into the different options for indirect tax determination in purchasing, the relevance of the purchase order and invoice receipt, and finally some typical scenarios where the SAP standard needs to be extended.

4.2.1 Electronic Data Interchange versus Purchase Info Records Electronic Data Interchange (EDI) is an electronic format for data exchange. For tax determination in purchasing, EDI is a good option to determine indirect taxes on incoming invoices of either related suppliers (i.e., within the same group) or of suppliers with established and regular relationships. To maintain EDI mapping, execute Transaction OBCD or follow menu path Materials Management • Logistics Invoice Verification • Electronic Data Interchange (EDI) • IDoc • Assign Tax Codes. With EDI, the outgoing invoice of the supplier is mapped to the purchasing side of the recipient. For indirect tax, this means a mapping of the tax code of the supplier is mapped to the tax code of the system. In Figure 4.24, you can see an example of such mapping.

Figure 4.24 EDI Mapping for Tax in Purchasing

198

4.2 Indirect Tax Determination in Purchasing

To add a new EDI mapping, click the New Entries button. There are different partner types that can be used, which you can select in the Partn.Type column. Most relevant for indirect tax on the purchasing side are partner types LI (vendor) and LS (logical system). A logical system may, for example, be a pre-system such as a cash register or a sales system. The PartnerNo column includes the name of the partner, which is either the vendor number or the description of the logical system. The Tax Type is the outgoing tax code of the supplier. This is then mapped to a country in the C/R field and to a receiving tax code. Such a mapping based on the country makes it possible to map the same tax code of the supplier to different input tax codes for different countries, which is necessary for tax reporting purposes. Now, let’s discuss the other option for purchasing: purchase info records. Purchase info records define—among other things—a tax code based on the combination of supplier and material. Purchase info records are a good solution if the same products are purchased from the same vendor over and over, and if these products are always supplied from the same country. With purchase info records, it’s not possible to differentiate when a vendor delivers goods from different locations.

Example A vendor has two main warehouses: one in the United States and one in Canada. When this vendor delivers goods to a customer in the United States, they may ship from either of the warehouses. From an indirect tax perspective, one of these transactions would be an import, while the other would be a domestic purchase of goods. When using a purchase info record, it’s not possible to differentiate between the two, as only one tax code can be maintained for the combination of vendor and material group. In such a case, either the EDI mapping or the condition technique with multiple ordering addresses are better options.

By using Transaction ME12 and entering the vendor and material number, you’ll arrive at the screen shown in Figure 4.25, which shows the Purch. Organization Data 1 menu where the Tax Code for a combination of vendor, material (or material group), and purchasing organization can be maintained. Be aware that tax codes found with condition techniques always have priority over tax codes found with purchase info records. To create new purchase info records, use Transaction ME11, and enter the vendor, material, and purchasing organization. Press (Enter) and click the Purch. Organization Data 1 button. Here, you can enter the Tax Code and other basic information such as the usual Incoterms for this transaction or the planned delivery time.

199

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.25 Purchase Info Record: Purchasing Organization Data 1

4.2.2 Purchase Order The purchase order is a central point in the indirect tax determination on the input side. Relevant transaction codes related to the purchase order are the creation of a purchase order (Transaction ME21N), the creation of a purchase requisition (Transaction ME51N), and the creation of a purchase contract (Transaction ME31K). Before creating a purchase order, you can create a purchase requisition to get an offer from a vendor. This purchase requisition may also already contain a tax code. If this is the case, the tax code is copied from the purchase requisition into the purchase order. Additionally, you can create a purchase contract over a certain time frame or value with a vendor. Purchase orders are then created with reference to the purchase contract.

200

4.2 Indirect Tax Determination in Purchasing

Warning! When copying an existing purchase order as a basis for a new purchase order, the tax code is also copied without redetermination.

A tax code is assigned on the item level in the purchase order. To reach the view in Figure 4.26, use Transaction ME21N, and enter the relevant purchasing information. Afterwards, you’ll see a dropdown menu on the bottom third of the screen with the items on your purchase order. Choose the item you want to review the tax determination for, and navigate to the Invoice tab. Here, you see the Tax Code field with the determined or manually entered tax code.

Figure 4.26 Tax Code on the Purchase Order

4.2.3 Invoice Posting When posting an incoming invoice in relation to a purchase order in Transaction MIRO, the tax code is copied from the purchase order as a suggestion value. This means that contrary to the output tax determination, it’s still possible to change this manually. After executing Transaction MIRO, you can navigate to the Tax tab, as shown in Figure 4.27. In the bottom of Figure 4.27, the reference to the purchase order is made via the purchase order number. This then copies over the tax code and calculates the tax amount.

Figure 4.27 Incoming Invoice in Transaction MIRO with Purchase Order Reference

201

4

Indirect Tax Determination in SAP S/4HANA

Using this suggested value from the purchase order on the incoming invoice posting greatly reduces the error rate on tax determination of incoming invoices. Employees booking these incoming invoices into the system no longer have to decide the tax matter based on the incoming invoice—which may often be very difficult and prone to errors. If the incoming invoice is different from the purchase order, changes can still be made.

Example You receive an invoice from a provider of construction services inside the EU. This is a very special case from an indirect tax perspective, which leads to a local reverse charge in the country where the construction services were provided. The received invoice will be without indirect tax, as you’re liable for indirect tax in this scenario. With tax determination on the purchase order, or through purchase info records, you can predetermine the correct tax code on this matter. Not using tax determination on the input side will very likely lead to errors in such a case.

4.2.4 Customization Scenarios There are several scenarios in the SAP standard that may require users to extend the standard functionality, depending on the relevant business transactions. In this section, we’ll briefly mention two scenarios where we often see extensions of the SAP standard during input tax determination. Note that these scenarios aren’t comprehensive, and there are many other cases that may call for a system enhancement based on the business transactions or the local regulations.

Differentiation of Private and Business Vendors In many jurisdictions, there is a difference between private individuals and businesses, as the businesses are taxable entities while private individuals aren’t. To automate such transactions, it’s necessary to differentiate between business vendors and private vendors, and multiple options are available to do so: 쐍 Natural person

Maintain the status in the master data of the business partner. In the overview of the business partner accessed via Transaction BP (partner role Business Partner (Gen.)), under General Data • Identification, the Natural Person (technical field LFA1-STKZN) checkbox can be selected to identify that this is a private individual and not a business. This field must then be integrated into the tax determination as it’s not considered in the standard. 쐍 Tax number validation

Check the tax number of the vendor during pricing on the purchase order. Usually, a private individual won’t have a tax number maintained while a business should

202

4.2 Indirect Tax Determination in Purchasing

have the tax number maintained. This can be managed by adding such a check in EXIT_SAPLMEKO_001 and extending the tax determination, for example, by populating the customer tax classification, which usually isn’t used in input tax determination. For more information on this customer exit, see Chapter 6, Section 6.3.2.

Warning! Both of these approaches depend strongly on the quality of vendor master data. If the tax ID of the vendor is inconsistently maintained or private individuals are categorized incorrectly, the tax determination will also deliver inconsistent results when using these indicators.

Example A car dealership buys new cars from other entrepreneurs such as car dealerships or car producers, as well as used cars from private individuals. Therefore, the car dealerships or car producers will sell the cars with indirect tax, while the private individuals won’t include indirect tax.

Purchase Orders with Nonmaintained Materials When buying products and posting incoming invoices, there isn’t always a material maintained in the system. In such a case, the standard tax determination via the condition technique won’t be a viable approach. Often, these transactions occur for self-use products such as stationery or consulting services. For resale products, a material should always be maintained. There are two options for such a case: 쐍 Use an SAP standard condition table

Use table A087 (Taxes: Plant, Account Assignment, Origin and Region) when the account assignment is detailed enough for the business case, for example, if there are different accounts and cost centers for services, self-use products, and other cases that may be relevant for the business. This decision must always be made on a case-by-case basis. Be aware that when using this condition table, it’s not possible to differentiate between products that are subject to different indirect tax rates. 쐍 Create a new condition table

Create a new condition table that includes the material group (technical field KOMPMATKL) as a key field. You can create a new condition table including the material group as a super category of certain materials. This solution also makes it necessary to maintain the material groups in the material master settings. The number of

203

4

Indirect Tax Determination in SAP S/4HANA

material groups applicable here must be assessed on a case-by-case basis, but there should be at least enough material groups to reflect the different relevant business scenarios.

Example A business buys tax consulting services, food for the office, and stationery without maintained materials, as these are all for self-use and not for resale. There should be one material group for services, reduced indirect tax rate products, and regular indirect tax rate products.

4.2.5 Solutions for Procurement SAP provides further products for procurement to consider, along with similar thirdparty products, during an SAP implementation. We’ll briefly introduce them in the following sections as they create tax-relevant data that is transmitted into the system in a standardized approach and offer support on tax-relevant processes such as incoming invoice processing.

Vendor Invoice Management Vendor invoice management (VIM), also known as OpenText, is the SAP solution for invoice management and processing. It’s integrable with the OpenText Invoice Capture Center for SAP solutions to enable optical character recognition (OCR) to automate the capture of paper invoices. Manual processing of incoming invoices is often a very time-consuming and errorprone effort. VIM strives to optimize and simplify the end-to-end accounts payable process. VIM offers a number of features: 쐍 Review and approval processes

The review and approval processes are supported by exception handling, reporting, and escalation functionalities. 쐍 Workflows

Workflows can be created to organize and track the processing of incoming invoices. 쐍 Routing and sorting

Workflow steps can be defined to sort and route invoices per user roles, authorization rules, or timelines. Exceptions and approval steps can also be routed according to workflow policies, and you can define rules for problematic invoices, which are then automatically classified and escalated. For touchless invoice management, automatic association to related purchase orders and historic documents or payment information is available.

204

4.2 Indirect Tax Determination in Purchasing

쐍 Reports

Reports can be generated based on several filter possibilities, such as region, business unit, or exception type. Analytics are also available on these reports, such as cause and effect diagrams. 쐍 Granularity

A graphic dashboard enables you to access either the overall view or individual system documents. 쐍 Location independent

Invoices can be entered into SAP from anywhere, simplifying the invoice management process. VIM stores all invoices in electronic form, regardless of the original format. 쐍 Status monitoring

Invoices are monitored within VIM to determine the payment process, issues with the invoice, and so on. VIM also supports vendor notifications and communication regarding invoice issues and further information requests.

SAP Ariba SAP Ariba is an overall procurement solution with many subproducts for both the supplier and buyer side. Briefly put, it provides centralization, automation, and analytics capabilities for all types of activities related to procurement, for example: 쐍 Guided buying

SAP Ariba provides a simple user interface with the purpose of supporting employees during their procurement process. With this interface, the employee is directed to preferred suppliers, can collaborate with suppliers and product experts, and is driven to follow the company’s purchasing policies. 쐍 Demand management

With SAP Ariba Supply Chain Collaboration for Buyers and SAP Ariba strategic sourcing solutions, you have functionality for demand management—or as they call it, strategic sourcing. SAP Ariba Sourcing can be used to develop a strategic sourcing plan while supporting sourcing events, procurement processes, and key project management activities such as document or resource management. You can identify qualified suppliers for your demand and compare the individual agreements with the goal of generating savings and a faster reaction time. Purchasing processes become centralized and standardized. There are many analytics functionalities to identify spending and saving or optimization opportunities. 쐍 Supplier management

Just like demand, suppliers can be managed. SAP Ariba provides three products here: SAP Ariba Supplier Information and Performance Management, SAP Ariba Supplier Lifecycle and Performance, and SAP Ariba Supplier Risk. Between these products,

205

4

Indirect Tax Determination in SAP S/4HANA

you have information on suppliers themselves and analytics on the spend, performance, and risk linked to them. SAP Ariba supports supplier due diligence, supplier lifecycle management (within SAP Ariba Supplier Lifecycle and Performance), and the comparison of customer capabilities and portfolios. 쐍 Supplier interaction (purchase agreements and invoicing)

SAP Ariba Contracts supports the management of procurement contracts and other agreements over the entire lifecycle. SAP Ariba Invoice Management provides automation for invoices based on purchase orders and invoices not based on purchase orders. Several tools, such as the received-invoice dashboard and automated exception handling, support your team with supplier invoices. SAP Ariba Discount Management is a tool to automate the discount process by connecting to the supplier, for example, for early-payment or pre-negotiated contract discounts. 쐍 Analysis

SAP Ariba Spend Analysis offers in-depth analytics capabilities of spend areas. Procurement and finance departments can use these analyses to understand the procurement operations and improvement areas. As you can see, a plethora of tools support you throughout the entire purchasing process, starting at finding a deal and the correct partner for it (SAP Ariba Sourcing, SAP Ariba Discovery, SAP Ariba Spend Analysis, SAP Ariba Supplier Lifecycle and Performance, SAP Ariba Supplier Risk and Performance), through signing a contract (SAP Ariba Contracts), managing the available products (SAP Ariba Catalog), purchasing goods and services (SAP Ariba Buying), and managing the invoicing process (SAP Ariba Invoice Management, SAP Ariba Discount Management).

Coupa and JAGGAER Alternatives for SAP Ariba, depending on your business requirements, can be Coupa, which is a platform for expense management, or JAGGAER, which is a supplier relation management tool. Coupa is a cloud-based spend management app. It offers dashboards, spending reports, and analysis, generally with the same purpose as SAP Ariba. You’ll have support along the entire procurement process, starting at planning activities such as expenditure or budgeting. It supports your supplier management with transaction processing and making the suppliers and their products more accessible. Coupa has functionality for inventory management and contract lifecycle management, together with analytics and documentation capabilities on the individual steps—providing clear audit trails. At the end of the procurement process, Coupa provides an invoice system following general international standards.

206

4.2 Indirect Tax Determination in Purchasing

In comparison with SAP Ariba, Coupa has a stronger focus on responsible spend management and visibility through analytics, while SAP Ariba is more focused on process improvement. Despite SAP Ariba being more popular due to its large network of suppliers and buyers, customer reviews indicate that Coupa runs a little more stable with less implementation overhead. SAP Ariba is also popular for the customizable workflows and customizable reporting that caters to a wide range of industries, while the most popular feature of Coupa is employee expense and invoice management. As a verdict, these two products both offer virtually the same features, usability, integrations, flexibility, and marked connectivity, so which product you choose depends on your personal preference. The JAGGAER spend management solution is a software as a service (SaaS) solution for direct and indirect e-procurement. As with SAP Ariba and Coupa, JAGGAER supports the entire accounts payable contract lifecycle with the goal of optimizing the source-to-pay process. It offers tracking and analytics capabilities for the full operational supply chain, including spend analytics to provide insights on saving opportunities. JAGGAER, like its two competitors, offers management of the contract lifecycle starting with supplier and sourcing management—how is the supplier performing, which sourcing options are available—up to the management of the contracts themselves. Demand planning is supported by e-procurement, which is digitally supported buying suggestions, tracking, and approval workflows. Creation, approval, and management of invoicing is possible in a touchless invoicing process, and inventory management is supported with stock tracking and purchasing compliance. When deciding on a solution, we recommend determining your most important areas of need as the first step. If your procurement process is relatively simple, you may be happier with a smaller solution such as JAGGAER. In contrast, if your procurement process is more complicated, you’ll likely find that SAP Ariba or Coupa will fit your needs better.

SAP Concur SAP Concur is SAP’s solution for expense management. It’s a cloud-based service that supports management of travel, expenses, and expense invoices. Within these three areas, SAP Concur offers several features: 쐍 Concur Travel

With Concur Travel, you’ll be able to support your traveling employees with comprehensive data for each traveler, location check-ins, online travel booking and comparisons, centralization of travel data and analysis of travel expenditures, and enforcement of travel policies. 쐍 Concur Expense

Concur Expense enables you to track all your expenses in one place. You and your employees can capture receipts—paper or digital—from multiple card types. Concur

207

4

Indirect Tax Determination in SAP S/4HANA

Expense enables you to reimburse your employees faster by allowing them to review, submit, and approve expense reports also via mobile. Finally, it also enforces spending policies. 쐍 Concur Invoice

Concur Invoice was created to speed up the invoicing process and reduce the costs related to it by reducing paperwork and duplicate or late payments, and e-mailing invoices. The benefits of SAP Concur are the elimination of paperwork and errors, as well as the centralized overview of compliance and cost related to travel and expenses. It makes the entire travel process easier, from the choice of travel booking to the submission of prepopulated expense reports, approvals, and increased travel compliance.

4.3 Indirect Tax Determination in Sales You’ve already learned about the condition technique in Section 4.1. Indirect tax determination in sales and distribution is always based on the condition technique. In this section, we’ll dive deeper into how exactly the condition logic works and how to validate the indirect tax determination.

4.3.1 Sales Order The first step for the sales process in SAP is the sales order. The sales order is a formal order of a customer that defines the transaction. Transaction codes related to the sales order start with VA: creation of a sales order (Transaction VA01), change of a sales order (Transaction VA02), and display of a sales order (Transaction VA03). For indirect tax determination, the following information is important: 쐍 Customer

Any validations of tax numbers are based on the customer. The customer covers two important data fields for indirect tax determination. You’ve already learned about the relevance of the VAT ID and the different business partner roles it can be determined from in Chapter 3, Section 3.2.2. These settings are applied in the sales order for indirect tax determination. Note that there is no visible determination of the tax identification number on the sales order. Nevertheless, the tax identification number and customer tax classification per the rules defined for the tax ID are considered during pricing on the sales order. However, the tax ID will only be visible on the invoice. The customer master data contains the information on the customer tax classification on the sales area level that we’ve covered in Chapter 3, Section 3.2.1.

208

4.3

Indirect Tax Determination in Sales

쐍 Ship-to address

The tax destination country is generally determined from the ship-to address. The ship-to address is the address the goods are delivered to. After executing Transaction VA01 and entering the sales order type, you’ll reach the screen shown in Figure 4.28. Here, the Sold-To Party, that is, the customer, and the Ship-To Party, that is, the recipient of goods, are the same entity. The delivery address is determined from the customer master data.

Figure 4.28 Sales Order Business Partner: Same Sold-To and Ship-To Parties

In comparison, Figure 4.29 has a different Sold-To Party and Ship-To Party. The delivery address is determined from the master data of the Ship-To Party.

Figure 4.29 Sales Order Business Partner: Different Sold-To and Ship-To Parties

Change of Addresses in the Sales Order Note that the addresses of all business partners involved can be changed by clicking the header icon and navigating to the Partner tab. This will be the address then used for the delivery address on the delivery note and for tax determination. 쐍 Supplying plant

The tax departure country as one of our most important indicators for both tax determination and indirect tax reporting is generally determined from the supplying plant on the item level. The supplying plant is the warehouse from which the goods are dispatched. You can see this field (Plnt) at the sales order line item level, as shown in Figure 4.30 on the far right. To navigate here, look a bit further down on your Transaction VA01 screen. These are the items on your sales order. 쐍 Material

The material is the product or service sold, as determined on the item level. The material tax classification that we covered in Chapter 3, Section 3.2.1 is important to determine the indirect tax rate of a certain product. The material tax classification is

209

4

Indirect Tax Determination in SAP S/4HANA

determined from the material master data. You can see this field (Material) in Figure 4.30 on the far left.

Figure 4.30 Sales Order Item Level

The indirect tax is determined based on these fields. You can view the details of the condition types determined for pricing on the indirect tax determination on the item level. To find the overview, double-click on the item, and choose the Conditions tab. Figure 4.31 shows the pricing elements of this particular example sales order. You can see the net price of 120 EUR, the calculated Output Tax of 19%, and the total amount in the Total Value line, including both the net price and the tax amount.

Figure 4.31 Sales Order Pricing Elements

On this Conditions tab, there is an Analysis button. This button leads to a detailed overview of all pricing elements inside the pricing procedure. Figure 4.32 shows the analysis of the pricing elements of condition type TTX1. You can see the two condition tables, of which the system found a matching condition record in step 010, table A002 (Domestic Taxes). When double-clicking onto this match in the Procedure column with the green box, it leads to the overview shown in Figure 4.33. At the top, you can see the condition record that was found with the tax departure country DE, customer tax classification (TaxClass1-Cust) 1, and material tax classification (Tax class. material) 1. Further down, you see the output tax amount.

210

4.3

Indirect Tax Determination in Sales

Figure 4.32 Sales Order: Analysis Indirect Tax Condition

Figure 4.33 Sales Order: Tax Determination Details

By marking the condition type line (CnTy) in the Condition Supplements section and clicking the magnifying glass icon on the top left of the screen, you can view the details of the determined output tax of the condition type, as shown in Figure 4.34. At the bottom, you’ll find the determined Tax Code on the position. Additionally, information is available on the condition amount and the validity period of the condition record. This is a good point to start your validation and error search if you ever have an incorrect indirect tax determination.

211

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.34 Sales Order: Details Tax Calculation

4.3.2 Invoice The invoice or billing document is the final step in the tax-relevant sales and distribution process. Generally, an accounting document is created from an invoice. From this accounting document, tax reporting is possible. Transaction codes related to the billing document start with VF: creation of a billing document (Transaction VF01), change of a billing document (Transaction VF02), and display of a billing document (Transaction VF03). There are two options to create an invoice: 쐍 Sales order-based invoices

These are created directly from a sales order. This makes sense for invoices that contain materials without delivery, for example, services. 쐍 Delivery-based invoices

These are created from a delivery. This makes sense for invoices based on materials that can be delivered, such as any type of tangible product. The process to create an invoice, as well as to view the invoice document type and how much information from pricing is taken directly from the sales order or delivery, is

212

4.3

Indirect Tax Determination in Sales

maintained in the copying control. To reach the configuration and related settings for the copying control, use Transaction SPRO, and follow menu path Sales and Distribution • Billing • Billing Documents • Maintain Copying Control for Billing Documents. If you know which copying control you want to view or edit, you can also use Transaction VTFA to define the copying control from the sales order to the billing document, or you can Transaction VTFL to define the copying control from the delivery note to the billing document. In Figure 4.35, you can see the copying control between a standard order with order type OR1 and a standard invoice with billing type F2 for a service item with item category TAD.

Figure 4.35 Copying Control Standard Order to Invoice for Service Item

In comparison, Figure 4.36 shows the copying control between a delivery note with delivery type LF and a standard invoice with billing type F2 for a standard item with item category TAN.

Figure 4.36 Copying Control of Outbound Delivery to Invoice for Standard Item

213

4

Indirect Tax Determination in SAP S/4HANA

The indicators on the bottom right are significant for indirect tax: 쐍 Billing Quantity

The billing quantity for the sales order to invoice copying control is based on rule A (Order quantity minus invoiced quantity). This means that the billing quantity—the quantity shown on the invoice—will be the amount that was on the sales order, minus what was already invoiced to the customer. In contrast, the billing quantity for the delivery to invoice copying control is based on rule B (Delivery quantity minus invoiced quantity). This makes sense because there can be multiple deliveries for one sales order—and multiple invoices per delivery. So, you may have a situation with, say, one sales order, two delivery notes, and four invoices—but never four sales orders and only one delivery. 쐍 Pos./Neg. Quantity

This determines the amount of the quantity. A negative quantity will be used, for example, if a sales order is created against a quotation: Any creation of such sales orders should reduce the quantity in the quotation. 쐍 Pricing Type

Both copying rules have rule G (Copy price elements unchanged and redetermine taxes). This is useful because the tax is always determined at the most recent time. For example, if there was a tax rate change between the date of sales order pricing and invoice creation, the correct tax rate would be applied to the billing document. This pricing type can also be found in the sales order and invoice itself under the Update field in the Conditions tab on both the item and header level. Using this field enables you to redetermine parts of pricing if a pricing-relevant value changed and pricing wasn’t redetermined automatically.

Example You’re using an enhancement to determine indirect taxes with respect to the Incoterm. In the SAP standard, pricing isn’t redetermined when changing the Incoterm. Updating pricing with pricing type G is necessary.

As mentioned in Section 4.3.1, the billing document contains the determined tax identification number. Figure 4.37 shows the determined VAT ID based on the tax destination country.

Figure 4.37 VAT ID on the Billing Document

214

4.3

Indirect Tax Determination in Sales

The rule for the determination of the VAT ID in this case is , so the VAT ID is determined from partner role A (Ship-to party). You learned about VAT ID determination rules in Chapter 3, Section 3.2.2.

Invoice Numbering In some countries, such as Argentina, Brazil, Italy, Portugal, and India, you’re legally required to follow specific rules regarding invoice numbering. For example, invoice numbers may need to be consecutive per the date and without gaps. SAP offers the standard official document numbering (ODN) functionality to handle such requirements.

4.3.3 Customization Scenarios As for the purchasing side, several scenarios on the sales side aren’t covered by the SAP standard. In this section, we want to make you aware of some of the most common cases for which we’ve designed system enhancements. Note that these scenarios aren’t comprehensive and there are many other cases that in which a system enhancement may be needed based on the business transactions or the local regulations.

Place of Supply of Services In many countries, services supplied from one business to another business are generally taxable at the place of supply, that is, the establishment of the customer receiving the service. In SAP standard, the tax destination country is determined from the shipto address (technical field KUWEV-LAND1). This is incorrect for the supply of services in those countries. An enhancement is required here to adapt the tax destination country. For businessto-business (B2B) services, the tax destination country should equal the country of the customer (refer to SAP Note 1406106). One option to achieve this is to overwrite the tax destination country with the country of the payer in case a service material is identified.

Warning! There are cases where goods and services are mixed on the sales order and billing document. The SAP standard approach is to split the billing document in such cases. Refer to SAP Note 1412947. The place of supply rules for services, and the application of enhancements for mixed orders should always be closely revised on a country-by-country basis.

215

4

Indirect Tax Determination in SAP S/4HANA

Transport Responsibility in Tax Determination In chain transactions inside the EU or for cross-border transactions where the customer is responsible for the export, the transport responsibility is often a factor to be considered to determine the correct indirect tax. There are multiple fields in SAP that describe transport responsibility, for example, the Incoterm or the shipping condition. You can include these in the indirect tax determination either via code inside a user exit, or via a new condition table that is then added to the access sequence. Adding a transport responsibility indicator to the indirect tax determination enables you to differentiate between cases where you’re responsible for the export and cases where the customer is responsible for the export. This makes it possible to apply different tax codes for these scenarios. In the example, we’re using the Incoterm. However, there may be other indicators for transport responsibility that are more useful for your business.

Example You have business transactions where you export goods from Australia and transactions where Australian customers pick up the goods in Australia and export them. You identify the transport responsibility on the Incoterm: deliveries have Incoterm DAP, pickups have Incoterm EXW. In the first case, you can apply 0% GST. In the second case, the application of 0% GST is only possible if the customer isn’t registered for GST in Australia. Therefore, you add the Incoterm to your indirect tax determination.

Invoice Texts Many jurisdictions require the taxpayer to describe why they haven’t applied indirect tax on a transaction. The rules are very different between countries, but we strongly recommend taking the invoice texts into account when thinking about invoice forms. We recommend creating a mapping for an invoice text per tax code. With this, the correct invoice text can be printed on the invoice automatically. This isn’t standard functionality and is usually done via a Z-table that is accessed during print processing (see Chapter 6 for more information on Z-tables).

Example You apply 0% VAT on an intra-community supply of goods inside the EU. For this transaction, you must describe why you applied 0% VAT and choose the description “VAT exempt intra-community supply of goods” to be printed on the invoice.

216

4.4 Special Indirect Tax Transactions

Location-Based Supplies and Services In some jurisdictions, certain supplies and services are taxable at the location they are provided. Some examples are construction services, fairs, or events (not a comprehensive list). In these cases, the place of supply and therefore the tax destination country must be adapted during pricing. There are several options to solve this. As these are materialbased changes to the indirect tax determination, we generally recommend creating a new material tax classification for such cases. Based on this material tax classification, the tax destination country can be changed in the applicable user exit.

Example You’re a construction provider that specializes in resorts. Recently, you have won a project to build a large hotel in the south of France. You’re currently not registered for VAT in France and will need to register, as the construction service is taxable where it’s provided, that is, in France. Your tax departure country for these construction services is France. Another department currently advises a French customer on their resort management. This is a standard B2B service, which is VAT-exempt in your residence country Sweden and taxable as a reverse charge purchase of services in France by the French customer. Your tax departure country here is Sweden. You’ll need to differentiate your tax determination between these cases, for example, by using different material tax classifications.

4.4 Special Indirect Tax Transactions This section will cover special SAP processes for specific indirect tax requirements. We’ll focus on chain transactions, internal stock transfers, and special payment processes, such as down payments, billing plans, self-billing, and discounts.

4.4.1 Chain Transactions/Drop Shipments Chain transactions, also often called drop shipments, are a special case from an indirect tax perspective. Generally, such drop shipments can be described as transactions where three or more entrepreneurs enter a supply of goods where the goods are delivered directly from the first entrepreneur to the last entrepreneur in the chain. Figure 4.38 shows a schematic overview of such a transaction.

217

4

Indirect Tax Determination in SAP S/4HANA

1st Entrepreneur

Invoice

2nd Entrepreneur

Invoice

3rd Entrepreneur

Goods Movement

Figure 4.38 Chain Transaction

In such a transaction, there are three possible positions where your company may be: first entrepreneur, second entrepreneur, or third entrepreneur. We’ll discuss each in the following sections.

Drop Shipments Globally Almost every jurisdiction applies different rules on drop shipments: only taxing one of the supplies, only taxing the recipient of the goods, or applying place of supply rules. We’ll include some examples next, but it’s important to understand the requirements of the jurisdictions you’re implementing drop shipments for.

First Entrepreneur As the first entrepreneur in a chain transaction, your supply of goods is generally to the second entrepreneur—this is your customer. This means that you would need to be made aware that the transaction you’re in is a chain transaction rather than a different delivery address for your customer. Being aware that you’re in a chain transaction is especially important for cases where the goods are being exported by a party in the chain that isn’t yourself. For example, the third entrepreneur may be responsible for the export. To apply an exemption from indirect tax, also called zero percent indirect tax, many jurisdictions require that either the export is made by the first entrepreneur in the chain or that the receiving party isn’t resident of the departure country.

Example An Australian company (first entrepreneur) selling goods to a customer outside of Australia (second entrepreneur) can apply 0% indirect tax on this transaction if either the Australian company is responsible for the export or the party responsible for the export isn’t a resident of Australia. If a third entrepreneur who is a resident of Australia was responsible for the export, domestic indirect tax should be applied.

218

4.4 Special Indirect Tax Transactions

The EU applies special treatment of chain transactions in many ways: In a cross-border chain transaction, 0% VAT can only be applied to one supply within that chain. The general rule is that the exemption is ascribed to the party responsible for the transport. If the first entrepreneur in the chain is responsible for the transport, they can apply the exemption. If the second entrepreneur is responsible for the transport, they can choose which transaction they want to apply the exemption to.

Example A German company (second entrepreneur) receives an order from a French customer (third entrepreneur). They don’t have the goods in stock and order them from another German company (first entrepreneur). If the first entrepreneur was responsible for the transport, they would have a VATexempt intra-community supply of goods, and the second entrepreneur—who is a German company as well—would have to register for VAT in France, as they have an intracommunity acquisition there. If the second entrepreneur is responsible for the transport and indicates this by using its German VAT ID in the purchase from the first entrepreneur, they have a domestic purchase of goods in their residence country, followed by an exempt intra-community supply. If the example was the other way around, and our second entrepreneur was a French company, it would make sense to attribute the exemption to the transaction between the first and second entrepreneurs. In that case, our second entrepreneur would have an intra-community acquisition in France, followed by a domestic supply of goods.

If the third entrepreneur inside an intra-community chain transaction is responsible for the transport, the first entrepreneur must apply domestic VAT on their transaction because the exemption is attributed to the third entrepreneur. Let’s consider how this works in SAP S/4HANA. As the first entrepreneur, you’re the first entity in the chain transaction. This means that your sold-to party and ship-to party will be two different entities. The sold-to party is the second entrepreneur, the middleman in the transaction. The ship-to party is the third entrepreneur, the final recipient of the goods. Figure 4.39 shows an example of a sales order with different sold-to and ship-to parties. Refer to Section 4.3.1 for more information on the sales order.

Figure 4.39 Chain Transactions: First Entrepreneur

219

4

Indirect Tax Determination in SAP S/4HANA

Second Entrepreneur As the middle party in a chain transaction, you’re usually aware that you’re inside a chain transaction. For multiple-country chain transactions, this is usually a beneficial situation to be in: Oftentimes, no reporting requirements or tax are applicable to your transaction, as the goods never reach your country of residence. The first entrepreneur can be responsible for the export from the country of departure, and the third entrepreneur can be responsible for the import (and corresponding duties and import taxes) in the country of destination. We want to bring your attention to two special cases: 쐍 Drop shipments inside the United States

In a drop shipment transaction within the United States, the second entrepreneur (retailer) is generally responsible for the collection of sales and use tax. However, if the second entrepreneur isn’t a resident (i.e., doesn’t have a nexus) in the third entrepreneur’s (buyer’s) state, it’s possible that the first entrepreneur (supplier) may be held liable for the sales and use tax collection on the transaction if they have a nexus in the state. Alternatively, a nexus may be asserted to the second entrepreneur who isn’t from the state of destination under the flash title theory: As the retailer is owner of the product sold for a brief moment before it’s sold on to the final customer during the transaction, they have a presence in the state. 쐍 Triangulation simplification (ABC transactions) inside the EU

In this special case, three entrepreneurs are involved in an EU triangular deal. This type of deal is fulfilled if three legal entities enter a contract considering one supply, this supply is directly from the first supplier (first entrepreneur) to the last customer (third entrepreneur), the legal entities are registered for VAT in three different EU member states, the goods are transported from one EU member state to another, and the goods are transported by either the first supplier (first entrepreneur) or the first customer, second entrepreneur). Under this simplification, the second entrepreneur in the chain isn’t obligated to register for VAT in the state of departure or destination. The process of booking chain transactions in SAP S/4HANA isn’t entirely straightforward. This is due to the separation of the sales and distribution module and the materials management module, which requires the creation of an interface between the two. The third-party process (i.e., the delivery of goods not by the sales organization, but rather by an external vendor) begins with the customer ordering goods and the creation of the sales order. A purchase requisition is automatically created when the sales order is saved. A purchase order to the vendor is then created based on the purchase requisition. The vendor delivers the goods to the customer, and an invoice is created (received from the vendor). Finally, an invoice to the customer is created (the orderrelated invoice).

220

4.4 Special Indirect Tax Transactions

Now, let’s walk through the steps to create a third-party order: 1. Create a sales order The third-party process is triggered by creating a sales order with a third-party item. This third-party item has a special item category that can either be assigned manually directly in the item of the sales order or can be determined automatically via the material master data and item category determination. For details on how to reach the material master data settings, refer to Chapter 3, Section 3.2.1. If you go to the Sales: sales org. 2 tab, as shown in Figure 4.40, you can see the Item Category Group, which will be used for the item category determination.

Figure 4.40 Chain Transactions: Second Entrepreneur Material Settings

The item category determination for third-party items should be predefined in SAP. To reach the item category determination, use Transaction SPRO followed by menu path Sales and Distribution • Sales • Sales Documents • Sales Document Item • Assign Item Categories. You’ll arrive at the screen shown in Figure 4.41. On this screen, you can see the sales order type (SaTy), the item category group (ItCGr), and the possible item categories for this combination.

Figure 4.41 Chain Transactions: Second Entrepreneur Item Category Settings

When entering an item with item category group BANS in the sales order using Transaction VA01, item category TAS will automatically be determined, as shown in Figure 4.42.

221

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.42 Chain Transactions: Second Entrepreneur Step 1

2. A purchase requisition is automatically created After saving the sales order, a purchase requisition is automatically created. To see the purchase requisition number, double-click on the item with item category TAS, and go to the Schedule lines tab, as shown in Figure 4.43. On the right side, you’ll see the number of the purchase requisition created (Purchase column). Take note of this number.

Figure 4.43 Chain Transactions: Second Entrepreneur Step 2

Schedule Line Categories This purchase requisition is automatically created through schedule line category CS. The schedule line defines which information of the sales order to copy and what to do with it. Schedule line category CS contains information about the purchase requisition that is to be created. SAP standard schedule line category CB, for example, contains information about the relevance for goods movement and deliveries for normal items. To reach the maintenance of schedule line categories, go to path Sales and Distribution • Sales • Sales Documents • Schedule Lines • Define Schedule Line Categories in the SAP configuration menu.

3. Create a purchase order Based on this purchase requisition, we now want to create a purchase order. This purchase requisition is the connection between sales and distribution and materials management. You can create the purchase order automatically by using SAP standard item category group ALES instead of BANS. To create a purchase order, go to Transaction ME21N. On the left side of the screen, click the tree, and choose Purchase Requisitions, as shown in Figure 4.44. In the following screen, as shown in Figure 4.45, enter the Purchase Requisition Number from your sales order, and click the Execute icon on the top left.

222

4.4 Special Indirect Tax Transactions

Figure 4.44 Chain Transactions: Second Entrepreneur Step 3, Part 1

Figure 4.45 Chain Transactions: Second Entrepreneur Step 3, Part 2

Your purchase requisition will appear in the document overview of the purchase order, as shown in Figure 4.46. Click the Adopt icon (two squares icon) to copy the data over into the purchase order. This creates a connection between the sales order and purchase order via the purchase requisition.

Figure 4.46 Chain Transactions: Second Entrepreneur Step 3, Part 3

223

4

Indirect Tax Determination in SAP S/4HANA

Potentially, you already have a maintained standard vendor for this third-party order. If not, enter the vendor, and save your purchase order. 4. The vendor delivers the goods to the customer This happens outside of your own SAP system. Although it’s not necessary, you can link this process to a goods receipt inside your own SAP system via an inbound delivery with Transaction VL31N. 5. Invoice receipt After receiving the invoice from your vendor, you’ll enter this invoice in the system with a reference to the purchase order. We often see a process for automatic processing of incoming invoices with OCR implemented. For the purpose of demonstration and to manually enter an incoming invoice, use Transaction MIRO. In the Basic Data tab, entering the purchase order under PO Reference, as shown in Figure 4.47, enables you to copy over all relevant data, including the determined tax code on the purchase order.

Figure 4.47 Chain Transactions: Second Entrepreneur Step 5

6. Create and issue a customer invoice Only after posting the incoming invoice is it possible to issue a customer invoice based on the sales order. To create the invoice, use Transaction VF01. Enter your sales order number into the Document field, as shown in Figure 4.48, and press (Enter). Save your invoice by clicking the Save button at the bottom of the screen.

224

4.4 Special Indirect Tax Transactions

Figure 4.48 Chain Transactions: Second Entrepreneur Step 6

Third Entrepreneur As the third entrepreneur, a chain transaction is only a normal input transaction. This means that you’ll have the documents relating to a purchase: potentially a purchase order, a goods receipt, and an incoming invoice.

Best Practices for Indirect Tax As you’ve learned, there are significant differences for indirect tax determination with chain transactions depending on the jurisdiction. Therefore, the respective requirements should always be gathered before beginning the implementation. After gathering the requirements, certain issues repeat themselves in practice, mostly relating to transport responsibility or to the residence of the parties involved. Let’s walk through them: 쐍 Transport responsibility

SAP doesn’t offer a set indicator determining which party has transport responsibility in the transaction. In practice, we often see clients using the Incoterm as an indicator for transport responsibility. Incoterms (stands for international commercial terms) are a worldwide standard for describing terms and transport obligations relating to the sales of goods. If used correctly in a business, they can be a good indicator for the transport responsibility of the parties in a transaction. Incoterms can be included in a custom condition table to take them into account during tax determination. 쐍 Residence of involved parties

As mentioned in an example earlier, the residence of the exporting party—if the first entrepreneur in the chain isn’t the one responsible for the export—is oftentimes relevant. In SAP standard, the indirect tax determination only considers the countries of departure and destination as parameters. To include the residence of the involved parties in indirect tax determination, the respective communication structures for indirect tax determination (KOMKAZ, KOMPAZ) must be extended with the new field and must be populated during pricing. Then,

225

4

Indirect Tax Determination in SAP S/4HANA

you can use the residence of the involved parties in indirect tax determination. This can be done, for example, via a custom condition table or Z-table that overwrites the tax destination country with the tax departure country to achieve the application of domestic indirect tax. For more information, see Section 4.1.4 and Chapter 6, Section 6.2.1. 쐍 Distribution channel

In practice, we’ve seen clients using separate distribution channels to differentiate between drop shipments and direct sales. The distribution channel is a functionality from the sales and distribution landscape and not necessarily meant for tax. However, it’s still possible to leverage such a separate distribution channel for indirect tax determination. For example, it can be used in combination with transport responsibility where a certain distribution channel shows that the transaction is a chain transaction. 쐍 Proof of delivery

In many countries, a proof of delivery document is required to prove that a supply was indeed delivered. Sometimes, as in the EU, this document is relevant for the tax exemption of a transaction. You may also get an automatic verification and confirmation via the SAP standard proof of delivery process. This requires integration with the ship-to-party via IDocs (other SAP system) or an internet interface. 쐍 Cross-company sales

A cross-company transaction in SAP S/4HANA involves more than one company code. This is usually the case when more than one legal entity exists in the SAP organization structure. Several cross-company transactions are possible, but we’ll focus on cross-company sales. As an example, think about an organization where a sales entity in the United States (selling entity) purchases goods from a production entity in China (fulfilling entity), which are to be delivered to a customer in Europe (end customer), as shown in Figure 4.49. First, the order of the end customer in Europe is received by the system: the customer orders goods from the entity in the United States. This United States entity doesn’t have the product in stock, so it forwards this order to the production entity in China to fulfill this order. In practice, this is achieved by simply entering the plant of a different company code in the order. Therefore, the plant of the company code in China is the fulfilling plant. After the delivery, the entity in the United States invoices to the end customer. Finally, the Chinese company code invoices to the United States company code within a process called intercompany billing. In a crosscompany sale, there are always two invoices.

Warning! The standard pricing procedure for intercompany billing is different. Be sure to include the condition types for tax in the intercompany pricing procedure.

226

4.4 Special Indirect Tax Transactions

Company Code China

Company Code USA

Sales Order

Customer in Europe

Order

Delivery

Invoice

Intercompany Billing

Figure 4.49 Cross-Company Sale

As you’ve already learned in Section 4.1, tax determination usually uses the country of the plant as the tax departure country and the country of the ship-to address as the tax destination country. This isn’t the case in intercompany billing! Here, the tax departure country is determined from the address of the supplying company code and the tax destination country per the country of the maintained internal customer’s address. This isn’t always correct and should be assessed on a case-by-case basis. In the example, the standard setting would lead to a determination of import tax in the United States, even though the goods never enter the United States. If this entire transaction was within the EU, the standard setting would lead to even more issues. SAP offers guidance for this issue in SAP Note 10560 and provides two suggestions. First, you can use the country of the plant instead of the country of the company code as the tax destination country. Second, you can use the country of the ship-to party from the order instead of the country of the internal customer as the tax destination country. The SAP Note is only a consulting note, which needs to be implemented from a technical perspective.

4.4.2 Internal Stock Transfers Companies with multiple plants usually need to shift stock between them. The term stock transfer refers to the purely logistical movement of a company’s own goods within the company. From a tax perspective, however, these supposedly straightforward transactions present complex tax pitfalls that need to be assessed from a transfer pricing, corporate income, and VAT/sales tax perspective. The fundamental question at heart here is the taxability of transactions within a consolidated group (i.e., the legal entity).

227

4

Indirect Tax Determination in SAP S/4HANA

Prerequisites for Internal Stock Transfers In SAP S/4HANA, the stock transport order (STO) process is used to manage these transfers. Two types of processes are generally to be distinguished here: 쐍 Intracompany stock transfers

These transfers are used to move stock between plants of the same company code. 쐍 Intercompany stock transfers

These transfers are used to move stock between plants of different company codes. The prerequisite for both processes is to define the supplying and receiving plant as vendor and customer, respectively, in the business partner master data. Note that it’s necessary to define a business partner first. In the example in Figure 4.50, you can see such a business partner in Transaction BP. The naming usually includes a reference to the company code, or at least the plant. For this business partner, a customer and a supplier must be created.

Figure 4.50 Business Partner for Plant

The newly created internal customer must then be assigned to the receiving plant in the purchasing configuration under path Material Management • Purchasing • Purchase Order • Set Up Stock Transport Order • Define Shipping Data for Plants. In the overview, choose the plant you want to assign the customer data to. In the next screen, shown in Figure 4.51, you can enter the internal customer number of the plant into the Customer No. Plant field.

Figure 4.51 Assign Customer Number to Plant

228

4.4 Special Indirect Tax Transactions

Similarly, the internal vendor must be linked to the dispatching plant. This is done in the Vendor: General Data tab directly in the business partner settings for role Supplier, as shown in Figure 4.52.

Figure 4.52 Assign Plant to Internal Supplier

In the SAP standard, two purchase order document types are delivered for these transactions: UB for intracompany STOs and NB for standard purchase orders for intercompany STOs. The maintenance of purchase order document types can be reached through the SAP configuration menu path Materials Management • Purchasing • Purchase Order • Define Document Types. You’ll arrive at the screen shown in Figure 4.53, where you can view, edit, or create the purchase order document types. If required, a dedicated custom document type for STOs could also be set up here by clicking the New Entries button. If no special requirements exist, the item interval (ItmInt.) can be kept in steps of 10 and the number range assignment for internal and external documents (NoRgeInt and NoRge Ext) can also be kept within the standard number range.

Figure 4.53 Purchase Order Document Types for Stock Transfers

You can navigate to Allowed item categories, as shown in Figure 4.54. The item categories assigned to the document types control the billing relevancy of the purchase order. Intracompany stock transfers in the same country are in the SAP standard and are usually assigned item category U, as the single entity principle applies, and the transfer is therefore a nonbilling-relevant logistics process. The single entity principle means that the goods remain within the same legal entity and aren’t sold to another company. This is one of the core pitfalls for indirect tax. It’s very important to differentiate between stock transfers within the same legal entity that are generally not taxable and only

229

4

Indirect Tax Determination in SAP S/4HANA

potentially subject to import procedures, and stock transfers between different legal entities (generally different company codes) that must be treated similarly as a sale to an external customer.

Figure 4.54 Item Categories for Stock Transfers

In menu path Material Management • Purchasing • Purchase Order • Set Up Stock Transport Order • Configure Delivery Type & Availability Check Procedure by Plant, the delivery types and checking rules must be assigned to the combination of purchasing document type and supplying plant. In Figure 4.55, you can see the configured purchase order types (Ty.): NB for standard purchase orders without a delivery type assigned, NB2 for returns, and UB for STOs with delivery type NL in column DlTy. for internal stock transfers. These also have a checking rule (CRl) assigned that checks the availability of stock from the supplying plant, and they have shipment scheduling (Sh...) active as the goods will be scheduled for delivery.

Figure 4.55 Configure Delivery Type for STOs

In the SAP standard, there are two different delivery types available: NL (Replenishment Dlv.) for stock transfers within the same company code and NLCC (Replen.Cross-Company) for generally billing-relevant stock transfers between company codes. Generally, the document type UB is used with delivery type NL and checking rule B (SD Delivery), while for document type NB, delivery type NLCC is used. Furthermore, each combination of supplying and receiving plant with a default document type (UB or NL) can be maintained under the path Material Management • Purchasing • Purchase Order • Set Up Stock Transport Order • Assign Document Type, OneStep Procedure, Underdelivery Tolerance. In Figure 4.56, purchase order type UB is assigned for the combination of supplying plant 1010 and receiving plant 2010, both

230

4.4 Special Indirect Tax Transactions

within the same company code. Be careful not to assign UB for cross-company stock transfers.

Figure 4.56 Default Document Type for Stock Transport Orders

One-Step Option The One-Step option generates both the goods issue and receipt documents simultaneously. If the One-Step checkbox is deselected, the goods issue and receipt have to be posted manually, however, the goods can be tracked in transit.

Stock Transfers in SAP S/4HANA Cloud In SAP S/4HANA Cloud, no standard procedure is available to cover intercompany stock transfers. To do so, scope item 1P9 needs to be activated.

To be able to create an outbound delivery from your STO, the copying control must be maintained. To reach the copying control for STO to delivery, use the SAP configuration menu path Logistics Execution • Shipping • Copying Control • Specify Copying Control for Deliveries. In the Header section of the screen, as shown in Figure 4.57, the copying control should automatically be set up for the combination of DL (Order Type Sched.Ag.) (STO) to NL and NLCC.

Figure 4.57 Copying Control STO to Delivery

Create a Stock Transport Order To post an internal stock transfer, start with creating a STO via Transaction ME21N. As document type in the upper-left dropdown, choose Stock Transp. Order. After making this choice, the view will change and you’ll find several new fields, for example, the Vendor field has changed to Supplying Plant. In Figure 4.58, you can see the minimum input details that are required: the Supplying Plant on the very top (here, 1010 Plant 1 DE); the purchasing and material data, as you would also enter in a standard purchase

231

4

Indirect Tax Determination in SAP S/4HANA

order; and finally the receiving plant in the Plant field on the bottom-right corner (here, Plant 1 CZ). Depending on the settings and requirements in your system, it may also be useful to enter the supplying and receiving storage locations.

Figure 4.58 Create STO

Shipping Tab Note that you’ll only be able to create an outbound delivery in the next step if your configuration is correct and there is now a Shipping tab on your STO. If this tab isn’t available, recheck the assignment of customer and vendor to the plants, and check the settings mentioned previously.

Create an Outbound Delivery After saving the STO, go to Transaction VL10B to create an outbound delivery from this STO in materials management. You have several filtering possibilities, as shown in Figure 4.59, if there are many purchase orders displayed. If your STO isn’t displayed, check the delivery date and also the CalcRuleDefltDlvCrDt field. The default setting is 2 (Due for Shipment Today and Tomorrow). If your delivery date isn’t within these dates, you can set it to blank.

Figure 4.59 Transaction VL10B: Create Delivery from STO

Click Execute (not shown) to reach the list in Figure 4.60. Then, select your STO, and click Background to execute.

232

4.4 Special Indirect Tax Transactions

Figure 4.60 Transaction VL10B: Creating Delivery from STO

After the processing has finished, you’ll see a second line with a green light, as shown in Figure 4.61.

Figure 4.61 Transaction VL10B: Success

You can find the number of your created outbound delivery by going back to your STO and checking the Purchase Order History tab, as shown in Figure 4.62. Your outbound delivery number will appear above the yellow banner; here, it’s 8000017.

Figure 4.62 STO: Purchase Order History Tab

233

4

Indirect Tax Determination in SAP S/4HANA

From here, follow your standard outbound delivery process with a goods issue and your standard inbound delivery process with a goods receipt. You can see your change in stock for the supplying and receiving plants, for example, via Transaction MMBE.

Billing-Relevant Scenarios After the goods receipt, there are some scenarios that may be billing relevant. This is especially the case if you have stock transfers inside the EU and have plants abroad activated, or if you have stock transfers between different company codes. A deliveryrelated billing document can be created for those cases. This is the next large pitfall for internal stock transfers, as this process can be rather complex and the importance for indirect tax is often underestimated. The delivery-related billing document for internal stock transfers has billing type WIA, while the billing document for intercompany stock transfers is an intercompany billing with billing type IV.

Intra-Community Stock Transfers within the EU Intra-community stock transfers inside the EU, with the introduction of the internal market in 1993, were equated with an intra-community supply. This leads to a definitive charge of VAT in the country of destination. To accommodate this in SAP S/4HANA, there is a separate pricing procedure RVWIA1 that becomes relevant once you activate plants abroad (for details, refer to Chapter 3, Section 3.1.3). This pricing procedure— apart from the price—also contains three condition types relevant for tax: WIA1, WIA2, and WIA3. As you can see in Figure 4.63, these three condition types have different purposes. To provide some context, the concept of intra-community sales and acquisitions relating to the transfer of own goods between EU member states works as follows: If all requirements are met, the intra-community supply of goods—so the movement outside of the country of departure—is VAT-exempt. The supply from the tax departure country, that is, the output tax in the country of departure, is represented by condition type WIA2.

Figure 4.63 Pricing Procedure RVWIA1 for Stock Transfers inside the EU

234

4.4 Special Indirect Tax Transactions

Once the goods have arrived in the country of destination, two things happen: the acquisition of goods must be reported in the VAT return as an intra-community acquisition of goods, and this acquisition is also subject to input tax deduction at the same time. Therefore, we have two condition types for the input side: WIA3 for the intra-community acquisition and WIA1 for the deduction of the input VAT on the intra-community acquisition. These should usually have the same percentage and tax code, therefore negating each other.

4.4.3 Special Payment Processes Several special payment processes can be reflected in SAP S/4HANA and have an impact on indirect tax and indirect tax determination. We’ll be looking into down payments, the concept of the billing plan, self-billing, rebates and discounts, and also kit supplies.

Down Payments The recipient of the goods doesn’t always pay in full after receipt of the respective goods or services. For large investments, down payments or prepayments are often agreed. From an indirect tax perspective, the tax point is often the time where the prepayment is received. Nevertheless, the respective regulatory requirements for the tax point should always be validated on a country-by-country basis. In SAP, the down payment process (see Figure 4.64) begins with an order being placed by a customer, which is then created as a sales order. Based on this sales order and the agreed down payment amount, a down payment request is issued. In practice, it’s unusual to receive down payments without an official request. However, if you receive a down payment without issuing a deliberate down payment request (e.g., the request is issued via the order confirmation), you can skip this step. After the customer pays the amount requested via the down payment request, a down payment receipt is created.

Vendor

Customer

Sales Order

Order

Down Payment Request

Down Payment Issue

Down Payment Receipt

Figure 4.64 Down Payment Process in SAP S/4HANA

235

4

Indirect Tax Determination in SAP S/4HANA

To begin the configuration, check whether your system already has a general ledger account for down payments with Transaction OBXR or menu path Financial Accounting • Accounts Receivables and Accounts Payable • Business Transactions • Down Payment Received • Define Reconciliation Accounts for Customer Down Payments. The list should look similar to Figure 4.65.

Figure 4.65 Special General Ledger List

If the desired account isn’t available, create an alternative reconciliation account for down payments via Transaction FS00. You’ll arrive at the screen shown in Figure 4.66, where you can view or change the settings for your down payment account. Setting the Recon. Account for Acct Type to Customers is especially important here. Notice how this down payment account has a special Tax Category of +B (Output tax – down payments managed gross). This means that only output tax is permitted, as this is a customer down payment that may be subject to indirect tax. Additionally, this lets the system know that the document is a down payment that must be processed in a special way. While down payments may be subject to tax in some countries, they may not be subject to tax in others. Therefore, to avoid errors, the checkbox for Posting without tax allowed is also checked.

Figure 4.66 Down Payment Account

Then, a link must be created between the standard reconciliation account and the new account. For this, go back to Transaction OBXR, and double-click on the special general ledger account you just created. After creating this link, in the example in Figure 4.67,

236

4.4 Special Indirect Tax Transactions

the standard account 12100000 will be used for normal payments against an invoice. For down payment receipts, special general ledger account 21190000 will automatically be used when selecting special general ledger indicator A. Save your changes by clicking the Save button on the bottom-right corner.

Figure 4.67 Link Down Payment Account to Standard Account

The down payment request itself is created via Transaction F-37. As shown in Figure 4.68, set the document Type to DZ (Customer Payment) and the special general ledger indicator (Trg.Sp.G/L Ind.) to F (Down Payment Request).

Figure 4.68 Create Down Payment Request

After pressing (Enter), you’ll reach the screen shown in Figure 4.69. Here, you enter the down payment Amount and the Tax Code. Select the Calculate Tax checkbox to automatically and correctly calculate the tax amount and populate the Tax Amount field. Enter the due date for the down payment. You can link an existing sales document on this screen by adding the sales document into the Assignment field (not shown).

237

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.69 Enter Down Payment Request Details

Warning! This is a manual process that may be prone to errors. Checking the Calculate Tax checkbox is imperative for the posting, as this calculates the correct tax amount per the tax code. However, there are also possibilities to link the tax code determination to the sales order as condition-based down payments. For details, refer to SAP Note 1788841.

After posting the down payment request by clicking the Post button in the bottomright corner (not shown), a down payment receipt can be posted. This is possible via Transaction F-29, as shown in Figure 4.70.

Figure 4.70 Create Down Payment Receipt

238

4.4 Special Indirect Tax Transactions

Here, the same document Type is used. The document has Special G/L Ind A (Down Payment) instead of F (Down Payment Request). You’ll also need to enter the company code, currency, document date, customer account, down payment amount, and the general ledger account for the bank the amount will be posted to. If you want to connect the down payment receipt to an existing down payment request, don’t press (Enter); use the Requests button at the top instead. This will lead you to the view shown in Figure 4.71. On this screen, choose the down payment request you created, and click on Create down payments.

Figure 4.71 Link Down Payment Receipt to Down Payment Request

You can add further information by double-clicking on the item (see Figure 4.72), or you can post directly by clicking the Post button in the bottom-right corner (not shown).

Figure 4.72 Down Payment Receipt Details

When looking at the posted financial accounting document, as shown in Figure 4.73, you’ll see four lines relating to the down payment request and the related settlement, as well as its respective output tax—that is, the receipt of the requested payment.

239

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.73 Down Payment Receipt: Financial Accounting Document

Warning! In some countries, it’s required to issue a tax-relevant invoice at the time of down payment receipt. As the down payment process in SAP is located entirely in financial accounting, several complications must be considered in this case. Naturally, the first issue is the creation of a sales and distribution document from financial accounting. Additionally, the invoice numbering ranges must be taken into account so that no two invoices with the same number can be created.

In practice, a delivery block is often put in place until a down payment for the order is received. After the receipt of the down payment, this block can be removed, and the outbound process can be continued as usual.

Billing Plan Another special payment process is milestone billing or periodic billing. While this process has some similarities to down payments and can also be used for this purpose, there are some differences: Down payments as described in the previous section only exist in the financial accounting functionality. For milestone billing and periodic billing, a functionality called billing plan is used. This functionality is part of sales and distribution. The billing plan is a schedule of delivery-independent billing dates for the supply of goods and services. Milestone billing, as the name suggests, schedules the total amount to be billed in predefined intervals. This is often used for large, long-term projects. A good example is the construction industry, where certain milestones equal a predefined partial delivery of a final product. In periodic billing, a certain amount is billed at regular time intervals—such as rent, licenses, or leasing.

240

4.4 Special Indirect Tax Transactions

Important settings for the billing plan include the following: 쐍 Billing plan type

The billing plan type includes the control data for the billing plan, such as the determination of start and end dates for the billing schedule. 쐍 Date category

The date category defines additional data for the billing date of the billing plan, for example, the billing rule, date description, billing block, whether a billing date is fixed, and the billing type. The SAP standard contains the two billing plan types mentioned previously: milestone and periodic billing. To reach the setting for the billing plan, use Transaction SPRO followed by path Sales and Distribution • Billing • Billing Plan • Define Billing Plan Types. In the popup, choose the billing plan type you want to edit. In the example, we’re looking at the billing plan type for milestone billing. Double-click the billing plan type you want to maintain or create a new billing type by clicking the New Entries button. On the screen shown in Figure 4.74, you can check the settings of billing plan types, date descriptions, date categories, and date proposals, as well as define rules for date determination. You can also create a new billing plan from this screen by clicking New Entries.

Figure 4.74 Maintain Billing Plan Types for Milestone Billing

For milestone billing plan types, you can define the Start date of the creation, as shown in Figure 4.74. In this case, it’s defined as 01 (Today’s Date). You can also define a reference billing plan number (RefBillPlanNo.), if you have one, and a billing plan usage category (BillingPlanUCat), such as 2 (Time and Expenses) or 1 (Fixed Price). For periodic billing plan types, you have a few more options in comparison to milestone billing plans (see Figure 4.75). The periodic billing plan type defined here has a start date and date-from equal to the contract start date, an end date equal to the contract end date and date-until, as well as a horizon of one year. Additionally, you can see the next billing date is the first of the month, each month.

241

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.75 Maintain Billing Plan Types for Periodic Billing

Note that you can create an assignment of billing plan types to document types or item categories if needed—for example, if there are only certain products that are sold via a billing plan. This is possible in Sales and Distribution • Billing • Billing Plan • Assign Billing Plan Types to Sales Document Types and Sales and Distribution • Billing • Billing Plan • Assign Billing Plan Types to Item Categories, respectively. The SAP standard item category for milestone billing is TAO. Also note the billing relevance I (Order-Relevant Billing – Billing Plan) of the line shown in Figure 4.76.

Figure 4.76 Assign Billing Plan Types to Item Categories

A billing plan for milestone billing could look like Figure 4.77. To reach this view, create a sales order with a material and sales order type that are relevant for a billing plan. On the header level, choose the Billing Plan tab. There are three dates for this exemplary milestone billing: the down payment date, the delivery date, and a date for a closing invoice. This could be, for example, a billing plan for the commissioning of a custom

242

4.4 Special Indirect Tax Transactions

product, which is produced after the down payment receipt and installed on-site after the delivery. This means that for one sales order over a certain value, several billing documents will be created. In the example, you can see that the value of the item is 20.000,00 EUR (Net value field). Below that, you’ll find details about the billing plan: the type (BillingPlanType) and Start date, as well as the percentage (InvoicePercentg) and value to be billed over the course of the billing plan (Billing Value). In the Dates table, you can see the individual billing dates of the billing plan. The field DtDs (date descriptions) contains the information about what the milestone billing date means, shown two columns to the right. A billing value is defined based on percentage. We’ve also defined the Billing Type for each milestone. Billing type FAZ is the SAP standard billing type for down payments, while billing type F2 is the standard billing type for invoices. Using different billing types makes it possible to have different settings for printing invoices, for forwarding the invoice into financial accounting, and for the creation of the billing document itself.

Figure 4.77 Example of Billing Plan

For the pricing in down payments or partial payments of a billing plan, SAP offers the standard condition type YZWR or AZWR (down payment/settlement), depending on the version of SAP you’re using. AZWR is the condition for SAP S/4HANA, while YZWR is the condition for SAP S/4HANA Cloud. When creating invoices based on a sales order with a billing plan, the system automatically determines an additional position for the received down payment. In Figure 4.78, you can see that the net value of EUR 6,000 was automatically determined. This is due to the previously mentioned condition type (YZWR) that was populated as defined in the billing plan in Figure 4.77. You can see the condition type in the pricing procedure in Figure 4.79.

243

4

Indirect Tax Determination in SAP S/4HANA

Figure 4.78 First Down Payment on the Milestone Billing Plan

Figure 4.79 Condition Type with Value for Billing Plan Value

Cross-Border Supply of Goods For cross-border supplies of goods, oftentimes the actual movement of the good is a prerequisite for a taxable transaction such as an intra-community supply of goods or an export. At the time of receipt of a down payment, the movement of the goods is often not complete. Therefore, determining an export tax code during tax determination would be incorrect. We recommend creating a condition table that includes the billing type in addition to the fields that are generally used for tax determination. That way, a new tax code for down payments on cross-border transactions can be found. Refer to Section 4.1.4 for details on how to create a condition table and add it to the access sequence.

So far, we’ve taken a deeper look into an example for milestone billing. Let’s now have a look at periodic billing in the next step. To create a billing plan for periodic billing, usually there will be a contract in place. A value contract can be created via Transaction VA41. On this screen, enter the contract type you want to create a contract for and press (Enter). The example in Figure 4.80 is a Value Contract to represent a rental contract for a period of one year. After entering the customer number into the Sold-To Party

244

4.4 Special Indirect Tax Transactions

field and entering the start and end dates, the system will create billing dates as defined by the dates and the frequency (here, monthly on first of month).

Figure 4.80 One-Year Rental Contract for Periodic Billing

From this value contract, you’ll be able to create a sales order via Transaction VA01. Click on Sales Document • Create with Reference, and enter the contract number, as shown in Figure 4.81.

Figure 4.81 Create Sales Order from Contract

Afterwards, you can follow your standard sales process. Every order and invoice you create will have reference to your rental contract and the associated value.

245

4

Indirect Tax Determination in SAP S/4HANA

Self-Billing Usually, the entity fulfilling a supply of goods or services is the one issuing the invoice. However, this isn’t always the case. In some industries, it’s common to pay for goods or services via self-billing: the recipient of the goods or service issues the invoice to themselves in agreement with the supplier. Usually, these self-billing invoices must fulfill the same requirements as a standard invoice. In some jurisdictions, the issuance of self-billing invoices isn’t permitted. Self-billing in SAP usually requires an integration to the supplier via EDI (see Section 4.2.1 for more information on EDI). The self-billing process then begins with an order of the customer. The tax code on the transaction is determined over the standard process in the purchase order. This order is confirmed by the supplier, followed by a delivery of the goods. The customer then creates a goods receipt and consequently issues the selfbilling invoice. This invoice is transmitted to the supplier, who processes it with their internal open invoice. If the values match, a financial accounting document is created.

Rebates and Discounts From an indirect tax perspective, rebates and discounts reduce the taxable base amount. The rules differ between jurisdictions: sometimes, the amount prior to the rebate or discount is to be taxed, and sometimes the amount after. There are two processes from an SAP perspective: pricing discounts and rebate agreements. Pricing discounts are condition types that form part of the pricing procedure and are determined directly at the same time as the rest of the sales order, billing document, or purchase order. In Figure 4.82, you can see that SAP standard pricing Procedure RVAA01 already contains several of those discounts, for example, a predefined customer discount that will be determined via a condition table, or a manual discount from the gross or net price that can be added directly in the document. In the pricing procedures of the sales order, invoice, or purchase order, such discounts will look as shown in Figure 4.83. Rebate agreements, in contrast, serve the purpose of providing condition-based discounts. For example, a company may want to offer a discount after the fact at the end of the quarter for customers who have bought a certain volume of product during the quarter. At a process level, there are several invoices that accumulate a rebate. At the end of the quarter, the rebate agreement is fulfilled, and a credit memo is issued to the customer. Technically—very briefly put—the condition contract is updated for each transaction that contains the defined business volume selection criteria.

246

4.4 Special Indirect Tax Transactions

Figure 4.82 Pricing Procedure Discounts

Figure 4.83 Net Discount in Pricing Elements

From an indirect tax perspective, it’s important to note that issuing of a conditional rebate after the fact does reduce the taxable base amount of all previous transactions but doesn’t lead to the necessity of correcting all prior invoices. In most jurisdictions, there are two important requirements: A reference to previously issued documents must be made (i.e., the document number and date), and the credit note must apply the same indirect tax as the original document. Note that all types of settlement offered by SAP—whether partial or final—are taxable transactions. Lastly, the tax point can be different between jurisdictions; for example, the issuance of credit note may be the tax point or the payment of the rebate. For details on customizing rebate agreements and condition contracts, refer to SAP Note 2481672.

247

4

Indirect Tax Determination in SAP S/4HANA

Example Company Z sells goods to a customer Y. Customer Y has those goods delivered to warehouses in multiple countries, some inside the country of company Z and some outside. Therefore, customer Y receives invoices both with indirect tax for domestic supplies and without indirect tax for cross-border supplies. When issuing a credit note over a certain time frame, these different applied indirect tax rates on the previously issued documents must be taken into account. This is very important, as incorrectly reducing the taxable base and indirect tax liability may lead to tax evasion.

Kit Supplies SAP offers functionality to create materials that consist of multiple products, that is, kits or bundles, via Transaction CS01. There, you can choose a header material—in the example shown in Figure 4.84, TG16_KIT—to which you assign a bill of materials (BOM) in the Alternative BOM field. In the example in Figure 4.84, the kit consists of the service TG16, a nonstock item, and the product TG15, a standard trading material.

Figure 4.84 BOM for Kit Material

When entering the header material in a sales order, the kit items are automatically added to the order as well. Different item categories are assigned automatically based on the settings in the SAP configuration menu path Sales and Distribution • Sales • Sales Document Item • Assign Item Categories (see Figure 4.85).

Figure 4.85 Item Categories for Kit Material

Here, the header material receives an item category TAQ (Pric. At Header Level) based on the item category group ERLA assigned in the material master data. The items of the kit are assigned an item category TAE (Explanation) in relation to the item category of

248

4.5

Summary

the high-level item. The relation is shown in column HL Itm in Figure 4.86: Items 20 and 30 refer to item 10 as the high-level item, which corresponds to the TAE item category. In the sales order, this means that pricing is only done for the high-level item, that is, cumulatively for all items of the kit. For the BOM items, all condition types—including the indirect tax condition—are deactivated. This means that if you have a service as part of a kit, it will be treated as an ancillary service to the main supply within the kit and will share the same indirect tax treatment.

Figure 4.86 Kit in Sales Order

4.5 Summary After reading this chapter, you should be able to customize your SAP S/4HANA system for automatic indirect tax determination based on condition logic according to the needs of your business. You’ve also learned about alternative ways of indirect tax determination on the purchasing side and procurement tools that produce tax-relevant data. Finally, you should be aware of special processes such as chain transactions, stock transfers, and special payment processes that produce tax-relevant data and that may have different requirements depending on the jurisdiction. In the next chapter, we’ll be looking into alternative ways for indirect tax determination outside of SAP S/4HANA.

249

Chapter 5 Indirect Tax Engines and Add-Ons So far, we’ve focused on indirect tax determination based solely on SAP-native condition logic within SAP core processes, without external functionality. Now, let’s take a moment to broaden our scope to consider other engines and add-ons.

In this chapter, we give an overview of alternative SAP tax determination solutions and provide some discussion points for a respective decision support for tax functions during SAP S/4HANA projects or general key design decisions in terms of tax technology solutions. Figure 5.1 shows the core indirect tax determination solution approaches that we’ll discuss in the following sections: SAP’s native condition logic, tax determination add-ons, SAP’s tax service, and external tax determination engines.

SAP-Native Tax Determination Logic Based on Condition Logic

Add-On (Predefined Condition-Based Tax Determination)

SAP’s Tax Service (Tax Computation Engine)

External Tax Determination (Tax Engine)

Figure 5.1 Indirect Tax Determination Solutions (Source: EY)

5.1 SAP Condition Logic The SAP condition logic is part of the SAP S/4HANA core functionalities and therefore provides an available tax determination solution without additional software. SAP standard tax determination itself is limited to basic settings that fulfill the indirect tax requirements of a limited catalog of business transactions:

251

5

Indirect Tax Engines and Add-Ons

쐍 Taxable local supplies (goods, services) at standard and reduced rates 쐍 Tax-exempt local supplies 쐍 Tax-exempt intra-community supply of goods (only applies to two-party transac-

tions; the SAP standard would not be sufficient for three-party transactions) 쐍 Tax-exempt exports (also only applies to two-party transactions) 쐍 Supplies to special territories with existing ISO country codes 쐍 Exception handling of intra-community supplies of goods to customers without a

value-added tax (VAT) ID (local supply with VAT) Figure 5.2 shows the SAP-native tax determination logic based on a process flow from the pricing procedure to the condition type to the access sequence to the condition tables. You’ll recognize these concepts from Chapter 4.

Pricing Procedure Condition Type Access Sequence ERP

SAP-Native Tax Determination Logic Based on Condition Logic

8

Access Requirement

Condition Table

7

Condition Table

Figure 5.2 SAP Condition Logic (Source: EY)

The following examples include transactions that aren’t covered by the SAP standard and need further investigation to be solved: 쐍 Chain supplies 쐍 Nontaxable supplies within a VAT group 쐍 Supply of services with deviating place of supply from country of residence of ser-

vice supplier 쐍 Work supplies 쐍 Intra-community movement of goods 쐍 Consignment stock rules

For a more detailed understanding of the SAP tax determination based on condition logic and indirect tax-related adjustments to the SAP standard, refer to Chapter 4.

252

5.3

Tax Service with SAP

5.2 Add-Ons Add-on suppliers use the fact that SAP standard doesn’t cover a range of standard indirect tax rules (as discussed in the previous section). With a predefined setup, typical indirect rules are covered directly in SAP based on predefined extended SAP-native setup and condition logic. The user experience of add-on solutions ranges from solutions with VAT cockpits as customer frontends, where the customer maintains rules and master data, to step-bystep solutions without customer frontends that instead use extended customizing tables with multiple additional tax determination parameters needed to determine taxes for more complex transactions. Figure 5.3 shows how the add-on can provide extended tax logic to enhance the standard SAP pricing procedures.

Add-On

SAP Pricing Procedure Add-On (Predefined Condition-Based Tax Determination)

Extended Tax Logic ERP

Extended Indirect Tax Logic (Customizing and Coding) and Integration in SAP Condition Logic by User Exits

Figure 5.3 Add-On Tax Determination (Source: EY)

5.3 Tax Service with SAP SAP offers a tax service (previously known as SAP Localization Hub, tax service, before being put into maintenance mode), with which you’re able to determine and calculate indirect taxes considering country-/region-specific issues. The tax service has been in maintenance mode since December 2021. With SAP Cloud Integration for data services, you can connect SAP S/4HANA and SAP S/4HANA Cloud with external tax engines. The tax service is an external tax calculation engine in an SAP environment: SAP S/4HANA, SAP Business Technology Platform (SAP BTP), and the connection to any SAP partner solution and platform. SAP Integration Suite connects the SAP customer’s SAP S/4HANA environment with the partner platform.

253

5

Indirect Tax Engines and Add-Ons

Tax Service Prerequisite As a prerequisite to use the tax service productively in your SAP S/4HANA system, you must have an enterprise global account on SAP BTP.

SAP offers a solution to enable the integration between SAP S/4HANA Cloud or SAP S/4HANA and external tax calculation engines. This ensures a standardized integration template at the SAP BTP level and an SAP infrastructure for the data exchange between SAP S/4HANA and SAP BTP. The tax determination itself is happening in the solution provided and integrated by the SAP partner. As an SAP partner with an external tax determination solution, you need to follow these steps to become part of the SAP BTP partner offerings: 1. Integrate the tax service and partner service APIs. 2. Certify the integration of the APIs. 3. Become part of the SAP PartnerEdge program. 4. Get a support cooperation agreement. 5. Include the endpoint domain in the allowed domains list. 6. Publish the partner service in the SAP Store. Figure 5.4 presents the new integration approach based on the SAP Integration Suite, which is a default SAP tool for integration. SAP Integration Suite is the router between SAP S/4HANA Cloud or SAP S/4HANA and external partners. SAP provides generic integration templates that must be deployed and configured in SAP Integration Suite. Routes to a specific partner can be defined, or different combinations of routes and partners using existing parameters in the data from your SAP S/4HANA Cloud and/or SAP S/4HANA system can be defined.

Business Transactions

Pricing

Extract Data

Generate JSON

Map Results

HTTP Call

SAP Integration Suite Send Calculated Tax Amounts

Partner A

Partner B Integration Template

Audit Log Tax Integration Extensible by Customers

Send Tax-Relevant Data

SAP S/4HANA

Figure 5.4 SAP Integration with External Tax Engines

254

…….

SAP BTP

Any Platform

5.3

Tax Service with SAP

There are standard templates and customizing options both for enriching data for tax calculation and determining combinations of routes and partners according to the tax requirements. Different business processes can be routed to different partners. With this new integration for external tax determination, at this moment, you may be wondering where to access the request and response payloads for auditing what was determined in the tax service. The audit log is now accessible within SAP S/4HANA Cloud and SAP S/4HANA. The tax service integration uses standard data to calculate taxes in a business transaction. However, there are business transactions that require a more sophisticated tax determination setup. After identifying the additionally required data, you can extend the tax service integration by executing the following steps: 1. Find the extendable interfaces. Find the interfaces where you can extend the tax service integration and implement the IF_TXS_CLASS_ENHANCEMENT interface. You can find the interfaces by executing Transaction SE80 and selecting Repository Browser to arrive at Figure 5.5. You can select Class/Interface from the dropdown and then enter “IF_TXS_CLASS_ ENHANCEMENT” as the object name.

Figure 5.5 Tax Service Integration Extensions

255

5

Indirect Tax Engines and Add-Ons

When you expand the comprehensive interfaces, you can read the interface documentation and determine the interface in which you need to extend the tax service integration. You can then align with your SAP partner for tax calculation. 2. Create a new class. Next, you can create a new class and inherit the methods from the standard class you previously determined via Transaction SE24. After creating a class, you can go to the Properties tab, click Superclass, and enter the location class that implements your interface. After implementing a tax rule according to your needs, you can activate the new class. 3. Set your own class. Under Customizing for Integration with Other SAP Components, choose SAP Localization Hub, Tax Service • Enhance Localization Interfaces for Tax Service. Now you set your own class to replace a tax service standard localization class for a determined interface. SAP’s tax service is available for SAP S/4HANA Cloud and SAP S/4HANA to be connected to external tax engines via SAP BTP. Therefore, API and connection configurations are available. Predefined indirect tax content isn’t supported, except existing scenarios for Canada (maintenance mode) and new functional content/scenarios released for Brazil. Former tax service configurations, standard integration templates, or connections can be used for tax automation projects in SAP S/4HANA Cloud or SAP S/4HANA. But remember, no maintenance beyond Brazil is supported anymore. Details for SAP S/4HANA Cloud can be found in SAP Notes 258016 and 2598888, and for SAP S/4HANA Cloud, private edition, refer to SAP Note 1497956.

5.4 External Tax Engines In comparison to SAP’s tax service, external tax engines work with connectors to transfer data from and to the SAP S/4HANA system. Solution providers offer both on-premise versions and cloud-based versions of tax engines. The on-premise versions of the tax engine software are increasingly disappearing due to the tax determination rules, the content that is maintained with the solution provider, and the content that is centrally managed in an external environment of the solution provider. The only on-premise part that remains is the cloud connector and the SAP add-in for data transfer purposes. Solution providers also offer private tenants for the deployment of the tax determination to ensure data protection and data security comparable to the on-premise alternative.

256

5.4

External Tax Engines

From an architectural point of view, a tax engine comes with different layers to be implemented and to be maintained, as shown in Figure 5.6: 쐍 Data layer: SAP S/4HANA

By default, a tax engine processes tax calculation parameters that are recorded in the operational SAP S/4HANA modules. Based on client-specific requirements, the data source is initially mapped and can be extended as needed. The solution providers use additional tools to process the transaction mapping. 쐍 Integration layer: Tax connector

The connector manages the data interface between the SAP S/4HANA system and the tax engine. The connector is an ABAP-based add-on that is installed on premise to collect data for tax calculation requests. Tax engine solution providers write the tax determination results in the respective SAP documents. This can either happen by monitoring on an additional layer (e.g., web-based customer frontend) or as a black box without additional functionalities. 쐍 Processing layer: Tax rules

The processing layer is hosted on the solution provider’s technology platform and serves as a data processing engine. Tax engine solutions include configurable rule sets to identify, classify, and declare indirect tax-relevant transactions within operational system processes.

SAP ERP

Real-Time Interface

External Tax Determination (Tax Engine)

Input Tax Engine

Output Input Database Output

Tax Determination Logic

Figure 5.6 Tax Engine Processing (Source: EY)

Following are examples of indirect tax engines: 쐍 Vertex Indirect Tax O Series manages global indirect taxes, including sales, use,

value added, communications, and leasing taxes.

257

5

Indirect Tax Engines and Add-Ons

쐍 Thomson Reuters ONESOURCE Determination calculates sales and use tax, goods

and services tax (GST), VAT, and excise tax on a global scale. 쐍 Avalara AvaTax is a tax calculation engine for sales and use tax, customs and duties

calculation, VAT, GST, communications tax, excise tax, consumer use tax, lodging tax, and beverage alcohol tax.

5.5 Decision Support for Vendor Selection Because there are different ways to handle tax determination in SAP S/4HANA, it’s recommended to run an assessment through different categories relevant for the tax function and the corporation to find a tax determination solution that fulfills the most relevant criteria. We provide a comprehensive list of categories that can be considered based on experiences during such assessments: 쐍 Implementation

Implementing indirect tax rules in native SAP requires effort. If there are gaps in the SAP standard setup, either customizing or enhancements may be necessary (e.g., chain supplies). Implementing an add-on or an external tax engine can reduce these efforts as a predefined logic or functionality is already embedded in the solution. However, a basic prerequisite implementation effort is a common topic for all possible tax determination solutions. 쐍 Documentation

A solution tailored to your needs that covers all your individual indirect tax requirements is only as good as the documentation. Regardless of the external tax determination solution or SAP-native setup, the documentation will be the reference for maintenance and change requests either in-house or offered by solution providers. 쐍 Indirect tax content and maintenance

Predefined and externally managed content and databases with external tax engines and add-ons compete with tax rates, tax rules, and master data to be manually maintained in your SAP S/4HANA system. Given an average complexity of the business transaction from an indirect tax perspective, you’ll always be responsible to ensure up-to-date master data, tax rates, and tax rules (refer to Chapter 10, Section 10.2). The extent to which managed services cover the maintenance of tax rates, tax rules, and master data can heavily differ between add-on solutions and external tax engines, as well as being subject to individual contracts between solution providers and their customers. Even for the native SAP S/4HANA setup, a possible subsequent service as part of tax monitoring can be based on exceptional findings. Not all tax-relevant data can be updated based on external tax determination solutions. With functionality such as time-dependent taxes currently available for SAP S/4HANA Cloud, native functionality is also subject to more efficient maintenance

258

5.5

Decision Support for Vendor Selection

processes with corporate IT or external consultancy support. However, in native SAP S/4HANA, all VAT rates and rules are embedded in hard-coded tax condition records. If changes in VAT rates and rules are necessary, recoding and testing of these tax condition records is required. 쐍 IT resources and user roles concept

Solution providers have their development teams that are responsible for the maintenance of the tax determination solution. With an SAP-native setup, internal IT resources and maintenance processes need to be established as alternatives to external (tax-related) IT support. However, for access to your SAP S/4HANA system, a user role concept needs to be set up and established. 쐍 Scalability

Especially at the beginning of global rollouts, the scalability of tax determination solutions needs to be considered. Economies of scale can be a saving potential when multiregional licenses are necessary. Most add-ons and SAP-native setups are limited to cover only regional tax requirements (European Union [EU], Asia Pacific, selected jurisdictions with an indirect tax system similar to the EU VAT system). Large tax engine solution providers offer a global scale of tax rules. With a tax engine, it’s relatively easy to include additional jurisdictions, regions, or legal entities by either extending a license or implementing an API into the ERP of the acquired legal entity. With an add-on, adding another (e.g., acquired) company requires either embedding this company in your ERP system or embedding the addon in the acquired entity’s systems. SAP-native setups can be scaled by reusing a template setup that already covers a big portion of the tax-related functionality needed for an EU country. For example, an EU VAT template that consists of three EU countries (Poland, Hungary, and Netherlands) and covers already identified gaps in the SAP standard, such as supply chains and intra-EU transfer of goods, can be reused for other EU countries with similar requirements. That way, implementation costs can be leveraged. 쐍 In control

Both a tax engine and a VAT add-on have embedded VAT controls and options to block or flag noncompliant transactions. Based on those tax functions together with accounts payable and accounts receivable teams, processing transactions can work with up-to-date tax rules. Native SAP functionalities need to be customized and adjusted for control framework purposes. 쐍 Multiplatform

A tax engine license can be used for and connected to multiple ERPs. In addition, other financial systems for procurement, expenses, or e-commerce can rely on the tax rules via the interface. Add-ons are embedded within an SAP S/4HANA system. Therefore, multiple installations will be needed. With native SAP, for each ERP or other financial system, VAT coding needs to be done within the system.

259

5

Indirect Tax Engines and Add-Ons

쐍 Reporting

The native reporting capabilities of your ERP can be used with all three solutions. As a result, the reporting process becomes more and more an equal to the IT process. Tax monitoring is therefore key to ensure exceptions can be managed separately. 쐍 Version control

Tax engine providers maintain and manage their solutions, and, as a result, you’ll always license the latest version of the software. With an add-on, this isn’t the case as version updates need to be uploaded and implemented in your SAP S/4HANA system. In addition, for native SAP, a version control will be maintained in the documentation to handle updates and change requests. 쐍 Tax classifications

Material, vendor, and customer tax classification drives the taxability of a transaction in native SAP ERP and also with an add-on. With a tax engine, incorrect tax classifications can be bypassed and still arrive at a correct tax determination. 쐍 Tax code availability

In native SAP, the time-dependent tax functionality is ready to use for countries in scope. Nevertheless, especially in multicountry systems, tax codes are limited because of the two-character structure. Tax engines solve this by assigning a validity date and as a result there is no need to create new tax codes just for VAT rates changes. 쐍 Pricing

A business case, including tax engines, add-ons, and/or an SAP S/4HANA setup, finally is a trade-off between maintenance cost on the one hand and license fees on the other hand. Especially at the beginning of a project, this calculation should take place to use the maximum of available economies of scale and make the right decisions in terms of tax determination solutions.

5.6 Summary In this chapter, we discussed the four alternative ways of tax determination in SAP. All of them have upside and downside potentials. After detailing the different solutions, we proposed some criteria to discuss and decide on a tax determination solution according to your requirements in your SAP S/4HANA environment. In the next chapter, we’ll discuss custom coding options for indirect taxes.

260

Chapter 6 Custom Coding for Indirect Taxes Now that you know how to configure your SAP S/4HANA system for indirect tax, let’s take a deeper look into what to do if there are requirements that can’t be covered with standard configuration.

This chapter gives examples of custom coding using typical reports, interfaces, conversions, enhancements, forms, and workflows (RICEFWs) to enhance the SAP standard system functionality on both the sales and the purchasing side. Let’s briefly break down these terms: 쐍 Reports

Reports are executable programs that read data and provide output in a structured way. An example from indirect tax is report RFUMSV00, the SAP standard report for tax on sales and purchases (see Chapter 9 for more details). 쐍 Interfaces

Interfaces are connections between two or more distinct systems, for example, between the SAP S/4HANA system and an online shop. An interface defines which data is shared between the two systems and in what way. The type and method of transferred data varies strongly, depending on the manufacturer, type of system, and purpose of the external system. 쐍 Conversions

During a conversion, data is converted from one format to another, or from one system to another. Think about a migration from a legacy system to SAP S/4HANA. You’ll usually migrate data from your old system, mapping your legacy data to the new system. 쐍 Enhancements

In this chapter, we’ll mostly talk about enhancements. Enhancements describe any way in which you add your own functionality into the SAP standard. There are several ways to implement enhancements, for example, through user exits, customer exists, or business add-ins (BAdIs). You’ll find several examples related to indirect tax in the following sections. 쐍 Workflows

Workflows describe sequential tasks that process a set of data or document. For indirect tax, you may have an approval workflow for incoming invoices: The invoice is

261

6

Custom Coding for Indirect Taxes

validated against open purchase orders, and then approved by procurement and the tax department. To set the stage, we’ll start with a brief discussion of important ABAP terms that are relevant for indirect tax. We’ll then explore the key user exits for tax determination in sales and purchasing.

6.1 ABAP Basics for Indirect Tax To begin, we’ll cover basic terminology and coding logic in the SAP programming language ABAP that will enable you to understand the example code snippets in the following sections.

Note on ABAP Be aware that the explanations and examples offered here aren’t a complete overview of ABAP and the enhancement functionality of SAP and don’t replace the involvement of an ABAP developer on a project.

6.1.1 User Exits, Customer Exits, and Business Add-Ins In SAP S/4HANA, there are several enhancement points you can use to implement your own functionality: 쐍 Customer exits

These are predefined spaces in an SAP standard program, screen, or menu, where customers can implement their own functionality. We’ll be covering how to identify and create customer exits based on EXIT_SAPLMEKO_001 and EXIT_SAPLMEKO_002 in Section 6.3. 쐍 User exits

These serve basically the same purpose as customer exits, but they are only available for the sales and distribution functionality. They generally don’t contain a lot of code, but rather call a function module. For details on function modules, refer to Section 6.1.3. Classic examples for user exits relevant for indirect tax are PRICING_PREPARE_TKOMK or PRICING_PREPARE_TKOMP for the sales order and invoice. For more information on these user exits and their purpose, refer to Section 6.2. 쐍 BAdIs

These are also predefined locations where a customer’s own functionality can be implemented. However, in comparison to the other two approaches, they can be reused within several projects. The appropriate BAdI can be identified in the SAP Customizing menu. For BAdIs in materials management, go to path Materials

262

6.1

ABAP Basics for Indirect Tax

Management • Purchasing • Business Add-Ins for Purchasing. You’ll find, for example, a BAdI for enhancements to price determination or to adopt the tax jurisdiction code from the delivery address. For BAdIs in sales and distribution, there are several locations in the SAP Customizing menu. For example, you’ll find BAdIs for sales documents via Sales and Distribution • Sales • Sales Documents • Business Add-Ins (BAdIs) and BAdIs for billing documents via Sales and Distribution • Billing • Business Add-Ins (BAdIs).

6.1.2 Objects Objects—structures that hold a certain type of data in a specified format—in ABAP are declared with declarative statements. They begin with a keyword, usually DATA. This tells the program which type (i.e., format) a certain object has. For example, the net value of a billing document is of type VBRK-NETWR (net value), as follows: DATA lv_netwr TYPE vbrk-netwr.

You can also use less specific data types and directly assign a value to your variable. In the following example, we define a packed number lv_netwr with value 100 and give it a defined length of 10 with 2 decimal places. The result of printing this variable would be 100.00 with seven preceding spaces. Be aware of this, as it may influence your operations and output of the variable. DATA: lv_netwr TYPE p VALUE 100 LENGTH 10 DECIMALS 2.

ABAP Isn’t Case Sensitive You’ll notice in the preceding code snippet that the keywords data and type are written in uppercase letters, while the variable name lv_netwr and the type vbrk-netwr are in lowercase letters. ABAP isn’t case sensitive. Therefore, this statement would still be valid if everything was in uppercase or lowercase letters. It’s best practice to have a consistent use of capitalization in ABAP, but it’s up to your taste how you use it. For example, you could use uppercase or lowercase letters all over your program, or you could use an approach as shown in the previous example.

It’s also possible to declare structures consisting of multiple variables. In the example shown in Listing 6.1, we declare a structure type st_kna1 that contains a customer number variable (kunnr) and a country (land1). This can be useful if you want to accumulate data into a report, or if you require a number of data fields in relation to each other to perform operations on certain data fields. TYPES: BEGIN OF st_kna1, kunnr TYPE kunnr,

263

6

Custom Coding for Indirect Taxes

land1 TYPE land1, END OF st_kna1. Listing 6.1 Declaration of a Structure

Usage of the Structure So far, the structure can’t be used because it’s only a type. To use the structure you created, you’ll need to declare a variable with the type of your structure: DATA wa_kna1 TYPE st_kna1.

Or you can use an internal table of your structure: DATA it_kna1 TYPE STANDARD TABLE OF st_kna1.

Additionally, it’s possible to declare variables inline, that is, inside other statements. This is possible, for example, during a select—a selection of data from a certain database table, as shown in the example in Listing 6.2. The statement @DATA(lt_vbrk) declares the structure lt_vbrk as a table with the fields taxk1 and inco1 that are to be selected during the statement. You’ll encounter database statements a lot in ABAP. For details, refer to Section 6.1.4. SELECT taxk1, inco1 FROM vbrk WHERE vbeln = lv_vbeln INTO @DATA(lt_vbrk) ENDSELECT. Listing 6.2 In-Line Declaration of Local Table

6.1.3 Includes, Functions, Subroutines, and Programs SAP uses several different methods of structuring functionality. We’ll briefly cover includes, function modules, subroutines, and programs in this section: 쐍 Includes

These are reusable objects that are included as source code inside the general program code during runtime. This means that inside an include, all variables of the overall program are available without the need to import or export them explicitly. For indirect tax, there are several such includes that are relevant. One example is include V05EZZRG for the determination of the tax ID and customer tax classification based on the payer business partner role. 쐍 Function modules

These are subprograms that consist of reusable statements. They import and export certain parameters—usually to modify the export parameters in relation to the

264

6.1

ABAP Basics for Indirect Tax

import parameters. To view a function module, use Transaction SE37 and enter the name of the function module. There are several useful function modules predefined by SAP. An example for such a useful function module is READ_EXCHANGE_RATE—a function module to read the exchange rate between two currencies for a certain date and exchange rate type. Nevertheless, it may be useful to create custom function modules, for instance, to encompass all modifications inside a certain user exit. 쐍 Subroutines

These are similar to a function module, except that it can only be used inside a certain ABAP program and not outside of it using certain parameters (instead of importing or exporting them). That means that it can’t be reused by other programs. Subroutines are defined using the FORM statement. 쐍 ABAP programs

These are units that process data. Executable programs are defined by the keyword REPORT and can contain includes, function modules, or subroutines.

6.1.4 ABAP Statements Generally, every statement in ABAP begins with a keyword. You’ve already learned about the keywords DATA, TYPES, SELECT, FORM and REPORT. Each statement ends with a full stop. This makes it possible to have statements over multiple lines. A program generally consists of multiple statements.

Spaces Spaces are generally ignored in ABAP, unless they are relevant for the code. For example, the statement var = 1+2.would be incorrect, while var = 1 + 2. is correct. Additionally, there are statements where a space is expected as a separator instead of a comma, such as in statement CONCATENATE that combines several text items.

Within ABAP, there are many types of statements. We’ll focus on the following: 쐍 Declarative statements

You’ve already learned about some declarative statements such as DATA or TYPES. They declare a certain type of object. 쐍 Modularization statements

Modularization statements such as FUNCTION…ENDFUNCTION or FORM…ENDFORM are used to define processing blocks inside an ABAP program. There are also other types of modularization statements that define, for example, events. 쐍 Calling and exiting program units

Calling and exiting program units call or exit a certain transaction, processing block, or program unit. For example, a function is called with CALL FUNCTION, and a processing block can be exited via statement EXIT.

265

6

Custom Coding for Indirect Taxes

쐍 Program flow logic

We’ll focus on control structures here. You’ll encounter case distinctions IF…ELSEIF …ELSE…ENDIF and CASE…WHEN…ENDCASE in our example code snippets. They help to distinguish between cases and create conditions for certain operations. 쐍 Data processing statements

Because SAP S/4HANA is based on tables, we’ll often use Open SQL statements such as SELECT…ENDSELECT to access data in tables and JOIN to join data of several tables on certain conditions.

6.2 User Exits for Tax Determination in Sales In sales and distribution, we’ll take a closer look at user exits, in comparison to the customer exits we’ll cover in Section 6.3.

Use Enhancement Implementations It’s a best practice to create the implementation within a user exit via an enhancement implementation. Enhancements can be created in a certain program, such as program MV45AFZZ or program RV60AFZZ. Using enhancements is especially beneficial during system upgrades, as they are transport objects instead of part of the modification. During an SAP upgrade, all SAP objects are replaced by a newer version, including the modifications.

To begin this section, we first want to focus on the relevant structures and how they are filled. You’ll come across structures TKOMK and TKOMP, which are the communication header and item for the pricing structure. They contain all relevant data for pricing, for example, the tax departure country, tax destination country, material tax classification, and customer tax classification, and should contain any custom fields you’ve created (appended via structures KOMKAZ or KOMPAZ) that are to be used during pricing. They are based on structures KOMK and KOMP and are populated during pricing from different tables, such as table VBAK and table VBAP for the sales order, and table VBRK and table VBRP for the billing document. Additionally, some fields are populated from other tables, such as the business data for the sales document, including the Incoterm, which is populated by table VBKD, or the partner information for the sales document, which is populated by table VBPA. During the pricing processing, the information for certain fields, structures, and tables may be changed. To track these changes, there are different prefixes you should be aware of: 쐍 X

A table or structure with prefix X, such as table XVBAK, contains the current status of

266

6.2

User Exits for Tax Determination in Sales

the object. These are the changes that are written into the database table when the object is saved. 쐍 Y

A table or structure with prefix Y, such as table YVBAK, contains the status of the object before any changes were made. This is the object as it was read from the database. We’ll cover custom coding for indirect taxes using user exits for sales orders and invoices in the following sections. We’ll also consider some other relevant system enhancements.

6.2.1 Sales Orders The program containing the most relevant user exits for indirect tax is program MV45AFZZ. It contains a number of user exits for sales document processing. We’ll focus on user exits PRICING_PREPARE_TKOMK, PRICING_PREPARE_TKOMP, MOVE_FIELD_TO_VBAK, and MOVE_FIELD_TO_VBAP in this program. Further along this section, we’ll also look at program MV45AFZB.

USEREXIT_PRICING_PREPARE_TKOMK This user exit is used to read, write, or modify further information into the communication header for the pricing structure. If you’re using a custom header-level field in a condition table, this is the point you would pass the value to pricing. In many countries, the export of goods is exempt from indirect tax or valued as zerorated under certain conditions. Usually, the goods must leave the country. This is easy to prove when your company is responsible for the export. However, there are cases where this is harder to prove and where the legal requirements dictate that if the customer is responsible for the export and is a resident of the country of departure, the exemption can’t be applied. For example, let’s consider company A in Australia, which sells goods to customer B, a resident of Australia. Customer B picks up the goods at the warehouse of company A (Incoterm EXW) and exports them to their customer C. Company A, under the Australian indirect tax law, must charge goods and services tax (GST) on the transaction to B, even though the goods leave the country. In such a case, you may want to create a condition table that includes the residence country of the customer and the Incoterm. The Incoterm is part of structure KOMK—the communication header for pricing (field KOMK-INCO1). However, the residence country of the customer isn’t part of structure KOMK within the SAP standard. After adding the field to structure KOMKAZ (refer to Chapter 4, Section 4.1.4), the new field must be filled using information from TKOMK—the temporary structure at the time when the user exit is processed.

267

6

Custom Coding for Indirect Taxes

The code may look similar to the example in Listing 6.3, where we select the residence country from customer table KNA1 for the business partner role payer (KNRZE) into custom field ZZLANDPY. Other options for the business partner role available in structure KOMK are KUNNR, the sold-to party; KUNRE, the bill-to party; and KUNWE, the ship-to party. SELECT SINGLE LAND1 FROM KNA1 INTO TKOMK-ZZLANDPY WHERE KUNNR = TKOMK-KNRZE. Listing 6.3 Assign Payer Country to Custom Field in Pricing Structure KOMK

USEREXIT_PRICING_PREPARE_TKOMP This user exit is used to read, write, or modify further information into the communication item for the pricing structure. If you create a custom condition table that creates a custom field on the item level, this is the point you would pass the value to pricing. If your company acts globally, there are almost 200 countries worldwide that you could deliver your goods or services to. As we’ve learned in Chapter 4, Section 4.1, tax determination for all transactions in sales and distribution is based on the condition technique. If you’re acting within the SAP standard, say using condition table A011 for your maintenance of condition records, you would have a combination of each tax destination country worldwide for each tax departure country you’re acting in. If you’ve activated plants abroad or if you’re implementing tax determination in SAP S/4HANA for multiple company codes, this may result in several thousand condition records to maintain. If your company is supplying goods or services to multiple countries, it’s often a good idea to simplify this to avoid overhead. However, not all supplies of goods and services between countries are the same. For countries inside the European Union (EU) or within other tax and customs unions such as the Gulf Cooperation Council, the transactions between them may have special taxation requirements, such as special reporting requirements (e.g., European Commission [EC] Sales List and Intrastat). Therefore, it’s necessary to differentiate not only whether the transaction from the tax departure country is to another country but also the relation the countries have to each other. Let’s look at an example: A Polish company P supplies goods to customers all over the European continent. This includes both EU countries, such as Slovakia, as well as countries outside of the customs and tax union of the EU, such as Switzerland. For supplies to EU countries, company P generally has an indirect tax-exempt intra-community supply of goods or services if they support the transaction with the required documents and reporting requirements. For supplies to countries outside of the EU, company P generally has an indirect tax-exempt export of goods or services. These two

268

6.2

User Exits for Tax Determination in Sales

transactions—among reporting requirements such as EC Sales List and Intrastat arising for the intra-community supplies—are to be reported in different boxes of the indirect tax return in Poland and, therefore, must be distinguished from each other. To simplify this, it’s possible to create a condition table that includes an indicator of the status of the country. In our example, we created a data element ZXEGLD that we appended to structure KOMPAZ. This indicator from our example can have two values: E for EU country and N for not EU country. We’re using the SAP standard field XEGLD of the country table T005 as an indicator of whether the country is a member of the EU. The assignment of an indicator can be made with a short piece of code implemented in program MV45AFZZ (and RV60AFZZ, see Section 6.2.2) in USEREXIT_PRICING_PREPARE_TKOMP, as shown in Listing 6.4. DATA: LV_XEGLD TYPE XEGLD. IF TKOMK-ALAND NE TKOMK-LAND1. SELECT SINGLE XEGLD FROM T005 WHERE LAND1 = TKOMK-LAND1 INTO @LV_XEGLD. IF LV_XEGLD IS INITIAL. TKOMP-ZXEGLD = 'N'. ELSEIF LV_XEGLD IS NOT INITIAL. TKOMP-ZXEGLD = 'E'. ENDIF. ENDIF. Listing 6.4 Assign EU Indicator to Field in Pricing Structure KOMP

We begin defining an object LV_XEGLD with type XEGLD as described previously. Then, as this user exit will be called regardless of whether the transaction is cross-border or not, there is an IF condition that only continues with the overwrite if the transaction is cross-border. From the system table, we select the value of field XEGLD for the tax destination country into our local variable LV_XEGLD. For the tax destination country, we check whether this country is part of the EU: If the field XEGLD in table T005 is empty, we give our custom field ZXEGLD a value of N—it’s not an EU country. If it’s not empty, we give it a value of E signifying it is an EU country. Note that if you want to identify whether a country belongs to another customs union such as the Gulf Cooperation Council, there is no standard indicator available for this. In such a case, we recommend creating a custom Z table to manage the affiliation to a customs union and to choose an identifier from that table. Such a table could be structured as shown in Table 6.1.

269

6

Custom Coding for Indirect Taxes

Country

Customs Union

Indicator

AE

GCC

G

SA

GCC

G

QA

GCC

G

…

…

Table 6.1 Example for Affiliation to Customs Union

Z Tables Generally, a Z table is a custom table that serves the purpose of aggregating information and isn’t part of the SAP standard set of tables. The definition of the table can be created via Transaction SE11.

If you were looking for affiliation to another customs union than the EU, you define field LV_XEGLD as a simple character type with length 1 and make a similar selection from your custom table. Now, let’s consider a second example of the USEREXIT_PRICING_PREPARE_TKOMP user exit. Many countries have rules for the place of supply that dictate the country of taxability for a certain transaction to be different from the country of the ship-to address. One example is the provision of business-to-business (B2B) services in the EU. Under the general rule per Article 44 of the European VAT Code, the place of supply of such a service is the place where the recipient of the service has established its business. To implement this rule with the code snippet shown in Listing 6.5, there must be a distinct material tax classification for services assigned to the service material. For details on material tax classifications, refer to Chapter 3, Section 3.2.1. First, we implement an IF condition that only continues if our material tax classification is S—a service. Secondly, we select the residence country LAND1 of the payer TKOMKKNZRE into TKOMK-LAND1, which is the tax destination country. IF TKOMP-TAXM1 = 'S'. SELECT SINGLE LAND1 FROM KNA1 WHERE KUNNR = TKOMK-KNZRE INTO TKOMK-LAND1. ENDIF. Listing 6.5 Changing Tax Destination Country for Services

270

6.2

User Exits for Tax Determination in Sales

Note that this implementation doesn’t consider differences between countries, which means this rule is implemented for all countries, even if they don’t have this rule. If you need to implement this on a country-by-country basis, we recommend creating a table with the countries where such a rule is relevant. Additionally, this is only a viable solution if the sales order consists exclusively of services. If goods and services are mixed on the sales order, the recommended SAP approach is to split the document. You can also refer to SAP Note 1412947 for mixed orders.

USEREXIT_MOVE_FIELD_TO_VBAK/VBAP User exit USEREXIT_MOVE_FIELD_TO_VBAK is used to read, write, or modify further information into the SAP standard table for header information on the sales order. Generally, all information that is available in table VBAK can be manipulated or filled here. USEREXIT_MOVE_FIELD_TO_VBAP works in the same way for the item level. Many actions that can be made via MOVE_FIELD_TO_VBAK/VBAP can also be made via PRICING_PREPARE_TKOMK or via PRICING_PREPARE_TKOMP. The values also influence each other— TKOMK reads from table VBAK and writes to table VBAK at the end of the transaction. Using USEREXIT_MOVE_FIELD_TO_VBAK or USEREXIT_MOVE_FIELD_TO_VBAK instead of PRICING_PREPARE_TKOMK or PRICING_PREPARE_TKOMP is especially relevant for information that isn’t available in structures KOMK and KOMP. Let’s consider an example. In most countries of the EU, the domestic reverse charge mechanism must be applied if a provider of construction services provides these services to another construction provider within the same country. This was applied to reduce fraud in an industry that is heavily characterized by sub-subcontracting. Reverse charge in the indirect tax context means that the recipient of the goods or service is liable to report and pay the indirect tax on the transaction, rather than the supplier. In the customer master data in the customer business partner role, SAP enables you to insert a license (see Figure 6.1).

Tax Exemption Licenses Note that this is one of many ways in which SAP offers the tax exemption license functionality. For example, several countries have a condition type for tax exemption licenses, such as LCIT, that can be maintained on a condition-level basis.

This license, per se, can mean anything and is stored in table KNVL. If you’re a construction provider that provides construction services to other construction providers, you can use this functionality to store the license identifying your customer as a construction provider for a certain period of time.

271

6

Custom Coding for Indirect Taxes

Figure 6.1 Customer Master License

In the code snippet shown in Listing 6.6, we’ll be using this license data to overwrite the customer tax classification. We’re not changing the customer tax classification directly in the customer master data, as it’s linked to the validity of the license. This reduces the risk of incorrect tax determination after the license runs out. DATA: ls_knvl TYPE knvl. SELECT * FROM knvl INTO ls_knvl WHERE kunnr = xvbak-kunnr AND aland = xvbak-aland AND tatyp = 'TTX1'. ENDSELECT. IF ls_knvl-datab = xvbak-audat AND ls_knvl-licnr IS NOT INITIAL AND ls_knvl-belic NE ' '. xvbak-taxk1 = 'C'. ENDIF. Listing 6.6 Change Customer Tax Classification for License

272

6.2

User Exits for Tax Determination in Sales

As usual, we start with the declaration of a variable. Here, we’re declaring a local instance of table KNV1. We select the matching entry of tax type TTX1 with the customer number and tax departure country available within structure XVBAK—table VBAK with all current changes. Then, we go into an IF condition to check whether the order date is within the validity date of the license (fields DATAB and DATBI), and whether the license number (field LICNR) and confirmation indicator (field BELIC) are available. If this is the case, we overwrite the customer tax classification TAXK1 with C (construction provider). This tax classification must have been created earlier. For details, refer to Chapter 3, Section 3.2.1. Note that if there were multiple entries in the license table for one customer, we could either adapt the selection to include a validity date, or we could loop over the selected entries to choose the one that matches.

USEREXIT_NEW_PRICING Program MV45AFZB contains two user exits—USEREXIT_NEW_PRICING_VBAP and USEREXIT_ NEW_PRICING_VBKD—that enable you to automatically carry out pricing again for changes made to a certain item field that would not trigger a new pricing automatically within the SAP standard. They work similarly for data stored in different tables. We’ll show you an example with USEREXIT_NEW_PRICING_VBKD. Several parameters are relevant for tax determination in SAP S/4HANA, which trigger a redetermination of indirect tax. These parameters include, for example, the supplying plant and the country of the ship-to party. For some scenarios, the Incoterm, indicating the party with the transport obligation, becomes a relevant parameter. Usually, the change of the Incoterm in the sales order should re-trigger indirect tax determination to fulfill the indirect tax regulations and to redetermine the tax code correctly. This may be relevant, for example, if a customer established in the country of departure picks up the goods and exports them to a third country (i.e., Incoterm EXW). This, in most jurisdictions, leads to a domestic supply of goods from an indirect tax perspective. If you or somebody on your behalf transports the goods to a third country, in most jurisdictions, it will lead to an export of goods.

Note This isn’t meant to be indirect tax advice in any way, but merely shows an example of an indicator that may be relevant for the identification of different tax scenarios and, thus, may be relevant to trigger new tax determinations.

The code for this is rather simple, as shown in Listing 6.7: Within an IF condition, we compare the value stored in field INCO1 in the database to the value currently in INCO1. If they are different, we execute a new pricing with condition G (copy price elements unchanged and redetermine taxes). For details, also refer to Chapter 4, Section 4.3.

273

6

Custom Coding for Indirect Taxes

IF vbkd-inco1 NE *vbkd-inco1. new_pricing = 'G'. ENDIF. Listing 6.7 Carry Out New Pricing for Incoterm Change

6.2.2 Invoices Program RV60AFZZ contains the most relevant user exits for indirect tax. It contains a number of user exits for sales document processing. As we’ve covered USEREXIT_PRICING_PREPARE_TKOMK and USEREXIT_PRICING_PREPARE_TKOMP in the previous section, and USEREXIT_MOVE_FIELD_TO_VBRK and USEREXIT_MOVE_FIELD_TO_VBRP are very similar to USEREXIT_MOVE_FIELD_TO_VBAK/VBAP, we’ll focus on an example of USEREXIT_PRICING_PREPARE_TKOMK that is unique to the billing document, as well as USEREXIT_NUMBER_RANGE within this program.

USEREXIT_PRICING_PREPARE_TKOMK for Billing Documents This user exit in program RV60AFZZ is called when the billing document is created. Analogously as for the sales order, the information for the communication structure containing pricing data can be modified. Let’s look at an example. In some jurisdictions, credit notes or generally reversals of documents must be reported in a different box of the indirect tax return. Credit notes have a separate billing type in SAP S/4HANA: G2 in the SAP standard. Generally, there would be at least two options for how to solve this from a tax determination perspective: (1) create a condition table that includes the billing type, or (2) overwrite one of the primary tax determination parameters—the material tax classification or customer tax classification— depending on the billing type used. There are pros and cons for both options. Creating an additional condition table often leads to a more complex access sequence and tax determination, but easier maintainability. Overwriting a parameter can be more desirable, especially if one access sequence is used for multiple company codes. We’ll look at option 2: overwriting a parameter. We start by creating a Z table, which would look something like Table 6.2. Sales Organization

Billing Type

Material Tax Classification

0001

G2

C

Table 6.2 Z Table for Overwriting Material Tax Classification Based on Billing Type

Z Tables versus Hard Coding Although it’s possible to hard code the company code and billing type combination, this is generally not advised as it’s very inflexible and not good practice. When using a Z

274

6.2

User Exits for Tax Determination in Sales

table, the values used for changing a tax parameter are clearly defined and aggregated. This information can be called on in the code, and, if changes are necessary, they can be done in the table without touching the code. In contrast, when hard coding the information, any change of logic or parameters must always be done in the code.

Generally, we want to overwrite the material tax classification with C (correction)—a material tax classification we’ve created previously (also refer to Chapter 3, Section 3.2.1) for sales organization 0001 if the billing type is G2 (credit note). Our code snippet shown in Listing 6.8 does exactly that, starting with declaring a local variable lv_taxm1 to hold the material tax classification. This is important, as a select from the Z table can be empty if we have a billing type that isn’t maintained. In that case, a correct material tax classification could be overwritten with an incorrect empty value. Then, we make a simple select to our Z table zztaxm1 and select the material tax classification value that matches the combination of sales organization and billing type. If our local variable lv_taxm1 isn’t empty, we overwrite field tkomk-taxm1—the material tax classification during pricing. DATA: lv_taxm1 TYPE taxm1. SELECT SINGLE taxm1 INTO lv_taxm1 FROM zztaxm1 WHERE vkorg = tkomk-vkorg AND fkart = tkomk-fkart. IF lv_taxm1 IS NOT INITIAL. tkomk-taxm1 = lv_taxm1. ENDIF. Listing 6.8 Change Material Tax Classification for Billing Type

USEREXIT_NUMBER_RANGE for Billing Documents The internal number range used in the standard system is specified in the billing type table and can be changed in the USEREXIT_NUMBER_RANGE user exit. This user exit is only called when the billing document is created. In most jurisdictions, consecutive numbering of invoice documents is required within that jurisdiction, without any gaps. In SAP standard, the number range is assigned at the document type level and for the billing document at the billing type level. This assignment is then valid for all countries due to upward compatibility. SAP Note 595327 describes the solution we’ll be referring to: using a dedicated user exit to change the internal number range for the billing document. However, instead of the hard coding provided in the SAP Note, we’ll be using a table for maintainability reasons. Z table ZZNUMBERRANGE can look like Table 6.3.

275

6

Custom Coding for Indirect Taxes

VKORG

LANDTX

FKART

NUMKI

0001

PT

F2

10

0001

PT

G2

11

Table 6.3 Example Z Table for Number Range Assignment

In our user exit USEREXIT_NUMBER_RANGE within program RV60AFZZ, we add the small code snippet shown in Listing 6.9 that selects the number range numki from our Z table into the internal number range us_range_intern if there is a match for sales organization vkorg, country landtx, and billing type fkart. SELECT SINGLE numki INTO us_range_intern FROM zznumberrange WHERE vkorg = vbrk-vkorg AND fkart = vbrk-fkart AND landtx = vbrk-landtx. Listing 6.9 Change Number Range for Billing Document

6.2.3 Additional Enhancements So far, we’ve looked at the two most relevant includes for system enhancements and user exits for the sales order and billing document. However, there are other relevant enhancement points that you’ll come across during your indirect tax implementation in SAP S/4HANA. In this section, we’ll look at routines for access requirements and the includes for value-added tax (VAT) ID determination.

Access Requirements As you’ve learned in Chapter 4, Section 4.1.5, access requirements control the access to condition tables within an access sequence. An access requirement consists of a piece of code within a routine. To reach the routines for pricing, use Transaction VOFM, and choose Requirements • Pricing in the menu. This will lead you to an overview of all pricing routines in the system, as shown in Figure 6.2.

Figure 6.2 Access Requirements Overview

276

6.2

User Exits for Tax Determination in Sales

As described earlier, the most relevant for indirect tax in SAP standard are routines 7 (Domestic business) and 8 (Export business). To reach the source code, simply doubleclick the routine.

Activate the Routines If you change a routine or create a new routine, it’s important to run report RV80GHEN to activate the routines. This must also be done in all following systems after transport of the routine.

If you want to change a routine, it’s best practice to leave the SAP standard routines and to copy them into a new routine within the customer namespace. For routines, you use a number starting with 9, such as 907 for the copy of routine 7. Let’s consider routine 8 (Export business) as an example. The code shown in Listing 6.10 is mostly SAP standard. To extend it depending on the requirements of your jurisdiction, it’s necessary to understand how it’s structured. You’ll recognize the statement form from Section 6.1.4. It structures the routine and tells us that it’s a subroutine called during the execution of a higher program. The program starts by setting sy-subrc—the return code of the program—to 4 (error). This means that we start off with the requirement for the access to a condition table not fulfilled. Following this, there are three lines introduced by keyword check. This statement checks the validity of a statement. If the statement is valid, the program continues. If it’s invalid, the processing block—and in this case the entire subroutine—is terminated. This means that three conditions must be fulfilled to proceed within the access requirement for cross-border transactions. First, the tax departure country komk-aland and the tax destination country komk-land1 can’t be empty and can’t be equal. Should these two checks succeed, we reach an IF condition that indicates this routine should only be used for tax conditions, that is, for condition types with condition class (field komt1-koaid) D (taxes). This means that this routine could not be assigned, for example, to a discount condition type. Inside this IF condition, there is another IF condition. This is a cumulative IF condition linked by three and statements, followed by an exit statement. What leads to the fulfillment of the access requirement and not to an exit are two possible options: In the first option, both the tax departure country and tax destination country are part of the EU (identified by EU indicator at005-xegld and et005-xegld = 'X'), and there is a European VAT ID number of the customer available (field komk-stceg). In the second option, either one or both of the tax departure countries aren’t part of the EU, making the VAT ID irrelevant. In that case, sy-subrc, the return value of the program, is set to 0 (success). If we’re in the situation that both countries are part of the EU and the VAT ID is empty, the program exits with return value 4 (error).

277

6

Custom Coding for Indirect Taxes

You’ll see a second form kobev_008 labeled Prestep by a comment below. This is a check that is made before the elaborate check in form kobed_008 is started for performance reasons. The checks performed include whether the tax departure and destination countries aren’t empty and aren’t the same. There is no check for whether the countries are part of the EU, as the prestep will end immediately if they are the same. If the check succeeds, form kobed_008 starts. form kobed_008. sy-subrc = 4. check: komk-aland ne space. check: komk-land1 ne space. check: komk-aland ne komk-land1. if ( komt1-koaid eq 'D' ) . "Only for tax conditions if ( at005-xegld eq 'X' ) and "participant european community ( et005-xegld eq 'X' ) and ( komk-stceg is initial ) . exit. endif. endif. sy-subrc = 0. endform. * Prestep form kobev_008. sy-subrc = 4. check: komk-aland ne space. check: komk-land1 ne space. check: komk-aland ne komk-land1. sy-subrc = 0. endform. Listing 6.10 Access Requirement 08 for Tax Conditions

There are several extension scenarios for this routine or its partner routine 7 for domestic supplies. For example, it could be extended by a check for special territories— such as Northern Ireland, which still belongs to the EU VAT union but is part of the United Kingdom, or the Canary Islands that belong to Spain but aren’t part of the EU VAT union. Furthermore, it can be extended by a check for the country of the VAT ID. Since 2020, there is a rule in the EU that says if the middleman in a chain transaction uses the VAT ID of the departure country, it can be assumed this middleman will be responsible for the transport. This means that the first transaction between the seller and the middleman will be subject to domestic VAT, while the second transaction between the middleman and the final recipient of the goods may be exempt from VAT.

278

6.2

User Exits for Tax Determination in Sales

Tax ID Determination If you’re using rule A (generally from sold-to party), or B (generally from payer) for the tax ID determination, you can use an include to enhance the tax ID determination. As also described in SAP Note 91109, the include for the sold-to party is V05EZZAG, and the include for the payer is V05EZZRG. Logic-wise they work the same; only the suffix depending on the partner role used must be taken into account. If you’re using rule A and want to use the tax ID of the residence country of the sold-to party in case that the sold-to party doesn’t have a tax ID in the country of destination, you can use include V05EZZAG to implement this. Let’s look at our example shown in Listing 6.11. We start with an IF condition, checking if the tax ID of the sold-to party (field kuagv-stceg) is empty. If it’s not, we’ve already determined a tax ID in the tax departure country and this enhancement must not be called. Then, within another IF condition, we check that the tax ID of the customer in the country of residence, that is, from the customer master data table KNA1 (field lkna1stceg), isn’t empty and that the tax departure country (here, field vtcom-lland) isn’t the same as the residence country (lkna1-land1). In the next step, we check if we’ve already made a selection from country data table T005. If not, we select the entire information for the tax destination country (vtcomlland) from table T005. If we already have that data available, that is, if our field t005land1 equals the tax destination country and the country is a country within the EU (indicated by field t005-xegld, the EU indicator), we fill the tax ID of the customer (field kuagv-stceg) with the tax ID from the customer master data (field lkna1-stceg) and the country of the tax ID (field kuagv-stceg_l) with the country of residence from the customer master data (field lkna1-land1). IF kuagv-stceg IS INITIAL. IF NOT lkna1-stceg IS initial AND vtcom-lland NE lkna1-land1. IF t005-land1 NE vtcom-lland. SELECT SINGLE * FROM t005 WHERE land1 = vtcom-lland. ENDIF. IF t005-land1 = vtcom-lland AND NOT t005-xegld IS INITIAL. kuagv-stceg = lkna1-stceg. kuagv-stceg_l = lkna1-land1. ENDIF. ENDIF. ENDIF. Listing 6.11 Tax ID Determination in Include V05EZZAG

Note that there are many more user exits and enhancement points that can be used to implement indirect tax-relevant requirements than those that we’ve mentioned here. We wanted to give you an overview of the most common enhancement points that we

279

6

Custom Coding for Indirect Taxes

touch in most projects. However, the individual legal and functional requirements should always be assessed during the beginning of an SAP S/4HANA implementation— also considering other requirements than the examples described.

Standard Tax Determination Parameters in Sales and Distribution Many relevant system enhancements in the order-to-cash process include interfaces to external systems. A few examples are pre-systems for order management (e.g., online shops or sales management systems). These external systems usually have an interface into the system. Thus, the mapping and integration of data from external systems into the SAP S/4HANA system should be considered closely. From an indirect tax perspective, the most important point is that all information required for tax determination is available in the best possible quality. Table 6.4 shows the standard parameters that must always be available and where they usually originate from. Data Description

Data Field

Source

Tax departure country

KOMK-ALAND

Supplying plant VBAP-WERKS/VBRP-WERKS

Tax destination country

KOMK-LAND1

Ship-to address

KNA1-LAND1 VAT ID of the customer

KOMK-STCEG

KNA1-STCEG/KNAS-STCEG

Material tax classification for the country

VBAP-TAXM1

MLAN-TAXM1 (relation to

Customer tax classification

VBAK-TAXK1

plant and sales organization)

KNVI-TAXKD (relation to sales organization, distribution channel, and division)

Table 6.4 SAP Standard Tax Determination Parameters in Sales and Distribution

6.3 Customer Exits for Tax Determination in Purchasing The exits we’ll be looking at on the purchasing side aren’t user exits, but rather customer exits. Therefore, the approach to identifying them is different. We’ll explain how to identify customer exits next, then explore some specific customer exits relevant for tax determination in purchasing, and end with some additional enhancements to consider.

280

6.3

Customer Exits for Tax Determination in Purchasing

6.3.1 Identifying Customer Exits To identify a user exit, you need to know the program that contains it. To identify a customer exit, on the other hand, you use Transaction SMOD—the overview of all enhancements in the SAP system—and enter the enhancement name if you know it, as shown in Figure 6.3. If you don’t, press the (F4) help and enter a keyword to help your search, such as pricing.

Figure 6.3 Identifying a Customer Exit

The enhancement names for the extended communications structure KOMK and KOMP for pricing are LMEKO001 and LMEKO002, respectively. You can see the components—that is, the function exits that are part of the enhancement—by choosing the Components radio button and clicking the Display button to arrive at the screen shown in Figure 6.4.

Figure 6.4 Viewing Components

After you’ve identified the enhancements that include the exits you want to use, you can use Transaction CMOD to view, create, and modify all customer projects where Transaction SMOD enhancements are implemented. Such an enhancement implementation must always be part of a project. In the overview, create a project to get started with the implementation of our enhancements for pricing on the tax input side (see Figure 6.5). Enter a Project name (“Z_ITX_AP”, in our example), select Enhancement Assignment under Subobjects, and click Create.

281

6

Custom Coding for Indirect Taxes

Figure 6.5 Creating the Project

You’ll be prompted to give a Short text for your project, as shown in Figure 6.6.

Figure 6.6 Adding the Project Description

From there, click on the Enhancement assignments button. This will lead you to the overview in Figure 6.7. Here, enter the enhancements that you want to activate. This assignment of the enhancement to a project is important, as you may otherwise well be able to add code, but it won’t be called during the execution of the pricing in purchasing. Basically, you can imagine it as creating a function that is never called.

Figure 6.7 Enhancement Assignments

In the next step, you can reach the source code directly by double-clicking on the function module name in Transaction SMOD overview (refer to Figure 6.4). The implementation of these exits is also different. It’s not possible to change the source code of the function module (e.g., EXIT_SAPLMEKO_001) directly, but you’ll rather create an implementation of the include inside this exit by double-clicking on it. There will be a warning on the bottom of the screen (see Figure 6.8). Simply press (Enter) to continue.

282

6.3

Customer Exits for Tax Determination in Purchasing

Figure 6.8 Warning for Implementation of Include

In the popup shown in Figure 6.9, click Yes, and enter the transport and package.

Figure 6.9 Create Include for EXIT SAPLMEKO

These Exits Aren’t Includes but Functions The enhancements in Transaction SMOD aren’t includes like we’ve used with the user exits in sales and distribution, but rather functions. This means that in contrast to sales and distribution user exits where you can see, use, and modify all relevant data, in materials management, you can only use the tables and variables that are explicitly imported in the declaration of the function.

The most relevant information for indirect tax determination on the purchase order is stored in structures KOMK and KOMP, as well as tables EKKO, EKPO, and LFA1. If you’re using purchase info records, tables EINA and EINE will be relevant for you as well. Similarly to tax determination in sales and distribution, structures KOMK and KOMP store the information for pricing on the header and item level. However, they are filled differently, that is, filled differently between the sales order and the billing document. For example, structure KOMK contains a field for the billing type. Naturally, as we’re not looking at pricing for a billing document, this field will be empty. Additionally, there are

283

6

Custom Coding for Indirect Taxes

some fields that are used in sales and distribution pricing that aren’t filled for materials management pricing. For example, you’ll remember the customer tax classification as a central part of pricing on sales documents. As the customer tax classification is part of the customer master data (table KNA1) and not of the supplier master data (table LFA1), the field isn’t filled despite a connection in SAP S/4HANA between the customer and vendor master data via the business partner. Tables EKKO and EKPO are the standard tables that contain the purchase order data— such as table VBRK and table VBRP on the output side. Table LFA1, as mentioned, is the supplier master data table. In Chapter 4, Section 4.2.1, we looked at different options for pricing and indirect tax determination on the input side. Next to the condition technique, purchase info records are another option to determine indirect taxes. Purchase info record information is stored in two tables: table EINA stores the general information for the purchase info record, and table EINE stores the purchase info record applied to certain purchasing documents, including the number of the info record, the purchasing organization, and the tax code.

6.3.2 EXIT_SAPLMEKO_001 Let’s have a look into EXIT_SAPLMEKO_001. With this exit, you can change the values in structure KOMK, which is the communication header for pricing. As we mentioned earlier, these exits are functions and not includes, which means that you can only use the tables and variables that are explicitly imported in the declaration of the function. You see these parameters right in the beginning of the function. For EXIT_SAPLMEKO_001, this would look like Listing 6.12. *"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(I_EKKO) LIKE EKKO STRUCTURE EKKO OPTIONAL *" VALUE(I_EKPO) LIKE EKPO STRUCTURE EKPO OPTIONAL *" VALUE(I_LFA1) LIKE LFA1 STRUCTURE LFA1 OPTIONAL *" VALUE(I_T001) LIKE T001 STRUCTURE T001 OPTIONAL *" VALUE(I_LFM1) LIKE LFM1 STRUCTURE LFM1 OPTIONAL *" VALUE(I_T001W) LIKE T001W STRUCTURE T001W OPTIONAL *" VALUE(I_KOMK) LIKE KOMK STRUCTURE KOMK *" VALUE(I_EINA) LIKE EINA STRUCTURE EINA OPTIONAL *" VALUE(I_EINE) LIKE EINE STRUCTURE EINE OPTIONAL *" VALUE(I_WEDATEN) LIKE MEPRWE STRUCTURE MEPRWE *" OPTIONAL *" TABLES *" T_EKPA STRUCTURE EKPA OPTIONAL

284

6.3

*" *"

Customer Exits for Tax Determination in Purchasing

CHANGING VALUE(E_KOMK) LIKE KOMK STRUCTURE KOMK

Listing 6.12 Imported and Exported Variables and Tables for EXIT_SAPLMEKO_001

Several tables are imported, such as the purchasing document header and item EKKO and EKPO, vendor master data LFA1, company code data in T001, vendor information by purchasing organization LFM1, plant data via T001W, structure KOMK, purchasing record information EINA and EINE, and pricing date information MEPRWE and partner role table EKPA. The only information changed is structure KOMK. EXIT_SAPLMEKO_001 then contains only the include ZXM06U14 that we’ve implemented

earlier. As a reminder, an include means that at runtime, the code is inserted into the program. Thus, we can only use the part of the function that contains the include. Let’s consider an example, as shown in Figure 6.10. Company C, a car dealer, buys cars from other businesses and private individuals. In most jurisdictions, transactions made by private individuals aren’t subject to indirect tax.

Company P Car Producer Outside Scope of

Company C Car Dealer

19% Indirect Tax

Private Individual

Indirect Tax

Company D Car Dealer

Figure 6.10 Schematic Overview of Company C’s Purchases

On the output side, where company C sells cars to businesses and private individuals, they are using the customer tax classification as an indicator in their tax determination. On the input side, however, this indicator doesn’t exist. Our goal for this enhancement is to find a way to use the customer tax classification in materials management pricing. Table 6.5 shows the condition table we could be using, which is standard table A086 extended by the customer tax classification. LLAND (Tax Destination Country)

TAXIM (Tax Indicator Material)

TAXIL (Tax Indicator Import)

TAXIW (Tax Indicator Plant)

TAXK1 (Tax Classification)

DE

1

0

1

1

DE

1

0

1

N

Table 6.5 Customer Tax Classification for Materials Management Tax Determination

285

6

Custom Coding for Indirect Taxes

We want to present two possible solutions to you. In solution one, we check the tax ID of the vendor. If the vendor has a tax ID, we can expect the supplier to be a business. If the vendor doesn’t have a tax ID, we expect it to be a private individual. This is only possible if the tax ID is properly maintained in the vendor master data. The code for this is a simple IF condition, as shown in Listing 6.13. We check the imported table of vendor master data for the tax ID. In this case, we only check the European VAT ID (field STCEG), but depending on your jurisdiction, you may want to include other fields such as STCD1. If the tax ID exists, we set the customer tax classification field TAXK1 to 1 (taxable). If not, we set it to N (natural person). N isn’t an SAP standard customer tax classification and must be created first. Refer to Chapter 3, Section 3.2.1, for details. This value is then stored in structure KOMK during pricing on the input side and can be used for indirect tax determination on the purchase order. IF I_LFA1-STCEG IS NOT INITIAL. E_KOMK-TAXK1 = 1. ELSEIF I_LFA1-STCEG IS INITIAL. E_KOMK-TAXK1 = 'N'. ENDIF. Listing 6.13 Determine Customer Tax Classification by VAT ID

In solution two, as shown in Listing 6.14, we use a connection that only exists in SAP S/4HANA: the connection between the vendor and customer master data via the business partner. We select the customer tax classification TAXKD from table KNVI into structure KOMK where the customer number matches the supplier (KUNNR = IBPC~CUSTOMER), and the country of the tax classification matches the tax destination country (ALAND = @I_KOMK-LAND1). To do so, we need to join the business partner both from the supplier side and customer side. SELECT SINGLE TAXKD FROM KNVI LEFT JOIN I_BUSINESSPARTNERSUPPLIER AS IBPS ON IBPS~SUPPLIER = @I_LFA1-LIFNR LEFT JOIN I_BUSINESSPARTNERCUSTOMER AS IBPC ON IBPS~BUSINESSPARTNER = IBPC~BUSINESSPARTNER WHERE KUNNR = IBPC~CUSTOMER AND ALAND = @I_KOMK-LAND1 INTO @E_KOMK-TAXK1. Listing 6.14 Determine Customer Tax Classification by Link of Vendor and Customer via Business Partner

To illustrate, look at Figure 6.11 where you can see the internal business partner for the supplier and for the customer. Here, we want to make you aware of two things. First, in this case, the supplier number, business partner number, and customer number are all the same. This is good practice but may not always be the case in a live system. Second,

286

6.3

Customer Exits for Tax Determination in Purchasing

note how the tables are IBPSUPPLIER and IBUPACUSTOMER instead of I_BUSINESSPARTNERSUPPLIER and I_BUSINESSPARTNERCUSTOMER as we’ve used. We’re using a core data services (CDS) view that contains information about the supplier-business partnercustomer relationship instead of the actual table. This has certain benefits, such as better performance and access to authorizations.

Figure 6.11 Business Partner to Supplier and Customer Relation Tables

6.3.3 EXIT_SAPLMEKO_002 With EXIT_SAPLMEKO_002, you can change the values in structure KOMP, the communication item for pricing. Like SAPLMEKO_001, this exit is a function and not an include. This means that you can only use the tables and variables that are explicitly imported in the declaration of the function. Let’s consider an example, as shown in Figure 6.12. Company P has an organizational setup in SAP that includes one plant per country with several storage locations. One of these storage locations is a customs warehouse. Customs warehouses usually receive special treatment from an indirect tax perspective, as the goods are located physically in the country but aren’t fully imported. They can be stored but can’t be sold before they are imported.

Company Code of Company P

Plant India

Plant Bulgaria

Plant China

Warehouse 1

Warehouse 2

TAXIW 1

TAXIW 1

Customs Warehouse TAXIW 0

Figure 6.12 Organizational Setup of Company P

As you’ve learned in Chapter 3, Section 3.2.1, the tax indicator plant (TAXIW) can only be assigned on the plant level. Now, it’s possible to create a new plant. However, there is a

287

6

Custom Coding for Indirect Taxes

high master data maintenance effort involved. Alternatively, you can change the tax indicator plant on the item level for the storage location of the customs warehouse. As in all the previous examples, we start with creating a Z table instead of hard-coding the customs warehouse into EXIT_SAPLMEKO_002. Our Z table in the example will be called ZZS_CustomsWarehouse and will contain four fields, as shown in Table 6.6: the company code (field BUKRS), plant (field WERKS), storage location (field LGORT), and tax indicator plant. BUKRS (Company Code)

WERKS (Plant)

LGORT (Storage Location

TAXIW (Tax Indicator Plant)

1000

0001

0003

0

Table 6.6 Example Table ZZS_CustomsWarehouse

We start by declaring a local variable to store the tax indicator plant, as shown in Listing 6.15. Then, we check if our table ZZS_CustomsWarehouse has a match maintained for the combination of company code (I_KOMK-BUKRS), plant (I_EKPO-WERKS), and storage location (I_EKPO-LGORT). If it does, we select the tax indicator plant and overwrite it in structure KOMP. DATA: LV_TAXIW TYPE KOMP-TAXIW. SELECT SINGLE TAXIW FROM ZZS_CUSTOMSWAREHOUSE WHERE BUKRS = I_KOMK-BUKRS AND WERKS = I_EKPO-WERKS AND LGORT = I_EKPO-LGORT INTO E_KOMP-TAXIW. IF LV_TAXIW IS NOT INITIAL. E_KOMP-TAXIW = LV_TAXIW. ENDIF. Listing 6.15 Change Tax Indicator Plant for Storage Location

6.3.4 Additional Enhancements Many relevant system enhancements in the procure-to-pay (also in order-to-cash and logistics) process include interfaces to external systems. A few examples are presystems for order management (e.g., SAP Ariba or alternatives mentioned in Chapter 4, Section 4.2.5, other supplier online shops or purchase management systems) and optical character recognition (OCR) software. These external systems usually have an interface to the system. Thus, a large portion of the materials management system enhancements consists of the mapping and integration of external systems into the SAP S/4HANA system.

288

6.4

Summary

Generally, SAP offers a number of technologies to realize interfaces, such as remote function call (RFC), Business Application Programming Interface (BAPI), intermediate document (IDoc), Simple Object Access Protocol (SOAP), and representational state transfer (REST). Which technology is the best for a certain interface must be decided on a case-by-case basis. From an indirect tax perspective, the most important point is that all information required for tax determination is available in the best possible quality. For example, it’s possible that a pre-system enables users to enter information into text fields that are mapped to SAP. Classic examples are Incoterms or delivery addresses, which are often entered manually and can lead to indirect tax risks. Adequate controls and validations should be in place for interface data.

Standard Tax Determination Parameters for Materials Management Table 6.7 shows the standard parameters that must always be available and where they usually originate from. Data Description

Data Field

Source

Tax departure country

KOMK-ALAND

LFA1-LAND1 (derived from country of supplier)

Tax destination country

KOMK-LAND1

T001W-LAND1 (derived from country of receiving plant)

Tax indicator import

KOMP-TAXIL

Populated from ME_FILL_KOMP_PO. If departure country equals destination country → TAXIL = 0 If departure country isn’t equal to destination country:

쐍 If departure country is non-EU → TAXIL =1 쐍 If departure country is EU → TAXIL = 2 Tax indicator plant

KOMP-TAXIW

T001W-TAXIW

Tax indicator material

KOMP-TAXIM

MLAN-TAXIM

Material group

EKPO-MATKL

EKPO-MATKL

Table 6.7 SAP Standard Tax Determination Parameters in Materials Management

6.4 Summary In this chapter, you’ve learned about deeply technical topics relevant to indirect tax determination in SAP. This overview should bring you closer to understanding the regulatory requirements that your company has and how they translate into a technical language.

289

6

Custom Coding for Indirect Taxes

Note that enhancements like this should always be tested in detail with positive and negative tests. Positive tests are test cases that include the expected result. For example, if you overwrite the tax destination country for the supply of service, you would test a supply of service with a delivery address different from the country of residence of your customer. Negative tests are test cases that ensure that there are no interferences in other areas and that your enhancement can handle invalid or unexpected input. In our example, you would, for example, test a normal supply of goods and ensure that the tax destination country isn’t overwritten. Despite there being coding examples, we always recommend involving an implementation partner who has the technical knowledge to understand, implement, and test these requirements. In the next chapter, we’ll switch gears from indirect tax and dive into direct tax determination in SAP S/4HANA.

290

Chapter 7 Direct Taxes in SAP S/4HANA In this chapter, we’ll explain which capabilities SAP S/4HANA offers in the area of direct taxes and how these can be implemented. This provides the basis for highly automated income tax reporting and compliance processes, as well as contributes significantly to a datadriven tax function.

Direct taxes include all types of taxes that are assessed and levied at the level of the taxpayer and are based on the profit or taxable income of the company. This covers in particular the area of income taxes (e.g., corporate income tax), including withholding tax (WHT) as a special form of levy. After a brief introduction to the essential tasks of the direct tax function, we’ll explain how you can support the end-to-end process for taxes in the areas of data capturing and tax determination, analysis and monitoring, tax filing and reporting, and tax planning through organizational and master data structures available in SAP S/4HANA and SAP-integrated applications. For example, we’ll discuss the importance of SAP Tax Compliance, SAP S/4HANA embedded analytics, SAP Profitability and Performance Management, and SAP Analytics Cloud for direct taxes. This chapter will provide you with a better understanding of the major fields of play in SAP S/4HANA from a direct tax perspective so that you can incorporate tax requirements into your SAP S/4HANA implementation project in a structured manner. At the same time, you’ll gain insights into different use cases of the SAP-integrated applications presented. This should enable you to develop your own strategy for the future design of end-to-end tax processes and weigh it against your existing system landscape.

7.1 Direct Tax Basics In the field of direct taxes, the tax function has a wide range of tasks, which mainly include the following activities: 쐍 Supporting the preparation of annual financial statements in the context of tax

reporting, that is, ensuring the correct presentation of the net assets, financial position, and results of operations in the individual and consolidated financial statements from an income tax perspective

291

7

Direct Taxes in SAP S/4HANA

쐍 Fulfillment of tax filing obligations, that is, submission of corporate income tax and

trade tax returns, including tax balance sheets in electronic form 쐍 Management of tax audits, for example, evaluation of tax audit findings and their

impact on annual financial statements and assessments 쐍 Monitoring of income tax risks as part of tax compliance management through

process-integrated/ERP-based controls 쐍 Fulfillment of tax withholding obligations in current business operations

SAP S/4HANA can support the tax function in all of these areas with comprehensive capabilities. You’ll learn more about these capabilities in the following sections. It’s crucial that you also see the implementation of SAP S/4HANA for direct taxes as an opportunity and take advantage of this potential.

7.1.1 End-to-End Process for Direct Taxes The tasks of the tax function from the perspective of the overall project mainly tie in with the record-to-report scenario of the company. For the area of direct taxes, these tasks are extended by tax-owned end-to-end processes, as shown in Figure 7.1. Data Capturing + Tax Determination SAP S/4HANA

Tax Data Analytics + Monitoring SAP S/4HANA Embedded Analytics

Tax Data Warehouse

SAP Tax Compliance

Ledger Organizational Structures

Tax Data Mart

Tax Filing + Reporting Master Data Third-Party Solution Asset Accounting

SAP Document and Reporting Compliance

Tax Data Mart Chart of Accounts Financial Statement Version Tax Tagging

Tax Planning Tax Data Mart

WHT

SAP Analytics Cloud

Figure 7.1 End-to-End Process for Direct Taxes

With regard to the first phase shown in Figure 7.1, data capturing and tax determination, you’ll create the structures in Customizing that should enable you to capture taxrelevant data in the desired quality, granularity, and availability in operational business. At the same time, you provide the basis for an automated tax determination. SAP S/4HANA can thus play an important role as a data provider for the tax function, which

292

7.1 Direct Tax Basics

is the fundamental basis for all tasks in the further phases of the end-to-end process for taxes. Following are the important questions that we’ll address in this context: 쐍 How can tax balance sheets be mapped along the tax lifecycle in SAP S/4HANA using

the concept of parallel ledgers? 쐍 Which organizational structures need to be created in SAP S/4HANA so that tax-

related corporate structures such as taxation subjects are mapped appropriately? 쐍 How can master data structures be defined in SAP S/4HANA so that they support the

recording of tax-relevant facts in the best possible way? 쐍 How can the fixed asset accounting be designed to meet the requirement of parallel

tax valuation areas? 쐍 How can you set up the chart of accounts in SAP S/4HANA to enable automated

transfer of account balances, especially off-balance sheet items for tax reporting, tax return preparation, and e-balance sheet purposes? 쐍 What alternatives to the chart of accounts, such as the use of a tax tagging concept,

are available for direct taxes? 쐍 How can you set up the basic or extended WHT function in SAP S/4HANA so that it

efficiently supports tax determination and tax reporting? Once you’ve familiarized yourself with these questions and associated settings in Customizing in Section 7.2 and Section 7.3, you’ll already be a little closer to your goal of setting up your tax function more efficiently in the area of direct taxes. Based on this, you can consider how you’ll use the tax data you can provide in SAP S/4HANA in the further phases of the end-to-end tax process. The second phase, tax data analytics and monitoring, focuses on whether the tax data recorded in the system also meets the requirements for the desired tax data quality. In Section 7.5, we therefore look at the options for analyzing the quality of tax-relevant data in SAP S/4HANA. For this purpose, we’ll give you an overview of SAP Tax Compliance and SAP S/4HANA embedded analytics. You’ll find suggestions for analyzing and monitoring direct taxes, for example, using core data services (CDS) in SAP S/4HANA. In this way, we’ll provide you with tools that can support you in operationalizing your tax control framework for the area of direct taxes. In the third phase, tax filing and reporting, you can establish the connection between the tax data held in SAP S/4HANA on the one hand and the software solutions for tax filing and reporting on the other. In addition to the standard reports available in SAP S/4HANA, you can prepare the data for third-party applications using your own tax data management. SAP Document and Reporting Compliance is another solution of interest with regard to direct taxes. This applies in particular to the area of WHT and the fulfillment of reporting obligations in accordance with the Standard Audit File for Tax (SAF-T) initiated by the Organization for Economic Cooperation and Development (OECD) for companies with extensive foreign activities. We’ll cover these topics in Section 7.6.

293

7

Direct Taxes in SAP S/4HANA

In the fourth phase, tax planning, you can use SAP Analytics Cloud as a planning tool for the area of direct taxes. In Section 7.7, you’ll learn which functions SAP Analytics Cloud includes, for which planning scenarios the solution is suitable, and how you can implement the first use cases.

7.1.2 Direct Tax Organizational Structures and Master Data Setting up organizational structures and master data is one of the core tasks in the implementation of SAP S/4HANA and forms the central basis for the subsequent operational use of the system. Because it’s often no longer possible to change settings at a later point in time, or only with a disproportionate amount of effort, the tax requirements for organizational structures and master data must also be incorporated into the implementation project at an early stage. In this section, we’ll provide you with the essential requirements for the area of direct taxes and provide you with recommendations on how to implement them with regard to your daily work. In detail, we’ll take a closer look at the organizational structures and master data that have a tax significance. Tax organizational structures in direct taxes include the following: 쐍 Ledger 쐍 Company code/further organizational units 쐍 Chart of accounts 쐍 Balance sheet structures/e-balance sheet 쐍 WHT

Master data in the area of direct taxes includes the following: 쐍 Personal account master data (business partner: debtors, creditors) 쐍 General ledger account master data 쐍 Asset master data

Even though you’ll be working as a tax function at the user level in SAP S/4HANA and customizing will be left to your IT team, we’ll provide you with insights into customizing so you can better understand and address the tax requirements in the area of organizational structures and master data. You may also have the option of accessing a sandbox or test environment as a tax function, which gives you the opportunity to familiarize yourself with the settings in Customizing. Provided you have the necessary authorizations, you can access Customizing by selecting Transaction SPRO in the SAP Easy Access menu. After executing Transaction SPRO, you can display the SAP Reference Implementation Guide (IMG). In the IMG, most of the settings relevant for the area of direct taxes can be found under the Enterprise Structure or Financial Accounting items.

294

7.2

Organizational Structures

After you’ve opened the IMG, you can jump from here to the respective customizing activities. You’ll learn about the most important customizing settings for direct taxes in the following sections.

7.2 Organizational Structures First, we’ll introduce you to the basic tax-relevant organizational structures in SAP S/4HANA. As already mentioned in the introduction, these include in particular the customizing settings for ledger, company code, chart of accounts, and WHT.

7.2.1 Ledger Pursuant to local tax provisions, taxpayers usually must prepare a tax balance sheet that differs from generally accepted accounting principles under commercial law. Due to special tax accounting rules, there are often significant differences between the commercial and the tax balance sheet across the enterprise. Compared to the presentation of a commercial balance sheet, the tax balance sheet poses the particular challenge of having to anticipate different phases in the preparation of the tax balance sheet, the tax lifecycle: 1. Preparation of the annual financial statements In the first phase of preparing the annual financial statements, the tax balance sheet serves as the basis for determining current tax provisions and deferred taxes by comparing commercial and tax balance sheet positions. As a rule, not all detailed information from a tax perspective is available at this point. 2. Preparation of annual tax returns In the second phase, the completeness and correctness of the tax balance sheet prepared in the annual financial statements phase are checked. This serves as the basis for the preparation of the annual tax returns. Any necessary adjustments are made via return-to-provision adjustments before the tax balance sheet is submitted to the tax authorities as an enclosure to the tax return. 3. Tax audit In the third phase, the tax returns submitted for the tax audit period, including tax balance sheets, are taken up by the tax authorities. In the event of differing legal opinions, tax audit findings are often assessed with regard to the tax accounting. As audit-to-return adjustments, these may lead to further differences between the commercial and tax balance sheets (tax auditor’s balance sheet). These must be developed further in subsequent years based on the tax audit period. During these phases, the tax balance sheet is subject to ongoing changes (called trueups).

295

7

Direct Taxes in SAP S/4HANA

Due to its scope and complexity, this process of tax balance sheet preparation should be supported by your ERP system as much as possible. This applies all the more as the profit effects from differences between the commercial and tax balance sheets, together with off-balance sheet items such as nondeductible business expenses and tax-exempt income, form the main reconciliation items between the annual net profit under commercial law and the determination of the tax base. We’ll walk through key direct tax ledger concepts in the following sections, including the framework in SAP S/4HANA, and its setup and use in business operations.

Account Solution versus Ledger Solution Until the introduction of SAP S/4HANA, the picture in practice with regard to the process of tax balance sheet preparation was very heterogeneous: For the majority, the tax balance sheet was prepared outside the ERP system on the basis of Microsoft Excel or with the help of a tax balance sheet tool, if necessary, in combination with the account solution in SAP, limited to the time of preparation of the annual financial statements, as shown in Figure 7.2. Within the framework of the account solution, parallel accounting principles are represented by parallel accounts within a single general ledger. All postings are initially made according to the accounting principles of a previously defined leading general ledger (e.g., US Generally Accepted Accounting Principles [GAAP] or International Financial Reporting Standards [IFRS]). Deviating valuations in the tax balance sheet are then taken into account via delta postings. For this purpose, adjustment accounts (Laccounts) are created for the respective account of the leading general ledger, and the delta postings are recorded in the adjustment accounts. The actual tax balance sheet value of a balance sheet item is the balance of the underlying commercial balance sheet value and the adjustment entry to the tax balance sheet valuation. Parallel Accounting through Parallel Accounts in One Ledger

Account Solution

Tax

Local

IFRS Ledger X + Delta Postings

Figure 7.2 Account Solution

However, because the account solution directly uses the commercial general ledger and this is closed with the preparation of the annual financial statements, the account solution isn’t suitable for implementing the complete tax lifecycle from the preparation of the annual financial statements to the incorporation of tax audit findings. The

296

7.2

Organizational Structures

other phases of the tax lifecycle can only be mapped outside SAP. As a result, the preparation of the tax balance sheet according to this approach is characterized to a large extent by media disruptions and manual activities. The desire for a single point of truth for the tax balance sheet is therefore largely missed. In SAP S/4HANA, the aim should therefore be a complete mapping of the tax balance sheet in the ERP system along the entire tax lifecycle. Full posting of the tax balance sheet in the ERP system creates a central prerequisite for automated processing of the tax lifecycle from the creation of tax reporting to the preparation of tax returns or ERPbased tax planning. So, you can use the implementation of SAP S/4HANA to establish the tax balance sheet as a single source of truth for the tax function. SAP S/4HANA offers new possibilities to achieve this goal by combining different ledger functions. The concept of mapping parallel accounting rules via ledgers isn’t fundamentally new and is probably already familiar to those of you who have worked in SAP before. In contrast to the account solution, parallel accounting principles can be represented using parallel general ledgers in the ledger solution. Here, a separate general ledger is available for each relevant accounting principle of the company (see Figure 7.3).

Ledger Solution

Parallel Accounting through Parallel Ledgers

IFRS

Local

Tax

Ledger X

Ledger Y

Ledger Z

Figure 7.3 Overview of the Ledger Solution

In SAP S/4HANA, general ledgers managed in parallel are taken into account via standard ledgers (fixed ledgers). Companies that want to prepare consolidated financial statements in accordance with international accounting standards and at the same time use separate general ledgers for commercial and tax purposes generally create three parallel standard ledgers: 쐍 Standard ledger: Consolidated financial statements (e.g., IFRS) 쐍 Standard ledger: Individual financial statements under commercial law 쐍 Standard ledger: Tax balance sheet

With this procedure, a standard ledger must be defined as the leading ledger in Customizing, which inherits all business transactions to the other standard ledgers. This enables you to efficiently derive your tax balance sheet from the leading standard ledger in SAP S/4HANA.

297

7

Direct Taxes in SAP S/4HANA

Because an additional standard ledger for the tax balance sheet inherits all business transactions of the leading ledger, it’s only necessary to intervene if there are differences in accounting, for example, between the commercial and tax balance sheets.

Example Let’s consider an example of using parallel ledgers. In the commercial balance sheet, a provision of EUR 1,000 is recognized; in the tax balance sheet, this provision may not be recognized; the carrying amount in the tax balance sheet is EUR 0. This results in the following different balance sheet approaches in the parallel ledgers for the commercial and tax balance sheets: 쐍 Standard ledger (commercial balance sheet): EUR 1,000 Carrying amount commercial balance sheet 쐍 Standard ledger (tax balance sheet): EUR 0 Carrying amount tax balance sheet

The deviating posting in the tax balance sheet can be represented either by using a ledger group that disregards a posting in the standard ledger (tax balance sheet) or by reversing the posting made in the standard ledger (commercial balance sheet).

In addition to the option of reconciling differences between accounting principles using a parallel standard ledger, you can also use an extension ledger. Compared to the standard ledger, an extension ledger records the variances between different accounting principles as delta postings to a standard ledger. In this case, the representation of a different accounting principle results from the joint consideration of the standard and extension ledger. Delta postings in the extension ledger are always made at the account level.

Example Let’s consider an example of using extension ledgers. In the commercial balance sheet, a provision of EUR 1,000 is recognized. In the tax balance sheet, this provision may not be recognized; the carrying amount in the tax balance sheet is EUR 0. The resulting differences between the commercial balance sheet and the tax balance sheet are converted using a delta posting in the extension ledger: 쐍 Standard ledger (commercial balance sheet): EUR 1,000 Carrying amount commercial balance sheet 쐍 Extension ledger: -1,000 EUR delta posting 쐍 Tax balance sheet: EUR 0 Carrying amount tax balance sheet

An extension ledger is always assigned to a base ledger and inherits all posting documents of the standard ledger for reporting. You can assign any number of extension ledgers to each standard ledger. Postings that have been explicitly posted to an extension ledger are visible in this extension ledger, but not in the underlying base ledger.

298

7.2

Organizational Structures

You can use the extended ledger functions in SAP S/4HANA as an integrated ledger concept to reflect the tax balance sheet across the tax lifecycle. We recommend a 1+2 approach, which combines a standard ledger for the preparation of the tax balance sheet in the consolidated financial statements with an extension ledger for the status of the tax balance sheet at the time of the tax returns, as well as another extension ledger for the status of the tax balance sheet at the time of the tax audit (tax auditor’s balance sheet) (see Figure 7.4).

Tax Ledger Workflow

Tax Postings

Delta Posting

Fiscal Year 202X - Tax Audit

Standard

Tax Ledger Hub

IFRS

IFRS

IFRS Local GAAP

Local GAAP

Local GAAP Tax

Extension

Ledger

Parallel Accounting

Fiscal Year 202X - Tax Return

App

Fiscal Year 202X - Tax Reporting

Fiscal Year Carryforward

Tax

Tax

ReturntoProvision

Audit-toReturn

Figure 7.4 1+2 Approach for Reflecting the Tax Balance Sheet in SAP

This approach allows you to reflect on the different phases of the tax lifecycle separately.

Set Up the Tax Ledger In this section, we’ll show you which settings you can make in Customizing to reflect the ledger approach in SAP S/4HANA. You can access the settings in Customizing via Transaction SPRO and menu path Financial Accounting • Financial Accounting Global Settings • Ledgers • Ledger • Define Settings for Ledgers and Currency Types. You’ll first get an overview of the standard and extension ledgers already created in the system and can extend them for your purposes. In the example in Figure 7.5, various ledgers have already been created in Customizing. In addition to a standard ledger 0L, which has been defined as the leading ledger and covers the IFRS accounting standard, a standard ledger 2L, for example, has been defined in the system to reflect local accounting standards. To create a new ledger, you can click on New Entries in the header and then assign a ledger and other relevant attributes.

299

7

Direct Taxes in SAP S/4HANA

Figure 7.5 Overview of Created Ledgers

As you can see, the 1+2 approach we proposed, which combines a tax ledger as a standard ledger with two extension ledgers for tax purposes (e.g., standard ledger TX and extension ledgers TE and TL), is also already set up in the SAP standard system.

Deactivate Ledgers The settings for ledgers are defined per client, that is, they are made for all company codes in a first step. If you decide not to use the defined ledgers for all company codes, you must actively control this in Customizing by deactivating a ledger for specific company codes. You can access this setting in Customizing via menu path Financial Accounting • Financial Accounting Global Settings • Ledgers • Ledger (see Figure 7.6). To deactivate a ledger, you need to choose the relevant ledger by determining the work area in the popup window and then continue with selecting the relevant company code (CoCd) and entering the fiscal year period the deactivation should apply to in the From FYear and To FYear fields.

Figure 7.6 Deactivation of Ledgers per Company Code

300

7.2

Organizational Structures

Ledger Groups/Document Entry To be able to make specific postings to the ledgers you’ve created, ledger groups with a matching name are created for each ledger automatically. When making a posting in SAP S/4HANA, you can select a ledger group for each posting. In this case, the posting will only be made to the ledgers covered by the ledger group. As you can see in Figure 7.7, ledger groups (as intended) also exist in the system for the standard and extended tax ledgers that we’ve defined (TE for Tax Return 1, TL for Tax Audit 1, and TX for Tax Ledger Reporting).

Figure 7.7 Overview of Created Ledger Groups

Example The posting of a difference between the commercial and tax balance sheet at the time of the preparation of the financial statements can be done by selecting the TX ledger. If you want to enter a delta posting due to a return-to-provision adjustment in SAP S/4HANA, you can specifically use ledger group TE in this case. For a delta posting due to an audit-to-return adjustment, you need to access ledger group TL.

The selection of the ledger group in the case of general ledger account postings via Transaction FB50L is shown in Figure 7.8. Once you’ve opened Transaction FB50L, you can enter the desired ledger group (Ledger Grp) in the upper-left frame (TX, in our example). If no ledger group is selected, then the posting will be executed in all defined parallel ledgers.

301

7

Direct Taxes in SAP S/4HANA

Figure 7.8 Selection of Ledger Group in Transaction FB50L

Fiscal Year Variant In addition to tax ledger-specific postings, a common question is whether tax ledgers can have their own fiscal year and posting period variants. The fiscal year variant determines whether the fiscal year corresponds to the calendar year, and at the same time determines the number of posting and special periods to be created for the given fiscal year. You can view the fiscal year variants defined in Customizing by choosing Financial Accounting • Financial Accounting Global Settings • Ledgers • Fiscal Year and Posting Periods • Maintain Fiscal Year Variant (see Figure 7.9). To create a new fiscal year variant, you can click on New Entries in the header and then assign a fiscal year variant (FV) and other relevant attributes such as calendar year, number of postings, or special periods. The fiscal year variant is always determined on a company code basis. You can view the fiscal year variants attributed to a specific company code by choosing Financial Accounting • Financial Accounting Global Settings • Ledgers • Fiscal Year and Posting Periods • Assign Company Code to a Fiscal Year Variant. In this case, the fiscal year variant K4, which has a fiscal year that is the same as the calendar year with 12 posting periods and 4 special periods, was assigned to Company Code 1010 created in the system (see Figure 7.10).

302

7.2

Organizational Structures

Figure 7.9 Overview of Created Fiscal Year Variants

Figure 7.10 Assigning a Fiscal Year Variant to a Company Code

An extension ledger always inherits the fiscal year variant of the underlying standard ledger. In the present case, the fiscal year variant of the two created tax extension ledgers TE and TL thus necessarily matches the fiscal year variant of the tax standard ledger TX. You can see this for the ledger TL in Figure 7.11. The Fiscal Year Variant field is automatically set to the fiscal year variant K4 of the tax standard ledger TX.

Figure 7.11 Inheritance of the Fiscal Year Variant to the Extension Ledger

303

7

Direct Taxes in SAP S/4HANA

Posting Period Variant Unlike the fiscal year variant, you can define the posting period variant flexibly. The posting period variant determines whether you can open and close a ledger you created independently of other ledgers for accounting purposes. This is important, for example, to still be able to make postings to the extension ledgers you created in the case of a closed tax general ledger. As you can see in Figure 7.12, the posting period variant can be defined without binding to other ledgers for the shown extension ledger TL. In our example, the posting period variant Tax Reporting is selected for the extension ledger.

Figure 7.12 Selection of Posting Period Variant

Posting to the tax ledgers you’ve created is thus possible without further ado, as long as the posting period of this ledger remains open.

Balance Carryforward Directly linked to the posting period variant is the execution of the balance carryforward to a new posting period. Here, too, an independent conversion is possible for each individual ledger; that is, the balance can be carried forward separately for each ledger. To set the balance carryforward, as shown in Figure 7.13, run Transaction FAGLGVTR, select relevant parameters such as Ledger and Company Code, and click on Execute.

304

7.2

Organizational Structures

Figure 7.13 Balance Carryforward per Ledger

Tax Ledgers in Regular Business Operations As you can see, the use of the ledger functionality in SAP S/4HANA offers many companies completely new starting points for an ERP-integrated accounting for taxes establishing a single source of truth for all accounting standards. However, to make the most of your transformation project, you should think about further potential for automation and thus efficiency gains. One option to enhance the tax ledger concept is a custom-built tax ledger application. The following features are often requested by clients in this respect: 쐍 Integration into SAP S/4HANA 쐍 Rule-based determination of statutory-to-tax adjustments 쐍 Posting of the statutory-to-tax adjustments to the tax ledger at the push of a button 쐍 Determination of statutory-to-tax adjustments per account or line item 쐍 Predefinable templates for statutory-to-tax adjustments 쐍 Freely definable tax lifecycle phases 쐍 Lifecycle phase and fiscal year carryforward of statutory-to-tax rules 쐍 Workflow-based approval process and status overview 쐍 Document and notification service 쐍 Responsive SAP Fiori-based web design

305

7

Direct Taxes in SAP S/4HANA

Based on these features, the following additional benefits for the tax ledger setup can be achieved: 쐍 Single source of truth for the tax balance sheet 쐍 Availability of tax balance sheet data in real time 쐍 Accelerated preparation of the tax balance sheet through automation 쐍 Interface reduction to peripheral tax balance sheet solutions 쐍 Relieving the finance and tax area of routine activities 쐍 Improved governance between finance and tax 쐍 Increased data quality through IT-sided mapping of the tax balance sheet 쐍 Operationalization of tax compliance through integrated approval processes for the

tax balance sheet 쐍 Improved documentation of the tax balance sheet through central document stor-

age 쐍 Unified SAP user experience (UX)

In this section, we’ll demonstrate in a nutshell what such a custom application can look like. In the case at hand, we’ve created an application in SAP Fiori that focuses on three capabilities: 쐍 Setting up a full direct tax lifecycle management system covering major lifecycle

phases such as tax reporting, tax return preparation, or tax audit management 쐍 Creating rule-based statutory-to-tax adjustments based on statutory GAAP values 쐍 Enabling automated posting of all statutory-to-tax adjustments at the push of a but-

ton, including a workflow-based approval process Eventually this application provides the tax function with a powerful tool to develop the tax ledger concept toward a highly automated process while creating a single source of truth for all parallel accounting standards at the same time. As previously outlined, it’s first required to create different lifecycle phases for applying a full tax ledger concept across the entire direct tax lifecycle prior to creating any statutory-to-tax adjustments. The task can be performed by clicking on the Lifecycle Maintenance tile in the Tax Ledger Hub app (see Figure 7.14).

Figure 7.14 Tax Ledger Hub App: Tiles

306

7.2

Organizational Structures

Figure 7.15 shows how a full tax lifecycle can be set up as a basis for capturing any adjustments. You can easily add new lifecycle phases by clicking the button in the lower-right corner.

Figure 7.15 Direct Tax Lifecycle Management

Once you’ve finalized this preparatory work, you can start to create rule-based statutoryto-tax adjustments by uploading posted local and tax GAAP values. Navigate to the App tile in the Tax Ledger Hub app (refer to Figure 7.14), and select the relevant Company Code, Fiscal Year, and created tax Lifecycle Phase (see Figure 7.16). Click the Go button, and you’ll see real-time Local GAAP and Tax GAAP numbers as posted in your ledgers in SAP S/4HANA.

Figure 7.16 Posted Local GAAP and Tax GAAP Values at a Glance

In the next step, you can select balance sheet items that are subject to statutory-to-tax adjustments and create new adjustments (see Figure 7.17). To do so, just click on one line item (account line), and then if a statutory-to-tax adjustment needs to be created, click on the Add Deviations button on the right-hand side.

307

7

Direct Taxes in SAP S/4HANA

Figure 7.17 Creation of New Statutory-to-Tax Adjustments

When creating a new statutory-to-tax adjustment, you can decide whether you want to define the adjustment on the account or line-item level by turning the Account Split button to ON or OFF (see Figure 7.18). If you choose OFF, then the entire account balance will be taken into account for the statutory-to-tax adjustment; if you choose ON, then you’re able to select the checkboxes of specific transactions posted to this account and then proceed with the next step by clicking Next Step.

Figure 7.18 Statutory-to-Tax Adjustments on the Account or Line Item Level

Once you’ve selected the relevant items for your statutory-to-tax adjustment you’re able to create a rule to automate the determination of the respective tax GAAP values based on available templates. You can either choose between predefined rules provided with a standard content package or define your own templates based on your specific needs.

308

7.2

Organizational Structures

Tax rules that can be defined, for example, are depreciation plans, correction of valuation allowances in percent for assets, discounting of accruals or liabilities, tax-specific valuation plans for accruals and liabilities, or rules for nonrecognition of assets and liabilities for tax purposes. For our example, navigate to the Choose Template step, as shown in Figure 7.19, where you can see the catalog of available templates for tax rules.

Figure 7.19 Application of Tax Rules for Statutory-to-Tax Adjustments

Once you’ve created the statutory-to-tax adjustments, you can directly see the profit impact on your tax base by navigating to the Review Template step (see Figure 7.20).

Figure 7.20 Profit Impact of Statutory-to-Tax Adjustments at a Glance

In the last step, the user (approver) can select the created statutory-to-tax adjustments and submit these for posting at the click of a button to the underlying ledger. To do so,

309

7

Direct Taxes in SAP S/4HANA

the user opens the Approve and Post tile within the Tax Ledger Hub app to get to the page shown in Figure 7.21. In the case at hand, all postings for the tax reporting lifecycle phase will be made to an underlying parallel tax ledger. Postings can alternatively be made to, for example, extension ledgers for the tax return or tax audit lifecycle phases depending on the underlying ledger concept. The postings can be triggered by checking items in the list of available postings and selecting Simulate (as an optional step) and Posting.

Figure 7.21 Posting of Statutory-to-Tax Adjustments at the Click of a Button

To keep the work across all lifecycle phases and fiscal years as efficient as possible, all statutory-to-tax adjustments can be carried forward from phase to phase or to the next fiscal year. As you can see, the standard ledger functionality in SAP S/4HANA can be enhanced to a significant extent if you make use of additional capabilities such as SAP Fiori. We strongly recommend that you make use of these capabilities to leverage the full potential of SAP S/4HANA for your tax function.

7.2.2 Company Code In SAP S/4HANA, company codes represent organizational units of accounting that subdivide the company from a financial accounting perspective. You can use company codes to reflect several self-contained accounting records at the same time. A separation is usually based on commercial or tax considerations, but it can also take into account other reporting requirements. By default, each company code corresponds to a legal entity in the company. You can make company code settings in SAP S/4HANA using the Customizing menu path Enterprise Structure • Definition • Financial Accounting • Edit, Copy, Delete, Check Company Code. The company code exists as an organizational unit of accounting alongside other organizational units and accounting objects that support different objectives in SAP S/4HANA. For the tax function, the implementation of SAP S/4HANA results in the task of analyzing tax requirements to be reflected via appropriate organizational units

310

7.2

Organizational Structures

and accounting objects. In particular, you need to assess whether the existing implementation of company codes already meets tax requirements with regard to reporting or needs to be expanded in the future. The following organizational units or accounting objects are available: 쐍 Company code 쐍 Profit center 쐍 Plants abroad 쐍 Cost centers 쐍 Internal orders 쐍 Projects (work breakdown structure [WBS] elements)

Functions of Organizational Units/Accounting Objects In particular, include the following functions in your considerations, which individually or in combination determine the requirements for the respective organizational unit: 쐍 Preparation of balance sheet and profit and loss (P&L) account 쐍 Allocate revenues and costs 쐍 Apply parallel accounting 쐍 Create asset accounting 쐍 Assign individual roles and permissions 쐍 Define your own currency types 쐍 Deposit tax master/tax registration data 쐍 Implement tax reporting requirements (e.g., SAF-T, e-balance sheet)

From a tax perspective, the following issues arise in the area of direct taxes that require a decision to be made when choosing the right organizational unit: 쐍 Legal entities as tax subjects

As a rule, tax law, for example, for corporate income tax purposes, bases taxation on legal entities as tax subjects (e.g., limited liability companies). Because configuration in SAP S/4HANA provides for the creation of company codes as standard for this case anyway, this doesn’t result in any special tax requirement. As a recommendation, it can be stated that from a direct tax perspective, a company code should be created for each legal entity. 쐍 Permanent establishments abroad of domestic legal entities

The situation is different if legally dependent organizational units are also taken into account for tax purposes. In practice, this is usually the case with permanent establishments abroad. From a tax perspective, the result of the permanent establishment abroad is exempt from domestic taxation by applying the exemption method. In contrast, the results of the permanent establishment abroad are subject

311

7

Direct Taxes in SAP S/4HANA

to taxation, and a tax return must generally be filed for the permanent establishment abroad. To fulfill the tax filing obligations, a separate P&L calculation must be prepared for the permanent establishment. On one hand, this serves to distinguish the expenses and income attributable to the permanent establishment from the domestic determination of profits; on the other hand, separate accounting rules may have to be applied to the permanent establishment. If the previously mentioned functions are taken as a basis, only one company code can fulfill the tax requirements for organizational units because a separate balance sheet and income statement must be prepared for the determination of permanent establishment profits. In addition, there may be a need to resort to parallel accounting, including separate valuation areas in asset accounting, due to differing accounting regulations under domestic and foreign tax law. 쐍 Special features for partnerships

Insofar as partnerships are part of the company, requirements may arise from the transparent taxation of partnerships. This can, for example, lead to special and supplementary balance sheets of the partners and additional tax documentation and filing obligations. As you can see, the decision should generally be made in favor of creating a separate company code, regardless of the circumstances. Even if existing filing and reporting obligations can currently be reflected via alternative organizational units, the creation of a company code is more future-proof in any case. At the same time, you still have the option of combining the created company code with other organizational units or accounting objects to derive additional reporting options, for example, in the area of transfer pricing.

Transaction for Displaying Created Company Codes If you want to get an overview of the company codes created in Customizing, you can do this by using Transaction SE16 in the SAP GUI and then selecting table T001.

7.2.3 Chart of Accounts As already explained, the requirements of companies for the design of a uniform (consolidated) chart of accounts are complex. In addition to the requirements of parallel accounting in the consolidated and separate financial statements under commercial law, country-specific features in the respective jurisdictions must be taken into account for local accounting. In addition, the tax function needs to reflect tax requirements, especially in the area of direct taxes, in a country-specific manner and as granularly as possible in the chart of accounts. The reason for this is that the chart of accounts and the account balances

312

7.2

Organizational Structures

behind it provide the numerical framework for the existing filing and reporting obligations to a considerable extent. All in all, these requirements lead to a considerable administrative effort with regard to the maintenance of the chart of accounts, which understandably should be avoided in practice on a regular basis by specifying a lean chart of accounts. For the tax function in SAP S/4HANA, you must, on one hand, take into account the guardrails for the chart of accounts defined in the overall project, and on the other hand, you should take advantage of the tax opportunities of a granular chart of accounts with regard to your processes as much as possible. If we look in detail at the requirements for the area of direct taxes, the following questions, for example, arise in practice that you must consider when designing your chart of accounts: 쐍 What are the commercial law obligations in the consolidated and individual finan-

cial statements that require a more granular design of the chart of accounts? 쐍 What are the tax obligations that must be taken into account when implementing

the chart of accounts? 쐍 What are the requirements with regard to the desired automation of tax reporting

and filing processes? During the project it will likely turn out that the need to create an account often doesn’t only arise from a single requirement, but from a combination of these areas. There is regularly a need for discussion in the overall project in cases where the creation of a tax-relevant account is solely based on the objective of tax-efficient processes. In this case, the need for creating additional accounts must be justified in more detail by means of a business case.

Documentation of Tax Requirements in the Chart of Accounts In practice, it’s advisable to mark the tax requirements that arise for the chart of accounts in separate columns in the project template and to explain them via comments. Given the large number of requirements, it will then be easier for you to understand the reason for creating a tax-relevant account retrospectively.

Before you begin with the actual design of the chart of accounts from a tax perspective, it’s important to further narrow the scope of accounts to be evaluated by the tax function. In our experience, the conception of the chart of accounts from a direct tax point of view includes two account areas in the balance sheet and the income statement: tax position accounts and tax-sensitized accounts. Tax position accounts form the actual tax accounts in the chart of accounts and record the accounting of current taxes, including tax fringe benefits and deferred taxes in the balance sheet and the income statement.

313

7

Direct Taxes in SAP S/4HANA

Consideration of Additional Tax Requirements Under international accounting standards, additional tax position accounts may be required, but these won’t be discussed in detail here. These serve, for example, to show the maturity of deferred taxes, the presentation of deferred taxes in equity or the distinction between tax provisions and tax liabilities.

To be able to turn to automated monitoring of tax movements in real time (see Section 7.5), it’s important that you use other available account assignment features in SAP S/4HANA in addition to the chart of accounts. This relates in particular to the use of movement types, which allows you to clearly differentiate between account movements, for example, in additions, reversals, and consumption. In this way, you can significantly reduce the effort required for the manual creation of a tax receivable and a tax accrual statement. Tax-sensitized accounts carry items in the balance sheet and income statement that are assessed differently under commercial and tax law or have to meet additional tax reporting requirements. The following are important accounts with relevance for taxsensitization: 쐍 Balance sheet accounts

– Financial assets and related receivables that can be sensitized by differentiating between legal form, participation quota, and foreign/domestic investments to determine tax-exempt sale of assets or impairments to be disallowed for tax purposes – Equity accounts that can be sensitized through the use of movement types and partner IDs to manage tax equity accounts more efficiently, for example, to track movements in tax equity automatically by shareholder – Liabilities and accruals that can be structured by item, maturity, movement, and intercompany relevance 쐍 P&L accounts

– Income from revaluation or disposal of investments that can be sensitized by differentiating between legal form, foreign/domestic income, and participation quota to track tax-exempt income – Other income from investments to be differentiated by type of payment, legal form, foreign/domestic income, and participation quota to structure tax-exempt income – Income and expenses from realized and unrealized currency gains/losses that may be subject to specific tax provisions – Income and expenses from special tax reserves relevant only for tax accounting purposes

314

7.2

Organizational Structures

– Nondeductible business expenses by type of expense; thresholds; availability of tax certificates/vouchers; intercompany relevance such as entertainment expenses, gifts, or donations; supervisory board compensation; and rental, lease, and license expenses In particular in the area of tax accounts, the concept of the chart of accounts should be supplemented with additional account assignment features. This concerns, for example, the use of transaction types for the presentation of the fixed asset schedule, tax movement schedule or movements in equity. If the chart of accounts doesn’t provide all relevant taxation characteristics as information, you can alternatively consider using the concept of tax tagging for the area of direct taxes. The reason for this may be either the limitation of the chart of accounts by project specifications or the fact that the design via accounts can’t technically provide all the required taxation attributes. We’ll discuss tax tagging in more detail in Section 7.4.

Choice of Tax Account Descriptions Because the uniform (group) chart of accounts is used globally, you should ensure that the tax account descriptions are generally understandable and applicable. A specific account description should be applied only if country-specific requirements can be reflected via additional subaccounts. Consider the following examples: 쐍 An account description “nontax-deductible entertainment expenses” is generally more appropriate than “entertainment expenses under Section 4(5)(2) of the EStG.” 쐍 An account description “nontax-deductible interest” is preferable to describing it

as “nontax deductible interest under Section 233a AO.”

Via Transaction SE16 and the subsequent selection of table T004, you can get an overview of which charts of accounts are currently set up in the system (see Figure 7.22).

Figure 7.22 Overview of the Created Charts of Accounts

315

7

Direct Taxes in SAP S/4HANA

To analyze which accounts are currently already provided in a chart of accounts, an overview is available via Transaction SE16N in connection with the selection of table SKA1 (see Figure 7.23).

Figure 7.23 Overview of Created General Ledger Accounts

7.2.4 Withholding Tax For various business transactions, globally operating corporations are taxed at the service recipient’s place of business, that is, are subject to limited corporate taxation. In this case, the respective service recipient is obliged to withhold a portion of the remuneration agreed on with the service provider to pay it directly to the tax authorities. Typical cases for a respective taxation at the source are—among others—license payments, construction services, or sporting, artistic, and similar performances. Due to these obligations, there are numerous implications at the level of the service recipient and the service provider that need to be reflected in SAP S/4HANA. As in the other tax areas, this includes the entire end-to-end tax scenario from data collection and tax determination to reporting and filing. In this section, we focus in particular on the input side in the area of WHT (see Figure 7.24). The main activities processed in the area of WHT on the input side (essentially in the procure-to-pay scenario) are, for example, the assessment of facts for any potential WHT obligations to be able to derive the correct tax determination in SAP S/4HANA based on available WHT types and WHT codes. Based on this, WHT-relevant data in SAP S/4HANA can be extracted, and WHT filings can be prepared, checked, and finalized for transmission to the tax authorities. At the same time, tax certificates can be issued to the vendor.

316

7.3

Master Data

Procure-to-Pay Process – e.g., License-In (Input Side)

Contact

Request

Proposal

Order

Delivery

Invoice

Payment

WHT Determination

Tax Reporting and Filing (Input Side)

Review

Preparation SAP Query

Prepare WHT Filing

Review WHT Filing

Filing Electronic Submission WHT Filing

Documentation

Create/Issue WHT Certificate

Archiving

Figure 7.24 Overview of WHT Process (Input Side)

SAP S/4HANA offers two alternative ways to support the WHT process: the basic WHT function and the extended WHT function. Which of the two options should be implemented in SAP S/4HANA depends on the complexity of the WHT case. This complexity is, for example, determined by the interaction of the tax base, taxable portion of the remuneration, prescribed tax calculation methods, applicable WHT rate, and WHT exemption certificates. In addition, it must be decided whether both the input and output side will be covered by the WHT function. While the basic WHT function only supports the management of WHT at the level of the service recipient (input side), the extended WHT function also provides the possibility to manage WHT at the level of the service provider (output side). We covered the step-by-step configuration for WHT (basic and extended) in Chapter 3, Section 3.1.1.

7.3 Master Data In addition to the setup of organizational structures, master data governance is also highly relevant for the area of direct taxes. It represents basic information created in the system that can be accessed centrally when processing business transactions. In addition to tax determination, master data enables the accurate and uniform handling of tax cases in the area of direct taxes and can be divided thematically into the areas business partner, general ledger account, and asset master data. We’ll explore each area in the following sections.

317

7

Direct Taxes in SAP S/4HANA

7.3.1 Business Partner Business partner master data comprises all basic information relating to the debtors/ creditors of your company. Although these are of minor importance for the direct tax area as a whole, they are nevertheless highly relevant for WHT determination. As you can see in Figure 7.25, important information about WHT types, WHT codes, and WHT exemptions is assigned to the business partners. Correct system-supported tax determination can only be ensured if the master data is carefully maintained and updated.

Figure 7.25 Example for Business Partner Master Data

Incorrect personal account master data can, for example, lead to a WHT case being incorrectly posted by the system or a WHT deduction being made in the wrong amount. Given the considerable amount of master data in the company, neglecting master data governance can thus have material consequences.

Monitoring Data Quality for Person Account Master Data To enable you to monitor data quality in the area of business partner master data, we recommend that you establish a detective check (see Section 7.5) and monitor the master data continuously as part of your tax control framework.

We covered the Vendor: Withholding Tax data in detail in Chapter 3, Section 3.2.1.

318

7.3

Master Data

7.3.2 General Ledger Account You can use general ledger account master data to include important information when posting tax-relevant transactions to general ledger accounts. An important starting point for this is the definition of field status variants and field status groups. These define which input fields are visible when performing document entries and also determine whether the filling is optional or mandatory. You can access the Customizing settings and see created field status variants in the IMG by choosing Financial Accounting • Financial Accounting Global Settings • Ledgers • Fields • Define Field Status Variants (see Figure 7.26).

Figure 7.26 Overview of Field Status Variants

By selecting a field status variant (FStV) and clicking on Field status groups, you can see the list of available field status groups (see Figure 7.27). For the area of direct taxes, for example, you could define separate field status groups TX01 for the area of your tax receivables and tax accruals.

Figure 7.27 Overview of the Customizing of Field Status Groups

This enables users to add further information to a posting via mandatory fields, which is required for the tax reporting but can’t be provided via the definition of the chart of accounts. Subgroups for the field status group, in which you can make settings for the individual input fields during document entry, can be accessed by selecting the field status group (e.g., TX01) and double-clicking on the line item; the subgroups are shown in Figure

319

7

Direct Taxes in SAP S/4HANA

7.28. For example, you can specify cost centers in the Additional account assignments subgroup, tax codes in the Taxes subgroup, or transaction types in the Consolidation subgroup (not shown) as account assignment attributes.

Figure 7.28 Maintain Field Status Groups

One attribute that you should always include in your general ledger account master data when implementing SAP S/4HANA in the area of direct taxes is transaction types. You can view the available transaction types in the IMG under Financial Accounting • Financial Accounting Global Settings • Books • Fields • Standard Fields • Maintain Consolidation Transaction Types. Transaction types offer you, among other things, the option of displaying the horizontal change in balance sheet items, for example, additions, reversals, and consumption. In the area of direct taxes, for example, this is an important tool for the automated derivation of a tax movement schedule or can support the presentation of changes in tax equity in SAP S/4HANA. SAP already provides a large number of predefined transaction types in the standard system (see Figure 7.29) that you can use for your requirements. If these aren’t sufficient, you can also add your own transaction types by clicking the New Entries button.

Customer-Specific Fields in the General Ledger Account Master Data Area In addition to the settings for the field status variants, you can also use customerspecific fields in the general ledger account master data area. You can use these fields, for example, to use a tax code for the area of direct taxes to implement the concept of tax tagging. See Figure 7.33 later in this chapter for an example.

320

7.3

Master Data

Figure 7.29 Customizing Overview Transaction Types

7.3.3 Asset In addition to the business partner and general ledger account master data, the management of asset master data has a major impact on the area of direct taxes. Asset master data can be reflected in SAP S/4HANA for various accounting regulations and thus also for tax accounting purposes. The basis for master data management is the chart of depreciation. This is defined on a country-specific level and combines various parallel valuation areas as a single unit. To define a chart of depreciation, you can use path Financial Accounting • Asset Accounting • General Valuation • Depreciation Areas • Define Depreciation Areas. As you can see in Figure 7.30, a tax depreciation area (e.g., 10 [Tax – Local Currency] and 15 [Tax – Group Currency]) can also be part of the chart of depreciation.

Figure 7.30 Chart of Depreciation

321

7

Direct Taxes in SAP S/4HANA

The tax valuation area carries the valuation parameters required for the valuation of fixed assets, defined in accordance with tax regulations, which are used to automate asset accounting and thus also the preparation of the tax balance sheet. For this purpose, you can technically link the tax depreciation area to the tax ledger you’ve defined by double-clicking on the tax depreciation area line item in the list of depreciation areas as shown in Figure 7.30. You can make the corresponding setting in the Define Depreciation Areas section by selecting the Target Ledger Group (here TX, as shown in Figure 7.31). (Other settings on this screen aren’t specific to tax.)

Figure 7.31 Linking of Depreciation Area and Ledger

For this reason, we recommend that you accompany the conception of asset accounting from a tax perspective right from the start, so that the tax valuation and the representation of the tax balance sheet are fully aligned.

7.4 Tax Tagging Business transactions captured in SAP often don’t carry the information required for appropriate tax reporting and compliance. Even in the case that business transactions can be enriched with additional tax-relevant information, business operations struggle with an appropriate tax determination as different potential tax impacts may exist.

322

7.4

Tax Tagging

In this case, tax tagging can support the operating business with guidance and technical capabilities in SAP to make the relevant tax decisions and provide additional data capturing options. For this purpose, tax tagging combines different technical enhancements available inside and outside SAP and can be thus flexibly adapted to the specific use cases. As shown in Figure 7.32, tax tagging usually comprises the following steps: 1. First, a new tax-relevant business transaction is processed in SAP S/4HANA (triggering event). This can be a purchase order, an incoming invoice, or a posting to general ledger accounts. Depending on the data captured in the transaction, the system checks whether there’s a need to add additional tax-relevant information (tax tag) based on predefined validations. 2. In the case of a tax-relevant transaction, a user exit is triggered that guides the user to a tax decision engine (routing out) which returns the required tax tag through a guided or automated Decision Model and Notation (DMN)-based process. 3. Once the tax tag is available, the information is routed back and stored in the relevant transaction in SAP S/4HANA, for example, by way of a customer-specific field (routing in). Alternatively, the tax-relevant transaction also can be stored outside SAP and referred to via a document number or other criteria. 4. Based on the available tax tags and all other data captured during the transaction, the journal entries can be evaluated and relevant tax reports processing the tax tags can be built.

SAP Decision Engine

Guided Process (DMN)

Tax Tags

Triggering Event

Routing Out

Routing In

Tax Data Analytics

New Transaction

User Exit (e.g., Popup)

Processing Tax Tags Manually or Automated

Evaluation of Tax Tags and Journal Entries

SAP S/4HANA

Figure 7.32 Tax Tagging Workflow

In this section, we’ll show two examples of how tax tagging can support the tax function. In the first case, tax tagging is used to standardize and enhance postings made to tax accounts such as tax receivables, tax accruals and liabilities, and tax expense. In the case at hand, the coding block in Transaction FB50L has been enhanced by additional columns capturing additional tax-relevant information such as Tax period, Tax

323

7

Direct Taxes in SAP S/4HANA

author, Tax type, and Tax PL mov (tax P&L movement) type for each transaction made to tax accounts (see Figure 7.33). This example is based on a user exit that doesn’t exist in the standard SAP system.

Figure 7.33 Standardization of Tax Postings

If appropriately set up, the additional information provided in this example can be evaluated to automatically derive a tax movement schedule, tax expense, or tax cashflow report. In the second case, tax tagging is used to detect WHT-relevant transactions and trigger a guided process to determine the appropriate WHT tax consequences within Transaction FB60 that can be cross-checked with the available WHT types and codes (see Figure 7.34). In particular, a user exit (popup window) is triggered (see Figure 7.35) if a combination of a foreign vendor (where no WHT is maintained) and specific material is selected. Based on the exit, the user can either choose to Post Anyway (not recommended as an incorrect WHT would result) or Open Tool to be routed out to a decision engine where the WHT determination is supported with a guided process or automated decision support. Based on the process, the user can select the appropriate WHT type and code and then receive instructions to correct the WHT settings in SAP S/4HANA accordingly. In this example, tax tagging not only enriches business transactions with tax-relevant information but also supports the tax control framework with an ERP-integrated control that detects tax-relevant transactions.

324

7.4

Tax Tagging

Figure 7.34 Identification of WHT-Relevant Transactions

Figure 7.35 WHT User Exit Based on Triggering the Event

325

7

Direct Taxes in SAP S/4HANA

7.5 Direct Tax Data Analytics and Monitoring The quality of your tax-relevant data in SAP S/4HANA depends significantly on the organizational structures and business processes behind the data collection. In addition to the maintenance of your organizational structures and master data, this also applies in particular to the transactional data of your company. Due to the complexity of business processes, manual interaction of users with the system, and permanent changes in tax regulations, it’s practically impossible to ensure all tax requirements for data quality at all times. Nevertheless, you must ensure that your company correctly fulfills all tax filing and reporting obligations and can fully ensure compliance with tax regulations. To this end, you must establish a tax control framework that supports you in complying with the aforementioned requirements and reduces the risk of tax evasion or fraudulent tax avoidance to the greatest extent. In addition to the setup of suitable guidelines and the documentation of tax processes and potential tax risks, the introduction of processand system-integrated controls represents an important building block for the regular operation of your tax control framework. This is where the analysis and monitoring phase in the tax end-to-end scenario comes in and can support you in various ways in the area of direct taxes: 쐍 Master data screening

Master data screening is about ensuring the completeness and accuracy of tax-relevant master data. If tax-relevant master data is insufficiently maintained, incorrect in terms of content, or redundant, the master data may result in incorrect tax determination.

Example A company regularly makes royalty payments to a business partner based abroad. In the vendor master data, the relevant WHT types and codes aren’t stored correctly for a vendor. As a result of the incorrect vendor master data, payments to the relevant vendor are incorrectly not classified as relevant for WHT or have an incorrect WHT rate assigned. Therefore, the company may be held liable for the WHT shortfall in the course of a subsequent tax audit. Master data screening can, for example, identify WHT types and codes that have not been attributed to a business partner, thus helping to improve master data quality. 쐍 Transaction data screening or account screening

Transaction data screening or account screening analyzes whether tax-relevant facts have been recorded completely and correctly in the accounts intended for this purpose. The reason for the incorrect booking of tax-relevant facts can be that they

326

7.5

Direct Tax Data Analytics and Monitoring

aren’t recognized as such in the first place, are assessed incorrectly, or are booked to incorrect accounts. Incorrectly recorded business transactions can, in particular, lead to the omission of tax corrections in the tax return filing process and to the understatement of the tax base.

Example A company thanks a business partner with monthly gifts of EUR 30, which are erroneously recorded in the account “Gifts to business partners up to EUR 35 per fiscal year.” In the tax return, there is no addition of the account balance totaling EUR 360, because only the account “Gifts to business partners in excess of EUR 35 per fiscal year” is taken into account in the context of off-balance sheet additions, and the company’s tax department relies on the correct posting of the facts in the accounting system. Transaction data screening reveals that the total amount of gifts to a business partner exceeds the permissible sum of EUR 35. Accordingly, the incorrectly recorded amount can still be corrected in the tax return. 쐍 Analytical review

The purpose of an analytical review is to uncover tax-relevant transactions by means of analytical test routines or to derive technical conclusions for tax reporting. Corresponding review routines are based on, among other things, inter-periodic correlations, changes to master data, or the targeted analysis of account movements. Failure to recognize tax-relevant facts may result in them being disregarded when preparing tax returns or in tax benefits not being appropriately used.

Example A company realizes a tax loss of EUR 100 in the current fiscal year and a tax profit of EUR 100 in the previous fiscal year. When preparing the tax return for the current fiscal year, a tax loss carryforward of EUR 100 is taken into account. The tax return is to be submitted to the tax office after a rough review by the head of the tax department. Through an analytical check routine that compares the tax result determined via the use of the tax ledger over the past few fiscal years, it becomes apparent that a tax loss carryback would have been more advantageous. By identifying the error, the tax return can still be corrected in time before submission to the tax office.

As you can see, implementing a solution that enables the analysis of tax-relevant data according to the aforementioned criteria can create a significant value proposition for ensuring tax compliance in the company. In this section, we’ll present you with SAP

327

7

Direct Taxes in SAP S/4HANA

Tax Compliance and SAP S/4HANA embedded analytics, two alternatives with which you can effectively implement tax data analytics and monitoring in SAP S/4HANA.

Core Data Services Core data services (CDS) in SAP S/4HANA underlies both solutions as an approach to data modeling. Check routines that you want to define and use in SAP Tax Compliance and SAP embedded analytics must be mapped using CDS. CDS has gained a lot of importance with the introduction of SAP S/4HANA. Compared to previously existing concepts for data modeling, data models with CDS can be defined directly in the database (SAP HANA) located in the core. This leads to a significant performance improvement in data analysis. For detailed information on CDS in SAP S/4HANA, including the basics of CDS data modeling and modeling analytical and transactional applications, see Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik (SAP PRESS, 2022, www.sap-press.com/5294).

7.5.1 SAP Tax Compliance SAP Tax Compliance provides you with a standard solution for tax data analysis that you can license as an extension in SAP S/4HANA. In addition to the actual execution of compliance checks using predefined check routines, SAP Tax Compliance also provides functions for investigating identified anomalies. Using predefined tasks, errors can be tracked in a system-supported and process-integrated manner and remedied in SAP S/4HANA.

Check Routines in SAP Tax Compliance You have the option of extending the existing check routines in SAP Tax Compliance via tax type-related content packages or the definition of your own views. SAP Tax Compliance is thus not only available to you for compliance checks in the area of direct taxes but also in particular for carrying out audits in the area of indirect tax.

Before you can use SAP Tax Compliance via your SAP Fiori interface, you must first set up the solution in Customizing as part of an implementation project. You can access the settings in the IMG via the Customizing function Set Up SAP Tax Compliance. In this section, we’ll focus on the user perspective. You can access the SAP Tax Compliance applications in your SAP Fiori interface via the Detection and Investigation areas. There you’ll find SAP Fiori apps that cover all important tasks in SAP Tax Compliance, as shown in Figure 7.36.

328

7.5

Direct Tax Data Analytics and Monitoring

Figure 7.36 Overview of SAP Tax Compliance

To get an overview of the check routines available in SAP Tax Compliance, first open the Manage Compliance Checks app. You can then add further compliance checks (check routines) and combine them into compliance scenarios that can be managed using the Manage Compliance Scenarios app and ran using the Run Compliance Scenario app. You can view the status of your compliance scenario runs using the Monitor Compliance Scenario Runs app and check your results using the My Compliance Check Results app. For detailed information on monitoring with SAP Tax Compliance, see Chapter 10.

7.5.2 Embedded Analytics Now that we’ve provided you with an initial overview of SAP Tax Compliance from a user perspective, we’ll introduce you to SAP S/4HANA embedded analytics as a possible alternative for performing tax analyses in the area of direct taxes. With SAP S/4HANA embedded analytics, SAP offers a way to perform analyses of your tax data in SAP S/4HANA without the additional use of a business intelligence (BI) solution. SAP S/4HANA embedded analytics is integrated as a component in your SAP S/4HANA system, making the additional licensing of a solution unnecessary. Embedded analytics builds on CDS and uses the virtual data model in SAP S/4HANA. This enables real-time tax data analytics and doesn’t require data to be extracted for analytics purposes. For using embedded analytics, in addition to standardized views based on CDS, extensive templates for analytics applications are available via the SAP Fiori apps reference library (see Figure 7.37), which you can easily adapt to your requirements (see http://sprs.co/v549503). At the same time, you can develop your own analytics apps based on SAPUI5.

329

7

Direct Taxes in SAP S/4HANA

Figure 7.37 SAP Fiori Apps Reference Library

Embedded analytics is also interesting for analyses in the area of direct taxes. Defined check routines based on CDS views can be converted into meaningful lists or dashboard views without major development effort. For a transaction data screening/account screening, for example, a dashboard might look like the one shown in Figure 7.38.

Figure 7.38 Example of a Dashboard in Embedded Analytics

330

7.5

Direct Tax Data Analytics and Monitoring

Further Reading For more information on SAP S/4HANA embedded analytics, see SAP S/4HANA Embedded Analytics by Jürgen Butsmann, Thomas Fleckenstein, and Anirban Kundu (SAP PRESS, 2021, www.sap-press.com/5226).

7.5.3 Comparative Review Whether you’ll use SAP Tax Compliance or SAP S/4HANA embedded analytics as your solution of choice depends both on your expectations of the functions of the respective solution and on financial considerations. Table 7.1 summarizes important similarities and differences between the two solutions. Features

Embedded Analytics

SAP Tax Compliance

License costs

No

Yes

Content package

Yes

Yes

Available on-premise

Yes

Yes

CDS-based

Yes

Yes

Analyses in real time

Yes

Yes

Flexible dashboards

Yes

No

Standardized task management

No

Yes

Workflow-based task processing

No

Yes

Table 7.1 Embedded Analytics and SAP Tax Compliance in Comparison

As you can see, the choice of a suitable analytics solution depends primarily on your personal preferences and, among other things, on the weighting of the aforementioned criteria.

Use of SAP Analytics Cloud in the Area of Analytics and Monitoring In this section, we haven’t gone into detail about the use of SAP Analytics Cloud as a possible (visualization) alternative. The use of this solution can also be a valuable alternative. This can be assessed, for example, on the basis of the criteria mentioned in Section 7.7.3.

331

7

Direct Taxes in SAP S/4HANA

7.6 Direct Tax Filing and Reporting Tax filing and reporting is usually the most labor-intensive phase of the end-to-end tax scenario and encompasses the entire tax lifecycle in the area of direct taxes—from the preparation of tax reporting as part of year-end closing activities to the preparation of corporate income tax returns or tax filings in the area of WHT. The actual reporting takes place outside the ERP system, so SAP S/4HANA primarily serves as a data provider. In our experience, a very heterogeneous picture emerges with regard to the implemented tax applications in this area. In practice, a large number of historically grown solutions are generally used, which must be taken into account when implementing SAP S/4HANA. These include, for example, tax reporting solutions, applications for the preparation of tax returns, and WHT filings or tax audit management solutions. In the course of the introduction of SAP S/4HANA, the question arises as to whether the solutions used to date should continue to be used or whether a fundamental realignment of the system landscape should take place. If the aim is to retain the existing system landscape, in addition to the tax requirements in SAP S/4HANA, further compelling questions arise with regard to the design of tax data management as an intermediary between the ERP system and the software solutions used. In addition, comprehensive interface requirements must be taken into account. In any case, the project to implement SAP S/4HANA should be used to establish the ERP system as a single source of truth for tax data to reduce previously existing media disruptions and at the same time the number of interfaces to the most possible extent. As an alternative to retaining the existing system landscape, the introduction of SAP S/4HANA offers interesting starting points for fundamentally rethinking tax reporting and integrating it into the SAP system landscape. SAP Profitability and Performance Management and SAP Document and Reporting Compliance are the main solutions to consider in this area.

Future Alignment of Filing and Reporting Which strategy is ultimately pursued depends to a large extent on the licensing costs incurred by existing and future solutions, the functional scope of existing and alternative solutions, whether there is the possibility of a module transfer between the applications, or what effort can be expected in the future with regard to tax data management and the necessary interfaces. User acceptance of existing and potential future solutions should not be underestimated as well.

In the following sections, we’ll show how you can use SAP Profitability and Performance Management as a solution for tax reporting and SAP Document and Reporting

332

7.6

Direct Tax Filing and Reporting

Compliance as a solution for tax filing. Both solutions offer the flexibility to reflect different scenarios for reporting and to implement company-specific requirements. As part of the SAP system landscape, you as a user benefit, for example, from a uniform UX, an existing role and authorization concept, a coordinated IT infrastructure, an existing master data model, and immediate access to tax data via drilldown.

7.6.1 SAP Profitability and Performance Management As outlined earlier, SAP Profitability and Performance Management is an application based on SAP HANA database technology that enables near real-time profitability and cost analysis, as well as complex calculations and simulations. Assuming an available license and setup, you can access the application via the SAP Fiori launchpad (see Figure 7.39).

Figure 7.39 SAP Profitability and Performance Management Tiles in the SAP Fiori Launchpad

Let’s explore an example of how tax reporting can be implemented in SAP Profitability and Performance Management. In our case, it’s accessed via the My Activities – Process Activities tile. Figure 7.40 shows the process activities set up for our example scenario.

333

7

Direct Taxes in SAP S/4HANA

Figure 7.40 Process Activities in SAP Profitability and Performance Management

The application scenario is modeled as a process in SAP Profitability and Performance Management and contains all the essential elements that you may already be familiar with from a classic tax reporting solution. You can access the elements shown in Figure 7.41 by clicking on line item Tax Calculation Process.

Figure 7.41 Elements of Tax Reporting in Profitability and Performance Management

In SAP Profitability and Performance Management, you can perform a number of activities by choosing the line items, including entering master data and maintaining tax rates (see Figure 7.42). In addition, you can perform account mapping and calculate current and deferred taxes, as shown in Figure 7.43.

334

7.6

Direct Tax Filing and Reporting

Figure 7.42 Maintain Tax Rates

Figure 7.43 Calculation of Current Taxes

Figure 7.44 shows the documentation of tax loss carryforwards or the reconciliation of expected to actual tax expense. Figure 7.45 shows the calculation of deferred taxes.

335

7

Direct Taxes in SAP S/4HANA

Figure 7.44 Documentation of Tax Loss Carryforwards

Figure 7.45 Calculation of Deferred Taxes

336

7.6

Direct Tax Filing and Reporting

Within the individual activities, you can switch between the company codes available in the master data or select fiscal year and posting period. Data can either be maintained manually, obtained from data sources, or determined by calculation. Information from different company codes can also be aggregated or consolidated at a higher level using the options offered by SAP Profitability and Performance Management. As a result, a fully-fledged application scenario can be modeled that combines all the essential functions of a tax reporting solution with the advantages of an SAP-integrated application.

7.6.2 SAP Document and Reporting Compliance SAP Document and Reporting Compliance covers a wide variety of reports required for global tax filing in the file formats specified by the tax authorities. From the perspective of direct taxes, this includes in particular the creation of reports such as the SAF-T or the generation of WHT returns.

Developing Your Own Scenarios with SAP Document and Reporting Compliance In addition, for the area of direct taxes, the modeling of your own scenarios is in principle also conceivable, such as the preparation of income tax returns or electronic tax balance sheets.

In this section, we’ll familiarize you with the basic functionality of SAP Document and Reporting Compliance. To create a report that can be transmitted, you can select the Define Compliance Reports tile in the SAP Fiori launchpad (see Figure 7.46).

Figure 7.46 Selection of Define Compliance Reports Tile

Here you can view the structure of the existing reports and define your own reports.

337

7

Direct Taxes in SAP S/4HANA

The definition of reports in SAP Document and Reporting Compliance follows a uniform structure. After you’ve selected a name and description for the report in the first step (Properties), you can define the parameters required for selecting the report in the second step (Parameters). This can be, for example, the selection of company code, fiscal year, or posting period (see Figure 7.47).

Figure 7.47 Define Report Parameters

In the third step (Queries), you can then define the queries that are required to obtain the report data (see Figure 7.48). The queries are usually modeled as CDS views and, if necessary, supplemented by calculations based on the Business Rule Framework plus (BRFplus).

Figure 7.48 Define Queries

Once you’ve completed the aforementioned steps, you can proceed to the creation of the actual report form in SAP Document and Reporting Compliance in step 4 (Document Definition). In our example, you can see the form of a WHT report for Belgium,

338

7.6

Direct Tax Filing and Reporting

which already exists as a template in SAP Document and Reporting Compliance. Figure 7.49 shows the definition of the report.

Figure 7.49 Define Report

You can structure the report by scrolling down to arrive at the screen shown in Figure 7.50. The report form is defined as an XML document and assigns the data fields defined within the queries to the individual form fields. This gives you complete flexibility in defining both the report structure and the underlying data fields.

Figure 7.50 Structure Defined Report

In addition, you also have the option in SAP Document and Reporting Compliance to model forms such as tax certificates, but we won’t go into this in detail here.

339

7

Direct Taxes in SAP S/4HANA

Once you’ve defined the report you want, you can run it in the SAP Fiori launchpad using the Run Advanced Compliance Reports app. By using a filter, you can select the desired report while monitoring the status of existing reporting obligations. Thus, SAP Document and Reporting Compliance is a powerful application that allows you to efficiently model report forms in the format required by tax authorities. You can implement tax filings on the basis of a uniform platform without having to resort to numerous coexisting third-party solutions for the fulfillment of tax reporting obligations, as was previously the case. See Chapter 9, Section 9.3, for more information on setting up the solution. Even though the solutions shown sometimes require a considerable implementation effort, they reveal the potential in terms of process efficiency and process automation, provided that SAP S/4HANA is established as the single source of truth for tax data. Compared to the third-party tax solutions available on the market, which can essentially be classified as standard solutions, tax application scenarios in SAP Profitability and Performance Management or SAP Document and Reporting Compliance can be realized via content packages or flexible extensions. In this respect, the two solutions are generally not used exclusively for tax purposes, but can also be used in other areas of the company, such as finance and controlling. This leads to both a simplification of the system landscape and a more economical use of the applications.

7.7 Direct Tax Planning with SAP Analytics Cloud In the explanation of the tax end-to-end scenario for the area of direct taxes, we’ve already shown that, in addition to ensuring tax compliance, a very important task of the tax function is to support business decisions. This applies in particular to the area of direct taxes. This includes the question of whether an investment decision makes sense in principle, taking into account income tax consequences, and, what current income tax effects arise on the company’s net assets, financial position, and results of operations or cash flow. In the area of direct taxes, tax planning represents a central task in the end-to-end tax scenario, in addition to the fulfillment and monitoring of compliance obligations. In this section, you’ll get to know SAP Analytics Cloud as a solution for supporting tax planning for the area of direct taxes. We’ll show you for which scenarios the solution can be considered and which functions it offers. Then, we’ll go into the central prerequisites for a meaningful tax use of SAP Analytics Cloud and explain for two exemplary use cases how you can implement tax planning with SAP Analytics Cloud.

340

7.7

Direct Tax Planning with SAP Analytics Cloud

7.7.1 Direct Tax Planning Scenarios With the new capabilities coming through SAP S/4HANA, analytics in SAP will also increasingly shift to the business departments of companies. With the introduction of in-memory technology that enables real-time analysis and planning, the shift to cloudbased applications that enable location-independent enterprise-wide access, or the creation of a modern UX that offers the use of new web standards such as SAPUI5 combined with SAP Fiori, the tax function can also act much more as a business partner in the company than before. SAP is building on these developments and, with SAP Analytics Cloud, is providing a solution that is characterized by a complete focus on the cloud and the introduction of flexible and user-oriented self-service components for the analytics area. The analytics area is supported very comprehensively in terms of the application scenarios available: 쐍 Business intelligence (BI)

Evaluation of actual data to create detailed analyses using reports or dashboards. 쐍 Forecast planning

Use actual data to create forecasts or cost and budget plans using reports or dashboards. 쐍 Predictive analytics

Predictive, automated analysis of possible development scenarios based on patterns identified in actual data using scenario-oriented reports or dashboards. 쐍 Application design

Free development of complex analytics applications, for example, based on the aforementioned application scenarios. All the aforementioned scenarios can potentially be considered as application scenarios for the tax function. Which tax scenario can and should be implemented ultimately depends on the quality, granularity, and availability of the tax-relevant data. In the simplest case, tax-relevant data is available directly, for example, as an SAP table in SAP S/4HANA. For complex analytics scenarios, the tax-relevant data must first be transformed and made available in the form of tax data marts (see Figure 7.51). Data Sources

Analytics

Tax Data Hub

SAP Analytics Cloud Tax Data Marts

Tax Data Warehouse

ETL Data Integrator

External Data

Extractors/Interfaces

SAP S/4HANA

Figure 7.51 Overview of Tax Data Model

341

7

Direct Taxes in SAP S/4HANA

In your project to implement SAP S/4HANA, you should therefore also work hard to establish your ERP system as a single source of truth from the perspective of the tax function. The more tax-relevant data is held directly in SAP S/4HANA, the easier it is to use the data for analytical and other purposes. At the same time, data governance of your tax data is also greatly facilitated.

7.7.2 Map Fiscal Application Scenarios Application scenarios in SAP Analytics Cloud are set up as stories, which provide you with a user-oriented entry into the tax planning scenario or report you require. After logging in to SAP Analytics Cloud, you can start creating a story directly on the start screen by clicking Create your first story, as shown in Figure 7.52.

Figure 7.52 SAP Analytics Cloud Startup Screen

Then, depending on the intended audience, you can select different templates for a story (see Figure 7.53). You can implement many use cases of the tax function, for example, using the dashboard template (see Figure 7.54). With the help of this template, you’re able to visualize tax data in table or list form or via different chart variants.

342

7.7

Direct Tax Planning with SAP Analytics Cloud

Figure 7.53 Templates in SAP Analytics Cloud

Figure 7.54 SAP Analytics Cloud: Dashboard Template

To use SAP Analytics Cloud to create reports or dashboards, you need to connect your tax data. SAP Analytics Cloud provides you with comprehensive options for this purpose. They range from the connection of simple files (e.g., Microsoft Excel files) from external data sources to the connection of your SAP system or the databases behind it (see Figure 7.55).

343

7

Direct Taxes in SAP S/4HANA

Figure 7.55 Data Connection in SAP Analytics Cloud

In principle, you can model the connected data before using it in SAP Analytics Cloud. However, for reasons of efficiency and practicability, it’s advisable to set up the tax data model in such a way that essential transformation steps which precede data usage are already implemented at the data layer level, if possible. For example, you could refer to a data layer as defined in a data warehouse where the required data is already fully transformed and stored in a specific format and table.

7.7.3 Implement Tax Scenarios Before you implement SAP Analytics Cloud as a solution, you must fundamentally consider which tax scenarios are to be implemented under which framework conditions. As already mentioned, SAP Analytics Cloud can be useful in the following cases: 쐍 If tax data is already comprehensively stored in SAP S/4HANA, for example, in the

form of master or transaction data 쐍 If there is a heterogeneous system landscape whose data is to be merged centrally in

the cloud 쐍 If external data is also to be included in the analysis 쐍 If the reports are to be made available to a larger group of addressees, that is, not just

the tax function, on a cloud-based basis 쐍 When reporting as a self-service is the responsibility of the tax function

Supplementary Considerations for the Use of SAP Analytics Cloud If, on the other hand, the target group doesn’t require a cloud connection, the complexity of the tax application scenario limits reporting as a self-service, or the system landscape follows a one-ERP strategy, the use of alternative solutions such as SAP S/4HANA embedded analytics may make more sense.

344

7.7

Direct Tax Planning with SAP Analytics Cloud

One use case is the continuous execution of mass data analyses in SAP S/4HANA based on more complex check routines. Their implementation is usually the sole responsibility of the tax function and serves to operationalize the tax control framework or simulate e-audits.

Typical scenarios in which SAP Analytics Cloud can provide support are tax-related detailed analyses of the net assets, financial position and results of operations, tax forecasting calculations, or the monitoring of key tax figures. These include, for example: 쐍 Monitoring tax receivables and tax provisions 쐍 Monitoring the fiscal cash flow 쐍 Determining effects from tax audits 쐍 Determining additional taxes and interest according to tax audit 쐍 Planning the tax base (tax forecast), for example, to assess the recoverability of

deferred taxes In this section, we’ll show two examples of scenarios in SAP Analytics Cloud. In the first scenario, simple tax forecasting is implemented. It’s used to plan the tax base based on the net income for the year under commercial law to determine the tax burden to be expected in the future and the extent to which tax loss carryforwards can be offset. The result of the tax forecasting is displayed alternatively in table view and dashboard view. In the table view (see Figure 7.56), the display of quantitative detailed information is highlighted in tabular form.

Figure 7.56 Table View Tax Forecast

345

7

Direct Taxes in SAP S/4HANA

The dashboard view (see Figure 7.57) is used for the aggregated presentation of key performance indicators (KPIs) in visual form.

Figure 7.57 Dashboard View Tax Forecast

In this case, all data for determining the tax assessment basis can be replicated for the current fiscal year, for example, from SAP S/4HANA, to then update it in subsequent years according to predefined rules. The tax burden is determined directly in SAP Analytics Cloud on the basis of predefined formulas. Tax rates and tax loss carryforwards are obtained from a centrally maintained database. In the second scenario, SAP Analytics Cloud is used to monitor the composition and development of tax receivables, tax provisions, and tax expenses. In this example, the user can filter the tax position by company code, country, vendor (tax office), tax type, and fiscal year (assessment period) and analyze the development in real time. The result of monitoring the tax positions is also presented alternatively in a table view and a dashboard view. As in the previous example, the table view (see Figure 7.58) is used to present detailed quantitative information on the composition of the tax positions. The dashboard view (see Figure 7.59) summarizes essential information about the tax items in visual form. In the present case, this enables continuous monitoring of the tax position, and the usually time-consuming manual reconciliation of tax positions at the end of the fiscal year can be eliminated. To realize this scenario, a standardized recording of tax postings must be ensured at the same time. This can be ensured, for example, by integrating an SAP Fiori app that provides automated support for users in processing tax postings or applying tax tagging principles.

346

7.8 Summary

Figure 7.58 Table View of Tax Account Management

Figure 7.59 Dashboard View of Tax Account Management

7.8 Summary In this chapter, we’ve shown you the opportunities that SAP S/4HANA offers for the area of direct taxes. As central starting points for improving data capturing and tax determination, we’ve presented the possibilities of customizing with regard to the

347

7

Direct Taxes in SAP S/4HANA

general ledger, organizational and master data structures, asset accounting, and chart of accounts, as well as WHT. Building on this, you’ve learned which application scenarios can be implemented via SAP Tax Compliance and SAP S/4HANA embedded analytics in the area of tax analysis and tax compliance management. With SAP Profitability and Performance Management and SAP Document and Reporting Compliance, we also presented two solutions that can provide you with system-integrated support in the area of reporting and filing. Together with SAP Analytics Cloud for the area of tax planning, this provides you with powerful tools along the tax end-to-end process that help you successfully complete the path to a data-driven tax function. This means that the area of direct taxes also forms an important value driver for your SAP S/4HANA project. In the next chapter, we’ll discuss a tax-adjacent topic, transfer pricing, in SAP S/4HANA.

348

Chapter 8 Managing Transfer Prices in SAP S/4HANA This chapter provides a brief overview of the transfer pricing functionality in SAP S/4HANA. We’ll focus on key tax topics that fall within transfer pricing, such as price determination, monitoring, and reporting.

Transfer prices are a prominent topic in many multinational companies for multiple reasons, including the following: 쐍 Scrutiny of tax authorities during related audits 쐍 Different objectives that must be met for tax and management purposes

For many years, there has been an ongoing discussion about how management and legal transfer prices are connected and what an optimized solution looks like. For tax, the objectives are typically related to compliance, risk management, and tax effectiveness. Management and controlling instead focus on coordination, performance measurement, and incentivization of the organization to achieve the expected targets. In this chapter, we discuss tax and related practical requirements for transfer prices, given the focus of tax authorities on transfer prices and the permanently increasing requirements to stay compliant. We’ll begin with a discussion of operational transfer pricing, and then you’ll learn how it’s done in SAP S/4HANA. We’ll also cover transfer pricing determination, monitoring, reporting, and testing.

Base Erosion and Profit Shifting Project A current example that is interdependent with tax transfer pricing and that adds complexity is the Organization for Economic Cooperation and Development (OECD) G20 Base Erosion and Profit Shifting (BEPS 2.0), which we introduced in Chapter 2, Section 2.2.2. To read more about it, go to www.oecd.org/tax/beps.

8.1 Operational Transfer Pricing Let’s first outline the definitions of typical terms used in the area of transfer pricing. In this section, we’ll introduce different types of transfer prices (management and operational), walk through the process, and consider challenges and requirements.

349

8

Managing Transfer Prices in SAP S/4HANA

8.1.1 Tax Transfer Prices First, let's look at the tax-related definition of transfer prices. A transfer price is the price that is applicable for controlled exchange of tangible and intangible goods and services between related parties. The price needs to follow the accepted arm’s length principle for determining each country’s value contribution. The price applied in a transaction between related parties (i.e., controlled transaction) should be the price that two independent parties would agree to under similar facts and circumstances (uncontrolled transaction). The OECD has provided a framework on how to determine an arm’s length price, which is also an underlying principle for many countries’ legislations (https://doi.org/10.1787/ 0e655865-en). The transfer pricing rules are designed to ensure each company in the value chain is rewarded according to the value it contributed to the final product or service.

8.1.2 Management Transfer Prices Management transfer prices are typically defined as enterprise internal prices for the transfer of goods and services between different stages in the value chain. They are seen as predominantly important in decentralized organizations and occur in intercompany and intracompany transactions. Management transfer prices need to fulfill different functions and are especially an instrument for the following: 쐍 Coordination, including setting incentives 쐍 Measurement of success 쐍 Calculation basis for decision-making 쐍 Inventory valuation 쐍 Simplified planning by using normalized values

The coordination function may especially cause a conflict compared to the tax regulations. When corporate management expects local managers to maximize its profitability, this doesn’t necessarily comply with tax rules. There are different options to bridge gaps between the different objectives of performance management and tax. In that context, SAP is a powerful platform to ensure a single source of truth. But the description of an integration scenario for management transfer prices and tax transfer prices is beyond the scope of this chapter.

8.1.3 Operational Transfer Prices Independent of the transfer pricing purpose, which is in general either meeting tax and/or management requirements, it’s necessary to operationalize transfer prices. In practice, this is often called operational transfer prices.

350

8.1

Operational Transfer Pricing

Operational transfer pricing summarizes all activities to execute the transfer pricing policy effectively and efficiently by processes, systems, and organization, which leads to compliant financial statements, including tax reports and effective management reports. In practice this requires an end-to-end transfer pricing process, which is integrated into different business processes and performed by numerous functions in a company. This transfer pricing process is outlined in the next section.

8.1.4 Transfer Pricing Process The transfer pricing process can be structured in six different steps, as shown in Figure 8.1.

Planning and Policies

Price Settings

Transactions and Journal Entries

Monitoring and Adjusting

Testing and Compliance

Controversy and Litigation

Figure 8.1 Transfer Pricing Process

The operational transfer pricing process typically starts from price setting per the transfer pricing policy, and then involves continuous monitoring and adjustments of the prices if necessary. The output of this process is used for transfer pricing documentation covering country-by-country reporting (CbCR), master files, and local files. We’ll now introduce those steps in more detail, with the focus on the operational implications: 1. Planning and policies This initial step is related to the planning of the transfer pricing model. This implies also the definition of the transfer pricing methods for the different types of intercompany and intracompany transactions. Specifically for intercompany transactions, there are five transfer pricing methods that can be applied to establish whether the conditions of controlled transactions are consistent with the arm’s length principle. These five methods consist of three traditional transaction methods: – Comparable uncontrolled price (CUP) method This method compares the price that has been agreed between related parties and the price that has been agreed between third parties or with third parties. – Resale price method This method typically applies for the trading of purchased goods. The price is calculated based on the sales price and a deducted normal profit margin. – Cost-plus method This method starts from the cost base of the provider. The cost base is then increased by a profit markup which results in the transfer price.

351

8

Managing Transfer Prices in SAP S/4HANA

In addition, there are two transactional profit methods: – Transactional net margin method (TNMM) This method compares the net-profit margin earned from controlled transactions in relation to an appropriate base (e.g., costs, sales, assets). – Transactional profit split method Based on that method, the combined operating income or loss from a transaction is allocated to the involved parties. The share is measured by the relative value of each party’s contribution to such overall profits or losses. The selected method for each intercompany transaction type determines the implementation requirement. 2. Price setting and contracts Based on the transfer pricing planning, it’s required to actually calculate the prices according to one of the mentioned five methods. Typically, there are multiple different transfer pricing methods in use within a multinational group to be able to price the different transactions appropriately. Those entail, for example, tangible goods, services, license, loans, and transfer of functions. All methods follow different calculation schemata and drive different practical implications. The different practical complexities drive the need for automations. Typical examples for these complexities are prices that need to distinguish between the following: – Related parties – Granular levels of the product hierarchy – Distinct cost bases – Different market prices – Customs implications – Local legal regulation – Net profits from selected intercompany transactions At this point, an additional complexity must be considered regarding whether the prices need to comply only with legal requirements, or if there are, for example, parallel valuations required for management purposes. This is especially important for production companies. This can be, for example, the group valuation that treats the transaction between intercompany trading partners only as a stock transfer, which passes the cost of the goods manufacturing between the affiliated entities. For selected methods, we’ll discuss further implementation considerations based on SAP S/4HANA in Section 8.2. 3. Transaction processing and journal entries Once the transfer prices are calculated, the intercompany sales and purchase transactions get recorded with the transfer prices that have been maintained. For SAP, these

352

8.1

Operational Transfer Pricing

include intercompany sales orders (e.g., Transaction VA01) and purchase orders (e.g., Transaction ME21N) or financial accounting invoices (e.g., Transaction FB01). 4. Monitoring and adjusting This step refers to multiple different monitoring activities that are required for transfer pricing management. The purpose is to ensure that the transfer pricing policy is actually executed. Noncompliance can potentially lead to double taxation, penalties to be paid, and even reputational risk for the companies. Additionally, today tax authorities are digitally equipped and can analyze data and find anomalies like never before. Therefore, there’s typically a number of different reports and related activities required. The following list provides an overview of what is regularly embedded in the monitoring process: – Segmented tax margin reporting (tax transfer pricing segmentation) This activity is especially important for transfer pricing models that require the consideration and monitoring of a margin, for example, margin earned from contract manufacturing, from contract R&D, or from distribution activities. – Segmented business margin reporting (business unit segmentation) This activity ensures management-relevant and business-specific margin reporting. As the business segmentation is generally different from the just-mentioned tax segmentation, an integrated approach worth considering. This needs to allow for a reconciliation of the tax and management margins. – Transfer pricing risk reporting This activity is related to risk monitoring. Resulting from the execution issues of the tax transfer pricing policy, these risks span, for example, from noncompliant profit allocation and noncompliant execution of intercompany transactions to outdated transfer prices. – Transfer pricing provisions report Based on the quantified transfer pricing risk position, the next activity is related to the assessment of a potential amount for a transfer pricing risk provision. – Transfer pricing alerts The frequent “management by exception” approach requires push information in case of any detected deviation from the standard transfer pricing model that may result in a risk. – Transfer pricing adjustments and true-up report This step determines the potential transfer pricing adjustment amount, which is required to ensure tax compliance. In addition, according to the matching principle, the price-induced revenue and expense corrections need to be performed in the reporting period of the underlying intercompany transaction. This true-up report shows, for example, the deviation of the targeted versus the actual profitability for the required reporting dimension.

353

8

Managing Transfer Prices in SAP S/4HANA

– Multiyear project reports Companies running large multiyear projects look at the transfer pricing induced profitability also across a longer period of time. – Simulation of these reports This activity is related to “how-to” and “what-if” analyses. The purpose is the assessment of the impacts, for example, resulting from transfer price adjustments or changes in the expected trading volumes. – Other reports Additional reports are dependent on the transfer pricing model as well, for example, profit split reports and reconciliation reports for parallel systems for tax and management transfer pricing. These reports are fundamental for potential transfer price adjustments and/or issuance of debit and credit notes to meet legal requirements. These monitoring activities imply several requirements, which are described in Section 8.4. These reports can be deployed in different SAP applications such as SAP Analytics Cloud. 5. Testing and compliance This step finally verifies that the transfer pricing policy has been properly executed and ensures that tax compliance documentation is prepared. The documentation refers typically to the preparation of the tax transfer pricing documentation according to OECD standards. This implies the preparation of the following: – Master file – Local file – Country-by-country reporting To fulfill these documentation standards, certain financial information needs to be prepared, such as the following: – Intercompany transaction volumes for different transaction types – Profitability data – Financial data for tax jurisdictions, for example, revenues, net profit before tax, taxes and tax provisions for the reported year, equity, number of employees, and assets According to the BEPS 2.0 pillar one (Tax Challenges Arising from Digitalization) action plan of the OECD, we expect additional reporting requirements to support the envisaged reallocation of taxing rights. This drives additional complexities, for example, related to revenue sourcing for distinct revenue categories, as well as implies additional transactional classification and the gathering of additional data points. 6. Controversy and litigation The last step refers to the potential controversy with certain tax authorities and potential subsequent litigation. Among others, this activity implies the regular analysis of historic data and time series to defend a certain fact pattern.

354

8.1

Operational Transfer Pricing

8.1.5 Challenges and Requirements You’ve seen that operational transfer pricing needs to enable numerous processes across the organization. For practical reasons, large multinationals are often facing challenges with the end-to-end implementation of the described operational transfer pricing process. We’ve observed multiple practical symptoms where the root cause can be addressed with an appropriate system setup. The following list covers prominent examples for challenges and typical root causes: 쐍 Complex international tax regulations exist that need to take local country specifics

into consideration, such as implementations in semi-manual spreadsheet calculations, which aren’t suited to address the complexity. 쐍 The same impact can be observed due to a complex intercompany transactional

model. 쐍 Interdependencies with other taxes and customs are in most implementations not

considered in the modeling due to the need to simplify. This often leads to uninformed decision-making and related cash leakages. 쐍 Built operational transfer pricing models are often static and have a limited flexibil-

ity regarding business dynamics or regulatory changes because either the built-in solution (e.g., the business warehouse) isn’t supporting this usability requirement or because it’s hardly possible to adjust the available complex spreadsheet model. 쐍 Compliance issues occur due to limited functionality of the existing operational

transfer pricing solution, for example, regarding prospective price adjustments. Companies try to tackle this with large transfer price adjustments, which has other negative knock-on effects. 쐍 The practical transfer pricing processes are regularly not set up end to end, but support

only a certain subprocess such as price setting or monitoring. The interdependencies with other upstream (e.g., planning) or downstream processes (e.g., monitoring) aren’t considered. This is especially the case for silo solutions and spreadsheet-based processes. 쐍 The data models are often neither of source systems nor of the operational transfer

pricing system defined to meet the variety of operational transfer pricing requirements, and the standardization across multiple source systems causes issues. In addition, source systems are regularly not able to provide required raw data, for example, classified intercompany transactions and financial data on permanent establishments. 쐍 The monitoring requirements for multifunctional legal entities are challenging

when there is no segmented reporting solution in place.

355

8

Managing Transfer Prices in SAP S/4HANA

쐍 The decision support is often very limited given simplified modeling (e.g., based on

spreadsheets). In addition, simulation capabilities for the segmented profitability, which is considering market dynamics (e.g., material price, sales price, volumes) or transfer pricing parameters, are lacking. 쐍 The multiple objectives that need to be met could lead into a trade-off decision

related to compliance versus performance management. Simplified modeling and system enablement are common root causes. 쐍 Scattered solutions for single subprocesses lead to a lack of central coordination and

control over the end-to-end process. The consequence are quality issues, inefficiencies, and delays. 쐍 A lack of a central and integrated solution with a single source of truth also leads to

challenges regarding reconciliation and proof of numbers. 쐍 The deployed scattered subsolutions or silo solutions are also the root cause for lim-

ited transparency or insights into calculations. 쐍 The lack of a central and integrated solution is often the reason for documentation

gaps, missing audit trails, and challenging transfer pricing audits. The identified challenges lead to several technical requirements to realize a robust and automated operational transfer pricing process. To automate operational transfer pricing processes, a solution must address the following components, as shown in Figure 8.2: 쐍 Integration across the operational transfer pricing process, as the different process

steps are interdependent 쐍 Data collection, checks, and validations, including master data enrichment 쐍 Rule-based configuration, classifications, calculations, allocations, and reporting 쐍 Traceability, auditing, and user access rights

There are typically four components in a solution: 쐍 A central data repository that holds raw data and results, as well as stores historic

results to allow easy data access to support audit enquiries 쐍 A modeling tool to reflect the rule base and perform calculations and allocations

across multiple dimensions (often designed for tax/business users, meaning they can run and maintain the models with limited support from IT) 쐍 A reporting/dashboarding tool to visualise and analyse the outputs 쐍 A mechanism to prepare and post journal entries, invoices, or updates to price lists

that go back to the ERP system (in our case, SAP S/4HANA)

356

8.2

Transfer Price Calculation

Traceability, audit, user access rights

Rule-based, calculations, allocations, and allocat reporting

Data collection, checks and validations, and master data enrichment

Integrated and Automated Operational Transfer Pricing Process

Figure 8.2 Technical Requirement Categories

8.2 Transfer Price Calculation According to the transfer pricing policy, you must calculate the different transfer prices that are applicable for the intercompany transaction types, for example, sale of semifinished goods, finished goods, and services. You also need to consider that different pricing methods are applicable in practice, which we discussed in Section 8.1.4. The cost-plus and the resale-minus method are very common, which we’ll discuss in this section. Let’s look first at how the cost-plus method is generally defined. The cost-plus method requires the determination of the cost base that often follows the full cost approach. The full cost approach uses the following standard scheme: Direct material cost +

Indirect material cost

=

Total material cost

+

Direct conversion cost

+

Indirect conversion cost

=

Total conversion cost

357

8

Managing Transfer Prices in SAP S/4HANA

Direct material cost =

Total production cost

+

General and administration and other cost

=

Total cost

This cost base needs to be marked up according to the applicable tax regulation. Let’s look now at how the resale-minus method is generally defined. The resale-minus method considers the purchase price for a product of an intercompany transaction, which is then sold to a third party. This resale price, which is reduced by an adequate gross margin, reflects the transfer price. The gross margin can be a percentage that is either determined internally or via external benchmarking. The resale-minus method follows a different calculation scheme: Market price +/-

Market price adjustments

=

Adjusted market price

-

Gross margin

=

Resale-minus price

Market Price Considerations An important consideration for tax and management purposes is the determination of an adequate market price as the starting point. In certain cases, this requires an adjustment to achieve comparability, for example, when the selling entity is serving intercompany and third-party customers. Therefore, in both the cost-plus and the resale-minus methods, a calculation functionality is required that considers, for example, market- and customer-specific adjustments as well as tax-specific considerations, such as the transfer pricing function.

Now, let’s review how costing occurs in SAP S/4HANA for these methods.

8.2.1 Cost-Plus Method in SAP S/4HANA First, we want to look at certain costing-related aspects. We assume that all basic settings for a product costing are available and look now at the costing structure to establish the cost-plus scheme. We need to determine the cost base, which needs to contain the different items that are introduced in the cost-plus calculation (shown in the beginning of

358

8.2

Transfer Price Calculation

this section). Here we want to focus on a few elements that are relevant in the transfer pricing context. Typically, the bill of materials (BOM) is fundamental, which considers the raw materials and semifinished products required for generating a quantity of finished products. Regularly the BOM for costing equals the BOM for productions. This master data element provides the quantities for the costing, including the roll up of cost for multilevel BOM structures. The BOM can be reviewed with Transaction CS03. Costs related to routings and the underlying manufacturing steps are also part of the cost base and can be reviewed with Transaction CA03. As for accounting and for transfer pricing, it’s important that the material master contains the correct costs. These costs determine the calculation base and are configured in the valuation variant. For raw materials, these costs are, for example, the moving average price or the standard cost available. Whatever price is chosen, marking and releasing the cost estimate results in the cost estimate being updated in the material master of the respective material. It’s also possible to define tax prices in the Accounting 2 view of the material master. The same principles apply as for the standard calculation just described. This can be considered by configuration of a valuation variant, for example, for tax prices. The results of this cost estimate can be transferred to the material master. This costing variant can be used for valuation purposes. In addition to the cost of all the individual materials, we need to also consider the overhead in a full cost approach, which covers the general and administration cost. This requires the calculation of a cost uplift. The materials and the conversion cost are typically the assessment basis for the application of the cost uplift for indirect cost. This indirect cost allocation needs to consider transfer pricing requirements. Only costs that are attributable to a respective transaction, which may be different for specific transfer pricing functions, will be considered. This isn’t necessarily the same for all the products, as they may be sold to a third party, sold to an intercompany entity, consumed, and so on. In practice, this regularly deviates from management accounting requirements, as neither the transfer pricing function nor the specific transaction are decisive. Therefore, different valuation variants may be required to accommodate for different valuations. From a practical perspective, the automated determination of dedicated cost uplifts is a typical requirement. This requires, for example, the distinct calculation of a cost uplift per uplift type and plant. This costing can be set up with several costing variants that are available in SAP. The costing scheme is maintained in the underlying valuation variant: 쐍 Basis line items are used for calculation, for example, the direct cost of raw material. 쐍 Uplifts are either based on percentages or quantities. Multiple uplifts can be defined.

359

8

Managing Transfer Prices in SAP S/4HANA

쐍 When considering multiple interdependencies, you may need to leverage condi-

tions. Examples are plants, overhead types, and keys. 쐍 Detailed settings are also required for the uplifts. This includes, for example, the

overhead amount in euros and the reference amount in kilograms. 쐍 In addition, the credit postings need to be defined. This refers, for example to the

cost center, which provides the indirect charge, and the cost type that receives the credit posting. For application of the full cost approach, you need to consider cost center allocations. The cost center allocation can be leveraged to allocate the indirect cost, for example, to production orders or other centers to allow for a full cost approach. But this approach isn’t necessarily in line with the management accounting concept, where these overhead costs are to be reported separately in the management profit and loss (P&L). Also depending on the business complexity and the corresponding transfer pricing requirements, it may be necessary to calculate the cost uplift for tax purposes separately, for example, in an SAP ecosystem application (see Section 8.2.3). For practical transfer pricing purposes, the compliant consideration of indirect cost typically requires the availability of a structured reporting according to Section 8.4. Following the required settings, the typical plan costing run (Transaction CK40N) or for specific materials (Transaction CK11N) performs the costing steps. It performs the cost estimate for each material in the mentioned BOM. The cost estimate can be reviewed by using Transaction CK13N. This also provides the general basis for inventory valuation of the selling plant. For transfer pricing purposes, however, you need to consider additional cost elements, which are typically not subject to inventory valuation of the supplier according to international Generally Accepted Accounting Principles (GAAP) or local tax regulations. Specifically, you must include a profit markup, which allows for an arm’s length transaction.

Address Different Valuation Requirements Companies using the Material Ledger can make use of the parallel valuation functionality to distinguish between legal valuation and group valuation: 쐍 Legal valuation This allows intercompany trading at arm’s length, with the consideration of additional cost and a profit markup being charged. This is defined in the pricing conditions related to the affiliated companies that are treated like external business partners. 쐍 Group valuation

This refers to treating the intercompany transactions as a stock transfer with the cost of goods being passed between the involved entities. The price condition KW00 selects the split of cost components and not only the selling price.

360

8.2

Transfer Price Calculation

8.2.2 Resale-Minus Method in SAP S/4HANA The resale-minus method is also generally supported by the SAP standard. The resaleminus method considers the purchase price for a product of an intercompany transaction, which is then sold to a third party. This resale price, which is reduced by an adequate gross margin, reflects the transfer price. The gross margin can be a percentage that is either determined internally or via external benchmarking. For each customer, including intercompany customers, pricing-relevant master data is defined (e.g., pricing procedure, applicable price list). The pricing procedure follows the information defined in the sales document type and the customer master record. Based on the following scheme, the applicable condition types are considered, which lead to the respective price: Intercompany list price +/-

Material surcharges/discounts

+/-

Customer-specific material surcharges/discounts

+/-

Customer surcharges/discounts

-

Price group discount

+

Freight cost (item)

+

Customs

+

Taxes

=

Final price

This resale-minus pricing procedure defines a group of condition types in a particular sequence. You can use Transaction V/08 to define the intercompany pricing procedure, as shown in Figure 8.3.

Figure 8.3 Pricing Procedure

361

8

Managing Transfer Prices in SAP S/4HANA

The pricing conditions are either set in sales and distribution or in profit center accounting. For legal purposes, we want to focus on sales and distribution. As the price needs to meet the tax requirements, the condition types need to be customized accordingly, for example, application of customer/country discounts to reflect specific market price levels. This can be achieved with the setup of specific condition tables. The condition type can, for example, also consider material- and countryspecific markups. For that purpose, it’s required to set up the condition type per customer and material (see Figure 8.4).

Figure 8.4 Creation of a Condition Record

The value for the typically required conditions for tax purposes can’t necessarily be derived in the SAP standard. Therefore, additional calculations outside the SAP standard are often required to determine the values, for example, for market price adjustments. Another example is the maintenance of the applicable gross margins, which could be distinct per country and distribution channel. The pricing procedure and the required condition types in this case need to become very complex, and the values need to be determined in side calculations. To apply the correct price conditions, an access sequence must also be defined. It’s a search strategy that the system uses to find valid data for a particular condition type. We’ll elaborate on this in Section 8.3. The relevant price is determined based on the applicable pricing procedure. Overall, we’ve seen that standard SAP functionality supports key elements of the entire costing and pricing process. Nevertheless, limitations are common, for example, regarding the calculation according to transfer pricing relevant dimensions (e.g., transfer pricing function, intercompany transaction types). For the introduction of those transfer pricing-relevant dimensions, you need a solution outside the SAP standard. So now, let’s look other SAP applications that allow for a very flexible transfer price setting.

362

8.2

Transfer Price Calculation

8.2.3 SAP Profitability and Performance Management There are a couple of limitations and side calculations required to support the cost-plus and resale-minus methods in SAP S/4HANA. In addition, other transfer pricing methods, for example, the profit split, require additional calculations. In this context, SAP Profitability and Performance Management becomes relevant. Figure 8.5 shows a couple of key capabilities of SAP Profitability and Performance Management, which include the following that are relevant for transfer pricing: 쐍 As the engine for complex cost modeling and allocation, optimized for a high number

of dimensions. This meets the requirement to introduce the transfer pricing-relevant dimensions and the flexible modeling of the transfer price calculation and its input values. In addition, consider the prerequisite of a sufficiently granular calculation of calculation items (e.g., cost uplifts), which is explored further in Section 8.4.4. 쐍 As the calculation and simulation engine that is required to close the gaps that were

discussed earlier. SAP Profitability and Performance Management supports primary costing on ERP dimensions in SAP S/4HANA. 쐍 For simulation of different scenarios considering the transfer pricing model as well

as macro-economic effects. 쐍 For the management of a stepwise process across multiple functions and stakehold-

ers. 쐍 For generation of transfer pricing-relevant P&Ls considering transfer pricing-relevant

dimensions. 쐍 To perform write-back of new prices, for example. 쐍 To ensure auditability and traceability.

SAP Profitabilitly and Performance Management Scenarios

Allocation

Databases

Forecasting

Planning Support

SAP Applications

Auditability

Drilldown

Calculation Engine

Simulation Application

Business Data Aggregator

Enrichment

Functions

Calculations

Other Apps and Data

Figure 8.5 SAP Profitability and Performance Management Functionalities

363

8

Managing Transfer Prices in SAP S/4HANA

8.3 Transfer Price Determination With the correct transfer prices available in the system, now you can explore the determination of the correct transfer price for a given intercompany transaction. According to the transfer pricing policy, distinct prices are relevant for different intercompany transactions, which consider the transfer pricing profile of the involved entities. Decisive factors can be, for example, the involved entities, the traded material, or the end customer. SAP needs to choose the price according to those individual criteria. The functionalities in SAP sales and distribution become relevant again here. It starts with the identification of the applicable pricing procedure and its condition types. In the SAP conditions master data, for example, the base price of the product, discounts, surcharges, and so on are defined. In SAP, the material price condition can be created with Transaction VK11. An access sequence is defined for these condition types. As mentioned, to reflect the access sequence the system uses a search strategy to find valid data for a particular condition type. The sequence defines which condition records have priority over others. This is especially relevant when the company has multiple prices that might be applicable for a customer, for example, a price for the following: 쐍 Material on a global basis 쐍 Material in a market 쐍 Material in a market that is applicable for a specific customer group 쐍 Material for a specific customer (e.g., key account) applicable across markets

The access sequence allows for a structured approach and starts typically with the most specific price, which, in our example, is the material price for a customer. The most general price is the global material price. The pricing procedure is executed based on the identified records for the condition type. In this case, the pricing procedure discussed in the previous section reflects the determination logic for transfer prices.

8.4 Transfer Price Monitoring and Adjustments The plan-based transfer prices are applied in the subsequent intercompany transaction. Transfer price monitoring is the process to ensure that the group’s transfer pricing policy is implemented correctly in the actual transactions. No matter how well the intercompany volume planning and cost planning are done, there are always some deviations from the plan that are usually defined at the beginning of the year. This requires a regular monitoring of the transfer price-relevant key performance indicators (KPIs), such as actual intercompany profits. This profitability

364

8.4

Transfer Price Monitoring and Adjustments

needs to be determined for different dimensions at a different the granularity, as we know it from other finance processes. The applicable transfer pricing dimensions are decisive. In case of noncompliance, corrective actions need to be taken. The instrument that is often required for monitoring and determination of a transfer price is a segmented P&L by transfer pricing dimension. Prerequisite for that is the availability of standard and enriched data dimensions to identify and classify the intercompany transactions. The enrichment can be achieved by extending the Universal Journal with the required transfer pricing dimensions. Further, the allocation and top-down distribution to the material levels needs to be performed while considering the transfer pricing dimension. Once you have the data segmented, allocated, and distributed to the required granularity level and by transfer pricing dimension, the monitoring process can be executed. If the actual margins aren’t within the expected range, then this is an indication for corrective actions. The transfer price will likely need to be adjusted regularly. This adjustment calculation refers back to the price setting step (see Section 8.1.4). Figure 8.6 shows a complete view of this process.

Extend Universal Journal entry in table ACDOCA with transfer pricing dimensions such as transaction group.

Perform allocations for overhead cost accounts.

Perform top-down distribution.

Check if actual transfer pricing target margins are within the target transfer pricing margins per the group’s transfer pricing policy.

If they are not, perform corrective actions (e.g., adjust the price).

Figure 8.6 Steps to Derive a Segmented P&L for Margin Management

We’ll explore these different steps in the following sections.

8.4.1 Extend Universal Journal We start with the various dimensions that are regularly needed for transfer price monitoring. There are two types of dimensions: 쐍 Standard dimensions

Typically, the margin analysis and monitoring by these dimensions is already possible. These dimensions include legal entities, periods, customers, profit center groups/business divisions, and materials.

365

8

Managing Transfer Prices in SAP S/4HANA

쐍 Transfer pricing dimensions

There are also special dimensions for transfer pricing: – Transfer pricing transaction group/transfer pricing transaction tag: Transaction group represents the aggregation of various intercompany transaction types, that is, goods, services, and so on. Goods can further be split based on finished products, raw materials, and semifinished products. These transactions need to be grouped/tagged according to the granularity that is required according to the transfer pricing model and the transfer pricing functions/methods. For example, the intercompany selling entity is a contract manufacturer, and the transfer pricing method applied is cost plus a 10 % markup. – Vendor/supplier: This is needed if you’re monitoring based on transfer pricing methods such as TNMM or resale price. The vendor/supplier for all transactions is usually not filled. The usual P&L statements that are generated for financial statements don’t have the dimensions needed from the transfer pricing perspective. However, with the Universal Journal extensibility options available in SAP S/4HANA, it’s possible to include this additional information in a journal entry. Several extensibility options are available in SAP S/4HANA: 쐍 Classic coding block extension

The classic coding block extension uses Transaction OXK3 and the CI_COBL structure. This structure doesn’t store data like a database table; instead, it’s used to process coding block information within ABAP programs. The introduced field is updated in table ACDOCA along with the COBL structure, which is referenced by multiple views (reporting), structures, and tables. This option provides the following features: – Possibility to extend the processes that lead to journal entries in table ACDOCA – Derivation and validation using validation/substitution (Transactions GGB0/ GGB1) 쐍 SAP S/4HANA key user extensibility using the Custom Fields and Logic app and

the coding block business context This option is the successor of the classic coding block extension in SAP S/4HANA Cloud. This isn’t recommended for the on-premise version of SAP S/4HANA. Be aware that this is only available in the SAP Fiori Reuse UI for many transactions that post journal entries, but not available in SAP GUI transactions. Derivation and validation can be done using FIN_CODINGBLOCK_SUBSTITUTION/VALIDATION enhancement options. 쐍 SAP S/4HANA key user extensibility using the Custom Fields and Logic app and

the journal entry item business context Local extension of journal entries is available in SAP S/4HANA Cloud and SAP S/4HANA. This option provides the following features:

366

8.4

Transfer Price Monitoring and Adjustments

– Custom fields are added (via include structure INCL_EEW_ACDOC) to accounting interface structure ACCIT and to tables ACDOCA and ACDOCP. – Derivation of custom field values is possible with the business add-in (BAdI) BADI_ FINS_ACDOC_POSTING_EVENTS and the FIN_ACDOC_EXT_SUBSTITUTION enhancement option in SAP S/4HANA Cloud. Note that this derivation will only affect table ACDOCA. 쐍 Classic profitability analysis custom characteristics

Profitability analysis characteristics can be created using Transaction KEA5. This option provides the following features: – Extension of the profitability analysis operating concern by custom characteristics created in Transaction KEA5. These fields are also generated in journal entries in table ACDOCA. – Derivation of values is possible with the profitability analysis derivation tool (Transaction KEDR). 쐍 SAP S/4HANA key user extensibility using the Custom Fields and Logic app and

the market segment business context This is the recommended approach. This option provides the following features: – Extension of profitability analysis operating concern available in SAP S/4HANA Cloud and on-premise as of SAP S/4HANA release 2020. – Derivation of values possible with the profitability analysis derivation tool (Transaction KEDR) in SAP S/4HANA. In SAP S/4HANA Cloud, use the Manage Substitution and Validation Rules app for the market segment business context. – Custom fields are also available in all relevant CDS-based cubes and queries.

Market Segments via Transaction SE11 You can also create your own field in an append to include INCL_EEW_MARKET_SEGMENT_ PS via Transaction SE11 and enable this new field for the market segment business context using Transaction SCFD_EUI. This field is then available in the Custom Fields and Logic app. However, SAP doesn’t recommend extending journal entry line items by creating append structures directly in Transaction SE11. In particular, it’s not recommended to create an append structure direct to table ACDOCA as this causes issues, such as the syntax error described in SAP Note 2160045. Due to restrictions on data types for this type of extension, it’s recommended to keep transfer pricing dimensions as data type CHAR10.

Custom fields created with any of these extensibility options are always added to tables ACDOCA (journal entry line items) and ACDOCP (plan data line items). For more details, refer to SAP Note 2453614. To summarize, Table 8.1 shows which options are available on-premise and in the cloud, along with recommendations.

367

8

Managing Transfer Prices in SAP S/4HANA

Extensibility Option

SAP S/4HANA

SAP S/4HANA Cloud

Classic coding block

Available

Not available

SAP S/4HANA key user extensibility: coding block business context

Not recommended

Available

SAP S/4HANA key user extensibility: journal entry item business context

Available

Available

Classic profitability analysis custom characteristics (Transaction KEA5)

Available

Not available

SAP S/4HANA key user extensibility: market segment business context

Available as of SAP S/4HANA 2020. Recommended by SAP.

Available

Table 8.1 Extensibility Options

8.4.2 Derivation and Validation You can categorize the transactional data for transfer pricing purposes. This allows for a distinct reporting of revenue and direct cost. The following options are available: 쐍 Validation/substitution tools

Values for custom fields added using the classic coding block can be derived from other values and validated using the Validation/Substitution tool (Transactions GGB0/GGB1, controlling call-up point 1 for the document line item in controlling). 쐍 Enhancement options

Values for custom fields added using the coding block business context can be derived from other values using the FIN_CODINGBLOCK_SUBSTITUTION enhancement option and validated using the FIN_CODINGBLOCK_VALIDATION enhancement option as of SAP S/4HANA Cloud 1705. 쐍 BAdIs

Values for custom fields added using the journal entry item business context can be derived from other values using the BADI_FINS_ACDOC_POSTING_EVENTS BAdI as of SAP S/4HANA 1511 and the FIN_ACDOC_EXT_SUBSTITUTION enhancement option as of SAP S/4HANA Cloud 1705. Note that this derivation will only update table ACDOCA. 쐍 Manage Substitution and Validation Rules app

In SAP S/4HANA, the profitability analysis derivation tool (Transaction KEDR) can be used for both classic profitability analysis custom characteristic values and custom fields created using the market segment business context. In SAP S/4HANA Cloud, rules created using the Manage Substitution and Validation Rules app can be used to derive values.

368

8.4

Transfer Price Monitoring and Adjustments

With these options, you can categorize the transactional data for transfer pricing purposes. This allows for a distinct reporting of revenue and direct cost. In the next step, the allocation of indirect cost is required to allow for P&L reporting.

8.4.3 Indirect Cost Allocation Limitations To allow for a full P&L reporting according to transfer pricing-relevant dimensions, you now need to allocate indirect costs. The SAP standard cost allocation needs to consider the custom fields introduced in Section 8.4.1. Consider the following regarding the application of custom fields: 쐍 General ledger assessments and distributions (on-premise only)

General ledger assessments in general support custom fields using the classic coding block, the coding block business context, and the journal entry item business context. But Transactions GLGCA1 or GLGCA6 don’t enable a custom field in General ledger assessments or distributions. These transactions aren’t available in SAP S/4HANA Cloud. 쐍 Overhead cost controlling allocations

They don’t support custom fields, so they aren’t an option. 쐍 Profitability analysis allocations

If selected, the custom fields using the classic profitability analysis custom characteristics and the market segment business context are supported. 쐍 Coding block: journal entry items

For the coding block and journal entry item business contexts, custom field values are automatically copied from sender to receiver items by cost center and profit center allocations. 쐍 Coding block: market segments

For the market segment business context, custom fields can be used as receivers in allocations for margin analysis (SAP S/4HANA and SAP S/4HANA Cloud). The same behavior is possible for classic profitability analysis custom characteristics, but only for on-premise SAP S/4HANA. Because these options aren’t available, we need to look at other options, which we’ll discuss in the next section, where we’ll introduce a flexible alternative that leverages custom fields.

8.4.4 SAP Profitability and Performance Management We’ve seen that SAP S/4HANA has limitations regarding complex cost allocation requirements. The better alternative for such requirements is SAP Profitability and Performance Management, which we first introduced in Section 8.2.3. It’s a solution that

369

8

Managing Transfer Prices in SAP S/4HANA

runs using the in-memory SAP HANA database that maintains and executes complex calculations, rules, and simulations, and also has the capabilities to perform complex allocations. It’s important to distinguish between the sender and receiver, as shown in Figure 8.7. The sender can allocate values to the receiver based on an allocation function. Characteristics are defined for the sender that are used to identify the corresponding receiver characteristics, for example, by name matching. The receiver’s key figures represent possible distribution bases.

Sender

Allocation

Receiver

Figure 8.7 Allocation

SAP Profitability and Performance Management also supports direct and indirect allocation. Direct allocation distributes key figures from the sender to the receiver dependent on the characteristics on both sides and based on the (cost-) driver on the receiver site. Indirect allocation distributes all key figure amounts from the sender to the receiver by leveraging the (cost) driver on the receiver site. Figure 8.8 shows how you can flexibly define direct or indirect allocation rules to overcome the limitations to generate a transfer pricing-relevant full P&L, for example, for the allocation of indirect cost amounts to transfer pricing-relevant dimensions such as the transfer pricing function in a specific intercompany transaction. To set up an allocation rule, the sender and receiver rule needs to be specified. This includes the definition of the Rule Type, for example, Direct or Indirect allocation. The sender input is required, such as the posted amount. In addition, the receiver rule needs to be set up.

Figure 8.8 Definition of Rules

370

8.5

Transfer Price Reporting and Simulation

Due to the flexible configuration of the characteristics and the rules, the cost allocation can be defined in the sufficient granularity. This allows for the required transfer pricing reporting and then the transfer pricing calculation.

8.5 Transfer Price Reporting and Simulation For the management of the transfer pricing system, typically additional reports and simulation capabilities are required. These reports are expected to provide an overview on, for example, the tax risk and potentially required provisions, interdependencies with other taxes and customs, and additional relevant KPIs. There are common denominators for these reports which we discussed already in Section 8.4. In those cases where certain transfer pricing master data or results such as net margin in a certain segment are required, subsequent reporting is also limited. This applies especially to the reporting on transfer pricing risk and related provisions, but also for the true-up reporting and any dependent KPI reporting. Let’s first consider some standard reporting options to see why the native SAP S/4HANA functionality may not be sufficient for transfer pricing scenarios: 쐍 Embedded analytics

SAP S/4HANA embedded analytics offers an integrated transactional and analytical data platform to process complex analytic queries. It’s recommended for operational reporting, providing insights into the very latest data coming out of the business transactions. The purpose is to provide real-time insights. It uses the technology of ABAP CDS to create virtual data models (representation of operational data). For transfer pricing purposes, the reporting requirement is beyond real time, as the reporting period is typically 12 months or more. Therefore, embedded analytics doesn’t necessarily meet transfer pricing reporting requirements. 쐍 Simulations

The simulation capabilities are, for example, related to what-if scenarios when transfer pricing or transactional parameters are adjusted. As SAP S/4HANA doesn’t offer any specific simulation capacity out of the box, the ecosystem applications become relevant. Now, we’ll explain two options to allow for the combination of real-time and persistent data of an entire group, which also typically includes non-SAP S/4HANA transactional systems. The first option is SAP BW/4HANA, which consolidates data across the entire enterprise using a standardized but fully extensible data model to support decision-making. This purpose of a single, comprehensive source of current and historical information implicates a redundant (aggregated and harmonized) persistence of data. All data values get harmonized, and the result is a single version of truth. This single version of truth

371

8

Managing Transfer Prices in SAP S/4HANA

could be leveraged for certain transfer pricing reporting purposes, which doesn’t require, for example, complex segmentation, but only transactional volume insights. The second option, SAP Profitability and Performance Management, supports the transfer pricing requirements related to more complex reporting and simulation requirements, as mentioned in Section 8.4.4. SAP Profitability and Performance Management allows integration with SAP Analytics Cloud and SAP Digital Boardroom. It also leverages the integration capabilities of SAP Business Warehouse (SAP BW) and SAP HANA, and supports live data connections and import data connections with SAP Analytics Cloud. The analytics component of SAP Profitability and Performance Management is the standard application to visualize data. It allows self-service reporting, where users can display data, for example, in data grids and charts like the value flow. The value flow shows the flow of values between dimensions, in our case, intercompany business partners (see Figure 8.9). The diagram also supports an interactive drilldown.

Figure 8.9 Analytics Component

In addition, SAP Profitability and Performance Management provides simulation capabilities. It enables the execution of what-if scenarios for the transfer pricing management and the maintenance of assumptions and drivers. Based on the granularity of the financial model, it allows drilldown and provides transparency by offering traceability and auditability information.

372

8.6

Transfer Price Testing and Compliance

A simulation can be accessed via the defined processes. You can execute process activities and change parameters and selections. The parameters can be changed at any time during the execution of activities. For transfer pricing purposes, this can be, for example, related to the profit markup or transaction volumes. You can access reports that are defined on top of processes and provide dynamic reporting and what-if simulations that can include multiple processes. When launching a report, the Reporting & Simulation app opens, as shown in Figure 8.10. When the included processes have the type Simulation, the launched report can be used for a what-if simulation as all parameters are available for changes.

Figure 8.10 Reporting and Simulation

8.6 Transfer Price Testing and Compliance Transfer pricing documentation entails a couple of elements, which drive different requirements: 쐍 Master file and local file

A master file should provide a high-level overview of the group, including the global business operations and transfer pricing policies. A local file should provide detailed transactional transfer pricing information for each jurisdiction of the group. This involves details of material-controlled transactions undertaken by the company and associated companies involved, amounts involved in those transactions, and

373

8

Managing Transfer Prices in SAP S/4HANA

transfer pricing analysis with respect to those transactions. This requires the preparation of an overview on the intercompany transactions with the related parties required. This is also known as a transaction matrix. 쐍 Country-by-country reporting (CbCR)

In CbCR, you must provide different financial data for each tax jurisdiction, for example, revenues (unrelated party, related party, total), profit (loss) before income tax, income tax paid (on cash basis), income tax accrued (current year), stated capital, accumulated earnings, number of employees, tangible assets other than cash, and cash equivalents. In this section, we’ll explore how this can be enabled with SAP S/4HANA.

8.6.1 Transaction Matrix The transaction matrix represents sales volume considering all intercompany transactions in a segmented view, as shown in Table 8.2. The report shows the following: 쐍 Sales volume by selling entity, buying entity, and transaction groups. 쐍 Transaction group representing the aggregated various transaction types, that is,

goods, services, and so on. Goods can be further split based on finished products, raw materials, semifinished products, and so on. Buying Entity Selling Entity

Transaction Group

Sales Volume

A

A

Finished goods

€ 15.465.400

A

Semifinished goods

€ 8.465.400

B

IT services

€ 9.465.400

€ 5.679.240

€ 33.396.200

€ 5.679.240

B

C

€ 15.465.400

€ 8.465.400

€ 3.786.160 € 15.465.400

€ 12.251.560

Table 8.2 Simplified Transaction Matrix Example

For the generation of the transaction matrix, the data dimensions discussed in Section 8.4.1 are required. With the seamless integration of embedded analytics features in SAP S/4HANA, you can create your own report for the transaction matrix. This depends on the availability of required reporting dimensions as indicated in the simplified example in Table 8.2.

374

8.6

Transfer Price Testing and Compliance

8.6.2 Country-by-Country Reporting CbCR is primarily the preparation of two required tables. The first table specifically requires the data per jurisdiction, as shown in Table 8.3. This is an aggregation of predominantly local entity financial data. If the related and unrelated party revenues are recorded on different accounts, the local financial statements can be leveraged. Name of the Multinational Enterprise (MNE) Group: Fiscal Year Concerned: Currency: Tax Jurisdiction Revenues

Unrelated Party Related Party Total

Profit (Loss) before Income Tax Income Tax Paid (on Cash Basis) Income Tax Accrued (Current Year) Stated Capital Accumulated Earnings Number of Employees Tangible Assets Other Than Cash and Cash Equivalents

Table 8.3 Overview of Allocation of Income, Taxes, and Business Activities by Tax Jurisdiction

Most of the financial data (e.g., revenue, profit, tax paid) needed to populate the first table can be sourced from the financial statements, for example, balance sheet and income statement generated in SAP S/4HANA (refer to report RFBILA00 or Transaction FC10). It’s also possible to leverage the Balance Sheet/Income Statement – Multidimensional app from SAP Fiori to access financial statements on the account level. You can also create your own report using the various possibilities that comes as part of SAP S/4HANA embedded analytics. The second table, as shown in Table 8.4, instead requires also qualitative information specifically on the conducted business activities. This information can’t be sourced from the SAP S/4HANA standard. Typically, it doesn’t require automation, as it’s not dynamically changing.

375

8

Managing Transfer Prices in SAP S/4HANA

Name of the MNE Group: Fiscal Year Concerned: Tax Jurisdiction Constituent Entities Resident in the Tax Jurisdiction

1.

2.

3.

4.

5.

Tax Jurisdiction of the Organization or Incorporation if Different from the Tax Jurisdiction of Residence Main Business Activities

Research and development Holding/managing intellectual property Purchasing or procurement Manufacturing or production Sales, marketing, or distribution Administrative, management, or support services Provision of services to unrelated parties Internal group finance Regulated financial services Insurance Holding shares or other equity instruments Dormant Other

Table 8.4 All the Constituent Entities of the MNE Group Included in Each Aggregation per Tax Jurisdiction

If any further brief information or explanation is necessary or would facilitate the understanding of the compulsory information provided in the CbCR, you can provide that information in a commentary table.

376

8.7

Summary

8.7 Summary You’ve now seen that a robust and efficient operational transfer pricing system implemented using SAP helps to address the following challenges: 쐍 Improving transparency and internal controls on data and calculations, for exam-

ple, exception reporting dashboards 쐍 Reducing year-end adjustments and implementing prospective transfer pricing

models, for example, segmented P&L with actual and forecast data integration 쐍 Integrating service charging and royalty models into the integrated transfer pricing

solution 쐍 Enabling intelligent transfer price adjustments, including impacts of price adjust-

ments (customs, inventory, VAT, pharma specifications, antidumping, etc.) 쐍 Supporting compliance and audit readiness (historic data and audit trail) and policy

making (analytics and simulations) Overall, we’ve shown that multiple operational transfer pricing subprocesses can be enabled with SAP S/4HANA. This refers to price setting for certain transfer pricing methods, price determination, and certain reports such as the transaction matrix and CbCR tables. But there are also limitations, which is why it makes sense to consider SAP ecosystem applications such as SAP Profitability and Performance Management. The generation of full segmented P&Ls, integrated transfer pricing adjustments, further transfer pricing reporting capabilities, and application of certain transfer pricing methods especially require a flexible modeling application such as SAP Profitability and Performance Management. In the next chapter, we’ll discuss tax reporting topics for both direct and indirect taxes.

377

Chapter 9 Tax Reporting in SAP S/4HANA Various capabilities and solutions are available for indirect and direct tax reporting with SAP S/4HANA. This chapter will discuss key considerations around tax reporting and walk through the key capabilities, focusing on SAP Document and Reporting Compliance in particular.

In this chapter, we focus on tax reporting for SAP S/4HANA (indirect and direct taxes). We start with general observations in the tax reporting landscape, resulting functionalities, and characteristics for tax reporting solutions and then cover periodic aggregated reporting obligations (e.g., value-added tax [VAT] return) and continuous transaction control (CTC) requirements (e.g., e-invoicing). This is followed by configuration guidance for SAP S/4HANA standard solutions for VAT returns, VAT listings, and Intrastat. In addition, the SAP reporting solution—SAP Document and Reporting Compliance for SAP S/4HANA—will be discussed in detail in this chapter.

9.1 Worldwide Tax Reporting Requirements As described in Chapter 2, more and more jurisdictions are introducing and establishing digital reporting requirements (DRRs), that is, near real-time tax reporting and mandatory e-invoicing regimes. For taxpayers, especially multinationals, this often means paradigm shifts in terms of organizing tax reporting processes and implementing and covering local or global tax reporting solutions at a very high pace. This is clearly a global trend that doesn’t exclude any region in the world. We see a very heterogenous tax reporting landscape in South America, Europe, India, China, and Australia within and throughout the regions and continents. South American countries such as Mexico and Brazil were digital tax reporting pioneers and developed totally different transaction-based reporting requirements, which is a challenge for multinational and local taxpayers as neither unification (tax system itself and reporting obligations as well) could be agreed on nor standardized. Tax functions must manage the tax challenges and the opportunities. Traditionally, tax compliance processes (i.e., tax reporting obligations and declarations, statutory tax accounting) are based on financial data that is requested from accounting and then extracted from the statutory or report-based environment into a separated tax

379

9

Tax Reporting in SAP S/4HANA

surrounding with very few or missing connections to operating processes and transactional data. After preparation and submission to the tax authorities, the tax audit period begins and often ends after years. With the raising of transaction-based, real-time reporting requirements worldwide, an evolution in digital tax compliance models is predicted. The prediction includes live data-based tax management in integrated operational system landscapes with connected stakeholders of the tax functions (other areas in the company and their employees, group entities, tax administrations, and banks). Figure 9.1 shows the process integration and the change from separated tasks in the traditional compliance model to end-to-end tax scenarios (refer to Chapter 1, Section 1.5, for end-to-end scenarios) that follow operational processes and data in the digital compliance model. Traditional Compliance Model Request Data from Accounting

Prepare, Fix, and Analyze Data

Prepare Form

Submit Return

Wait for Audit

Digital Compliance Model Extract Data Directly from Source Systems

Submit Data Directly to Authority

E-Audit, E-Assess, E-Match

Respond to Assessment or Audit

Figure 9.1 Evolution of the Compliance Process (Source: EY)

A further angle is the growing integration between taxpayers and tax authorities. Resulting from the previously mentioned transition, tax audits can also happen based on real-time business data of all business partners included in the transactions. This also has huge efficiency potential for both the taxpayers and the tax authorities. Depending on the development of rising tax reporting obligations, we distinguish between pure (real-time) tax reporting without connection to business processes and mandatory e-invoicing, which is fully integrated in the business (invoicing) process. In the new digital compliance model for worldwide tax reporting, there are several fundamental concepts to consider, which we’ll discuss in the following sections.

9.1.1 The Five Fingers of Tax Administration According to TaxVoice, the tax requirements raised by tax authorities can be compared to a hand. We can conclude that there are at least five fingers that grab after the following:

380

9.1

Worldwide Tax Reporting Requirements

쐍 Payments

The taxpayers need to report single payments together with tax reporting data. Split payment measures change the payment directions from taxpayer (customer) directly to the tax authority. Retailers and e-commerce businesses are especially affected, but the effect isn’t limited to these industries. 쐍 Logistical data

Tax authorities are tracking logistical movements, and taxpayers require live approvals of cross-border movements of goods. This directly affects the supply chain of the taxpayer and their customers and is therefore business critical. For example, in Hungary, we see Electronic Road Transportation Control System (EKAER) reporting requirements that fall under this category. 쐍 Purchase orders

The tax authorities are demanding business documents without a direct relevance for the tax burden and tax payment. From the purchase orders to the invoice, many things can happen, and changes can lead to heavy investigations to meet such requirements. We see this, for example, in Italy. Since February 1, 2020, the Public Administrations of the National Health System are obliged to issue purchase orders for goods in electronic format. These purchase orders are passed through the Nodo Smistamento Ordini (NSO) platform, which is an affiliated system under the Sistema di Interscambio (SDI; effectively an invoice approval portal). An extension of this obligation started in January 2021 and includes purchase orders for services. 쐍 Invoices/till fiscalization

Invoices are part of real-time tax reporting requirements and mandatory e-invoicing. As result of EU studies, we’ve learned that especially mandatory e-invoicing is the most proportional CTC type that leads to transparency for the tax authorities and to efficiency gains on the taxpayer side (e.g., SDI, mandatory e-invoicing in Italy). Real-time tax reporting only causes transparency without efficiency gains for taxpayers (e.g., Suministro Inmediato de Información [SII] in Spain). With regard to business-to-consumer (B2C) store sales, cash registers are under control of tax authorities under the till fiscalization regime. 쐍 General ledger data on the line item level

Invoices are categorized into account groups and need to be reported that way. This is the case in Greece.

9.1.2 Maturity of Tax Reporting Requirements There are several methods to compare the maturity of tax reporting requirements of jurisdictions. We want to introduce a measure that takes into account the relation between the taxpayer and the digital tax administration. Figure 9.2 shows five levels of tax reporting maturity, which can be broken down as follows:

381

9

Tax Reporting in SAP S/4HANA

1. Level 1: E-file Use of standardized electronic forms for filing tax returns required or optional; other income data (e.g., payroll, financial) filed electronically and matched annually. 2. Level 2: E-accounting Submit accounting or other source data to support filings (e.g., invoices, trial balances) in a defined electronic format on a defined timetable; frequent additions and changes at this level.

Paradigm Shift 1 Between level 2 (E-accounting) and level 3 (E-match), there is a paradigm shift. In comparison to level 2, the tax authorities can match documents on level 3 between customer and supplier and are able to manage these cross-checks in real time.

3. Level 3: E-match Submit additional accounting and source data; government accesses additional data (bank statements), begins to match data across tax types and potentially across taxpayers and jurisdictions in real time. 4. Level 4: E-audit Level 2 data analyzed by government entities and cross-checked to filings in real time to map the geographic economic ecosystem; taxpayers receiving electronic audit assessments with limited time to respond.

Paradigm Shift 2 In real-time e-assessments of both supplier and customer, no more declarations are necessary as the tax authorities have already received the relevant data.

5. Level 5: E-assess Government entities using submitted data to assess tax without the need for tax forms; taxpayers allowed a limited time to audit government-calculated tax. Level 1: E-File

1

Level 3: E-Match

2

3

Level 2: E-Accounting

Figure 9.2 Levels of Tax Reporting Maturity

382

Level 5: E-Assess

4

Level 4: E-Audit

5

9.1

Worldwide Tax Reporting Requirements

9.1.3 Tax Record Evidence Requirements Another perspective following the fast global CTC development is the rising importance of evidence of your own, and the business partners’, transaction data. If tax authorities offer archived transaction data and prefilled tax declarations as part of a centralized or decentralized exchange system, it will be much more important for tax functions to establish a very strong evidence position to be able to confirm or challenge preapproved transaction data by tax authorities. Based on a study rendered by Sovos, “Global VAT-Trends 2020”, Figure 9.3 shows how the source of truth of tax data shifts from the taxpayer to the tax authorities during the ongoing CTC transformation. Taxpayer

A

B

Tax Authority

Data Source

Backward Ascertainment

Data Source

Reconciliation by Taxpayer

C

Disproval by Taxpayer

Copy of Data

Data Source

Figure 9.3 Tax Record Evidence Shift

Tax record evidence requirements fall into three categories, as shown in Figure 9.3: 쐍 A: Post audit

In post-transactional tax audits, there is a high dependency on taxpayer’s data sources. This leads to the necessity for a backward ascertainment of the taxpayer’s data sources. 쐍 B: E-audit procedure

In this category, the tax authorities work based on a copy of a taxpayer’s data source which is cross-checked against trading partners. We see an example in Greece, with the myDATA (my Digital Accounting and Tax Application) platform. You file tax information to myDATA by using a platform-compatible software tool (e.g., Fonoa). Data is transferred into myDATA. which then validates the information and generates e-books. 쐍 C: Future procedure

As a service of tax authorities, they provide data based on authenticated, preapproved transaction data previously received from the taxpayer. The taxpayer performs a completeness check to confirm the data source of the tax authority. In

383

9

Tax Reporting in SAP S/4HANA

Italy, tax authorities already offer a free archive solution (provided by the Sogei company).

9.1.4 Global Tax Reporting Compliance Models As the future developments of tax reporting hold lots of new requirements in readiness, a solution for tax reporting needs to reflect the specific situation of a company and the resulting tax reporting requirements. During SAP S/4HANA implementations or deployments after go-live, tax functions can and should integrate their requirements and tax reporting solution considerations. The following categories will be considered in vendor selection processes and tax reporting solution discussions, as shown in Figure 9.4: 쐍 Insourcing

Following the insourcing alternative, the tax function has the highest degree of control and needs in-house talent and knowledge to control and retain the in-house capabilities. The costs for people, solutions, and processes are in line with the high level of control. The insourcing scenario can be accompanied by an external partner, as in all other scenarios. The role of the external partner is different here. Possible partners are solution providers that offer in-house solutions such as SAP Document and Reporting Compliance or software as a service (SaaS) solutions such as SAP S/4HANA Cloud. 쐍 Outsourcing

Outsourcing of the tax reporting process needs an additional partner and/or solution provider. The extent to which the in-house tax function is involved in processes and solutions is very limited; for example, the role may be limited to sign-off on tax declarations and returns. This alternative causes lower investments as services rendered are the basis of remuneration in exchange for outsourced control and inhouse use of external knowledge. IT investments are very limited to nonexistent. This variant is often chosen to ensure flexibility in tax functions and to secure tax compliance during the establishment of new business and group structures. In some cases, it may bridge the final scenario of an insourcing or co-sourcing model. 쐍 Co-sourcing

This is a mixed scenario with parts of both alternatives—insourcing and outsourcing. In general, the functional control remains with the in-house tax function to keep a minimum level of control and in-house knowledge. In very data-sensitive areas, in-house tax resources are without alternative. Headcount-related costs for recruiting, training, and employment can be reduced with the help of external employees.

384

9.2 Standardized Tax Reporting in SAP

Co-Sourcing

Functional Control Remains In-House

Highest Degree of Control

Cost Flexibility via »As-Needed« Resources Responsibility and Resources

Cost Effective

Control and Cost

In-House Talent and Knowledge Controlled and Retained

External Partner »Owns« Human Resources and Day-to-Day Administration (Secure Business Continuity)

ing urc tso Ou

Ins ou rci ng

Significant Reduction in Recruiting, Training, and Employment Costs

Minimal or No Investment in Tax Technologies Global Knowledge Management by External Partner

Figure 9.4 Compliance Model Alternatives (Source: EY)

We see such approaches in connection with the externalization of service hubs or shared service centers. What all these alternatives have in common is the need for tax reporting solutions, whether internal or external. The following sections will cover different ways to manage the tax reporting process with SAP S/4HANA core functionalities or SAP solutions available for SAP S/4HANA.

9.2 Standardized Tax Reporting in SAP It’s still possible to manage, generate, extract, and submit the tax reporting data in the legally required format form in SAP S/4HANA. In the following sections, we’ll give an overview of the most important settings for tax reporting in SAP S/4HANA.

9.2.1 Standard Report for Value-Added Tax Returns In many jurisdictions, you must periodically submit a VAT return according to the local filing requirements. Submitting the VAT return on a paper form is no longer an option, except in some special circumstances.

385

9

Tax Reporting in SAP S/4HANA

The electronic transmission of the reporting data to the tax administration takes place via interfaces to public tax portals (e.g., in the United Kingdom, the Making Tax Digital (MTD) initiative).

Report RFUMSV00 Within SAP, the standard report for VAT returns has traditionally been report RFUMSV00, which we’ll discuss in this section.

Report RFUMSV00 Availability There are several countries where SAP no longer supports report RFUMSV00. See SAP Note 2480067 for a complete list. After the SAP support stops, no more legal changes are supported by report RFUMSV00 in SAP S/4HANA. It’s recommended to check available alternatives for a future-proof tax reporting solution.

The first step toward a VAT return filing out of SAP is to select the data to be reported using program RFUMSV00. This program allows running in the background or can be started using Transaction S_ALR_87012357. The transaction path in the application menu is Accounting • Financial Accounting • General Ledger • Reporting • Tax Reports • General • Advance Return on Sales/Purchases • Advance Return on Sales/Purchases. Figure 9.5 shows the initial screen of report RFUMSV00.

Figure 9.5 Report RFUMSV00: Start Screen

386

9.2 Standardized Tax Reporting in SAP

The SAP standard report RFUMSV00 selects data from table BSET (Document Segment Tax Data). If you want to apply filtering rules to limit the document selection, you can choose the posting date, fiscal year and fiscal month, or the document date. Mass data requests can incur long waiting times. Therefore, further selections of documents are useful in the Further selections area, as shown in Figure 9.6.

Figure 9.6 Report RFUMSV00: Additional Selections

Following are other data selection parameters: 쐍 VAT group

Not all company codes are part of the same VAT group. 쐍 Tax codes

Some nontaxable tax codes aren’t relevant for reporting.

387

9

Tax Reporting in SAP S/4HANA

쐍 CPU date

This is the technical entry date captured by SAP. 쐍 Document date

This matches with the entry date of the document in financial accounting. It’s possible to change that date manually in some transactions. In some countries, legal requirements can be fulfilled by entering accounting documents with a tax reporting date (technical field BKPF-VATDATE). Report RFUMSV00 allows you to use the tax reporting date as an additional or alternative criterion for document selection. The tax reporting date needs to be activated in the global parameters of the company code (activate the indicator). The default value for the tax reporting date depends on the settings in Customizing for financial accounting (menu path Financial Accounting (New) • Financial Accounting Basic Settings (New) • VAT • Calculation • Assign Company Code Document Date for Tax Determination). The default system proposal is the posting date as the tax reporting date. See Chapter 3, Section 3.1.1, for more information.

Adaptation of the System Proposal If the tax reporting date is activated at the company code level, every accounting document with a tax code in a general ledger account line must contain a date in the BKPFVATDATE field. If the function isn’t active, the field in the accounting document isn’t formatted. Enhancement spot VATDATE_RULES with business add-in (BAdI) definition VATDATE_VALUES is available. SAP delivers the default implementation VATDATE_VALUES_ DEFAULT_SAP for this BAdI. See SAP Note 1232484 and the documentation “Reporting by Tax Date” in the note’s appendix.

In the Customizing of report RFUMSV00 (see Figure 9.7), you can assign a general ledger account to be able to post the VAT liability. For this posting, the batch input procedure is used. The Payable Posting area (not shown) is available to set up the data required for background processing. In the Output control area, it’s important to prepare your data for further processing. Depending on the use of the data, you can activate output tax and input tax at the line item level. Especially if you want to include the data for tax monitoring purposes, the line item is the right level of detail. To manage the size of the output data, you can use the previously mentioned selection criteria (e.g., company code and posting date) to avoid timeouts during data processing. Besides the standard layout, you can customize the layout for each output list after clicking the Configure button.

388

9.2 Standardized Tax Reporting in SAP

Figure 9.7 Report RFUMSV00: Output Processing

Sometimes you have to repeat a reporting run after the incorporation of changes. For this purpose, you can specify whether the system should update the documents that have already been selected, as shown in Figure 9.8. If the program is run with the Update documents: Update run parameter chosen, all selected data records receive a time stamp. Relevant data fields are populated automatically, that is, the fields for the

389

9

Tax Reporting in SAP S/4HANA

date on which the tax return was made (STMDT) and time of the program run for the tax return (STMTI).

Figure 9.8 Report RFUMSV00: Posting Parameters

Keep in mind that rerunning report RFUMSV00 only considers data records that don’t contain the date or time from an earlier program run, mainly subsequently entered documents during the reporting period. The Do not update documents parameter must be set to consider all accounting documents independently of previous runs.

390

9.2 Standardized Tax Reporting in SAP

A monthly tax return submission with SAP S/4HANA requires some settings to be done beforehand. You assign fields of the tax return form to your tax codes set up in SAP S/4HANA. For example, as shown in Figure 9.9, in a mapping for a German VAT return, you assign the tax code at the tax rate of 19% to VAT return field 81 and link the tax codes for deductible input tax amounts from domestic deliveries to VAT return field 66 (not shown).

Figure 9.9 Mapping Tax Codes to VAT Return Fields

In column Tx, you assign tax codes to a combination of transaction key (column Trs) and form field (column GrpNo). The transaction keys (column Trs) are used to determine accounts or posting keys for line items that are created automatically by the system. The transaction key MWS is assigned to accounts receivable tax codes, and the transaction key VST is assigned to accounts payable tax codes. VAT group settings can be considered by following path Financial Accounting • General Ledger Accounting • Periodic Processing • Reporting • Report • Sales/Purchases Tax Returns • Define Tax on Sales/Purchases Groups. Figure 9.10 shows an example of a sales tax group.

391

9

Tax Reporting in SAP S/4HANA

Figure 9.10 VAT Group Details

In our example, you can see that the Tax Group that represents the VAT group is assigned to company code 1010 as the controlling company (in the Dom.Ent./CoCode field). This company code reports the VAT for all company codes assigned to the VAT group. You assign company codes (controlling companies and controlled companies) to sales tax areas in a separate view. You can find this view via menu path Financial Accounting • General Ledger Accounting • Periodic Processing • Reporting • Report • Sales/Purchases Tax Returns • Assign Company Codes to Tax on Sales/Purchases Groups. Figure 9.11 shows the view where the assignment between company code and tax group can be done. Identify the company codes that are part of your VAT group as the controlling company or subsidiary. Then assign the VAT group key (Tx Grp field) previously defined tax group to these company codes to map the VAT group.

Figure 9.11 Company Code to VAT Group Mapping

392

9.2 Standardized Tax Reporting in SAP

Report RFUMSV10 You can use report RFUMSV10 (additional list for advance return for tax on sales/purchases) for reconciliation purposes in connection with the advance return for tax on sales/purchases, as shown in Figure 9.12.

Figure 9.12 Report RFUMSV10

393

9

Tax Reporting in SAP S/4HANA

This report also selects accounting document data, but from database table BSEG (Accounting Document Segment). The ABAP list that the system prepares after running the program also contains a column for the general ledger account to which the VAT assessment base was posted. Keep in mind that no completeness check is possible as postings without tax codes aren’t captured in this report. You’ll notice many parallels to report RFUMSV00. One important difference to report RFUMSV00 is the selection field G/L account, as this program additionally selects the general ledger account in the standard layout.

9.2.2 Standard Reports for EC Sales List You can also use SAP programs to report your company’s tax-exempt intra-community supplies and other intra-community services and/or deliveries as part of intracommunity triangular transactions in the European Commission (EC) Sales Lists (and EC Purchase List in some jurisdictions, e.g., Spain). The submission of EC Sales and Purchase Lists is typically due at a fixed date per filing period that differs from one EU country to another (see Chapter 2). The following sections provide an overview of the Customizing settings relevant for data selection and output processing of the EC Sales List.

Data Medium Exchange Engine Format Tree The system requires a Data Medium Exchange (DME) Engine format tree with the structure of the current reporting form to prepare the reporting data in comma-separated values (CSV) format. The DME Engine is a set of data exchange tools that you can call using Transaction DMEE. You can also find the DME Engine in Customizing via menu path Financial Accounting (New) • General Ledger Accounting (New) • Periodic Processing • Reporting • Sales/Purchases Tax Returns • Define DME Formats for Tax Reporting, arriving at the screen shown in Figure 9.13.

Figure 9.13 DME Engine Settings for the EC Sales List

Originally intended for communication with banks, the DME Engine is used to process data for various reports, including tax reports. The message type is specified by the Tree type, which is ASLD (Summary Report) for the EC Sales List.

394

9.2 Standardized Tax Reporting in SAP

In Figure 9.14, you can see an example of a DMEE structure of the EC Sales List for Latvia.

Figure 9.14 Transaction DMEE: EC Sales List Latvia

Report RFASLD20 The basis for the data preparation is the country-independent report RFASLD20 (EC Sales List Report in DTA Format).

Report RFASLDXX Availability There are several countries where SAP no longer supports report RFASLD20. SAP maintains it in the form of notes or as part of support packages. SAP Note 2480067 shows the SAP supporting period and replacement of existing legal reports with SAP Document and Reporting Compliance statutory reports.

You can find report RFASLD20 in the accounting application menu by choosing Accounting • Financial Accounting • General Ledger • Reporting • EC Sales List • General • EC Sales List in DME Format (or executing Transaction S_P00_07000221). In Figure 9.15, you can see the report RFASLD20 selection screen, which includes parameters such as Company code, Document Number, Fiscal Year, and the General selections such as Posting date and Reference number. With these selection parameters, you can choose the relevant data for a monthly or quarterly EC Sales (and EC Purchase) List. You need to enter the Reporting Quarter or Reporting Period in the respective fields.

395

9

Tax Reporting in SAP S/4HANA

Figure 9.15 Report RFASLD20: EC Sales List

Further selections are possible and comparable to report RFUMSV00. With report RFASLD20, you can and should activate Select Goods Delivery and Select Service as both types of supplies are to be reported in the EC Sales List even though EC Sales List requirements can differ in the European Union (EU). The Output control is limited to the digital format in report RFASLD20 either as list output or as a DME file. The electronic transmission needs to be set up separately according to local requirements.

396

9.2 Standardized Tax Reporting in SAP

Report RFASLM00 With report RFASLM00, you have an alternative to the digital variant in that you can print out the EC Sales List. Report RFASLM00 is accessible via Transaction S_ALR_ 87012400 or menu path Accounting • Financial Accounting • General Ledger • Reporting • EC Sales List • General • EC Sales List. An SAPscript and a PDF-based form for printing the EC Sales List is provided by SAP with the technical name F_ASL_DE. In comparison to report RFASLD20, there is a Print control section in the screen shown in Figure 9.16 to manage the print parameters. In Figure 9.17, you see the Print Screen List screen after clicking Print parameter (form) in Figure 9.16. In the Print Screen List, you can select your Output Device to print the EC Sales List form.

Figure 9.16 Report RFASLM00: EC Sales List

397

9

Tax Reporting in SAP S/4HANA

Figure 9.17 Print Screen

9.3 SAP Document and Reporting Compliance for SAP S/4HANA Advanced compliance reporting can be used in the context of SAP S/4HANA and SAP S/4HANA Cloud, now under the name SAP Document and Reporting Compliance for SAP S/4HANA. With SAP Document and Reporting Compliance for SAP S/4HANA, you can forward aggregated company-related information to individual local government and tax authorities. This ensures that global tax reporting requirements are met. The variety and complexity of local regulations and their tax-relevant processes mapped in IT systems require a central solution for the administration and monitoring of all different requirements. The SAP solutions for compliance reporting are delivered in two versions: basic compliance reporting and advanced compliance reporting (ACR). The basic compliance reporting services are part of SAP S/4HANA Enterprise Management and are therefore included in the SAP S/4HANA license. Advanced compliance reporting requires an additional license. This section outlines the overall settings, values, objectives, and rationale for the associated configuration area.

9.3.1 Setting Up Compliance Reporting SAP Document and Reporting Compliance statutory reporting needs to be set up before you can manage your tax reporting requirements with the solution. In the following sections, we’ll discuss the steps required to enable a proper setup.

398

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

Reporting Entities and Categories To create reports in ACR, it’s required to set them up in Customizing. To do so, you can execute Transaction SPRO and navigate to Financial Accounting • Advanced Compliance Reporting • Setting up Your Compliance Reporting. In Customizing, links are created between the reporting entities for which VAT reports must be submitted and the definitions, categories, and activities relevant for the corresponding compliance reporting scenario. We’ll walk through some key configuration activities at a high level in this section, as shown in Figure 9.18.

Figure 9.18 Define Compliance Reporting Entities

The purpose of the ACR documentation is to capture all data following the configuration steps for ACR. We highly recommend basing all implementation activities and the ACR setup on a separate documentation that becomes part of the tax configuration framework (until go-live) and the tax control framework (after go-live). This documentation will contain a standardized description as well as the technical specifications (characteristics) required to maintain the VAT reporting parameters in the SAP system. Let’s consider the key activities at a high level, as shown in the Dialog Structure in Figure 9.18:

399

9

Tax Reporting in SAP S/4HANA

1. Define Compliance Reporting Entities Set up according to the tax reporting-related entity structure. 2. Assign Report Categories to Reporting Entity Report categories that are needed for this reporting entity. A report category corresponds to the kind of compliance reporting needed, such as the VAT return for Germany. The report categories assigned to a reporting entity should have the same organizational units assigned. 3. Set Periodicity of Report Category For each report category, a periodicity per government regulations needs to be defined. The periodicity comprises several parameters that are used to determine time periods. Figure 9.19 shows an overview of the current standard settings and how the different parameters are set up: – The From field (active-from date for report category) and To field (active-to date for report category) determine the start and ending of the period in which the system is able to generate reporting tasks for this report category. – A report can be indicated as ad hoc or nonperiodic by selecting the Is Adhoc checkbox. Ad hoc reports have no periodicity assigned to them. Ad hoc reports may be requested on demand by the tax authorities on a nonperiodic basis such as Standard Audit File for Tax (SAF-T) reports in France or Austria. – The Offset field determines the number of days after the period end that the system uses to calculate the due date for submission to the authorities. The value can be positive, negative, or zero. – The Time Unit for offset calculation can be on a daily, weekly, monthly, or yearly basis. – The FY Variant defines the reporting periods in a year for which you need to submit your legal reports to the tax authorities. It doesn’t define the company code’s fiscal year. – The Notify field, the notification period in days, measures the number days before the report due date when the notification period for business users begins. – The Tax Calendar field is useful to maintain different due dates for different reporting periods. – With a Factory Calendar according to the requirements of your company, you distinguish between working days and nonworking days. – With the Due Date Adjustment field, you can adjust the due date for the reporting period in case the calculated due date falls on a nonworking day. 4. Set Properties of Reporting Activity Here you can assign time periods for the use of reporting activities, for example, the earliest possible date.

400

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

Figure 9.19 Set Periodicity of Report Category

5. Enter Parameters Specific to Report Category For each reporting entity, the following specifications need to be configured and documented per assigned reporting category. 6. Enter Parameters Specific to Reporting Entity For each reporting entity, the specifications need to be configured and documented. For these activities, there are two main concepts to understand: 쐍 Reporting entity

This is the legal entity within the organization that is obligated to submit certain compliance reports, as listed in Figure 9.18. A reporting entity can comprise one or more organizational units, such as business place, company code, section code, or tax jurisdiction. One organizational unit in the reporting entity must be marked as

401

9

Tax Reporting in SAP S/4HANA

the leading organizational unit. The assignment of the organizational unit to the reporting entity is time dependent. If there is an organizational change, it must only be considered as of a certain point in time, and a new set of organizational codes must be assigned with the respective valid-from date. 쐍 Report category

Report categories group versions of a report. The system uses the report category to help create concrete reports for a specific period and specific organizational units. For example, VAT returns for Germany is one report category, and the EC Sales List for Germany is another. For each of these report categories, the government may issue new versions over time in response to changes in legislation. Figure 9.20 shows how to select and assign reporting categories to reporting entities. The selection should consider the legal requirements that your reporting entity needs to fulfill.

Figure 9.20 Assign Report Categories

Tax Code Groups and Mapping A tax group version enables a time-dependent mapping of different tax codes to the same field of the VAT return form for the same reporting country. If the VAT rate changes, a new tax group version should be created. This function allows the processing of VAT reports for reporting periods before the VAT rate change took place. For configuration, use menu path Financial Accounting • General Ledger Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Assign Tax Group Version Time-Dependent (view V_T007Z). You’ll arrive at the screen shown in Figure 9.21. A tax group version and the starting date need to be defined, whereas the from date specifies the date from which the appropriate periodic VAT return can be generated by the system. Table 9.1 shows a selection of countries that can be used.

402

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

Figure 9.21 Assign the Time-Dependent Tax Group Version

Country

Name (Short)

From Date

Version

Austria

AT

01.05.2022

Reporting Entity

Australia

AU

01.05.2022

Reporting Entity

Sweden

SE

01.05.2022

Reporting Entity

Table 9.1 Relevant Countries for Tax Groups

The next step is defining the mapping between tax codes and the tax boxes on the VAT return for the tax base amounts. For this, follow the configuration for financial accounting under General Ledger • Accounting • Periodic Processing • Report • Sales/ Purchases Tax Returns • Group Tax Base Balances (view V_T007K), or execute Transaction OBCG. All required combinations of tax code and account key (Trs) have to be assigned to the relevant group number (GrpNo). Table 9.2 shows an example tax code mapping. Tax Code

(Tax Code) Description

Trs (Account Key)

Bal.

GrpNo

S2

SE-OUT-25% Output VAT (standard rate)

MWS

42

SW

SE-IN-25% Purchase of services RC EU

ESA

21

SX

SE-IN-25% Purchase of services third country RC

ESA

22

Table 9.2 Tax Code Mapping Example

The group number for tax base amount 42 corresponds to tax box 42. Note that there may be a difference between the internal group number indicated here (i.e., any number between 1 and 99) and the external group number, which is the actual mapping to the tax box. The next step is defining the mapping between the VAT codes and the VAT boxes on the periodic VAT return for the tax amounts. For this, follow the configuration for

403

9

Tax Reporting in SAP S/4HANA

financial accounting under General Ledger • Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Group Tax Balances (view V_T007L), or execute Transaction OBCH. Figure 9.22 shows a sample grouping of tax codes to tax base field numbers of a German VAT return.

Figure 9.22 Grouping of Tax Base Amounts

All required combinations of tax code and account key (Trs) have to be assigned to the relevant group number (GrpNo). Figure 9.23 shows an example of a grouping with German tax codes and group numbers. The example shows two accounts payable tax codes mapped to the same VAT return field 61.

Figure 9.23 Grouping of Tax Balances

Tax Box Structure Several countries in SAP already have the standard boxes of the VAT return preassigned. However, this isn’t always the case. If there are no preassigned boxes, they must be defined. For this, follow the configuration for financial accounting under General Ledger • Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Define Tax Box Structure.

404

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

There are a few key configuration activities, as shown in Figure 9.24: 1. Tax Box Structures Define for which structure the tax box will be used (e.g., “IE RTD – IE RTD Structure”, or “FIVATRET – VAT Return Finland”). 2. Tax Groups Define the mapping between the field of the VAT return, tax codes, and account key.

Figure 9.24 VAT Return Field Mapping

3. Tax Boxes Define the tax boxes as shown in Figure 9.25, including the number, name and whether it’s related to the tax amount, tax base, or a sum.

Figure 9.25 VAT Return Field Details

405

9

Tax Reporting in SAP S/4HANA

4. Assignment of Tax Groups to Tax Boxes Assign the tax group to the tax box, as shown in Figure 9.26.

Figure 9.26 VAT Return Field to Tax Group Mapping

Internal and External Group Number Mapping As mentioned earlier, the internal group number can differ from the actual number of the tax box. Therefore, there is a mapping done between the internal and external number. For this, follow the configuration under Financial Accounting • General Ledger Accounting • Periodic Processing • Report • Sales/Purchases Tax Returns • Assign External Tax Group to Internal Tax Group. Table 9.3 shows a sample mapping between internal and external group numbers that are different. Therefore, this mapping table exists to enable a group number assignment that is independent from the currently existing group numbers in a VAT return. Internal Group Number

External Group Number

Text

1

000

Supply of goods/services

2

011

Export

17

017

Intra-community supply of goods

Table 9.3 Example Internal and External Group Number Mapping

406

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

Tax Payable Posting With the post payable activity, tax amounts can be paid by posting the balances of input tax accounts and output tax accounts to a VAT payable account. Therefore, a general ledger account to be used when posting the tax payables must be specified. To enable the use of the post tax payables reporting activity, in addition to the country-/ region-specific roles, the SAP_BR_GL_ACCOUNTANT general business role has to be assigned to the user. Note that for VAT groups, additional configuration might be needed for allocation of VAT payable amounts per entity.

9.3.2 Setting Up EC Sales Reporting The EC Sales List or recapitulative statement is a mandatory reporting obligation within the EU to report their intra-community supplies. In 2010, the filing obligations were extended to EU cross-border services subject to the B2B default place of supply rule. In some EU member states, the additional obligation exists to also report intracommunity acquisitions of goods, for example, in Spain. You can arrange all required settings under Financial Accounting • Advanced Compliance Reporting • Setting Up Your Compliance Reporting. As explained previously, to set up the EC Sales List for a reporting entity, you follow the Dialog Structure of Figure 9.27. For some countries, such as Austria in our example, there is a setup available in your solution. Figure 9.27 shows the settings under Enter Parameters Specific to Report Category, and Figure 9.28 shows Enter Parameters Specific to Reporting Entity.

Figure 9.27 Enter Parameters Specific to Report Category

407

9

Tax Reporting in SAP S/4HANA

Figure 9.28 Enter Parameters Specific to Reporting Entity

9.3.3 Electronic Document Processing CTC found their way into many jurisdictions where companies are obligated to issue business documents electronically to business partners and/or legal authorities such as delivery notes, invoices, credit memos, debit memos, and tax certificates. SAP Document and Reporting Compliance for SAP S/4HANA provides electronic document (eDocument) processing functionality to enable taxpayers to meet CTC requirements. Visit the SAP Help Portal to find out if your reporting requirements are already met by the solution: http://s-prs.co/v549502. This product can be deployed in the cloud or on-premise, and system and software requirements vary. You can use a generic framework with building blocks to create electronic instances of documents based on source documents (e.g., invoices) created in other SAP applications. The document and reporting compliance framework for eDocument processing contains the business logic that triggers the generation of an eDocument and the subsequent steps. These steps include the mapping, submission, and reception of electronic messages. The framework provides the flexibility to support the constantly increasing number of processes required by the different regulators in a consistent way. It provides a set of functions that supports the common capabilities across scenarios, allowing countryspecific solutions to be easily incorporated and, at the same time, ensuring standardization. The framework allows you to carry out the following tasks: 쐍 Create, process, and monitor eDocuments for country-/region-specific processes

(Transaction EDOC_COCKPIT). 쐍 Import incoming messages and further process them in the system (Transaction

EDOC_INBOUND_MSG).

408

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

쐍 Upload incoming messages in the form of XML files from your file system to the

application server (Transaction EDOC_INBOUND_UPLOAD). 쐍 Submit several eDocuments bundled in one eDocument (Transaction EDOC_SUM-

MARY). 쐍 Automate the processing of several steps to run in the background (Transaction

EDOC_BACKGROUND). 쐍 Set the status of eDocuments to Completed (Transaction EDOC_COMPLETE).

To be able to send or receive eDocuments, the framework uses different services from SAP Business Technology Platform (SAP BTP). Depending on the scenario or country/ region, you must implement one of the following: 쐍 Peppol Exchange service for SAP Document and Reporting Compliance for SAP

S/4HANA Cloud. 쐍 An SAP-hosted service that enables you to exchange business documents among

Peppol network participants. 쐍 SAP Cloud Integration for data services (if you were onboarded before July 2020)/

SAP Integration Suite. 쐍 An SAP-hosted and customer-managed service that offers scenario and country-

region integration packages with preconfigured integration flows. You copy the integration packages and implement them with your systems. 쐍 SAP Document Compliance, inbound invoicing option for Brazil (the Nota Fiscal

Eletrônica project). 쐍 An SAP-hosted service that enables you to receive inbound notas fiscais (tax docu-

ments) and process them using the eDocument cockpit. There are different deployment alternatives available for the eDocument processing functionality. We’ll use eDocuments in Italy as an example.

Connected to Tax Authority In this first alternative, your SAP Document and Reporting Compliance solution is connected to the tax authority, in this case, SAP Integration Suite. The process flow is as follows (see Figure 9.29): 1. You create the source document (e.g., invoice) using an SAP application. Once you save the source document, the system creates an instance of the eDocument in the database. 2. You submit the eDocument by running the Italy eInvoice process in the eDocument cockpit (Transaction EDOC_COCKPIT). 3. The system retrieves the eDocument from the database and calls the interface connector to deploy the eDocument Interface connector (EDOC_INTERFACE_CONNECTOR) BAdI.

409

9

Tax Reporting in SAP S/4HANA

4. This BAdI calls the interface type that enables the system to connect to SAP Application Interface Framework. 5. SAP Application Interface Framework triggers the mapping of transactional data into the required XML format and saves the XML files. 6. The system calls SAP BTP via an ABAP proxy and establishes communication with the tax authorities’ or business partners’ systems. 7. If the call is successful, the XML is saved. After successfully receiving the response, the response XML is saved. 8. SAP BTP processes the XML to comply with the official communication requirements and triggers the corresponding web services for sending the XML file over to the external system. 9. SAP BTP receives information regarding the status of the request back from the external systems, transforms it into a consumable format (by decoding and mapping the result), and forwards it to SAP Application Interface Framework, and then to the SAP system. 10. The system updates the eDocument in the database with information received from the external systems. SAP Source Applications

Source Document

SAP Document and Reporting Compliance

SAP eDocument Framework

eDocument Instance

SAP Integration Suite

External Systems

eDocument Cockpit

2 eDocument Cockpit

8

Calls SAP Application Interface Framework

Interface Connector Triggers AIF_Proxy Connector

5 Calls

Checks

Processes the XML

Tax Authorities‘ Systems

Mapping 7

Creates XML

eDocument File

Reads

Figure 9.29 eDocument Connected to Tax Authority

Connected to Customer-Specific Solution In the second alternative, your SAP Document and Reporting Compliance solution is connected to a customer-specific solution such as a self-developed environment that manages the connection between your SAP S/4HANA system and SDI (Italian tax authority platform). The process flow is as follows (see Figure 9.30):

410

9.3

SAP Document and Reporting Compliance for SAP S/4HANA

1. You create the source document using an SAP application, such as financial accounting or sales and distribution. Once you save the source document, the system creates an instance of the eDocument in the database. 2. You submit the eDocument by running the Italy Fattura XML process in the eDocument cockpit report (Transaction EDOC_COCKPIT). For more information, see the application help documentation directly in the report. 3. The system retrieves the eDocument from the database and calls the interface connector to deploy the eDocument interface connector (EDOC_INTERFACE_CONNECTOR) BAdI. This BAdI calls the AIF_XML interface type that enables the system to connect to SAP Application Interface Framework. 4. SAP Application Interface Framework maps the transactional data into the required XML format and saves the XML files in the database for further processing. 5. You have the following options: – Download the XML and process it further manually. – Proceed with the XML processing using your own customer-specific solution.

SAP Source Applications

SAP eDocument Framework

Source Document

eDocument Instance

SAP Document and Reporting Compliance

Customer-Specific Solution

eDocument Cockpit Calls SAP Application Interface Framework

Interface Connector Triggers AIF_Proxy Connector

Calls

Checks

Mapping Creates XML Reads, Processes, and Sends XML to Tax Authority eDocument File

Reads

Figure 9.30 eDocument Connected to Customer Solution

Connected to SAP Partner Solution In this third alternative, your SAP Document and Reporting Compliance solution is connected to an SAP partner solution such as add-ins of Electronic Data Interchange (EDI) service providers that offer reporting as a service (RaaS) solutions. The process flow is as follows (see Figure 9.31):

411

9

Tax Reporting in SAP S/4HANA

1. You create the source document using an SAP application, such as financial accounting or sales and distribution. Once you save the source document, the system creates an instance of the eDocuments in the database. 2. You submit the eDocument by running the eDocument cockpit report (Transaction EDOC_COCKPIT). For more information, see the application help documentation directly in the report. 3. The system retrieves the eDocument from the database and calls the interface connector to deploy the eDocument interface connector (EDOC_INTERFACE_CONNECTOR) BAdI. This BAdI calls the AIF_PROXY interface type that enables the system to connect to SAP Application Interface Framework. 4. SAP Application Interface Framework maps the transactional data into the required XML format and saves the XML files in the database. 5. The system sends the XML to the partner solution along with additional data for the partner. The partner solution takes care of further processing the XML as well as transferring it to the tax authority’s system. SAP Source Applications

SAP eDocument Framework

Source Document

eDocument Instance

SAP Document and Reporting Compliance

Partner System

External Systems

eDocument Cockpit Calls Interface Connector

SAP Application Interface Framework

Tax Authorities‘ Systems

Triggers AIF_Proxy Connector

Calls

Checks Partner Solution Mapping

Creates XML

eDocument File

Reads

Figure 9.31 eDocument Connected to SAP Partner System

9.4 Summary In this chapter, we looked at the big picture of tax reporting. We started by establishing key concepts that support the worldwide tax reporting requirements. Then, we walked through key standardized tax reports delivered by SAP. We then explored statutory reporting with SAP Document and Reporting Compliance for SAP S/4HANA, including a look at key configuration activities and eDocument processing functionality. In the next chapter, we’ll move on to a final core piece of the tax function: monitoring.

412

Chapter 10 Tax Monitoring in SAP S/4HANA To close our journey through tax with SAP S/4HANA, this chapter will explore indirect tax monitoring, including the requirements, tax control framework, and available SAP solutions.

In this chapter, we introduce tax monitoring with SAP S/4HANA. We start with the objectives of tax monitoring, followed by an overview of the methodology. Further, we include the view on tax monitoring from a tax control framework perspective. We then discuss different SAP solutions for tax monitoring and give examples of tax monitoring with SAP Tax Compliance.

10.1 Why Monitor Tax? As outlined in Chapter 9, tax authorities around the world are introducing continuous transaction controls (CTC) (e.g., live tax reporting, e-invoicing) and periodic transaction controls (PTC) (e.g., Standard Audit File for Tax [SAF-T]) to improve their capabilities of collecting and controlling tax-relevant data, including the cross-check with all relevant business partners and tax assessments in real time. This way, tax authorities accelerate the digitization of tax functions and their stakeholders. For tax authorities, the transparency of tax data is the most relevant topic behind their digitization activities to defend and prevent tax fraud. Given the complex and evolving nature of tax legislation, the responsibility for tax matters within the organization traditionally belonged with subject matter experts in the tax function. In response to the globalization and transformation of business models and the widespread use of technology, the approach taken by companies to managing tax is rapidly changing. Big Four studies dated from before 2020 show that in more than 70% of the world’s largest economies, tax administrations are harnessing the power of technology through the use of electronic audits and targeted analysis of information contained within enterprise resource planning (ERP) systems. Taxpayers must be prepared to meet the challenges posed by this transformation in their tax authority approach if they want to avoid business disruption, tax risk, and unplanned tax charges. Indirect taxes such as value-added tax (VAT) and goods and services tax (GST) have proven a popular source of tax revenue generation for governments worldwide. While

413

10

Tax Monitoring in SAP S/4HANA

direct tax rates have fallen during the (direct) tax rate competition between countries (limited by pillar one, base erosion and profit shifting, and pillar two, minimum taxation measures), VAT and GST rates have increased and will increase further. Given this changing environment, it has become more critical than ever to manage indirect taxes with a view to optimizing cash flow and reducing risk. The overall value drivers for the tax function can be categorized as the following goals related to tax monitoring and increasing the value contribution of the tax function, which we’ll discuss in the following sections: 쐍 Reduction of compliance risks 쐍 Efficiency improvements 쐍 Cash flow optimization

10.1.1 Compliance Risks Many potential risks and costs are associated with compliance. Following are some of the major potential risk considerations caused by lack of tax monitoring as part of a tax control framework: 쐍 Loss of tax deductions

Tax deductions may get lost due to a delayed filing or due to missing recognition in the tax returns. 쐍 Fines and penalties

Tax administrations impose fines and penalties if taxpayers don’t follow the legally required procedures and deadlines. Late filing penalties or fines in connection with tax fraud are two examples for compliance costs that may occur in this regard. 쐍 Increased cost to defend audits

If taxpayers can’t prove or document historical tax-relevant decisions, increased costs can be the consequence during tax audits due to external consultancy costs or IT costs to restore documentation and archives. 쐍 Increase in audit activity

In general, the tax authorities may decide to increase their audit activity upon findings in tax audits. This is often the case in connection with inbound activities of foreign companies as the taxable substance is often less certain or out of reach for the tax authorities. 쐍 More data requests from tax authorities

More ongoing data requests during the normal tax assessment activities of the tax office can be caused from a perceived lower tax compliance level due to findings in the past. 쐍 Increased cost of compliance

A general increase in compliance costs is the overall outcome of the entire overview of potential risks. Higher tax provisions are consequently to be considered in the

414

10.1

Why Monitor Tax?

statutory accounts and can have a direct impact on the financial result of an enterprise. 쐍 Systemic ERP system exceptions

During tax calculations, erroneous ERP tax master data or tax customizing settings that called on the level of invoices or postings can cause repeating and systematic exceptions in the mass data recordings of an SAP system. This can have a huge impact on the tax risk position and can cause extensive mitigation work efforts. 쐍 Reputational risks

Reputational risks can be the consequence of public announcements of tax compliance deviations, which can have a direct impact on the operational and financial results of the company.

10.1.2 Efficiency Improvements Besides the avoidance of compliance risks, efficiencies serve as powerful leverage for tax functions to use the existing capabilities for the value drivers of tax management. Tax monitoring can contribute as follows to efficiency improvements: 쐍 No standardized tax compliance management processes

Standardization helps to streamline tax compliance management processes, which includes tax risk identification, mitigation, and respective controls. 쐍 Minimal usage of tax technology

The use of tax technology is an important measure of operational tax management. In the domain of tax monitoring, a variety of solutions is available in the market to support your tax function activities. 쐍 Tax as business partner in business process automation projects

Tax as a business partner in business process automation projects helps to integrate the tax requirements from the beginning of projects until the go-live. 쐍 Identification, mitigation, and control of tax risk and exceptions

Tax monitoring is a powerful mitigation task. Tax monitoring enables automated tax controls and can be a perfect start for workflows inside or outside the ERP system. See Section 10.5 for more information. 쐍 Teamwork

Teamwork in a tax function is based on having the right competencies within a team and a focused understanding and execution of the individual role as part of the team. When it comes to tax monitoring tax specialists, data scientists and coders collaborate and create tax technology and tax process solutions. 쐍 Data-based tax management

Data-based tax management is a prerequisite to have the right master data in place to describe tax-relevant objects in the ERP system (e.g., company code VAT ID) and to work with the right transaction data to enable tax decisions/determination and tax reporting.

415

10

Tax Monitoring in SAP S/4HANA

쐍 Multiple processes for different jurisdictions

We often see that different local processes for one and the same process step (e.g., VAT return plausibility checks before filing) result in inefficiencies and redundancies. 쐍 High effort in tax audits

Tax auditors have requests regarding historical data and historical mitigation tasks that sometimes are hard to find or complicated to combine based on archived data. 쐍 Manual correction efforts and processes

Correction tasks with a high repetition rate due to mass data postings can especially require high effort during the mitigation.

10.1.3 Cash Flow Optimization The indirect tax data flows lead to many payment-relevant transactions that can be optimized starting from compliance and efficiency, which also have an impact on the cash flow. Especially the procure-to-pay end-to-end tax scenario leads to many opportunities for cash flow optimization, for example, the timely deduction of input VAT or import VAT and the correct payment of withholding taxes (WHT) or the application of WHT suspension regimes to be applied in a compliant and timely way. Figure 10.1 shows indirect tax data flows with an impact on cash optimization. Your company buys and sells services and goods. Suppliers, customers, and your company are reporting to, paying money to, and receiving money from the tax authorities.

Tax Meaning for Taxpayers Company Sell

– Affects Every Transaction

Buy

– Millions of Transactions per Year Supplier

Customer Tax

– Complexity Due to Diverse and Locally Different Regulations

Tax d Refun

Report Tax d Refun

Tax Meaning for Governments

Tax

– Biggest Income Source

Government Authorities Report

Report

Data Exchange

Tax Authorities

– Very Sensitive Regarding Fraud – Strong Technological Efforts to Detect Fraud

Example: Indirect Tax Data Flows

Figure 10.1 Indirect Tax Data Flows

The tax authorities can be different bodies connected by a data exchange. All these flows are connected by a common business transaction, a common reporting obligation, and a corresponding amount to be paid or refunded.

416

10.2

Tax Monitoring Requirements

10.2 Tax Monitoring Requirements Most tax compliance solutions download business data for just part of the business and execute tax rule checks only once per quarter, when the tax declaration has already been completed. Processes for defining, scheduling, as well as executing compliance checks, and for reporting results and analyzing compliance issues, are rarely automated. Manual processes are required to identify compliance requirements, trigger and execute mitigation tasks, track and remediate compliance problems, and report results. Based on the generic process of continuous tax monitoring and risk management, SAP solutions for tax compliance management and tax monitoring provide a more holistic approach with predefined automated or semiautomated steps to establish a tax control system. Having a single source of data and applying dynamic exception reporting and tax risk management provides valuable insight into understanding a company’s VAT position and assists with making better, more informed decisions. Figure 10.2 shows the different layers of tax compliance management and tax monitoring, including the steps to be taken. On a conceptual level, the definition and valuation of tax-related risks lead to a catalog of principles, measures, and controls. On an operational level, these principles, measures, and controls need to be implemented. Different categories are relevant for the implementation summarized by the following questions: 쐍 What are the necessary roles and responsibilities to execute controls? 쐍 What is the corresponding concrete control catalog for the identified controls on the

conceptual level? 쐍 How do you identify the exceptions based on tax-relevant data? 쐍 What are the correction steps to be taken based on the findings? 쐍 How can learnings be integrated into the monitoring rules and the mitigation tasks

to permanently improve the operational and conceptual level? The monitoring level describes actions items that a generic monitoring process consists of: 쐍 Identifying compliance requirements, for example, the correct standard tax rate 쐍 Defining and implementing queries, for example, selecting the tax base amount and

the tax amount posted in the financial data, and comparing the calculated tax amount with the posted tax amount 쐍 Planning and execution of queries, for example, a monthly exercise according to a

monthly VAT return filing deadline 쐍 Results output and compliance risk analysis, for example, generate a result list and

highlight exceptions

417

10

Tax Monitoring in SAP S/4HANA

쐍 Execution of necessary actions in case of findings, for example, when deviating

(lower and higher) tax amounts are identified 쐍 Following up of correction tasks and cleaning up of compliance risks, for example,

correcting too high input VAT deduction and too low VAT payments, and improving tax code settings and posting procedures 쐍 Integrate monitoring results in the monitoring process, for example, adjusting the

check routine for false positives

Conceptual Level – Principles, Measures, Controls

Roles and Responsibilities

Control Catalog

Identification of Exceptions

Correction

Monitoring and Optimization

Operational Level – Implementation

Identification Tax Compliance Requirements

Definition and Implementation of Queries

Planning and Execution Queries

Results Output and Compliance Risk Analysis

Execution of Necessary Corrective Actions

Follow-Up Corrections/ Clean-Up Compliance Risks

Report Preparation and Optimization

Monitoring Level – Compliance and Adjustment

Figure 10.2 Tax Monitoring Steps

Deploying tax monitoring and compliance management with SAP solutions includes the following steps: 1. End-to-end technical implementation 2. Data and integration models reflecting the tax-relevant business processes 3. Client-specific creation or adaption of third-party proprietary ready-to-use tax compliance algorithms based on the SAP tax data model 4. Worklists 5. Change management The implementation of an SAP-based tax monitoring solution such as SAP Tax Compliance needs to contain a particularly designed data model that demands years of tax data analytics and SAP HANA experience. This can lead to improved performance and reduced resource consumption but also allows tax functions to own their tax compliance management activities and to maintain and customize the rules at a later stage to a changed tax control environment. Successful SAP Tax Compliance projects require the interplay of people from different disciplines, combining not only business and technical know-how but also experience

418

10.3

Tax Control Framework

in risk and controls, and a clear understanding of how to extract insights out of mass data as well as digital audit approaches of tax administrations. Table 10.1 shows important success factors of tax monitoring solutions that are necessary to finally enable a tax control framework based on the solution. IT Tasks

Customization Tasks

Steps with SAP Solutions

Assessment of infrastructure and hardware

Tax risk assessment

Creation of tax compliance scenarios for risk areas

Specific adjustments of data model

Implementation of check routines

SAP Tax Compliance workflow and reporting

Technical setup of an SAP Tax Compliance environment

Customizing of dashboards and cockpits

User training and documentation

Table 10.1 Tax Monitoring Project Areas Based on an SAP Tax Compliance Example

The first column of Table 10.1 includes activities with regard to IT tasks. The management of a data replication approach or the establishment of an add-on deployment especially needs to be covered. In addition, the SAP data model needs to be adapted to the specific data environment. A data normalization happens here. The SAP solution itself (here SAP Tax Compliance as an example) needs to be set up and installed as well. In the second column of Table 10.1, the tax function will run tax risk assessments or use results of existing tax risk assessments to customize the specific needs for a tax control environment. This is the basis for the implementation of check routines that cover the specific risks applicable to the enterprise. Dashboards and cockpits of the tax monitoring solutions can be adopted according to the results of the steps before. The third column of Table 10.1 covers specific SAP solution-oriented steps. In this case, SAP Tax Compliance scenarios need to be set up, workflows and solution users need to be defined, and user trainings and documentation need to be created to enable the respective use and maintenance of the solution after go-live.

10.3 Tax Control Framework As outlined in Chapter 1, a tax operating model includes a tax control framework to manage tax processes and tax data from a tax control point of view. The management of an enterprise has the obligation to install and control a framework to ensure the correctness and completeness of the tax-relevant obligations of the company. Figure 10.3 shows tax-relevant business processes and the bandwidth of preventive and detective controls.

419

10

Tax Monitoring in SAP S/4HANA

Tax-Relevant Business Processes Preventive

Detective

Controls

Master Data

Adjustments/Corrections

Transaction Types

Controls

Financial Accounting

Declaration/Return/Audit

Order-to-Cash

Order

Customer Data

Sales Process/ Accounting

Record-to-Report

General Ledger

Material Data Adjustments (Credit Note, Bad Debt, Accruals)

Transfer Prices

Plants/Locations

Supplier Data

Purchase Order

Group Entities

Tax Returns and Declarations

Annual/ Quarterly Reports

Purchasing Process/ Accounting

Procure-to-Pay

Departments IT

Production

Accounts Payable

Accounts Receivable

Logistics

Order Execution

Law

Finance

Taxes

Figure 10.3 Tax Control Framework (Source: EY)

Controls during the recording of business transactions and on the master data level are called preventive controls. Preventive controls are typically lying in the operational processes order-to-cash and procure-to-pay. In all companies, there is a high dependency on master data that describes tax-relevant objects such as customer data, supplier data, material data, or plants and locations. As master data is stored separately to be used for transactions, there is also transactional data that is recorded during the business process based on transaction types. Sales orders, invoices, and purchase orders are typical documents that contain tax-relevant transaction data. This transaction data can either be populated by the respective master data (customer VAT ID) or during the transaction process when entries are made (alternative customer VAT ID) that are recorded with the respective business document. When the data passes the operational processes and gets interfaced to the financial data, we arrived in the record-to-report process. Typically, we find corrections as credit notes, bad debt adjustments, or accruals in this area. Once the corrected values pass the general ledger annual or quarterly reports, tax returns and declarations are based on the financial data. Controls in this area are called detective controls as the data that has left the operational process already and exceptions can be identified based on financial data. Financial data has no direct relation to the operational base data as the country of departure or the country of destination isn’t a relevant financial data for accounting purposes. But it may be relevant to identify VAT-exempt intra-community supplies of goods. Therefore, connections between the financial data and the operational data need to be built on the basis of an SAP data model. Along the SAP process, the different SAP tables

420

10.3

Tax Control Framework

can be linked by key fields and identifiers. The result is called the SAP tax data model and is the basis for all tax monitoring activities in SAP. We can distinguish between different steps in a tax control framework, as shown in Figure 10.4: 1. Identify The first step is to identify the tax-relevant risks based on the tax process design framework. Refer to Chapter 1, Section 1.5, where we covered the different tax-relevant end-to-end scenarios. 2. Mitigate Once identified, risks need to be mitigated by corresponding control measures. The extent to which a risk needs to be covered is dependent mainly on the amount at risk (yearly basis) and the likelihood of the risk event. 3. Control Implemented measures need to be controlled to ensure completeness, correctness, accuracy, and actuality of the actions taken. These controls can be monitored via a plausibility check (comparison of two different angles of one and the same result, e.g., European Commission [EC] Sales List compared to VAT return with regards to EC supply of goods), or analytical data checks (e.g., a monthly SAP Tax Compliance scenario run).

Identify

Mitigate Implement Control Measures for Tax-Relevant Processes

Tax Process Design Framework

Automation

Continuous Monitoring

Control Tax Controls to Ensure Completeness, Correctness, Accuracy, and Actuality – Process Controls – Plausibility Check – Analytics

Control Environment

System Supported, Detective

System Supported, Preventive

Process Control

Manually, Detective

Manually, Preventive

Record-to-Report Process Data Control

Timing

Figure 10.4 Identify, Mitigate, Control

Let’s consider an example. During the order-to-cash process, there are complex transactions (e.g., drop shipments) with a value of 100 MEUR at risk, and with likelihood of

421

10

Tax Monitoring in SAP S/4HANA

more than 50%, we detect possible incorrect tax treatment during the invoicing process with the result of an inaccurate VAT return and VAT payment. With such a value, we conclude that we face a high risk from a VAT perspective that needs to be covered with respective measures. Of course, in practice, you should predefine risk thresholds to install a unified measure for all risks. In the end, this procedure supports finding adequate measures to offset the operational tax risks to an acceptable level. In our case, we conclude that an automated tax determination logic needs to be applied to ensure a correct VAT treatment by the SAP system. As we have a high risk, real-time tax monitoring of the tax determination results needs to ensure that exceptions are identified and mitigated. Now, let’s go further and highlight the procure-to-pay and order-to-cash process risk assessments and identify, mitigate, and control typical risks. We’ll then make proposals for possible mitigation actions and controls. Especially in the course of indirect tax risk assessments, the business processes are time-consuming and are linked to a high number of stakeholders in the company that are outside of the tax department but that are influencing or making tax decisions in their roles. In Figure 10.5, we start with supplier master data and move throughout the depicted process flow. The procure-to-pay risks, mitigation actions, and controls are captured in Table 10.2.

Supplier Master Data Team

Procurement

Accounts Payable Team

Maintain Supplier Master Data

Select Supplier Data

Create Purchase Order

Send To

Check Receipt and Post Goods Receipt Note

Receive Invoice

Supply

Send Invoice

Treasury Department

Supplier

Create Purchase Order

Check Receipt and Post Goods Receipt Note

Figure 10.5 Procure-to-Pay Risks

422

Scan Invoice

Check Invoice against Purchase Order and Goods Receipt Note

Post Invoice

Archive Invoice

Check Receipt and Post Goods Receipt Note

10.3

Tax Control Framework

Department/Area

Process Step

Risk

Control

Supplier master data

Maintain supplier master data

Maintaining the wrong supplier plant country that could cause the wrong VAT treatment

Regular request/check of supplier plants by master data team on invoice or with supplier directly

Procurement

Create purchase order

Wrong VAT treatment in purchase order resulting in wrong posting of the supplier invoice (missing proposal)

Automated accounts payable VAT determination and monthly controls by tax monitoring

Accounts payable team

Post invoice

Wrong tax code assignment

Accounts payable tax determination in purchase order as proposal

Treasury department

Payment based on three-way match

Input VAT deduction to high

Accounts payable tax determination in purchase order as proposal

Table 10.2 Procure-to-Pay Risks, Mitigations, and Controls

These values are examples for a risk assessment and don’t include any valuation of gross risks to classify mitigation activities and controls. Next, for order-to-cash, as shown in Figure 10.6, we start with the customer master data and move throughout the depicted process flow. The order-to-cash risks, mitigation actions, and controls are captured in Table 10.3.

Customer Master Data

Product Master Data

Warehouse Master Data

Master Data Maintenance

Tax Decision Central VAT Transaction Processes

Tax Code Allocation

Invoicing

Outgoing Invoices

Release to Accounting (Financial Accounting)

General Ledger

Internal Reporting Reporting

External Reporting

Periodic Tax Returns

Figure 10.6 Order-to-Cash Risks

423

10

Tax Monitoring in SAP S/4HANA

Department/Area

Process Step

Risk

Control

Master data maintenance

Maintain product master data

Maintaining the wrong material tax classification that could cause the wrong VAT treatment

Regular request/check of product master data and tax treatment of products based on exceptions identified by tax monitoring

Central VAT transaction processes

Tax decision

Wrong VAT decisions resulting in wrong VAT return values and wrong invoices that are sent to the customer or tax authority portal (e-invoicing)

Automated accounts receivable VAT determination and real-time controls by tax monitoring to prevent process anomalies due to incorrect VAT data

General ledger

Sales and distribution/financial accounting interface

Wrong tax code assignment due to wrong tax code settings

Tax code concept according to best practices when activating plants abroad functionality

Table 10.3 Order-to-Cash Risks, Mitigations, and Controls

All the entries are examples for a risk assessment and don’t include any valuation of gross risks to classify mitigation activities and controls.

10.4 SAP Solutions for Indirect Tax Monitoring In this section, we’ll see what SAP has to offer for indirect tax monitoring. We’ll focus on the tax-relevant capabilities of SAP S/4HANA embedded analytics, SAP Analytics Cloud, SAP BW/4HANA, and SAP Tax Compliance.

10.4.1 SAP S/4HANA Embedded Analytics SAP S/4HANA embedded analytics works directly on the SAP S/4HANA database. This technology enables real-time reports as no data replication from original SAP S/4HANA source data needs to be replicated. On the other hand, no legacy data from other source systems is available for embedded analytics. Embedded analytics in SAP S/4HANA aims to reduce the complexity and provides a more simplified modeling approach. The integration of embedded analytics allows SAP Fiori apps to be included in daily routines of the tax function in SAP. The availability of frontend user interfaces (UIs)

424

10.4

SAP Solutions for Indirect Tax Monitoring

with tax functionality is rather limited and needs to be designed, built, and maintained for the use of tax purposes.

Note For available functionality in terms of direct taxes, refer to Chapter 7.

10.4.2 SAP Analytics Cloud SAP Analytics Cloud brings together analytical and transactional capabilities of a variety of operational and legal systems into one platform. With the embedded functionality of SAP Business Warehouse (SAP BW) in combination with the data visualization functionality of SAP Analytics Cloud, the tax function can consume data and enhance the structures in real-time analysis. Following are the benefits of SAP Analytics Cloud: 쐍 Reduction of full-fledged data warehousing and other third-party tax and legal appli-

cations, as well as provision of real-time operational reporting 쐍 Simplified data models for tax reporting such as VAT, GST, and EC Sales Lists 쐍 Tracks relevant data under a specific reporting task for audit trails 쐍 Modern efficient interface available for business users, developers, and administra-

tors 쐍 Extracts a large volume of SAP data from SAP S/4HANA or SAP S/4HANA Cloud

Figure 10.7 shows important functions of SAP Analytics Cloud. It starts with the data modeling based on core data services (CDS) views that contain the analytics logic. Function Overview Data Modeling Based on CDS Views Containing the VAT Analytics Logic

SAP S/4HANA or SAP S/4HANA Cloud + ABAP CDS View

Persistency via Embedded SAP BW in SAP S/4HANA Visualization of VAT Analytics Using SAP Analytics Cloud

SAP Analytics Cloud

SAP Tax Compliance Report

Figure 10.7 SAP Analytics Cloud

425

10

Tax Monitoring in SAP S/4HANA

This implies an SAP data model on the level of CDS views as the basis for the data checks. As SAP core data is directly monitored, no replication or data transfer is necessary. For visualization purposes, SAP Analytics Cloud functionality is used to ensure consistent output and optical design.

10.4.3 SAP BW/4HANA SAP BW/4HANA stands for SAP Business Warehouse based on SAP HANA database technology. With in-memory SAP HANA database technology, fast and flexible reporting can be realized in SAP BW/4HANA. In many cases, SAP BW/4HANA already exists as the data source for other stakeholders in an enterprise such as for controlling or finance in general. SAP BW/4HANA can act as the single source of truth for you in the tax department as well. Especially when data sources from legacy systems is replicated to SAP BW/4HANA, this solution can cover end-to-end scenarios with data from operational processes. As this solution acts as a business warehouse, there is no built-in UI that is ready to use for tax. This has to be taken into account when tax monitoring is realized this way. Additional effort is necessary to design, create, and maintain a UI/frontend.

10.4.4 SAP Tax Compliance SAP Tax Compliance delivers the technical framework for an end-to-end process covering the automated detection, investigation, and mitigation of tax issues while also increasing tax compliance in business processes. Automating tax-checking processes with a unified, standardized set of rules reduces time and effort and allows anomalies to be identified more accurately. This is facilitated by using predefined components including the following: 쐍 Standard SAP data request to quickly identify and collect required data 쐍 Structured knowledge transfer to enable IT, tax, and business users 쐍 Customizable and ready-to-use check routines to quickly begin monitoring tax data

and detecting tax risks 쐍 Predefined workflow content that can be easily customized to the client to set up a

workflow process to mitigate identified tax risks Checks can be grouped centrally into scenarios based on predefined fields such as line of business, geographic location, timing, and tax type. The solution not only identifies compliance issues and detects error-prone postings with a variety of check routines but also covers indirect tax supply chain management and helps with managing indirect tax cash flow. Furthermore, SAP Tax Compliance provides context-rich information for each alert, enabling improved transparency, traceability, and auditability of data for the use of the tax function. Mitigation actions are triggered semiautomatically,

426

10.4

SAP Solutions for Indirect Tax Monitoring

including mitigation status and documentation. Tax compliance reporting completes the cycle of SAP Tax Compliance management, leveraging the tax function to the next level of tax automation and risk management. The ability to be close to activities of the business through the effective use of data, even if they are located at disparate places, becomes increasingly important to centralize and standardize VAT processes in shared service environments without losing oversight and control of VAT and GST compliance. The solution provides the ability to view and analyze country or sector-specific data, as well as drill down to individual tests and transactional data. This enables you to manage compliance, focus on major cost drivers, and develop a tax strategy on a local and global basis. Figure 10.8 shows the SAP Tax Compliance workflow, which starts with the connection of data sources from different SAP and non-SAP sources. The data runs through compliance scenarios that check the tax requirements based on a central check repository. These checks lead to hits where exceptions need to be identified by the respective owners of SAP Tax Compliance tasks. The SAP Tax Compliance user can assign tasks to connected business partners in your company to validate the hits. If hits are confirmed as exceptions, corrective actions can be taken and are managed with the help of task lists that assign tasks to the respective owners of tasks in the operational business processes. Compliance checks and tax-relevant ERP settings scan be optimized over time when certain findings appear on a recurring basis. This leads to efficient tax compliance management with SAP Tax Compliance. See Section 10.5 for more details.

1

Legacy

Connect data sources

Legacy

SAP

Legacy

Legacy

2

Examples: – Master data-related checks – Transaction data-related checks – Special checks (e.g., chain transactions)

Check repository

3

Manage/optimize checks

3

Receive/validate exceptions

Receive/validate exceptions

Manage tasks

Routing

Check source system

CFO IA BU IT

Status

Collaborate

Workflow

Tax compliance results

CFO IA BU IT

Routing Workflow System

Integrated dashboard

Figure 10.8 SAP Tax Compliance Workflow

427

10

Tax Monitoring in SAP S/4HANA

SAP Tax Compliance needs basic data to do its work and enable data-based workflows. There are two major alternative ways to access the tax-relevant transaction data and master data: 쐍 Sidecar approach

One approach is the sidecar method, as shown in Figure 10.9. Companies with different data sources, inlcuding non-SAP systems, can use this replication method to have one single source of truth for SAP Tax Compliance management. We also see companies use this method to be more independent from the SAP S/4HANA core activities and outages. The replication method requires the selction of reasonable data replication intervals to enable the respective check routines.

SAP ERP (SAP NetWeaver AS for ABAP)

Replication

SAP Tax Compliance (SAP NetWeaver AS for ABAP)

Replication

SAP S/4HANA

SAP Tax Compliance SAP HANA Database

SAP ERP Database

SAP S/4HANA Database

Figure 10.9 SAP Tax Compliance Side Car Approach 쐍 Add-on approach

Another approach is the SAP Tax Compliance as an add-on solution. In this scenario, as shown in Figure 10.10, SAP Tax Compliance is operating directly on the SAP S/4HANA core database, enabling real-time compiance checks without the need for replication.

SAP S/4HANA (SAP NetWeaver AS for ABAP)

SAP Tax Compliance (SAP NetWeaver AS for ABAP)

SAP S/4HANA Database

Figure 10.10 SAP Tax Compliance Add-On Approach

428

10.5

Monitoring with SAP Tax Compliance

With all of these features and options in mind, the benefits of SAP Tax Compliance can be summarized as follows: 쐍 Best-in-class in-house automated tax compliance process solution 쐍 Enables a company-wide standardized tax compliance approach for multiple juris-

dictions 쐍 Documentation of tax controls and corrective actions 쐍 Reduction of manual effort for tax compliance 쐍 Establishes clear roles and responsibilities in tax compliance process 쐍 Improved tax data quality as the basis for tax declarations

The SAP Tax Compliance software component comes with broad tax compliance functionality and workflow integration. However, be aware that the functionality only leads to a reasonable business case for tax when the SAP tax data model is implemented with resulting data tests for sales and distribution, materials management, and financial accounting. In addition, the data sources and data replication method can have a huge impact on the tax use case. After further observation of SAP Tax Compliance experiences with clients, we’ve seen the management of a changing tax process environment. Organizations need to adopt the workflow concept of SAP Tax Compliance as the tax function has a deep reach into business processes, which is a big opportunity for the quality of tax data and also a big change to be managed for many organizations.

10.5 Monitoring with SAP Tax Compliance Now that we’ve explored several SAP solutions for tax monitoring and compliance, we’ll take a closer look at the detailed process with SAP Tax Compliance in this section, as this solution is the most critical from a tax perspective. In Chapter 7, Section 7.5.1, you saw the SAP Fiori apps available for SAP Tax Compliance. In this section, we’ll go into detail with some of these core apps. To begin, SAP Tax Compliance offers a Compliance Results Overview app, as shown in Figure 10.11, which presents all relevant information captured in one dashboard to enable a smart handling of all tax compliance tasks of the tax compliance manager.

429

10

Tax Monitoring in SAP S/4HANA

Figure 10.11 SAP Tax Compliance Dashboard: Compliance Results Overview App

On the level of a compliance check, using the Manage Compliance Checks app, you can create a compliance check by clicking Create in the menu bar, as shown in Figure 10.12.

Figure 10.12 Manage Compliance Checks

You can then create your own data test by selecting Available Fields under the FIELD CONTROL section. In our example, we present a sample data test called Test 1, which accesses the fields shown and checked in Figure 10.13.

430

10.5

Monitoring with SAP Tax Compliance

Figure 10.13 Example Compliance Check

Figure 10.14 shows that after the selection of SAP data fields, a task list can also be assigned to the compliance check under the ASSIGNMENT OF TASK LIST TEMPLATES section. The compliance check can be selected to manage a task list, a task, and a confirmation of a completed task automatically without manual intervention by changing the corresponding toggles to ON.

431

10

Tax Monitoring in SAP S/4HANA

Figure 10.14 Other Tabs in the Manage Compliance Checks App

A central functionality of SAP Tax Compliance is the ability to combine compliance checks into compliance scenarios. On the level of a compliance scenario, you can assign data tests and manage the frequency of scenario runs in the Manage Compliance Scenarios app. After clicking the Create button, you’ll arrive at the view in Figure 10.15 where you can define a compliance scenario by assigning general information, compliance checks, and scheduling information. In the example shown in Figure 10.16, a scenario called Tax Compliance Demo Package was created. As shown in the open SCHEDULING INFORMATION tab, Basic Data such as start date and next run date can be set. Furthermore, you can set a Recurrence to manage frequencies according to the compliance scenarios to be monitored.

432

10.5

Monitoring with SAP Tax Compliance

Figure 10.15 Create Compliance Scenario

Figure 10.16 SAP Tax Compliance Scenario

433

10

Tax Monitoring in SAP S/4HANA

Once you set up a compliance scenario, it can be activated either based on manual intervention or based on recurrence settings. In Figure 10.17, we run the compliance scenario manually via the Run Compliance Scenario app, as no recurrence settings were made. All you need to do is enter your Compliance Scenario ID and a Date, and then click Execute.

Figure 10.17 Run Compliance Scenario App

In the My Compliance Check Results app, you have an overview of the status of compliance scenario runs (in our example, we defined this as Tax Compliance Demo Package), which covers data tests that support tax compliance during filing deadlines of VAT-relevant returns and declarations. In our case, as shown in Figure 10.18, the Run Status is Completed because no hits are found. If you defined a large number of scenarios, you can work with the filter function to select your view. To confirm tax compliance items from an open run, you can select the open run and check the items to be confirmed. Upon confirmation of all items, the status appears as Completed in the Compliance Check Hits app. In our example in Figure 10.18, no compliance hits were detected, so the Run Status is already Completed.

Figure 10.18 My Compliance Check Results App: Status Overview

434

10.5

Monitoring with SAP Tax Compliance

By clicking one of the two line items in Figure 10.18, you arrive at the Compliance Check Hits app. Figure 10.19 shows the resulting summary view of the Compliance Check Hits app for a different compliance scenario. In this example, we called Demo Package to show you a compliance scenario run with compliance hits results and their further handling. Here, the status of the first line is already changed to Confirmed as these exception line items were confirmed already by the user.

Figure 10.19 Compliance Check Hits App: Summary View

Figure 10.20 shows the detailed view at the line item level of compliance check hits after clicking in the row you want to take a detailed look at. You can either extract this list and forward it in the workflow, or you can check the respective lines to be discussed and resolved in the workflow.

Figure 10.20 Compliance Check Hits App: Detailed View

Once you select compliance hits in the result list, you can create and assign a task list for the selected hits based on available templates. In Figure 10.21, we’ve chosen Template 169, which can be set up and changed in the Manage Task List Templates app.

435

10

Tax Monitoring in SAP S/4HANA

Figure 10.21 Create Task List for Selected Hits

Figure 10.22 shows the Applicable Task Templates that can be applied to create a new task list. In our demo data, the templates are about two steps: 1. Cancel the billing document and issue a new billing document. 2. Correct the VAT return/amend the expected VAT burden. Based on that functionality, you don’t need to start from scratch each time you create a task list by clicking on Create in the Create Task List For Selected Hits window shown earlier in Figure 10.21.

Figure 10.22 Applicable Task Templates

436

10.5

Monitoring with SAP Tax Compliance

Regarding task lists, you can manage them in a separate app called Manage Task List Templates, as shown in Figure 10.23. Task list templates can be deployed for regional customizing and for local tax requirements.

Figure 10.23 Manage Task List Templates App (Source: EY)

Compliance tasks can be assigned to users in the workflow, as shown in Figure 10.24. We navigate to this window by starting the My Compliance Tasks app. Then we choose the tasks assigned to the task list 46 on the left side, which comprises our selected compliance hits results from the list shown previously in Figure 10.20. The task list item contains the task, the respective compliance check that led to a hit, and a check description, including the VAT risk. Furthermore, the user that receives this task finds a description of exactly what to do to mitigate this hit, including a deadline until May 14, 2022. Transaction details ensure solid communication based on the transaction level. When the SAP Tax Compliance manager clicks on Complete, the task will be assigned to the responsible user (in our case, an accounts payable user), and the task appears as Completed from the user point of view. The status of the task can be checked starting with the Compliance Results Overview app, as shown previously in Figure 10.11. Clicking the Show Log button shows the timeline on the left side where all historical actions are recorded that are assigned to this task. Based on this, log tax audits and further requests from authorities can be managed very efficiently for compliance.

437

10

Tax Monitoring in SAP S/4HANA

Figure 10.24 Assign Workflow Items to Other Relevant Users (Source: EY)

10.6 Summary In this chapter, we provided you with a basic understanding of tax monitoring activities. You learned about the role of tax monitoring as an activity in a tax control framework. Furthermore, you’re now familiar with the most relevant SAP solutions for tax monitoring. We detailed the best-in-class solution, SAP Tax Compliance, to make you comfortable working with the most important functionality. We’ve now completed our coverage of tax in SAP S/4HANA, from basic settings all the way to monitoring. We hope that you’ve gained the skills and confidence to implement the tax function in your SAP S/4HANA system.

438

Appendices A

Europe ........................................................................................................................

441

B

India ............................................................................................................................

461

C

North America .........................................................................................................

465

D

The Authors ..............................................................................................................

473

439

Appendix A Europe

In this appendix, we’ll take a deeper look into special reporting requirements and settings for Europe, or more specifically the European Union (EU). We’ll look into Intrastat reports, the European Commission (EC) Sales List and EC Purchase List, and Standard Audit File for Tax (SAF-T). Note that there are additional requirements that are mandatory in many jurisdictions that will not be covered here.

A.1 Intrastat Report The Intrastat report is a statistical report that tracks movement of goods between different EU member states. Generally, it’s linked to a threshold of cross-border goods movements and created monthly once this threshold is reached. Even though the Intrastat report is a statistical reporting requirement related to goods movement, it’s classified as an indirect tax reporting requirement. Several configuration steps are involved. Starting January 2022, the EU has tried to harmonize the fields of the Intrastat report. For some countries, this resulted in new fields, such as the nature of transaction (business transaction type in SAP), the country of origin, and the value-added tax (VAT) ID of the recipient of the goods. These are generally all available in SAP S/4HANA, as they have been mandatory in other countries before.

Note The user exit to map, modify, or exclude data for the Intrastat report is EXIT_SAPLV50G_ 001.

We’ll explain the basic settings for Intrastat reporting, as well as how to set up default values and providers of information, in the following sections. We’ll also show you how to run an Intrastat report.

A.1.1 Basic Settings for Intrastat Fields There are many key fields for Intrastat reporting. Let’s walk through each.

441

A

Europe

Define Partner Country To get started, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Partner Country • Define Partner Country, or use Transaction SM30 with object /ECRS/V_TPCI. Here, you set up all the country codes that are relevant for Intrastat reporting, that is, all EU member countries. Note that with the Northern Ireland treaty, Northern Ireland must be added here as well as country XI. This view should be prepopulated as shown in Figure A.1. If it’s not, click the New Entries button, and add the Partner Country and Description.

Figure A.1 Intrastat: Define Partner Country

Assign Partner Country to Country of Declaration Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Partner Country • Assign Partner Country to Country of Declaration, or use Transaction SM30 with object /ECRS/V_TRAP. For all partner countries created in the step before, you now need to create the mapping to the countries of the company code(s). For every country where your company must file an Intrastat report (Country of Decl.), a mapping to each Partner Country must be made, as shown in Figure A.2.

Figure A.2 Intrastat: Assign Partner Country to Country of Declaration

442

A.1

Intrastat Report

Define Exceptions for Conversion of Partner Country Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Partner Country • Define Exceptions for Conversion of Partner Country Declaration, or use Transaction SM30 with object /ECRS/V_TMPC. This is the place where you can define mappings between special regions that belong to a country and an Intrastat country, such as Northern Ireland. Or you can define mappings between countries that belong inside the VAT union of the EU, such as Monaco, which belongs to the VAT region of France. An example is shown in Figure A.3.

Figure A.3 Intrastat: Define Exceptions for Conversion of Partner Country Declaration

Define Country of Origin Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Country of Origin • Define Country of Origin, or use Transaction SM30 with object /ECRS/V_TCOO. As the country of origin can be any country in the world, all countries should be maintained here. These should be prepopulated with the values in table T005. If a country is missing, click the New Entries button, and add the country code and name of the country, as shown in Figure A.4.

Figure A.4 Intrastat: Define Country of Origin

Assign Country of Origin to Country of Declaration Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Country of Origin • Assign Country of Origin to

443

A

Europe

Country of Declaration Origin or use Transaction SM30 with object /ECRS/V_TRCO. Like we did for the partner country, we now need to assign all countries of origin to every country where your company must file an Intrastat report (Country of Declaration) as shown in Figure A.5.

Figure A.5 Intrastat: Assign Country of Origin to Country of Declaration

Define Exceptions for Mapping of Country of Origin Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Country of Origin • Define Exceptions for Mapping of Country of Origin, or use Transaction SM30 with object /ECRS/V_TMCO. Again, as you did for the partner countries, you can now define exceptions for special regions or countries, as shown in Figure A.6.

Figure A.6 Intrastat: Define Exceptions for Mapping of Country of Origin

Define Region Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Region • Define Region, or use Transaction SM30 with object /ECRS/V_TRGI. Here, you define the regions within a country. This isn’t relevant for all countries and should be checked in the individual Intrastat regulations. In Germany, for example, this information must be reported. You can see an example of some German regions in Figure A.7.

444

A.1

Intrastat Report

Figure A.7 Intrastat: Define Region

Define Conversion of Region Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Region • Define Conversion of Region, or use Transaction SM30 with object /ECRS/V_TMRE. Usually, the SAP regions (see table T005E) are different from the official Intrastat regions published by the authorities. Within this setting, a mapping between the SAP regions and Intrastat regions can be made (see Figure A.8).

Figure A.8 Intrastat: Define Conversion of Region

Define Business Transaction Type As mentioned earlier, the business transaction type is one of the fields that was harmonized inside the EU with the 2022 changes for the Intrastat report. The nature of transactions should be validated with the respective directives of each country, but they generally consist of eight categories ranging from transactions involving actual change of ownership with financial compensation to return and replacements free of charge to special cases, such as call-off stock or processing under contract. Table A.1 shows the business transaction types that all EU countries have agreed on and that are used in the Intrastat report.

445

A

Europe

Code

Category

Description

11

Transactions involving actual change of ownership with financial compensation

Outright sale/purchase except direct trade with/by private consumers

12

21 22

Direct trade with/by private consumers (including distance sale) Return and replacement of goods free of charge after registration of the original transaction

23

31

Return of goods Replacement of returned goods Replacement (e.g., under warranty) for goods not being returned

Transactions involving intended change of ownership or change of ownership without financial compensation

Movements to/from a warehouse (excluding call-off and consignment stock)

32

Supply for sale on approval or after trial (including call-off and consignment stock)

33

Financial leasing

34

Transactions involving transfer of ownership without financial compensation

41

42

51

52

71

72

Transactions with a view to processing under contract (not involving change of ownership)

Goods expected to return to the initial member state/country of export

Transactions following processing under contract (not involving change of ownership)

Goods returning to the initial member state/country of export

Transactions with a view to/following customs clearance (not involving change of ownership, related to goods in quasiimport or export)

Release of goods for free circulation in a member state with a subsequent export to another member state

Table A.1 Intrastat: Nature of Transaction Codes

446

Goods not expected to return to the initial member state/country of export

Goods not returning to the initial member state/country of export

Transportation of goods from one member state to another member state to place the goods under the export procedure

A.1

Intrastat Report

Code

Category

Description

80

Transactions involving the supply of building materials and technical equipment under a general construction or civil engineering contract for which no separate invoicing of the goods is required and an invoice for the total contract is issued

N/A

91

Other transactions that can’t be classified under other codes

Hire, loan, and operational leasing longer than 24 months

99

Other

Table A.1 Intrastat: Nature of Transaction Codes (Cont.)

Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Business Transaction Type, or use Transaction SM30 with object /ECRS/V_T605. Here, the mapping for the business transaction types must be made for each country where you file the Intrastat report, as shown in Figure A.9.

Figure A.9 Intrastat: Define Business Transaction Type

Define Procedure Generally, the statistical procedure should no longer be relevant (from 2022 onward). However, you can use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Procedure or use Transaction SM30 with object /ECRS/V_T616 to check the entries.

Define Movement Code This movement code is very specific to a few countries, such as the Czech Republic. To define the mode of transport code, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Movement Code, or use Transaction SM30 with object /ECRS/V_TSMC. Figure A.10 shows an example of movement codes for the Czech Republic.

447

A

Europe

Figure A.10 Intrastat: Define Movement Code

Define Mode of Transport at the Border To define the mode of transport code, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Mode of Transport at the Border, or use Transaction SM30 with object /ECRS/V_T618. Generally, there are nine mode of transport codes that are used around the EU: 쐍 1 Sea transport 쐍 2 Rail transport 쐍 3 Road transport 쐍 4 Air transport 쐍 5 Postal consignments 쐍 7 Stationary modes of transport 쐍 8 Inland water transport 쐍 9 Own propulsion

These must be mapped to all relevant countries where your company is filing Intrastat reports. In Figure A.11, you can see an example for the Czech Republic.

Figure A.11 Intrastat: Define Movement Code

448

A.1

Intrastat Report

Define Port and Airport The definition of a certain port or airport in combination with the mode of transport code is very specific to few countries. Should it be required for your Intrastat filing, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Port and Airport, or use Transaction SM30 with object /ECRS/V_TPRT.

Define Incoterms Here, you define all Incoterms per the requirements of the country. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Incoterms, or use Transaction SM30 with object /ECRS/V_TINC. The way they are defined can differ between countries. For example, the Czech Republic defines a grouping of Incoterms, while others use the three-digit code of the Incoterms (see Figure A.12).

Figure A.12 Intrastat: Define Incoterms

Define Collection Center The definition of a collection center is very specific to few countries. If it’s required for your Intrastat filing, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Define Collection Center, or use Transaction SM30 with object /ECRS/V_TCCE.

A.1.2 Default Values After defining all the underlying data fields, it’s now possible to create default values. These default values will be populated for certain combinations of parameters.

Define Default Values for Sales In this step, you’ll map the item category for a certain country of declaration to a business transaction type and, if relevant, to a statistical procedure or movement code. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Sales • Define Default Values for Sales, or use Transaction SM30 with object /ECRS/V_TDVS.

449

A

Europe

In our example in Figure A.13, standard item category TAN is mapped to standard business transaction type 11 for final sale, while item category TANN is mapped to business transaction type 34 for free-of-charge supplies. For our example country Germany, the other columns further to the right aren’t relevant.

Figure A.13 Intrastat: Define Default Values for Sales

Define Material Group for Intrastat If you have groups of goods that have similar Intrastat requirements, it’s possible to create an Intrastat group here. This value will then be assigned on the material master level. You can see both the material master and the settings for the Intrastat material group in Figure A.14. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Sales • Define Material Group for Intrastat, or use Transaction SM30 with object /ECRS/V_TVFM.

Figure A.14 Intrastat: Define Intrastat Group

Define Default Values for Purchasing Similar to the default mapping for sales, you can do a default mapping for purchasing as well. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Purchasing • Define Default Values for Purchasing, or use Transaction SM30 with object /ECRS/V_T161B. You map the combination of the country of declaration, purchasing document category, purchasing document type, and item category to a distinct business transaction type for receipts. In the example shown in Figure A.15, Purch. Doc. Category F (purchase

450

A.1

Intrastat Report

order), Purchasing Doc. Type NB (standard purchase order), and Item category 0 (standard) are mapped to Bus. Trans. Type Receipts 11 (final purchase).

Figure A.15 Intrastat: Define Default Values for Purchasing

Define Business Transaction Type for Returns to Supplier Next, you need to map receipt types to return types. This comes into play when you’ve received goods from a supplier that you want to return. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Purchasing • Define Business Transaction Type for Returns to Supplier, or use Transaction SM30 with object /ECRS/V_TBTR. In Figure A.16, you can see that business transaction type 11 (final purchase) is mapped to business transaction type for returns 21 (return of goods).

Figure A.16 Intrastat: Define Business Transaction Type for Returns to Supplier

Define Procedure for Returns to Supplier You can do the same thing for statistical procedures as you did for business transaction types where relevant. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Purchasing • Define Procedure for Returns to Supplier, or use Transaction SM30 with object /ECRS/ V_TPRR.

Define Default Values for Transportation Data for Dispatches In this setting, you can define default values for transport data on the sales side, such as the mode of transport for a combination of departure and destination country. If you know that all your goods, for example, between Germany and Austria, will be delivered via road, you could do a mapping as shown in Figure A.17. To get there, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Transportation Data • Define Default Values for Transportation Data for Dispatches, or use Transaction SM30 with object /ECRS/V_T617_2.

451

A

Europe

Figure A.17 Intrastat: Define Default Values for Transportation Data (Dispatch)

Define Default Transportation Data for Receipts Do the same thing for the receipt side by using Transaction SPRO and following path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Transportation Data • Define Default Transportation Data for Receipts, or use Transaction SM30 with object /ECRS/V_T617_1. You can see an example in Figure A.18.

Figure A.18 Intrastat: Define Default Values for Transportation Data (Receipt)

Define Default Transportation Data for Stock Transfers You can also assign default values for stock transfers between your own plants. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Transportation Data • Define Default Values for Transportation Data for Stock Transfers, or use Transaction SM30 with object /ECRS/V_T161W_T.

Define Default Values for Place of Delivery This setting can be relevant to define defaults for certain Incoterms. Remember that Incoterms relate to transport responsibility and can have influence on indirect tax and the Intrastat report. In our example in Figure A.19, we’ve defined the default place of delivery for Incoterm EXW—an Incoterm that signals pick-up at the warehouse of the supplier—as another member state of the EU. To get to this setting, use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Default Values • Define Default Values for Place of Delivery, or use Transaction SM30 with object /CCEE/SIFIINCP3.

Figure A.19 Define Default Values for Place of Delivery

452

A.1

Intrastat Report

Define Exceptions for Inclusion and Exclusion of Country and Region Remember how you defined the special partner regions earlier? Now, you can include or exclude specific regions from your Intrastat report. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Data Selection Control • Define Exceptions for Inclusion and Exclusion of Country and Region, or use Transaction SM30 with object /ECRS/V_T609II. In Figure A.20, we include Monaco and exclude the Canary Islands—a region of Spain that doesn’t belong to the EU VAT regime.

Figure A.20 Intrastat: Define Exceptions for Country and Region

Define Exclusion of Sales Document Item Category If you have special item categories you use in your sales documents, such as text items, you can exclude them by using Transaction SPRO and following path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Data Selection Control • Define Exclusion of Sales Document Item Category, or use Transaction SM30 with object /ECRS/V_TICX.

Define Sales Document Item Category for Services Here, you can define the item categories for services. These will be excluded from the Intrastat report, as the report is only relevant to track the movement of goods inside the EU. Use Transaction SPRO and follow path Governance, Risk and Compliance • International Trade • Intrastat • Basic Data • Data Selection Control • Define Sales Document Item Category for Services, or use Transaction SM30 with object /ECRS/V_TICS. In Figure A.21, we’ve recorded item category TAD.

Figure A.21 Define Sales Document Item Category for Services

A.1.3 Provider of Information Before you can run your Intrastat report, you need to create a provider of information. This is a reporting entity that represents a country where your company code is registered for VAT. This can be different from the company code or legal entity. Use Transaction /ECRS/POI_EDIT.

453

A

Europe

Click the Create icon, and fill in the fields for your Provider of Info., as shown in Figure A.22. We’ve chosen a combination of the company code and country. Additionally, enter the country of declaration and the company code you’re creating the provider of information for.

Figure A.22 Create Provider of Information

You’ll be forwarded to an overview populated by the information available for your company code in the declaration country. Fill in the missing information—for this example, fill in the State of Tax Office and Tax Number, as shown in Figure A.23.

Figure A.23 Provider of Information: Company Details

454

A.1

Intrastat Report

Next, fill in the basic settings of your report. If you’re using a different exchange rate than the standard rate M, enter it in the Exchange Rate Type box, as shown in Figure A.24. For Germany, you only have two choices for the receipt declaration level (Receipt Decl. Level) and dispatch declaration level (Dispatch Decl. Level): 0 (No Declaration) and 2 (Standard Declaration). There are other countries that offer, for example, an extended declaration option. Also enter your declaration format file (Declar. File Format). You’ll be able to extract the result as a Microsoft Excel file if you like, but, in this case, we’ll create an XML file.

Figure A.24 Provider of Information: Basic Report Settings

Finally, for the provider of information—and definitely an important step—enter the plants that belong to this registration in their respective boxes (see Figure A.25). If you don’t enter the Plant, the transactions won’t show up in your Intrastat report.

Figure A.25 Provider of Information: Record Plants

A.1.4 Run Intrastat Report Use Transaction VE01 to run the Intrastat report for dispatches, as shown in Figure A.26. With this functionality, you run a program in the background that collects all information on dispatches to be reported in the Intrastat report for the defined provider of information in a certain reporting period.

455

A

Europe

Figure A.26 Run Intrastat Report: Transaction VE01

A popup similar to Figure A.27 will show you how many data entries were found.

Figure A.27 Run Intrastat Report: Transaction VE01 Popup

Use Transaction MEIS to run the Intrastat report for receipts, as shown in Figure A.28. With this functionality, you run a program in the background that collects all information on receipts to be reported in the Intrastat report for the defined provider of information in a certain reporting period.

Figure A.28 Run Intrastat Report: Transaction MEIS

456

A.1

Intrastat Report

A popup similar to Figure A.29 will show you how many data entries were found.

Figure A.29 Run Intrastat Report: Transaction MEIS Popup

Use Transaction /ECRS/RP_EDIT to manage your Intrastat report. Enter your provider of information, and then you can see the declarations you created, as shown in Figure A.30.

Figure A.30 Intrastat: Manage Intrastat Declaration

You can click into the return—always split by receipt and dispatch—and view the details of the return in a certain period, as shown in Figure A.31. On the item level, you can see any errors or missing information that will need to be maintained, as shown in Figure A.32. As soon as all fields are filled, the Correct field is automatically checked.

457

A

Europe

Figure A.31 Intrastat: Manage Intrastat Declaration Details

Figure A.32 Intrastat: Manage Intrastat Declaration at the Item Level

Integration with SAP Global Trade Services If SAP Global Trade Services (SAP GTS) is used, you can configure all this in SAP GTS as well. The applications always integrate into each other; that is, logistical data from SAP GTS is sent to the SAP S/4HANA core.

458

A.2

EC Sales and Purchase List

A.2 EC Sales and Purchase List The EC Sales List and EC Purchase List are reporting requirements all over the EU. It usually has local names in the respective jurisdictions, such as “Zusammenfassende Meldung” in Germany and Austria and “VIES Return” in Ireland. Nevertheless, its main purpose is to show financial flows between the member states. We’ll explain some key tax code settings and the standard report for the EC Sales/Purchase List in the following sections.

A.2.1 Tax Code Settings As described in Chapter 3, Section 3.1.1, the EU code determines whether a tax code must be taken into consideration for the EC Sales List/Purchase List. There are several indicators that are used frequently in practice that we’ll have a deeper look into with some examples. If the EU Code field is blank, the tax code isn’t EU relevant or isn’t relevant for the EC Sales List/Purchase List. EU code 1 is generally used on a tax code for intra-community supplies of goods. The difference between EU code 1 and 4 is that EU code 1 is related to goods, and EU code 4 is related to services. Therefore, you would use EU code 4 for supplies of services to customers in other EU countries. For the purchasing side, the most relevant EU codes are 9 and 5. EU Code 9 is used for intra-community acquisitions of goods. EU code 5 is used for the acquisition of services. EU code A is special here because it’s used to indicate that a transaction is subject to reverse charge but isn’t relevant for the EC Purchase List. It can be used, for example, for local reverse charge transactions.

A.2.2 SAP Standard Report Transaction S_ALR_87012400 is used for the stanZPdard EC Sales List/Purchase List report in SAP S/4HANA. On the selection screen, the most important selection parameters are the company code, reporting country (if you’re using plants abroad), and extraction period. You can choose the extraction period either for a date range, reporting quarter, or reporting period, depending on the frequency of extraction and your setup. In Figure A.33, you can see some of the available fields of the output. Depending on the respective country requirements, this can also be adapted.

459

A

Europe

Figure A.33 EC Sales List Output

EC Sales List/Purchase List with SAP Document and Reporting Compliance SAP Document and Reporting Compliance (formerly the two products SAP Advanced Compliance Reporting and SAP Document Compliance) also offers functionality for the EC Sales List/Purchase List. For details on advanced compliance reporting (ACR), refer to Chapter 9.

A.3 Standard Audit File for Tax The SAF-T file is a standard data structure used widely across Europe to support predefined data extraction. Some countries use the SAF-T file as a monthly reporting requirement; others request it on-demand to support tax audits. A SAF-T file generally contains information about the taxpayer creating the file, master data, and accounting data, and can also contain inventory and transactional data. SAP offers one general SAF-T format and several predefined formats for countries where SAF-T is mandatory with a deviating format, such as Portugal or Poland. Use Transaction SPRO and follow path FinaZPncial Accounting • General Ledger Accounting • Periodic Processing • Report. Here, you have the StZPandard Audit File – Taxation menu with the Activate Countries for SAF-T Data Extraction and Activate Countries for SAF-T File Generation settings, as well as a submenu for country-specific settings for Norway. The settings for the other countries can be found further down in the respective submenus of Statutory Reporting, for example, Statutory Reporting: Portugal • Standard Audit File for Tax Purposes (SAFT-PT) or Statutory Reporting: Poland • SAF-T for Poland.

460

Appendix B India

The Indian goods and services tax (GST) is implemented within a dual model. Within the country, it contains one part central GST (CGST) levied by the state and one part state GST (SGST) or union territory tax (UTGST) levied by the states or union territories. For cross-state transactions, integrated GST (IGST) applies, equivalent to the sum of GCST and SGST. You can find all available solution notes for GST in India in SAP Note 2435968.

Example For goods sold within the state, for example, within the state of Maharashtra, a combination of CGST and SGST applies. For goods sold between two states, such as Maharashtra and Karnataka, IGST applies.

The standard tax procedure for India is TAXINN. With TAXINN, the system will determine the tax rate not based on the percentage added via Transaction FTXP directly in the tax code, but rather based on conditions maintained via Transaction FV11. In this appendix, we’ll briefly touch on how tax determination works in India, and how it’s different from the SAP standard approach described in this book. Furthermore, we’ll include some pointers on master data management for tax relevant master data in India and discuss official document numbering (ODN).

B.1 Tax Determination In your tax determination, you’ll have multiple financial accounting condition types for the different types of GST that are part of the tax procedure TAXINN. These are split up again, depending on the usage. For example, you have different financial accounting condition types—and account keys—for standard output GST, nondeductible GST, reverse charges, and import GST. We’ll take a closer look at the condition types and condition technique for tax determination in India in the following sections.

461

B

India

B.1.1 Condition Types To view the financial accounting condition types listed in this section, use Transaction OBQ1. To start, Table B.1 shows the deductible input condition types. GST Type

SAP Condition Type

SAP Account Key

Description

CGST

JICG

JIC

IN: Central GST

SGST

JISG

JIS

IN: State GST

IGST

JIIG

JII

IN: Integrated GST

UTGST

JIUG

JIU

IN: Union Ter. GST

Table B.1 Deductible Input Condition Types

Next, Table B.2 shows nondeductible input condition types. GST Type

SAP Condition Type

SAP Account Key

Description

CGST

JICN

NVV

IN: Central GST – ND

SGST

JISN

NVV

IN: State GST – ND

IGST

JIIN

NVV

IN: Integrated GST – ND

UTGST

JIUN

NVV

IN: Union Ter. GST – ND

Table B.2 Nondeductible Input Condition Types

Finally, Table B.3 shows output tax condition types. GST Type

SAP Condition Type

SAP Account Key

Description

CGST

JOCG

JOC

IN: Central GST – OP

SGST

JOSG

JOS

IN: State GST – OP

IGST

JOIG

JOI

IN: Integrated GST – OP

UTGST

JOUG

JOU

IN-Union Ter. GST – OP

Table B.3 Output Tax Condition Types

All input condition types listed have access sequence JGSI (IN: GST for Input Taxes) assigned, and all output condition types listed have access sequence JGSO (IN: GST for Output Taxes) assigned.

462

B.2

Stock Transfers

B.1.2 Condition Technique As mentioned before, the tax is determined via Transaction FV11, which is generally used if you want to maintain a tax rate that is determined for a certain tax code. In comparison to Transaction MEK1 or Transaction VK11, it enables you to determine different tax amounts for a single tax code. To view the access sequences, you can use Transaction OBQ2. In the tables we’ll discuss in this section, you’ll see that the region of the customer (REGIO) and of the supplying plant (WKREG) are always present. These are the indicators for the tax jurisdiction and therefore also for the tax rate. This determination of tax rates via Transaction FV11 works together with the standard condition technique in sales and distribution and materials management that you’ve already learned about. However, this is a far more flexible approach for a country that would otherwise require an abundance of tax codes if every tax rate were to be created in one individual tax code. For output tax determination—or rather, the determination of the tax rate on the output tax code—access sequence JGSO is used. It has three tables: 쐍 768 ALAND | WKREG | TAXK1 | TAXM1 | REGIO | STEUC 쐍 775 WKREG | TAXK1 | REGIO | MATNR 쐍 750 WKREG | REGIO | TAXK1

For input tax determination—or rather, the determination of the tax rate on the output tax code—access sequence JGSI is used. It has three tables: 쐍 792 ALAND | REGIO | WKREG | VEN_CLASS | TAXIM | STEUC 쐍 790 REGIO | WKREG | VEN_CLASS | MATNR 쐍 791 REGIO | WKREG | VEN_CLASS | SRVPOS

B.2 Stock Transfers In India, cross-state stock transfers are taxable transactions that must have a tax determination and a tax invoice. This requires a specific setup in which the plants must be created as a business partner and have vendor and customer data, including tax numbers. In the business partner data, the plant can be assigned in the Vendor: General Data tab. For the assignment of a customer number to a plant, use Transaction SPRO and path Materials Management • Purchasing • Purchase Order • Set Up Stock Transport Order • Define Shipping Data for Plants. Choose the plant and assign the customer number. SAP describes the best practice as creating an info record. If you’re using the condition technique on the purchasing side to determine the indirect tax, this is also possible.

463

B

India

Note that you’ll also need—similar to the EU setup—a separate billing type and pricing procedure. For more information, you can refer to the very detailed description in the appendix of SAP Note 2474335.

B.3 Multiple Tax IDs In India, the same customer or vendor often has multiple GST IDs over different states. Per SAP Note 2514392, it’s not possible to maintain multiple GST numbers for Indian business partners. The recommended solution is to create as many business partners as there are GST numbers—this also enables you to assign the GST number to the region for GST number determination.

B.4 Official Document Numbering in Sales and Distribution ODN is the SAP solution for legal requirements regarding sequential numbering without gaps. It’s more flexible than the standard document numbering. You can find all instructions for ODN according to the GST rules in India in SAP Note 2491168. To begin with ODN, the first step is to maintain document classes via Transaction SM30 and view V_DOCCLS. In the popup, enter the Country “IN”. You can then follow these steps: 1. Click New Entries and enter your document classes. Each document class will represent a distinct number range. 2. In the next step, again via Transaction SM30 with view J_1IG_V_T003_I, you’ll assign the billing type and document type to the document class and choose whether ODN is required for this combination. 3. Next, maintain the number group—representative of a specific number range—via Transaction SM30 with view J_1IG_V_NUMGRP. 4. Then, assign the number range group to the combination of company code, chart of accounts, and document class via Transaction SM30 with view J_1IG_V_OFNUM. 5. You’ll find your generated official document number in table VBRK, field XBLNR.

464

Appendix C North America

North America, especially the United States, is a special region for indirect taxes. The United States doesn’t impose a national-level indirect tax. Instead, different sales taxes are imposed at state and local city levels. This results in approximately 13,000 taxing jurisdictions in the United States—each imposing its own laws, rules, and procedures considering tax-base calculation, taxability of specific items, and tax rates. Canada is a little simpler, although the total tax is also a combination of the federallevel GST and the provincial-level harmonized sales tax or Quebec sales tax, depending on the province. In this appendix, we’ll look at tax determination via jurisdiction codes, as well as the specialties of tax codes and tax procedures for tax determination in SAP in North America.

C.1 Jurisdiction Codes To reach the settings for the creation of tax jurisdictions (see Figure C.1), use Transaction SPRO and follow path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Specify Structure for Tax Jurisdiction Code. Here, you can define the structure of the tax jurisdiction code per tax procedure with jurisdiction code. Those discussed in this section are delivered with the SAP best-practice installations for the respective countries. To create a new structure for tax jurisdiction codes, click on New Entries. The length is defined on the first, second, third, and fourth level in the hierarchy within the tax jurisdiction code structure. Indicator Tx In defines whether taxes are determined on a line-by-line basis.

Example The jurisdiction codes of tax procedure TAXUSX are defined as follows: 쐍 2 digits for the state code (e.g., Alaska = AK) 쐍 3 digits for the county code (e.g., area code 907 = Anchorage County) 쐍 4 digits for the city code (e.g., ANCH = Anchorage)

465

C

North America

Figure C.1 Tax Jurisdiction Code Structure

To define the tax jurisdiction codes themselves, use Transaction SPRO and follow path Financial Accounting • Financial Accounting Global Settings • Tax on Sales/Purchases • Basic Settings • Define Tax Jurisdictions. Here, in Figure C.2, you can see the result of your structure.

Figure C.2 Define Tax Jurisdiction Codes

C.2 Tax Codes The tax codes for North America are more complex than most other countries. This complexity is triggered by the tax procedure. The tax procedure you can see while creating a tax code will look something like Figure C.3. You can see four levels of taxes for each type of tax: nondeductible input sales tax (only partly on the screenshot), deductible input sales tax, output sales and use tax, and output sales tax. These four levels exist due to the different levels of indirect tax determined on the jurisdiction level. For details on tax determination, refer to Chapter 3, Section 3.3.

466

C.2

Tax Codes

You can see in Figure C.3 that this is a sales tax code. All the levels have value 100, as the tax value is determined on different levels, such as federal, county, city, and so on during pricing—and potentially through an external system. Transaction FV11 is generally used if you want to maintain a tax rate that is determined for a certain tax code. In comparison to Transaction MEK1 or Transaction VK11, it enables you to determine different tax amounts for a single tax code.

Figure C.3 Tax Procedure TAXUSX

For a system using TAXCAJ, you can see the tax jurisdiction directly on the tax code level. It contains a federal value with jurisdiction code CA00 and a provincial value with the jurisdiction code of the province, as you can see in Figure C.4.

467

C

North America

Figure C.4 Tax Procedure TAXCAJ

C.3 Tax Types As there are several types of indirect tax that work together for a single transaction in North America, the pricing procedures for Canada and the United States also offer several tax types. Note that the best practice for North America—the United States in particular with the immense number of jurisdictions and frequent changes of tax rates— is to use a tax engine. Let’s walk through the tax types in this section: 쐍 RVAAUS (Standard USA w/out Jur.Code)

Pricing procedure RVAAUS is the standard US pricing procedure without jurisdiction codes (Standard - USA /w/out Jur.Code). This pricing procedure should be used if your country (US) is assigned to tax procedure TAXUS, not TAXUSJ. In Figure C.5, you can see that the pricing procedure has three levels: State Sales Tax with condition type UTX1, County Sales Tax with UTX2, and City Sales Tax with UTX3. Note that the condition types here differ slightly from each other. UTX1 is defined with condition category D (Tax), as you’ve learned is the standard for tax conditions. UTX2 and UTX3, however, have condition category M (Sales tax w/license checking) (VAT). This means that generally, this is a standard condition type, but a check for a valid tax exemption license in the customer master segment is made. If a valid exemption license is found, the condition record with customer tax classification “L” is made, if maintained. For the most part, however, the maintenance of condition records works exactly like it does for condition type MWST via Transaction VK12. You’ll have the choice between an assignment of departure and destination country, and a domestic option, including the country, state, county, customer tax classification, and material tax classification.

468

C.3

Tax Types

Figure C.5 Pricing Procedure RVAAUS 쐍 RVAJUS (Standard USA /With Jur.Code)

Pricing procedure RVAJUS is the standard US pricing procedure with jurisdiction codes, as shown in Figure C.6. This pricing procedure should be used if your country (US) is assigned to tax procedure TAXUSJ, not TAXUS.

Figure C.6 Pricing Procedure RVAJUS

The condition types are defined differently here. UTXJ has condition category 1 (TaxJurDic level 1) (with license check). This is the indicator for a trigger condition that triggers the others. In UTXJ, the tax code is set, while the tax value is built in the following conditions. Like for UTX1, the maintenance of condition records is done on a country basis. The condition table contains the tax departure country, region, and customer and material tax classifications. However, it also includes a field for a license number and date. The following levels—the tax jurisdiction conditions—aren’t maintained via Transaction VK12, but rather via Transaction FV12 on a country and tax code basis. The tax jurisdiction code is contained in the customer master data and is used during pricing to identify the tax value. If this pricing procedure used for external tax determination, UTXJ, has formula 300 assigned in the field alternative calculation type, this is the indicator for external tax determination.

469

C

North America

쐍 RVAXUD (Standard USA /Tax per doc.)

In pricing procedure RVAXUD, as shown in Figure C.7, there are two condition types: UTXD and UTXE. They must be used together for technical reasons and have a formula value assigned—they have no access sequence and are both group conditions. UTXD uses UTXJ as a reference condition type. This means that UTXD uses the same condition records as UTXJ.

Figure C.7 Pricing Procedure RVAXUD 쐍 RVAACA (Standard - Canada)

The standard pricing procedure RVAACA for Canada, as shown in Figure C.8, includes three tax types: CTX1, CTX2, and CTX3. CTX1 is for the standard GST on the federal level. CTX2 contains the provincial tax HST or QST. Finally, CTX3 is the provincial tax calculated based on the gross value of the tax base amount plus GST. You can see how it refers to step 911, the net value plus GST. All three of these condition types are defined with condition category D (Tax).

Figure C.8 Pricing Procedure RVAACA 쐍 RVAJCA (Standard - CA /With Jur.Code)

Like for the United States, condition types are defined differently here (see Figure C.9). CTXJ has condition category 1 (TaxJurDic), level 1 (with license check) as a trigger condition.

470

C.3

Tax Types

The following levels—the tax jurisdiction conditions—are maintained via Transaction FV12 on a country and tax code basis. The tax jurisdiction code is contained in the customer master data and is used during pricing to identify the tax value.

Figure C.9 Pricing Procedure RVAJCA

471

Appendix D The Authors

Michael Fuhr is a certified tax advisor with a business informatics background. He co-leads a German Big Four indirect tax technology practice. Together with his team, he delivers end-to-end indirect tax solutions that enable data-based indirect tax management for multinational and regional clients. As deputy lead of expert committee III of the Institute of Digitization for Taxes, Michael is part of a community to shape the future of indirect tax developments for real-time reporting and e-invoicing. Dirk Heyne works as a partner in the Big Four. He advises clients during the transformation and digitization of their tax function and its integration with the finance function. One of his focus areas is the support of the tax function during SAP S/4HANA transformation projects. The use cases span tax data management across operational transfer pricing to the implementation of BEPS 2.0 requirements. Dirk is a certified tax advisor and a certified public accountant in Germany. Beyond that, he holds a PhD from the Department of Mathematics and Computer Science as well as two master’s degrees in engineering and business engineering from the Technical University Munich. Nadine Teichelmann is a senior consultant in the EY indirect tax technology practice based in Munich, Germany. In this role, she advises multinational clients on the digitization of their tax department. With her degree in business informatics and her ongoing PhD in tax technology, Nadine’s core focus is on the technical and business process side of indirect tax implementation projects in SAP S/4HANA.

473

D

The Authors

Jan Walter is a tax partner in the EY business tax practice, and he is based in Munich, Germany. As an SAP S/4HANA expert, Jan supports tax functions in transformation projects to identify, address, and manage direct tax requirements in SAP. He has more than 15 years of professional experience in tax operating model transformation, direct tax-enabled ERPs, and tax compliance management and reporting. Jan has been the project lead for several tax technology and transformation projects, and he has been responsible for the development of various SAP-based tax applications.

474

Index 1+2 approach .......................................................... 299

A ABAP ................................................................ 262, 263 programs ............................................................. 265 statements .......................................................... 265 ABC contract .............................................................. 74 Access requirement .......................... 176, 185, 197 enhancements ................................................... 276 Access sequence .............. 165, 175, 182, 184, 463 0003 ...................................................................... 188 add condition table ......................................... 186 define .................................................................... 184 exclusive .............................................................. 185 MWST .......................................................... 185, 188 transfer pricing ....................................... 362, 364 Account assignment .................................. 142, 315 categories ............................................................ 142 Account determination ...................................... 178 Account key ............................................................ 180 Account mapping ................................................. 334 Account screening ................................................ 326 Account solution .................................................. 296 Account split ........................................................... 308 Accounting document ..................... 162, 164, 169 Accounting principle ........................................... 297 Accounts payable .................................................. 204 Accruals .................................................................... 180 Accumulation type .............................................. 101 Actual cost .................................................................. 33 Add-on ............................................................. 253, 428 Adjustment account ............................................ 296 Administration ...................................................... 380 Advance return ............................................ 128, 130 Advanced compliance reporting (ACR) ........ 398 documentation ................................................. 399 set up ..................................................................... 399 Airport ....................................................................... 449 Allocation rule ....................................................... 370 Amendment ............................................................... 79 Amortization ............................................................. 30 Analytical review .................................................. 327 Analytics ......................................................... 293, 372 direct tax ............................................................. 326 Annual tax return ................................................. 109 Append structure ............................... 195, 269, 367 add ......................................................................... 195

Application design ............................................... 341 Application manager ............................................. 32 Application programming interface (API) integration ............................................................ 39 Application scenario ........................................... 342 Arm’s length principle ....................... 89, 350, 351 Asset ................................................................... 93, 321 Audit ....................................... 91, 292, 295, 380, 414 ensure readiness ................................................. 92 log .......................................................................... 255 post ........................................................................ 383 Audit-to-return adjustment ............................ 295 Automated digital services ................................. 89 Automation ................ 19, 21, 39, 44, 58, 308, 426 Availability level ...................................................... 39 Avalara AvaTax ..................................................... 258

B Balance carryforward .......................................... 304 Balance sheet ......................................... 33, 296, 297 accounts .............................................................. 314 commercial versus tax .................................. 301 select items ......................................................... 307 Balance Sheet/Income Statement – Multidimensional app ................................... 375 Base amount .......................................... 25, 101, 122 Base calculation ....................................................... 98 Base Erosion and Profit Shifting (BEPS) ......... 86 2.0 .......................................................... 88, 349, 354 Base ledger .............................................................. 298 Basic compliance reporting ............................. 398 Basic settings ............................................................. 97 Batch input ............................................................. 388 Bill of materials (BOM) .............................. 248, 359 Billing ........................................................................... 34 date .............................................................. 166, 243 quantity ............................................................... 214 Billing document ......................................... 164, 212 delivery-related ................................................ 234 exchange rate ................................................... 133 issue output ....................................................... 172 user exits .................................................... 274, 275 VAT IDs ....................................................... 152, 214 Billing plan .............................................................. 240 milestone billing .............................................. 242 periodic billing .................................................. 244 pricing .................................................................. 243

475

Index

Billing plan type .................................................... 241 assign .................................................................... 242 maintain .............................................................. 241 Billing type .............................................................. 283 credit notes ......................................................... 274 Bill-to party ............................................................. 146 Brazil .............................................................. 39, 66, 68 Brownfield approach .............................................. 49 Business add-in (BAdI) .............................. 262, 368 tax reporting date ............................................ 115 Business case ..................................................... 29, 51 Business intelligence (BI) ................................... 341 Business partner ............... 34, 137, 145, 286, 318 choose role .......................................................... 146 internal ................................................................. 286 maintain ................................................................. 34 plant ...................................................................... 228 roles for tax ID ................................................... 145 supplier ................................................................. 229 type ........................................................................... 35 WHT ....................................................................... 318 Business process ...................................................... 58 Business process document (BPD) ................... 52 Business Rule Framework plus (BRFplus) ... 338 Business transaction type ................................. 445 define .................................................................... 447 returns to supplier ........................................... 451 Business unit segmentation ............................ 353 Business vendor .................................................... 202

C Calculation rule ..................................................... 166 Calculation type .................................................... 183 Calling and exiting program unit .................. 265 Canada ...................................................... 39, 465, 470 Cash discount ......................................................... 101 Cash flow optimization ...................................... 416 Central Finance ................................................. 23, 49 Central GST (CGST) ............................................... 461 Centralized exchange model .............................. 85 Certificate of exemption .................................... 104 Chain transaction ....................... 74, 150, 216, 217 first entrepreneur ............................................. 218 second entrepreneur ....................................... 220 special ...................................................................... 75 third entrepreneur ........................................... 225 Change of ownership .......................................... 446 Chart of accounts ................................. 94, 113, 312 account descriptions ...................................... 315 overview ............................................................... 316 requirements ...................................................... 313

476

Chart of depreciation ........................................... 321 Check routine ...................................... 328, 330, 419 Checking rule ......................................... 44, 146, 230 Class ............................................................................ 256 Classic coding block extension ........................ 366 Clearance model ...................................................... 84 COBL structure ....................................................... 366 Coding block ............................... 323, 366, 368, 369 Collection center ................................................... 449 Commercial invoice ............................................... 68 Communication header ........................... 267, 284 Communication item .......................................... 268 Company code ........................... 119, 122, 123, 310 assign .................................................................... 392 currency ................................................................ 127 display ................................................................... 312 fiscal year variants ........................................... 302 Comparable uncontrolled price (CUP) method ................................................................. 351 Compliance ................................. 354, 355, 373, 379 costs ....................................................................... 414 digital model ...................................................... 380 global model ....................................................... 384 management ...................................................... 417 reporting .............................................................. 398 risks ........................................................................ 414 show log ............................................................... 437 tasks ....................................................................... 437 Compliance check ................................................. 427 create ..................................................................... 430 hits .......................................................................... 435 task lists ................................................................ 431 Compliance Check Hits app .............................. 434 Compliance Results Overview app ....... 429, 437 Compliance scenario ........................................... 432 run .......................................................................... 434 Concur Expense ..................................................... 207 Concur Invoice ....................................................... 208 Concur Travel .......................................................... 207 Condition amount ...................................... 180, 183 Condition base value ........................................... 180 Condition category ............................................... 183 Condition class ....................................................... 182 Condition logic ............................................. 175, 251 Condition record ............ 165, 178, 190, 191, 210 create ..................................................................... 189 plants abroad ..................................................... 124 Condition table .............. 176, 184, 185, 187, 244, 268, 285 add to access sequence .................................. 186 assign fields ........................................................ 187 create ..................................................................... 190

Index

Condition table (Cont.) create data element ........................................ 191 nonmaintainable materials ........................ 203 purchasing .......................................................... 188 requirements ...................................................... 197 sales and distribution ..................................... 188 status of country .............................................. 269 technical view .................................................... 191 Condition technique ....... 38, 175, 251, 268, 463 Condition type ....... 105, 156, 175, 176, 181, 210 assign to countries .......................................... 157 AZWR ..................................................................... 243 billing plans ........................................................ 243 control data ........................................................ 182 create/copy ......................................................... 182 CTX1 ....................................................................... 470 CTX2 ...................................................................... 470 CTX3 ....................................................................... 470 CTXJ ....................................................................... 470 custom .................................................................. 138 define .................................................................... 181 DIFF .............................................................. 180, 182 display for tax procedure .............................. 105 financial accounting ....................................... 166 formulas .............................................................. 182 GRWR ............................................................. 43, 178 India ...................................................................... 462 intra-community stock transfers .............. 234 manual entries .................................................. 184 MWST ....................................... 177, 180, 182, 183 plants abroad .................................................... 124 pricing ......................................................... 132, 158 pricing discounts .............................................. 246 sales and distribution ..................................... 165 settings ....................................................... 177, 179 statistical ............................................................. 178 transfer pricing ................................................. 362 TTX1 .................................................... 135, 184, 210 US ................................................................. 468, 469 UTX1 ...................................................................... 468 UTX2 ...................................................................... 468 UTX3 ...................................................................... 468 UTXD ..................................................................... 470 UTXE ...................................................................... 470 UTXJ ....................................................................... 469 WHT ....................................................................... 102 WIA1 ....................................................................... 124 WIA2 ...................................................................... 124 WIA3 ...................................................................... 124 YZWR ..................................................................... 243 Condition value ..................................................... 183 Conditional rebate ............................................... 247

Construction provider .................... 137, 138, 271 Consumer tax (CT) .................................................. 66 Consumer-facing business .................................. 89 Content manager .................................................... 31 Continuous transaction controls (CTC) .............................. 80, 81, 83, 383, 408, 413 decentralized ........................................................ 85 Contract type ......................................................... 244 Control ....................... 101, 259, 420, 421, 423, 424 data .............................................................. 105, 116 Conversion .............................................................. 261 rule ......................................................................... 131 Coordination .......................................................... 350 Copying control .................................................... 213 billing documents ............................................ 132 settings ................................................................ 214 STO for delivery ................................................ 231 Core data services (CDS) view ................ 287, 328, 329, 425 Corporate income tax ........................................... 86 Co-sourcing ............................................................. 384 Cost allocation ....................................................... 369 Cost center allocation ......................................... 360 Cost uplift ....................................................... 359, 360 Costing ...................................................................... 358 run ......................................................................... 360 variants ............................................................... 359 Cost-plus method .............................. 351, 357, 358 Country of declaration .............................. 442, 443 Country of origin .................................................. 443 assign ................................................................... 443 exceptions .......................................................... 444 Country-by-country reporting (CbCR) ......................................... 87, 351, 374, 375 Country-independent tax ................................. 165 Coupa ........................................................................ 206 Created-on date ..................................................... 168 Credit account ................................................ 99, 104 Credit note .............................................................. 274 Credit posting ........................................................ 360 Cross-border goods movement ...... 63, 120, 124 Cross-border supplies of goods ...................... 244 Cross-border transaction ..................................... 76 Cross-company transaction ............................. 226 Currency .................................................................. 126 assign multiple ................................................. 127 exchange rates ................................................. 126 translation ................................................ 129, 131 types ...................................................................... 127 Custom coding ...................................................... 261 Custom Fields and Logic app .................. 366, 367

477

Index

Customer ............................................... 137, 144, 208 create invoice ..................................................... 224 exempt .................................................................. 140 license ................................................................... 271 master record ....................................................... 34 projects ................................................................. 281 tax classification .............................................. 137 VAT ID ................................................................... 420 Customer exit ............................................... 262, 280 EXIT_SAPLMEKO_001 .................................... 284 EXIT_SAPLMEKO_002 ................................... 287 identify ................................................................. 281 Customer tax classification .................... 137, 164 examples ............................................................. 139 maintain .............................................................. 138 vendor WHT ....................................................... 144 Customs clearance ............................................... 446 Czech Republic ............................................. 447, 449

D Dashboard template ............................................ 342 Data capturing ....................................................... 292 Data element ................................................ 191, 269 add ......................................................................... 194 add to field catalog ......................................... 196 create .................................................................... 194 Data flow ..................................................................... 24 Data layer ................................................................. 257 Data Medium Exchange (DME) Engine ........ 394 Data processing statement ............................... 266 Data quality ...................................................... 56, 326 Data replication ........................................................ 44 Data Retention Tool (DART) catalog ................ 25 Data type .................................................................. 194 Data-based tax management ........................... 415 Date category .......................................................... 241 Debit account .................................................. 99, 104 Decentralized CTC and exchange model (DCTCE) ................................................................... 85 Declarative statement ........................................ 265 Default value .......................................................... 449 place of delivery ................................................ 452 purchasing .......................................................... 450 sales ....................................................................... 449 transportation data ........................................ 451 Deferred tax .................................................. 113, 335 liability .................................................................... 93 Delivery ................................................. 164, 212, 224 billing documents ............................................ 234 block ...................................................................... 240 place ...................................................................... 452

478

Delivery (Cont.) type ......................................................................... 230 Delta posting ........................................................... 296 extension ledger ................................................ 298 ledger groups ...................................................... 301 Demand management ........................................ 205 Deploy phase ............................................................. 54 Deployment .............................................................. 47 Depreciation area .................................................. 321 target ledger groups ........................................ 322 Design workshop ..................................................... 52 Destination principle ...................................... 69, 71 Detective control ................................................... 420 Determination extension .................................. 151 Determination rule .............................................. 149 examples .............................................................. 152 maintain .............................................................. 150 Development package ......................................... 194 Digital compliance model ................................. 380 Digital reporting requirements (DRRs) ... 80, 379 drivers, problems, and effects ........................ 82 EU .............................................................................. 82 Digital tax administration ................................... 18 Direct allocation .................................................... 370 Direct tax ................................................... 57, 86, 291 basics ..................................................................... 291 data analytics and monitoring ................... 326 filing ....................................................................... 332 lifecycle ......................................................... 57, 307 master data .............................................. 294, 317 organizational structures ......... 294, 295, 311 planning ............................................................... 340 process .................................................................. 292 reporting ...................................................... 93, 332 tax tagging .......................................................... 322 Discount .......................................................... 122, 246 Discover phase ......................................................... 51 Dispatch .................................................................... 451 declaration level ............................................... 455 run report ............................................................ 455 Distribution channel ................................. 181, 226 Division ..................................................................... 181 Document class ...................................................... 464 Document date .................................. 162, 167, 388 Document type ...................................................... 229 assign .................................................................... 230 define ..................................................................... 229 Documentation ...................................................... 258 Domain ............................................................ 191, 194 create ..................................................................... 192 value range ......................................................... 192 Domestic tax ................................................. 185, 188

Index

Double taxation ....................................................... 72 Down payment ...................................................... 235 calculate tax ...................................................... 237 connect receipt to request ............................ 239 create request .................................................... 237 general ledger accounts ................................ 236 link to standard account ............................... 236 receipt ......................................................... 238, 240 Drop shipment ............................................... 74, 217 inside US .............................................................. 220

E E-accounting ........................................................... 382 E-assess ..................................................................... 382 E-audit ....................................................................... 382 EC Purchase List ..................................................... 459 standard reports ............................................... 394 tax code ................................................................ 112 tax code settings .............................................. 459 EC Sales List ............................................... 63, 79, 459 print ....................................................................... 397 set up ..................................................................... 407 standard reports ............................................... 394 tax code ................................................................ 112 tax code settings .............................................. 459 Economic link ........................................................... 72 Education .................................................................... 71 Efficiency .................................................................. 415 E-file ........................................................................... 382 E-invoicing ..................................... 19, 45, 80, 82, 83 Electronic Data Interchange (EDI) .......... 85, 198, 246, 411 add mapping ..................................................... 199 Electronic document (eDocument) ............... 408 connected to customer solution ................ 410 connected to partner solution .................... 411 connected to tax authority .......................... 409 Electronic filing ........................................................ 78 Electronic Road Transportation Control System (EKAER) ................................................ 381 E-match ..................................................................... 382 Embedded analytics ............... 293, 329, 371, 424 dashboard ........................................................... 330 versus SAP Tax Compliance ......................... 331 Enhancement ............................................... 261, 368 assignments ....................................................... 282 implementations ........................... 115, 266, 281 overview ............................................................... 281 purchasing .......................................................... 288 sales and distribution ..................................... 276 Equity account ....................................................... 314

EU code ............................................................ 113, 459 EU Triangular Deal ............................................... 220 European E-invoicing Service Providers Association (EESPA) ........................................... 80 European Union (EU) ..... 62, 69, 74, 79, 407, 441 digital reporting requirements ..................... 82 EC Sales and Purchase List ........................... 459 Intrastat report ................................................ 441 legal requirements ............................................. 80 SAF-T ..................................................................... 460 European VAT Code ............................................. 270 Event ............................................................................. 68 tax exempt ............................................................ 70 Exception ................................................................. 453 Exchange rate ............................................... 126, 455 advance return ................................................. 130 assign to country ............................................. 130 basic settings ..................................................... 127 conversion rules ............................................... 131 define .................................................................... 130 determine ............................................................ 116 import from XML file ..................................... 130 maintain ............................................................. 129 sales and distribution .................................... 131 types ............................................................. 127, 129 Exemption ........................... 70, 140, 218, 311, 468 categories .............................................................. 70 licenses ................................................................. 271 reason .......................................................... 103, 110 rules .......................................................................... 72 VAT ........................................................................ 234 Explore phase ........................................................... 52 Export .......................................................................... 71 tax ............................................................... 186, 188 Extendable interface ........................................... 255 Extension ledger ................................................... 298 fiscal year variants .......................................... 303 posting period variants ................................. 304 External group number ..................................... 406 External partner ................................................... 254 External system .................................................... 280 External tax calculation ........................................ 39 engine .......................................................... 253, 256 External tax determination ............................. 254

F Factory calendar ................................................... Field catalog ............................................................ Field control ........................................................... Field status group ................................................. subgroups ...........................................................

400 196 430 319 319

479

Index

Field status variant ............................................... 319 Filing ................................................ 77, 293, 312, 332 electronic ................................................................ 78 Financial accounting ........... 32, 34, 97, 160, 163, 166, 239 WHT ....................................................................... 170 Financial link ............................................................. 72 Financial reporting .................................................. 93 Financial statement ................................... 291, 375 annual .................................................................. 295 First entrepreneur ................................................ 218 Fiscal year variant ................................................. 302 Fit-to-standard analysis ........................................ 52 Fixed ledger ............................................................. 297 Flash title .................................................................. 220 Forecast planning ................................................. 341 Form routine .......................................................... 172 Function module ........................................ 264, 282

G General ledger .............................................. 296, 297 assessment .......................................................... 369 General ledger account ......... 116, 236, 319, 388 customer-specific fields ................................. 320 ledger groups ..................................................... 301 tax relevant ........................................................ 116 transaction types ............................................. 320 VAT ........................................................................ 118 Generally Accepted Accounting Principles (GAAP) ............................ 93, 296, 307 Germany ......................................................... 444, 455 Gift ................................................................................. 70 Global Anti-Base Erosion (GloBE) ...................... 90 Global enterprise ..................................................... 87 Global tax management ....................................... 36 Goods and services tax (GST) .................... 64, 413 ID ............................................................................ 464 India ...................................................................... 461 Goods receipt ......................................................... 160 Governance and organization ............................ 28 Greece ........................................................................ 383 Greenfield approach ............................................... 49 Gross margin ................................................ 358, 361 Group condition .................................................... 183 Group number ....................................................... 406 Group valuation .................................................... 360 Grouping ..................................................................... 72 Guided buying ....................................................... 205 Gulf Cooperation Council .................................... 64

480

H Historical data .......................................................... 26 Hungary .................................................................... 381 Hypercare ................................................................... 54

I Identification .......................................................... 146 If condition .............................................................. 270 Immediate Supply of Information System (SII) ......................................................... 110 Implementation project ............... 22, 26, 28, 258 SAP Activate ......................................................... 51 Import ........................................................................ 141 Importation of goods ............................................ 69 Imposto sobre Circulaçao de Mercadorias e Serviços (ICMS) ...................... 67 Imposto sobre Produtos Industrializados (IPI) ......................................... 67 Imposto Sobre Serviços (ISS) .............................. 67 Includes ..................................................................... 264 Income inclusion rule ........................................... 90 Income tax ................................................................. 86 reporting ................................................................ 93 Incoterm ...................................... 216, 225, 267, 273 define ..................................................................... 449 India .................................................................... 64, 461 condition types .................................................. 462 multiple IDs ......................................................... 464 ODN ........................................................................ 464 stock transfers ................................................... 463 tax determination ............................................ 461 Indirect allocation ....................................... 369, 370 Indirect tax ............................................... 19, 61, 175 ABAP basics ......................................................... 262 chain transactions ........................................... 225 content and maintenance ............................ 258 custom coding ................................................... 261 data flow .............................................................. 416 digital reporting requirements ..................... 80 engines and add-ons ....................................... 251 gap ............................................................................ 19 global systems ..................................................... 61 jurisdictions .............................................. 107, 157 lifecycle ................................................................... 27 monitoring .......................................................... 424 registration ........................................................... 42 returns ..................................................................... 78 special jurisdictions ........................................... 66 special transactions ......................................... 217 standard reporting requirements ................ 76

Index

Indirect tax (Cont.) tax codes .............................................................. 109 tax procedures .................................................. 105 tax processes ......................................................... 55 tax rate ................................................................. 109 values abroad ....................................................... 43 Indirect tax determination ..................... 157, 175 condition logic in SAP .................................... 175 customizing scenarios ......................... 202, 215 purchasing .......................................................... 198 sales and distribution ..................................... 208 Inline declaration ................................................. 264 Input tax ......................................... 62, 124, 184, 202 Insourcing ................................................................ 384 Intangible goods ...................................................... 68 Integration ..................................................... 160, 254 layer ....................................................................... 257 templates ............................................................. 254 Intercompany billing .......................................... 226 Intercompany profit ............................................ 364 Intercompany stock transfer ................. 228, 231 Intercompany transaction ................................ 351 Interface ................................................. 255, 261, 280 Internal group number ...................................... 406 Internal number range ....................................... 275 Internal stock transfer ........................................ 227 International Financial Reporting Standards (IFRS) ......................................... 93, 296 International tax order .......................................... 88 International trade .................................................. 31 Interoperability model .......................................... 84 Intra-community supply of goods ........... 63, 71 Intracompany stock transfer ........................... 228 Intra-group transaction ........................................ 73 Intrastat ............................................ 31, 79, 178, 441 basic settings ..................................................... 441 default values .................................................... 449 manage report .................................................. 457 material group .................................................. 450 provider of information ................................ 453 report .................................................................... 148 run report ............................................................ 455 view return .......................................................... 457 Intrastate acquisition ............................................. 70 Investment ................................................................. 30 Invoice .......................................... 161, 164, 212, 381 Brazil ........................................................................ 68 create .................................................................... 224 date .............................................................. 162, 167 electronic ................................................................ 80 numbering .......................................................... 215

Invoice (Cont.) posting ........................................................ 101, 201 receipt ................................................................... 224 tax-relevant ....................................................... 240 texts ...................................................................... 216 user exits ............................................................. 274 Invoice-credit method .......................................... 64 IT expert ...................................................................... 28 Item category ......................................................... 221 assign ................................................................... 221 assign billing plan types ............................... 242 billing relevance ............................................... 125 kit items ............................................................... 248 sales document ................................................. 453 services ................................................................. 453 stock transfers .................................................. 229 TAN ........................................................................ 450 Item condition ...................................................... 184

J JAGGAER .................................................................. 206 Japan ...................................................................... 64, 68 Journal entry .......................................................... 352 extend .................................................................. 366 item .............................................................. 366, 369 Jurisdiction ...................................................... 39, 107 chain transactions ............................................. 74 codes ..................................................................... 465 define .................................................................... 466 define codes ....................................................... 108 exemptions ........................................................... 72 GST ........................................................................... 64 indirect tax ......................................................... 157 reporting requirements ................................. 381 requirements ..................................................... 122 requirements gathering ................................... 52 sales tax .................................................................. 65 special indirect tax ............................................. 66 tax rates .............................................................. 109

K Key performance indicator (KPI) .......... 346, 371 Key user extensibility ......................................... 366 Kit ............................................................................... 248 KOMK structure .............. 266, 267, 281, 283, 284 KOMKAZ structure ........................... 194, 266, 267 KOMP structure ........................ 266, 281, 283, 287 KOMPAZ structure ................... 194, 195, 266, 269

481

Index

L L-account .................................................................. 296 Leader ........................................................................... 28 Ledger ................................................................. 94, 295 balance carryforward ..................................... 304 business operations ........................................ 305 deactivate ........................................................... 300 depreciation areas ........................................... 322 extension ............................................................. 298 fiscal year variant ............................................ 302 groups ................................................................... 301 parallel ................................................................. 297 posting period variant ................................... 304 set up ..................................................................... 299 solution ...................................................... 296, 297 standard .............................................................. 297 Legacy system ........................................................... 50 Legal entity .............................................................. 311 Legal valuation ....................................................... 360 License ....................................................................... 271 Local currency .............................................. 126, 127 advance return .................................................. 128 Local file ................................................... 87, 351, 373 Location-based supply ........................................ 217 Logistical data ........................................................ 381

M Maintenance .............................................................. 54 Making Tax Digital (MTD) ................................. 386 Malaysia ....................................................................... 66 Manage Compliance Checks app .......... 329, 430 Manage Compliance Scenarios app ..... 329, 432 Manage Launchpad Spaces and Pages app .... 32 Manage Substitution and Validation Rules app ............................................................. 368 Manage Task List Templates app .......... 435, 437 Management transfer price .............................. 350 Market price ............................................................ 358 Market segment .......................................... 367, 369 Market state ............................................................... 89 Master data management .................................... 53 Master data screening ......................................... 326 Master file ............................................... 87, 351, 373 Material ..................................................................... 209 group ..................................................................... 450 movement .............................................................. 33 Material Ledger ............................................... 33, 360 Material master ..................................................... 359 Material tax classification ....................... 133, 136 examples ............................................................. 139

482

Material tax classification (Cont.) maintain .................................................... 135, 136 purchasing .......................................................... 136 sales and distribution ..................................... 134 Materials management .............................. 33, 160 Medical care ............................................................... 71 Microsoft Excel ...................................................... 296 Migration .................................................................... 47 strategies ............................................................... 48 template approach ............................................ 50 Milestone billing .......................................... 240–242 Mini One Stop Shop (MOSS) ............................. 113 Mitigation ................................................................ 421 action .................................................................. 426 Mode of transport ................................................. 448 Modularization statement ................................ 265 Monaco ...................................................................... 443 Monitor Compliance Scenario Runs app ..... 329 Monitoring ................................................ 44, 56, 413 business partners .............................................. 318 direct tax .................................................... 293, 326 indirect tax .......................................................... 424 requirements ...................................................... 417 solutions ............................................................... 418 tax movements ................................................. 314 transfer pricing ........................................ 353, 364 Movement code ..................................................... 447 Multinational enterprise (MNE) ................. 88, 89 Multiplatform ......................................................... 259 Multiyear project report ..................................... 354 My Compliance Check Results app ...... 329, 434 My Compliance Tasks app ................................. 437 myDATA .................................................................... 383

N Natural person ........................................................ 202 Nature code ............................................................. 110 New implementation ............................................ 49 Nexus .................................................................... 75, 88 Nondeductible VAT .............................................. 118 Nonroutine profit ................................................... 89 Nonstock item ........................................................ 136 North America ........................................................ 465 jurisdiction codes ............................................. 465 tax codes .............................................................. 466 tax types ............................................................... 468 Northern Ireland ......................................... 442, 443 Number range ........................................................ 275

Index

O Object ......................................................................... 263 OECD Committee on Fiscal Affairs (CFA) ....... 91 Official document numbering (ODN) .......................................................... 215, 464 Online validation .................................................. 148 service ...................................................................... 43 OpenText ................................................................. 204 Operational transfer pricing .................. 349, 350 automate ............................................................. 356 challenges ........................................................... 355 Optical character recognition (OCR) ............. 204 Order-to-cash ............. 59, 163, 175, 280, 421, 423 example ............................................................... 165 Organization for Economic Cooperation and Development (OECD) ..................... 64, 350 Organizational link ................................................. 72 Origin principle ........................................................ 70 Outbound delivery ..................................... 164, 231 create .................................................................... 232 number ................................................................. 233 Output control ............................................. 388, 396 Output device ......................................................... 397 Output tax ...... 110, 114, 124, 137, 177, 184, 236 down payments ................................................ 239 Output type ............................................................. 171 Outsourcing ............................................................ 384 Overhead cost controlling ................................ 369

P Pan-European Public Procurement OnLine (Peppol) network ................................. 80 Parallel accounting ............................................... 296 Parallel currencies ................................................... 33 Parallel ledgers ....................................................... 297 Parallel valuation .................................................. 360 Partner country ..................................................... 442 assign .................................................................... 442 exceptions for conversion ............................ 443 Partner solution ....................................................... 39 Partner type ............................................................ 199 Partnership .............................................................. 312 Payer ....................................................... 146, 149, 152 no VAT ID ............................................................ 156 Payment ................................................................... 381 PDF output .............................................................. 170 Periodic billing ............................................. 240, 241 billing plan .......................................................... 244 Periodic tax return ............................................... 109 Periodic transaction controls (PTC) .......... 80, 81

Periodicity ............................................................... 400 Permanent establishment abroad ................ 311 Place of delivery .................................................... 452 Planning .......................................................... 294, 340 scenarios ............................................................. 341 Plant ......... 119, 141, 179, 209, 227, 287, 455, 463 assign customer data .................................... 228 assign to supplier ............................................ 229 define tax indicators ...................................... 141 requesting ........................................................... 160 supplying ................................................... 164, 231 Plants abroad .......... 119, 120, 127, 180, 189, 234 activate ................................................................ 121 non-EU ................................................................. 124 pricing procedure ............................................ 181 pros and cons .................................................... 120 settings ....................................................... 121, 123 tax procedures .................................................. 105 VAT registration ............................................... 123 Plausibility check ................................................. 421 Poland .......................................................................... 44 Port ............................................................................. 449 Posting date ............................................................ 162 Posting key ....................................................... 99, 104 Posting period variant ....................................... 304 Predictive analytics ............................................. 341 Prefix ......................................................................... 266 Prepare phase ........................................................... 52 Preventive control ............................................... 420 Price condition ...................................................... 362 create .................................................................... 364 Pricing .................................................... 260, 266, 283 carry out new pricing ..................................... 273 conditions ........................................................... 157 date .................................................... 131, 132, 168 discount ............................................................... 246 exchange rate type ......................................... 132 material master ............................................... 359 routines ............................................................... 276 structure ..................................................... 267, 268 tax determination ........................................... 156 transfer pricing ................................................. 352 type ........................................................................ 214 Pricing communication structure ................ 187 add data elements ........................................... 194 Pricing procedure ..................... 157, 175, 176, 180 analysis ................................................................ 210 Canada ................................................................. 470 condition types ........................................ 177, 179 create .................................................................... 181 define .................................................................... 180

483

Index

Pricing procedure (Cont.) document ............................................................ 181 India ...................................................................... 461 intercompany billing ...................................... 226 pricing discounts .............................................. 246 RVAA01 ................................................................. 176 RVAAUS ................................................................ 180 RVWIA1 .............................................. 180, 181, 234 transfer pricing ....................................... 361, 364 US ................................................................. 468–470 Print control ........................................................... 397 Print type ................................................................. 179 Priority rule ............................................................. 149 examples ............................................................. 152 Private vendor ....................................................... 202 Procedure ................................................................. 447 returns to supplier ........................................... 451 Process expert ........................................................... 28 Processing layer ..................................................... 257 Procurement ................................................. 160, 204 Procure-to-pay .......... 58, 160, 175, 288, 416, 422 example ............................................................... 161 WHT ....................................................................... 316 Profit allocation ........................................................ 88 Profit and loss (P&L) ......................... 360, 365, 369 accounts .............................................................. 314 Profit markup ......................................................... 360 Profit split ................................................................ 363 Profitability analysis ........................................... 178 custom characteristics ......................... 367–369 Program .................................................................... 265 flow logic ............................................................. 266 MV45AFZB ........................................................... 273 MV45AFZZ ........................................ 266, 267, 269 print output ........................................................ 172 RFIMPNBS ........................................................... 130 RFTBFF00 ............................................................ 130 RV60AFZZ ................................................. 266, 274 V05EZZAG ........................................................... 151 V05EZZRG ........................................................... 151 Program of Social Integration (PIS)/ Contribution for the Financing of Social Security (COFINS) ................................... 67 Proof of delivery .................................................... 226 Provider of information ..................................... 453 Provisions report .................................................. 353 Public interest ........................................................... 71 Puerto Rico ................................................................. 39 Purchase contract ................................................. 200 Purchase info record ................................. 199, 283 create .................................................................... 199 tables ..................................................................... 284

484

Purchase order ................................... 160, 200, 381 create ..................................................................... 222 document types ................................................. 229 nonmaintaining materials ........................... 203 reference ............................................................... 224 Purchase requisition ............... 160, 200, 222, 223 Purchasing ............................................................... 160 access sequences ............................................... 184 BAdIs ...................................................................... 262 basic settings ...................................................... 133 condition records .............................................. 189 condition tables ...................................... 188, 190 condition types .................................................. 181 customer exits ................................................... 280 customizing scenarios .................................... 202 default values ..................................................... 450 indirect tax determination ........................... 198 organizations ..................................................... 119 pricing procedures ........................................... 176 SAP Ariba ............................................................. 205 tax determination parameters ................... 289 tax indicator examples .................................. 143

Q Query .......................................................................... 338

R Realize phase ............................................................. 52 Reallocation ............................................................... 89 Real-time analysis ....................................... 329, 425 Real-time reporting ............... 19, 45, 81, 110, 380 model ....................................................................... 84 Rebate ........................................................................ 246 Recapitulative statement ..................................... 81 Receipt ....................................................................... 452 declaration level ............................................... 455 run report ............................................................ 456 type ......................................................................... 451 Receiver ..................................................................... 370 Reconciliation account ....................................... 236 link .......................................................................... 236 Record-to-report ............................................ 60, 420 Recurrence ............................................................... 432 Recurring cost ........................................................... 30 Redetermination ................................................... 273 Reduced rate product .......................................... 140 Refund ......................................................................... 79 Region ........................................................................ 444 conversion ........................................................... 445

Index

Registration for Indirect Taxation Abroad (RITA) ....................................................... 42 Regulation .................................................................. 83 Remote function call (RFC) interface ............... 39 Report ........................................................................ 261 categories .................................................. 400, 402 RFASLD20 ............................................................ 395 RFASLM00 .......................................................... 397 RFBILA00 ............................................................ 375 RFUMSV00 ............................ 120, 126, 261, 386 RFUMSV10 .......................................................... 393 RV80GHEN ......................................................... 277 transfer pricing ................................................. 354 Reporting ................................ 45, 57, 109, 260, 379 BEPS .......................................................................... 87 compliance ......................................................... 398 compliance models ......................................... 384 country ....................................................... 113, 125 date ........................................................................ 162 digital requirements .......................................... 80 direct tax ................................................... 293, 332 EC Sales List ........................................................ 407 entities .................................................................. 401 financial .................................................................. 93 Intrastat ............................................................... 441 maturity ............................................................... 381 standard .............................................................. 385 standard requirements ..................................... 76 tax requirements ................................................. 93 transfer pricing ....................................... 354, 371 worldwide requirements ............................... 379 Reporting & Simulation app ............................ 373 Repository browser .............................................. 255 Requirement ................................................. 179, 197 Requirements gathering ....................................... 52 Resale price .................................................... 358, 361 method ................................................................. 351 Resale-minus method ............................... 358, 361 Residence ................................................................. 225 country ................................................................. 155 Return type ............................................................. 451 Returns to supplier .............................................. 451 Reverse charge ............................. 63, 111, 137, 138 RISE with SAP ............................................................. 27 Risk ................................................ 414, 421, 423, 424 analysis ................................................................ 417 assessments .............................................. 419, 422 management ........................................................ 21 reporting .............................................................. 353 Rounding rule .............................................. 101, 183 Routine ........................................................... 197, 276 activate ................................................................ 277

Routine profit ........................................................... 89 Routing ..................................................................... 204 in ............................................................................ 323 out ......................................................................... 323 Run Advanced Compliance Reports app .... 340 Run Compliance Reports app ............................. 31 Run Compliance Scenario app ............... 329, 434 Run phase ................................................................... 54

S Sales and distribution ........................................ 163 access sequences .............................................. 184 BAdIs ..................................................................... 263 basic settings ..................................................... 133 condition records ............................................. 189 condition tables ...................................... 188, 190 condition types ................................................. 181 customizing scenarios ................................... 215 dates ..................................................................... 166 exchange rates ................................................. 131 indirect tax determination .......................... 208 material tax classification ........................... 134 ODN ....................................................................... 464 pricing procedures .......................................... 176 tax determination parameters .................. 280 transfer pricing ................................................. 362 user exits ............................................................. 266 WHT ............................................................. 102, 170 Sales and service tax (SST) ................................... 66 Sales area ................................................................. 180 Sales document type ........................................... 131 Sales list ....................................................................... 79 Sales order ............................................ 163, 208, 245 addresses ............................................................. 209 create .................................................................... 221 invoices ................................................................ 212 user exits ............................................................. 267 Sales organization ....................................... 119, 180 Sales tax ..................................................... 65, 70, 467 group .................................................................... 391 SAP Activate ....................................................... 26, 51 SAP Analytics Cloud ................ 331, 340, 372, 425 connect tax data .............................................. 343 create a story ..................................................... 342 implement tax scenarios .............................. 344 tax forecasting ................................................. 345 tax monitoring ................................................. 346 SAP Application Interface Framework ................................................ 410–412 SAP Ariba ................................................................. 205 SAP Ariba Contracts ............................................ 206

485

Index

SAP Ariba Discount Management ................. 206 SAP Ariba Invoice Management ..................... 206 SAP Ariba Sourcing .............................................. 205 SAP Ariba Spend Analysis .................................. 206 SAP Ariba Supplier Lifecycle and Performance ...................................................... 206 SAP Ariba Supply Chain Collaboration for Buyers ............................................................ 205 SAP Business Technology Platform (SAP BTP) ................................................... 253, 409 SAP Business Warehouse (SAP BW) ............... 425 SAP BW/4HANA ........................................... 371, 426 SAP Cloud Integration for data services ...... 253 SAP Concur .............................................................. 207 SAP CoPilot ................................................................. 32 SAP Document and Reporting Compliance ............ 31, 45, 293, 337, 384, 398, 408, 460 create a report ................................................... 337 document definition ....................................... 338 features ................................................................... 46 parameters ......................................................... 338 queries .................................................................. 338 run report ............................................................ 340 set up ..................................................................... 398 SAP ERP ........................................................................ 49 SAP Fiori ...................................................................... 31 SAP Fiori apps reference library ...................... 329 SAP Fiori launchpad ................................................ 31 SAP Global Trade Services (SAP GTS) ..... 31, 458 SAP HANA ............................. 23, 32, 37, 44, 49, 370 SAP Integration Suite ................ 39, 253, 254, 409 SAP Localization Hub, tax service .................. 253 SAP Profitability and Performance Management ........................ 333, 363, 369, 372 process activities .............................................. 333 tax reporting elements .................................. 334 SAP S/4HANA ................ 17, 21, 23, 30, 47, 50, 97, 254, 292 business processes ...................................... 55, 58 CDS ......................................................................... 328 chain transactions ................................. 219, 220 company codes ................................................. 310 database table ...................................................... 32 deployment options ........................................... 47 embedded analytics .............................. 329, 424 extensibility .............................................. 366, 368 implementation projects .................. 22, 28, 51 ledgers ........................................................ 297, 305 migration ............................................................... 47 migration strategies .......................................... 48 monitoring ......................................................... 413

486

SAP S/4HANA (Cont.) on-premise ............................................................ 47 reporting .......................................... 332, 379, 385 simplification list ................................................ 30 solution grouping ............................................... 37 special payment processes ........................... 235 tax capabilities .................................................... 36 tax data management ..................................... 25 tax determination .............................................. 38 tax operating model ......................................... 22 tax processes ........................................................ 26 time dependency ................................................. 40 transfer pricing .................................................. 371 WHT ....................................................................... 317 SAP S/4HANA Cloud ............. 40–42, 47, 231, 254 extensibility ........................................................ 368 SAP S/4HANA Cloud, private edition .............. 47 SAP solutions for global tax management ................................................. 36, 37 SAP Tax Compliance ............ 29, 37, 44, 293, 328, 418, 426, 429 access tax-relevant data ................................ 428 add-on ................................................................... 428 applications ........................................................ 328 navigation ............................................................. 44 versus embedded analytics .......................... 331 SAP tax data model .................................... 421, 429 Scalability ................................................................. 259 Schedule line category ........................................ 222 Second entrepreneur ................................. 219, 220 Segmented business margin reporting ........ 353 Segmented tax margin reporting ................... 353 Selective data transition ....................................... 49 Self-billing ................................................................ 246 Self-supply .................................................................. 70 Seller privilege tax (SPT) ....................................... 66 Sender ........................................................................ 370 Service tax ................................................................ 111 Shipping .................................................................... 232 condition .............................................................. 216 Ship-to address ................................... 209, 215, 227 Ship-to party .............................. 145, 149, 209, 219 VAT ID ................................................................... 152 Sidecar approach ................................................... 428 Simplification list .................................................... 30 Simulation ........................................... 354, 371, 372 Single entity principle ......................................... 229 Sixth Directive .......................................................... 63 Smart forms ............................................................. 170 display ................................................................... 170 Social security ........................................................... 71

Index

Sold-to party .............................. 145, 149, 209, 219 VAT ID ................................................................... 153 Source currency ..................................................... 128 Spacing ...................................................................... 265 Special general ledger indicator ...................... 237 Spend management ............................................ 206 Standard Audit File for Tax (SAF-T) .... 19, 81, 91, 293, 400, 460 Standard dimension ............................................ 365 Standard ledger ........................................... 297, 299 overview ............................................................... 299 Standard rate product ......................................... 139 Standard setup ....................................................... 252 Standardization ................................................ 23, 84 State GST (SGST) .................................................... 461 Statement ................................................................ 265 Statutory reporting ................................ 45, 57, 398 Statutory-to-tax adjustment ............................ 307 account split ....................................................... 308 approve and post ............................................. 309 create rules ......................................................... 308 profit impact ...................................................... 309 Step ............................................................................. 176 Stock transfer ............................................... 180, 227 billing scenarios ................................................ 234 India ...................................................................... 463 intra-community in EU .................................. 234 item categories ................................................. 229 legal entities ....................................................... 229 non-EU .................................................................. 124 transport data ................................................... 452 Stock transport order (STO) .............................. 228 create .................................................................... 231 document types ................................................ 230 outbound deliveries ........................................ 231 Storage location ..................................................... 119 Story ........................................................................... 342 Structure ......................................................... 263, 266 Subject to tax rule .................................................... 90 Subroutine ..................................................... 265, 277 Substituição Tributária (ICMS-ST) ..................... 67 Subtotal ..................................................................... 179 Subtraction method ............................................... 65 Superclass ................................................................ 256 Supplier interaction ............................................. 206 Supplier management ........................................ 205 Supply of goods ........................................................ 68 Supply of services .......................................... 69, 215 Supplying plant ..................................................... 231 Switch-over rule ....................................................... 90 System conversion .................................................. 49

T Table ACDOCA ....................................................... 32, 366 BKPF ......................................................................... 33 BSEG ...................................................................... 394 BSET ...................................................................... 387 EINA ...................................................................... 284 EINE ....................................................................... 284 EKKO ..................................................................... 284 EKPO ..................................................................... 284 KNA1 ...................................................................... 284 KNV1 ...................................................................... 273 KNVL ..................................................................... 271 KOMK ................................................................... 194 KOMP ................................................................... 194 LFA1 ....................................................................... 284 MATDOC ................................................................ 33 SKA1 ....................................................................... 316 T004 ...................................................................... 315 T005 ............................................................. 279, 443 VBAK .................................................. 266, 271, 273 VBAP ............................................................ 266, 271 VBPA ..................................................................... 266 XVBAK .................................................................. 266 YVBAK .................................................................. 267 Task list ..................................................................... 431 create .................................................................... 435 manage ................................................................ 437 Task template ......................................................... 436 Tax account ..................................... 26, 94, 113, 116 assign tax categories ..................................... 116 assign tax codes ............................................... 118 chart of accounts ............................................. 315 descriptions ........................................................ 315 types ...................................................................... 313 VAT ........................................................................ 118 Tax administration ....................... 83, 87, 380, 414 Tax advisor ................................................................. 28 Tax amount ..................................................... 25, 201 Tax audit ........................................ 91, 292, 295, 380 ensure readiness ................................................. 92 Tax authority ............ 65, 77, 80, 84, 91, 353, 380, 381, 409, 413, 416 Tax balance sheet ................................................. 296 single source of truth ..................................... 297 versus commercial .......................................... 301 Tax box structure ................................................. 404 Tax calculation ......................................................... 38 external .................................................................. 39 time-dependent ............................................ 40–42 Tax calendar ........................................................... 400

487

Index

Tax category ......................................... 116, 157, 236 assign to countries .......................................... 157 pricing procedures ........................................... 157 tax codes .............................................................. 117 Tax classification ................................. 34, 133, 260 condition table .................................................. 186 customer .............. 137, 164, 208, 272, 284–286 examples ............................................................. 139 material ......................... 133, 209, 217, 270, 274 overwrite ............................................................. 274 Tax code ............................................ 26, 97, 116, 187 assign multiple .................................................. 118 availability .......................................................... 260 basic WHT .............................................................. 98 central repository ................................................ 50 deletion ................................................................... 42 design .................................................................... 109 EC Sales/Purchase List ................................... 459 enter chart of accounts .................................. 113 EU ........................................................................... 113 extended WHT ................................................... 103 foreign ..................................................................... 42 groups ......................................................... 117, 402 inactive ................................................................. 113 indirect tax ......................................................... 109 invoices ................................................................ 201 maintain .............................................................. 110 mapping .................................................... 402, 403 mapping with EDI ............................................ 198 North America ................................................... 466 properties ............................................................ 111 purchase orders ................................................ 201 purchasing organization data .................... 199 reporting countries ......................................... 125 sales orders ......................................................... 211 service tax ........................................................... 111 settings ................................................................. 110 table .......................................................................... 40 target .................................................................... 113 time-dependent .................................... 39, 41, 42 transfer ................................................................. 163 Tax compliance ........................................................ 36 officer ....................................................................... 28 Tax control framework ...... 28, 44, 414, 419, 421 Tax data .................................................................... 134 model ................................................. 341, 421, 429 recording ................................................................ 55 structure ................................................................. 25 warehouse .............................................................. 24 Tax data analytics ....................................... 293, 326 real-time .............................................................. 329

488

Tax data management ................................ 24, 293 business partners ................................................ 34 operational ........................................................... 25 Tax decisions ............................................................. 55 Tax deduction ......................................................... 414 Tax departure country .......... 142, 164, 179, 188, 191, 209, 227, 268 VAT ID ................................................................... 154 Tax destination country ....... 124, 151, 160, 215, 227, 268–270 adapt ........................................................... 215, 217 VAT ID ................................................................... 155 Tax determination .......................... 38, 53, 55, 258 categories ............................................................ 258 customer exits ................................................... 280 direct tax .............................................................. 292 external ................................................................ 254 India ....................................................................... 461 integration .......................................................... 160 matrix ..................................................................... 55 pricing ................................................................... 156 purchasing data ................................................ 289 sales and distribution data ........................... 280 user exits .............................................................. 266 Tax engine ......................... 253, 256, 259, 323, 468 examples .............................................................. 257 layers ..................................................................... 257 Tax exemption ....................................................... 197 Tax filing ................................. 37, 77, 293, 312, 332 Tax forecasting ....................................................... 345 Tax function ................................................ 17, 26, 47 capabilities ............................................................ 36 challenges and requirements ........................ 18 chart of accounts .............................................. 312 digitalization ........................................................ 18 direct tax .............................................................. 291 end-to-end processes ......................................... 55 environment ......................................................... 27 planning ............................................................... 342 realize phase ......................................................... 52 risk management ............................................... 21 tax ledger concept ............................................ 306 tax tagging .......................................................... 323 user interface ........................................................ 31 value creation ...................................................... 20 value drivers ....................................................... 414 Tax gap ........................................................................ 77 Tax group ......................................... 72, 73, 392, 402 assign to tax boxes .......................................... 406 version .................................................................. 402

Index

Tax identification number ............ 145, 164, 169, 208, 286 country-specific checks .................................. 146 determination ................................................... 279 duplicate checks ............................................... 148 maintain .................................................... 146, 148 multiple ................................................................ 464 transfer ................................................................. 163 view in financial accounting ....................... 169 Tax invoice ................................................................. 68 Tax jurisdiction code ........................................... 108 Tax law ...................................................................... 311 Tax ledger .......................................................... 94, 295 balance carryforward ..................................... 304 benefits ................................................................. 306 business operations ........................................ 305 deactivate ........................................................... 300 depreciation areas ........................................... 322 fiscal year variant ............................................ 302 groups ................................................................... 301 lifecycle maintenance .................................... 306 posting period variant ................................... 304 set up ..................................................................... 299 Tax Ledger Hub app ................................... 306, 310 Tax liability ................................................................. 93 Tax lifecycle ................................................... 295, 307 Tax monitoring ................................ 44, 45, 56, 413 indirect tax ......................................................... 424 requirements ...................................................... 417 solutions .............................................................. 418 Tax number category .......................................... 148 Tax number validation ....................................... 202 Tax operating model ............................. 22, 47, 419 business case ......................................................... 29 governance ............................................................ 28 infrastructure and architecture .................... 23 tax data management ...................................... 24 tax processes ......................................................... 26 tax talents .............................................................. 27 Tax payable posting ............................................. 407 Tax planning .............................................................. 57 Tax position account ........................................... 313 Tax procedure ................................................. 98, 110 assign to country ............................................. 105 define .................................................................... 105 indirect tax ......................................................... 105 multiple ................................................................ 108 preassigned ........................................................ 107 without plants abroad ................................... 105 Tax process ......................................................... 26, 55 Tax rate ............................... 39, 41, 86, 99, 110, 463 changes ................................................................... 41

Tax rate (Cont.) indirect ................................................................. 109 maintain ............................................................. 334 minimum ............................................................... 90 retroactive maintenance ................................. 42 validity periods .................................................... 41 Tax record evidence ............................................ 383 Tax reporting ............................. 20, 24, 45, 57, 379 compliance models ......................................... 384 country ................................................................ 126 date ....................................................................... 388 indirect .................................................................... 42 maturity .............................................................. 381 standard .............................................................. 385 worldwide requirements ............................... 379 Tax reporting date ...................................... 114, 162 determine ............................................................ 115 Tax requirement ........................................ 25, 26, 55 Tax return ......................................................... 78, 312 annual .................................................................. 295 monthly ............................................................... 391 Tax rule ..................................................................... 309 Tax service .............................................................. 253 calculate taxes .................................................. 255 extend .................................................................. 256 Tax solution grouping ........................................... 37 Tax subject .............................................................. 311 Tax tagging ................................... 94, 315, 320, 322 detect WHT transactions .............................. 324 standardize postings ...................................... 323 steps ...................................................................... 323 Tax talent .................................................................... 27 Tax technology hybrid .......................................... 28 Tax template ............................................................. 50 Tax transfer price ................................................. 350 documentation ................................................. 354 segmentation .................................................... 353 Tax type ............................................. 24, 36, 112, 199 end-to-end processes ......................................... 26 lifecycles ................................................................. 27 North America .................................................. 468 Tax validation ........................................................... 33 Tax valuation area ............................................... 322 Taxable event .................................... 68, 70, 76, 323 Taxable profit ............................................................ 86 Taxing rights ............................................................. 88 Taxpayer ......................................................... 380, 381 Tax-sensitized account ...................................... 314 Teamwork ................................................................ 415 Template approach ................................................. 50 Template transaction matrix ............................. 50 Testing ...................................................... 53, 354, 373

489

Index

Third entrepreneur .................................... 219, 225 Third-party order .................................................. 221 Third-party process .............................................. 220 Thomson Reuters ONESOURCE Determination .................................................. 258 Till fiscalization ..................................................... 381 Time dependency .................................................... 40 activate ................................................................... 41 Time-dependent tax ............................................ 109 TKOMK structure .................................................. 266 TKOMP structure .................................................. 266 Tolerance .................................................................. 113 Tooling ......................................................................... 75 Transaction /ECRS/POI_EDIT ............................................... 453 /ECRS/RP_EDIT ................................................. 457 BP ........................................ 35, 137, 145, 202, 228 CA03 ...................................................................... 359 CK11N ..................................................................... 360 CK13N .................................................................... 360 CK40N ................................................................... 360 CMOD ................................................................... 281 CS01 ....................................................................... 248 CS03 ....................................................................... 359 DMEE ..................................................................... 394 EDOC_BACKGROUND .................................... 409 EDOC_COCKPIT ............................. 408, 409, 411 EDOC_COMPLETE ............................................ 409 EDOC_INBOUND_MSG .................................. 408 EDOC_INBOUND_UPLOAD ......................... 409 EDOC_SUMMARY ............................................ 409 F-29 ........................................................................ 238 F-37 ......................................................................... 237 FAGLGVTR ........................................................... 304 FB01 ....................................................................... 353 FB03 .................................................... 162, 163, 169 FB50L ........................................................... 301, 323 FB60L .................................................................... 324 FC10 ....................................................................... 375 FINSC_LEDGER .................................................. 127 FK03 .......................................................................... 35 FOTV ................................................................. 40, 57 FS00 ............................................................ 116, 236 FTXP .................................................... 110, 166, 461 FV11 .............................................................. 463, 467 FV12 .............................................................. 469, 471 GGB0 ..................................................................... 368 GGB1 ...................................................................... 368 KEA5 ...................................................................... 367 KEDR ............................................................ 367, 368 M/03 ...................................................................... 190 M/06 ..................................................................... 181

490

Transaction (Cont.) M/07 ...................................................................... 184 M/08 ...................................................................... 176 ME11 ....................................................................... 199 ME12 ....................................................................... 199 ME21N ....................................... 200, 222, 231, 353 ME31K .................................................................... 200 ME51N .................................................................... 200 MEIS ....................................................................... 456 MEK1 .................................................. 189, 463, 467 MIRO ......................................... 162, 163, 201, 224 MM02 .......................................................... 134, 136 MMBE .................................................................... 234 NACE ...................................................................... 171 OB07 ...................................................................... 130 OB08 ...................................................................... 129 OB22 ....................................................................... 127 OBC8 ...................................................................... 116 OBCD ..................................................................... 198 OBCG ..................................................................... 403 OBCH ..................................................................... 404 OBQ1 ...................................................................... 462 OBQ2 ...................................................................... 463 OBXR ...................................................................... 236 OBY6 ............................................................ 114, 121 OMKA .................................................................... 196 OMKL ..................................................................... 142 OMKM ................................................................... 141 OMKN .................................................................... 141 OMKO .................................................................... 142 OVX6 ............................................................ 135, 137 OXK3 ...................................................................... 366 S_AC0_52000644 ............................................. 113 S_ALR_87012357 ................................................ 386 S_ALR_87012400 .................................... 397, 459 SCFD_EUI ............................................................. 367 SE11 .................................. 191, 194, 195, 270, 367 SE16 ....................................................... 25, 312, 315 SE16N ..................................................................... 316 SE19 ........................................................................ 116 SE24 ........................................................................ 256 SE37 ........................................................................ 265 SE80 ....................................................................... 255 SM30 ...................... 114, 116, 148, 442, 447, 464 SMARTFORMS .................................................... 170 SMOD .......................................................... 281, 282 SPRO ..... 98, 180, 213, 294, 399, 442, 463, 465 V/03 ....................................................................... 190 V/06 ................................................... 132, 168, 181 V/07 ....................................................................... 184 V/08 ............................................................. 176, 361 VA01 ................................ 208, 209, 221, 245, 352

Index

Transaction (Cont.) VA02 ...................................................................... 208 VA03 ...................................................................... 208 VA41 ....................................................................... 244 VE01 ....................................................................... 455 VF01 ............................................................. 212, 224 VF02 ...................................................................... 212 VF03 ............................................................. 172, 212 VK11 ........................................... 189, 364, 463, 467 VK12 ....................................................................... 468 VL10B .................................................................... 232 VL31N .................................................................... 224 VOFM .......................................................... 197, 276 VOV7 ...................................................................... 124 VTFA ...................................................................... 213 VTFL ....................................................................... 213 XD02 ............................................................ 137, 146 XK02 ...................................................................... 144 Transaction currency .......................................... 128 Transaction data screening .............................. 326 Transaction group ................................................ 366 Transaction matrix .............................................. 374 Transaction processing ...................................... 352 Transaction tag ...................................................... 366 Transaction type ..................................... 25, 74, 320 Transactional net margin method (TNMM) ................................................................ 352 Transactional profit split method .................. 352 Transaction-based reporting (TBR) ........... 79, 80 Transfer pricing ....................................... 22, 33, 349 alerts and reports ............................................. 353 calculate prices ................................................. 352 calculation .......................................................... 357 challenges ........................................................... 355 derivation ............................................................ 368 determination ................................................... 364 dimensions ......................................................... 365 documentation ....................................... 354, 373 indirect cost allocation .................................. 369 management ..................................................... 350 monitoring ......................................................... 364 operational ............................................... 349, 350 planning .............................................................. 351 process .................................................................. 351 reporting .............................................................. 371 requirements ...................................................... 356 tax .......................................................................... 350 testing ................................................................... 373 Translation date .................................................... 128 Transport code ....................................................... 448 Transport data .............................................. 451, 452 Transport responsibility .......................... 216, 225

Tree type .................................................................. 394 Trial balance .............................................................. 33 Triangulation simplification ........................... 220 True-up ..................................................................... 295 report .................................................................... 353

U Undertaxed payments rule ................................. 90 Union territory tax (UTGST) ............................ 461 United States .............................. 39, 65, 70, 75, 465 tax types .............................................................. 468 Universal Journal ........................................... 32, 365 extend .................................................................. 365 Update run .............................................................. 389 Use tax ......................................................................... 66 User exit ....................................... 262, 266, 323, 324 invoices ................................................................ 274 sales orders ........................................................ 267 USEREXIT_MOVE_FIELD_TO_ VBAK/VBAP ................................................... 271 USEREXIT_NEW_PRICING ............................ 273 USEREXIT_NUMBER_RANGE ...................... 275 USEREXIT_PRICING_PREPARE_ TKOMK ................................................... 267, 274 USEREXIT_PRICING_PREPARE_ TKOMP ................................................... 268, 270 VAT ID determination ................................... 151 User interface ............................................................ 31

V Validation routine ............................................... 151 Validation/Substitution tool ........................... 368 Validity period ................................................... 40, 41 Valuation area ....................................................... 322 Valuation variant ................................................. 359 Value contract ....................................................... 244 Value flow ................................................................ 372 Value-added tax (VAT) ... 40, 57, 62, 76, 220, 413 accounts .............................................................. 118 directive .................................................................. 62 examples ............................................................. 143 exempt ................................................................. 234 group settings ................................................... 391 indicator .............................................................. 137 listings ..................................................................... 81 mapping .............................................................. 403 rate change ........................................................ 402 registration ........................................................ 123 returns .................................................................. 391 risk example ...................................................... 422

491

Index

Value-added tax (VAT) (Cont.) standard report ................................................. 385 systems .................................................................... 64 versus GST .............................................................. 64 Value-added tax (VAT) ID ....... 43, 145, 163, 197, 214, 277, 286 check ...................................................................... 197 customer .............................................................. 420 determination ................................................... 149 dummy ................................................................. 148 examples ............................................................. 152 extensions ........................................................... 151 rules ....................................................................... 149 undetermined .................................................... 154 Variable ..................................................................... 263 inline declaration ............................................. 264 VAT Information Exchange System (VIES) .... 43 Vendor invoice ......................................................... 39 Vendor invoice management (VIM) ............. 204 Vendor master record ............................................ 34 Vendor selection ................................................... 258 Vendor withholding tax ..................................... 144 Version control ...................................................... 260 Vertex Indirect Tax O Series ............................. 257 Virtual data model ............................................... 329 V-model ....................................................................... 85

W What-if simulation ............................................... 373 Withholding tax (WHT) ..... 86, 98, 170, 291, 316 basic ............................................................... 98, 317 business partners .............................................. 318 condition type .................................................... 102 country-specific settings ................................ 104 define accounts ......................................... 99, 104 define tax code .......................................... 98, 103 define type ........................................................... 100 determination .................................................... 159 extended .............................................. 94, 100, 317 input side ............................................................. 316 invoice posting .................................................. 101 sales and distribution ..................................... 102 settings ................................................................... 98 tax rate ................................................................... 99 tax tagging .......................................................... 324 tax type ................................................................. 101 vendors ................................................................. 144 Work delivery ........................................................... 76 Work performance .................................................. 76 Work supply .............................................................. 76 Workflow .............................................. 204, 261, 435

Z Z table ..................................................... 269, 274, 288 Zero percent indirect tax ................................... 218

492

Service Pages The following sections contain notes on how you can contact us.

Praise and Criticism We hope that you enjoyed reading this book. If it met your expectations, please do recommend it. If you think there is room for improvement, please get in touch with the editor of the book: [email protected]. We welcome every suggestion for improvement but, of course, also any praise! You can also share your reading experience via Twitter, Facebook, or email.

Technical Issues If you experience technical issues with your e-book or e-book account at SAP PRESS, please feel free to contact our reader service: [email protected].

About Us and Our Program The website http://www.sap-press.com provides detailed and first-hand information on our current publishing program. Here, you can also easily order all of our books and e-books. Information on Rheinwerk Publishing Inc. and additional contact options can also be found at http://www.sap-press.com.

Legal Notes This section contains the detailed and legally binding usage conditions for this e-book.

Copyright Note This publication is protected by copyright in its entirety. All usage and exploitation rights are reserved by the author and Rheinwerk Publishing; in particular the right of reproduction and the right of distribution, be it in printed or electronic form. © 2022 by Rheinwerk Publishing, Inc., Boston (MA)

i

Your Rights as a User You are entitled to use this e-book for personal purposes only. In particular, you may print the e-book for personal use or copy it as long as you store this copy on a device that is solely and personally used by yourself. You are not entitled to any other usage or exploitation. In particular, it is not permitted to forward electronic or printed copies to third parties. Furthermore, it is not permitted to distribute the e-book on the Internet, in intranets, or in any other way or make it available to third parties. Any public exhibition, other publication, or any reproduction of the e-book beyond personal use are expressly prohibited. The aforementioned does not only apply to the e-book in its entirety but also to parts thereof (e.g., charts, pictures, tables, sections of text). Copyright notes, brands, and other legal reservations as well as the digital watermark may not be removed from the e-book.

Digital Watermark This e-book copy contains a digital watermark, a signature that indicates which person may use this copy. If you, dear reader, are not this person, you are violating the copyright. So please refrain from using this e-book and inform us about this violation. A brief email to [email protected] is sufficient. Thank you!

Trademarks The common names, trade names, descriptions of goods, and so on used in this publication may be trademarks without special identification and subject to legal regulations as such. All of the screenshots and graphics reproduced in this book are subject to copyright © SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany. SAP, ABAP, ASAP, Concur Hipmunk, Duet, Duet Enterprise, ExpenseIt, SAP ActiveAttention, SAP Adaptive Server Enterprise, SAP Advantage Database Server, SAP ArchiveLink, SAP Ariba, SAP Business ByDesign, SAP Business Explorer (SAP BEx), SAP BusinessObjects, SAP BusinessObjects Explorer, SAP BusinessObjects Web Intelligence, SAP Business One, SAP Business Workflow, SAP BW/4HANA, SAP C/4HANA, SAP Concur, SAP Crystal Reports, SAP EarlyWatch, SAP Fieldglass, SAP Fiori, SAP Global Trade Services (SAP GTS), SAP GoingLive, SAP HANA, SAP Jam, SAP Leonardo, SAP Lumira, SAP MaxDB, SAP NetWeaver, SAP PartnerEdge, SAPPHIRE NOW, SAP PowerBuilder, SAP PowerDesigner, SAP R/2, SAP R/3, SAP Replication Server, SAP Roambi, SAP S/4HANA, SAP S/4HANA Cloud, SAP SQL Anywhere, SAP Strategic Enterprise Management (SAP SEM), SAP SuccessFactors, SAP Vora, TripIt, and Qualtrics are registered or unregistered trademarks of SAP SE, Walldorf, Germany.

ii

Limitation of Liability Regardless of the care that has been taken in creating texts, figures, and programs, neither the publisher nor the author, editor, or translator assume any legal responsibility or any liability for possible errors and their consequences.

iii