Skip to Content
Author's profile photo Christophe Compain

Leveraging Master Data in SAP TRM for best-run tax processes – Part I

A good definition of the master data architecture in TRM/PSCD is key to benefit from SAP standard functionalities.This blog post describes how TRM/PSCD master data can be used to represent real-life tax-related events.

In part I of this blog post, we will focus on the birth of the tax obligations and how to represent them in SAP TRM/PSCD.

First a short reminder of master data in SAP TRM/PSCD

The business partner master data stores information related to the taxpayer’ name and addresses, identification numbers, bank account details, etc.

The contract account stores parameters related to the tax type, such as payment methods, dunning procedure, interest calculation. Master data on the CA are derived from customizing and are identical for all business partners. However, they can be changed and adapted when required for each business partner specifically.

The contract object stores two types of parameters: parameters related to the object itself (such as the type of engine for a vehicle) and parameters that are specific to its relationship with the BP (for instance a dedicated bank account for tax collection).


We’ll be dealing with the following tax types: personal income tax, corporate income tax, and vehicle tax.

Typically personal income tax (as well as corporate income tax) is a form-based tax type (FBT) initiated by the taxpayer: he or she has to file a tax return to the tax authority, that processes her/his tax assessment and sends her/him a tax notice.

On the other hand vehicle tax is an object-based tax type (OBT) initiated by the tax authority: tax calculation is done on a recurrent basis by the tax authority, and a tax notice is sent out to the taxpayer.


The timeline and the figure below describe the key events of our example:



When a man…

Meet John Adam: he turned 18 years old in 2012 and registered to the Personal Income Tax (PIT) at the Tax authority of his country.

John is created as a business partner (BP). One contract account (CA) of type PIT and one contract object (CO) of type “Fiscal Id” are also created and assigned to him. A tax obligation (TOBL) is also created: it defines the periodicity and the validity dates of the tax obligation of a business partner for a specific tax type on a specific contract object. In our example, John Adam is an annual PIT taxpayer from 02.11.2012.

The Taxpayer Overview transaction displays as follows:

Remark: registration is supported in standard SAP TRM by a registration form bundle.

… meets a woman

Now meet Jane Doe, she also turned 18 years on the same year as John and she has registered to PIT as well. She also got her driving license and bought a second-hand car. She is then registered to the Vehicle tax (VHT).

In our example, Jane Doe is a PIT taxpayer from 29.10.2012 and a VHT taxpayer from 19.12.2012.

Both types of taxes are supported in SAP TRM/PSCD. A contract object is required to support inbound correspondence management in FBT (invitation to file sent by the tax authority to the taxpayers) or store tax-specific data for tax calculation in OBT.

The Taxpayer Overview transaction displays Jane Doe as follows:

The screenshot below depicts the user interface of the tax agent to process the PIT submission of Jane Doe:

Remark: In our VHT example we only consider one car but Jane could have several cars, each one represented by a contract object, and each linked to the same one and only contract account.

For the sake of simplicity, we consider that due amounts resulting from tax assessment are posted on the existing triplet BP-CA-CO. It is wise to consider the creation of a specific contract object for each yearly tax assessment, especially in consideration of the interest calculation rules on overdue amounts that may be applied by the tax authority.

Let’s get married!

Jane and John then meet and it’s love at first sight. They get married early on the 21st of May 2013.

Jane and John are defined as “individual” business partners. This means that fields like “date of birth”, “gender” or “date of death” are available for entry.

A business partner of type “group” is created to represent the household, it represents a group of business partners or a group entity in itself. A contract account and a contract object are created to support the joint PIT assessment process. A tax obligation is defined to set the start of the tax obligation of the household from 21.05.2013. Finally, an end date is set to 20.05.2013 on the tax obligation on each individual PIT taxpayer (Jane and John). In addition to the tax obligation, a business partner relationship is set between each member of the household and the household itself. This BP relationship has a start validity date on the 21.05.2013. The BP relationship is used to track the history of the business partners. It can also be used to track fraud by allowing crosschecks between related business partners’ tax returns.

First, the tax obligation is ended on the 20th May 2013 for both John and Jane on their respective PIT tax obligation.

Note the facts that

  • An end date has been set on the tax obligation for PIT
  • The validity dates of the tax returns for 2012 and 2013 has been adapted as well


The VHT on Jane’s car remains her sole responsibility and no change is done to his tax obligation.

The Taxpayer Overview transaction displays the happy couple as follows:

Tab “Relationship” provides the link between the two individual business partners


Jane is an entrepreneur and starts a new business

Jane has decided to start her own business. She has then registered a limited liability business to the tax authority on September 21st, 2013. Her company has to pay corporate income tax (CIT) annually and sales and use tax  (SUT) monthly.


A new business partner is created for the company “Jane’s Sushi shop” with contract accounts, contract objects, and tax obligations. Periodicity and validity start date are also maintained on the tax obligations. A business partner relationship is set between the owner Jane and her small business with a start date on 21.09.2013. Additional information can also be stored at the level of the BP relationship next to the validity dates. For instance, between two individual business partners the type of marital union could be specified (marriage, partnership,…)


The Taxpayer Overview transaction displays all the tax obligations of Jane:

Jane’s relationships are updated as well

Trustees and tax advisors of taxpayers are also represented with business partner relationships.

The tax officer is then able to process tax submission of corporate income tax from the Taxpayer Overview as well:

 So far we demonstrated that each life event of taxpayers can easily be represented in SAP TRM.

In part II, we will elaborate on the end of the tax obligations i.e.

  • Death of a joint filer
    • Estate is subject to collaborative liability
  • The divorce of two joint filers

We will also introduce the enforced recovery processes and the  “tax record” assigned to each taxpayer.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi Christophe,

      Thank you for this interesting blog.

      Excellent presentation of the SAP master data model for tax payer.

      Looking forward for the part II.




      Author's profile photo Paul Morgan
      Paul Morgan

      Hi Christophe,

      Nice blog. Perhaps in part 2 you could elaborate on a few things? I am wondering what the benefit is of having a group to represent a household and why having a contract object for each yearly tax assessment is suggested?





      Author's profile photo Christophe Compain
      Christophe Compain
      Blog Post Author


      Hi Paul,

      Thank you for your feedback and sorry for the late reply.

      Regarding the benefit of having a group to represent the household: basically the question is what other choice do we have? In some countries like Switzerland, when a man and a woman get married, the woman’s revenue is incorporated in the tax return of his husband. The “joint filer” feature in SAP TRM can support this requirement to some extent. In general, I can think of the following advantages of using a group BP: first, it will help to track the lifecycle of a taxpayer. For instance, if one person gets married then divorces than gets married again then divorces again, especially in a very short time frame, you can more easily track his/her tax lifecycle with different BPs and BP relationships (single = individual BP, married = group BP). Second, each tax-related open item (for personal Income tax for instance) is clearly assigned to the right person (or group of persons) that are liable for the payment of this open item at a certain point in time, facilitating the recovery process.

      Regarding the contract object for each yearly tax assessment: It is all based on the fact that it is easier to group items that are separated than to sort items in subgroups depending on criteria. Although not mandatory, it brings clarity to the account balance of the taxpayer. Basically, one contract object is used as the source of information for functional processing (enhanced inbound correspondence for submissions of tax returns,…) and each yearly contract object groups all posting related to the corresponding yearly assessment (liability, additional dunning charges, interest charges). You will certainly argue that the period key supports the segregation of the fiscal year, which is true. As always it all depends on the requirements of the customer, but I would definitely consider this approach and check its adequacy.

      Kind regards,


      Author's profile photo Min Gao
      Min Gao

      Hello Christophe

      well written piece and very helpful for me. I am looking forward for the part II which you mentioned will cover co-liability. Will it use group BP concept?

      thank you in advance

      Author's profile photo Christophe Compain
      Christophe Compain
      Blog Post Author

      Hi Min,

      thank you for your comment! I definitely have to write this next blog on co-liability. In the meantime, you can refer to the SAP Help URL below, where the concept of co-debtors is explained.



      Author's profile photo Ramky Prabhakar
      Ramky Prabhakar

      Hi Christophe,

      Nice blog, please guide me how to get learning plan in TRM module.



      Author's profile photo Christophe Compain
      Christophe Compain
      Blog Post Author

      Hi Prabha,

      thank you, I would recommend following IPS510 for PSCD and IPS520 for TRM.

      Kind regards,