more than you ever wanted to know about SAP Payroll taxes

Business Term	SAP Term	Definition
Federal Employer ID Number (FEIN)	Tax Company	A legal entity for tax reporting purposes
Tax	Tax Type	The type of tax levied (required to be paid) by a tax authority
Formula	Formula	Instructions for how to calculate a tax amount
Wage Base	Tax Model	A definition of which wages and deductions are considered taxable for specific tax authority and type of tax

Tax Calculation Process

Data Model

Infotypes

Infotype	Title	Description / Notes
207	Resident Tax	This is the tax area where the employee lives. They can only live in one place at a time, and payroll reads this infotype as of the check date.

Infotype	Title	Description / Notes
Infotype	Title	Description / Notes
208	Work Tax	This infotype stores the various tax areas the employee works in – they can work in multiple areas at once, and each is pro-rated by a certain %. The total % can not be more than 100. If it is less than 100, the remainder is allocated to the resident tax area. Payroll reads all the infotype 208’s active during the pay period and pro-rates wages according to each infotype 208 occurrence.

Infotype	Title	Description / Notes
209	Unemployment State	This infotype contains the state and worksite the employee is taxed in for unemployment taxes. For payroll calculations it is read as of the period-end date. If the worksite is filled in then you can use SAP’s Multiple Worksite Reports in Tax Reporter.

Infotype	Title	Description / Notes
210	Withholding Info	This infotype stores the W-4 or state-equivalent information needed for calculating withholding taxes. It is read as of the check date. Various tax authorities use different fields on this infotype, and the available fields change depending on the tax authority entered (which is also the subtype).
	Tax Exempt Indicator codes control which wages & taxes get calculated: X = no taxable wages or taxes; R = don’t take taxes but do report taxable wages; Y = don’t take taxes and don’t calculate reportable or taxable wages. Def. Form.No. is the default formula number SAP will use for the tax – and that can be overridden with the ‘Assign Form.No.’ field. For other fields, select them and press F1 for the SAP help text. This screen layout will change from one tax authority to another.

Infotype	Title	Description / Notes
234	Tax Overrides	This infotype contains various overrides for calculating withholding taxes, and is read as of the check date.
	Supplemental method: Many withholding taxes have an optional flat-rate method that can be used. Some have more than one supplemental method – here we can override the supplemental method for an employee’s paychecks. Override amount: This amount will override any withholding tax amount calculated by the system. Empl. Override group: This is a code created in BSI that defines a custom tax calculation, such as a custom flat-rate for certain bonus payments. The override group has to be created in BSI and then applied here.

Infotype	Title	Description / Notes
235	Other Taxes	This infotype contains overrides for all other taxes than withholding, and is read into payroll as of the period-end date.
	The formula numbers and ‘Exe.’ (exemption indicators) used here serve the same purpose as they do on infotype 210, but for everything except withholding taxes. Infotype 210 is withholding taxes-only, and 235 is for all other tax types.

Configuration of Taxes

IMG – Implementation Guide Steps

Transaction SPRO is used to access the SAP Implementation Guide. The transaction will first display various ‘project IMGs’, press F5 or the Enterprise IMG button to get to the complete IMG structure. Open the Payroll Accounting -> Payroll:

USA

-> Tax section.

If you do not have access to transaction SPRO, you can view the corresponding tables with transaction SE16 (Data Browser).

To get more documentation, double-click on a line’s text. For example, double-click on the ‘Tax’ text line and you get this documentation:

Tax Companies

This is the step where Tax Companies are defined and then assigned to each personnel area/subarea combination. The tax company is not the same as the Company Code (or accounting company) that is seen on infotype 1. In fact, Tax Company does not display on infotype 1. The information entered in the ‘Define tax companies’ (table t5utl) step is used for regulatory tax reporting (Tax Reporter). The screen below shows where Tax Company is assigned to the personnel area/subarea (table t5u0p):

The Tax Company is where taxes & taxable wages are reported for regulatory purposes. The accounting debits & credits go to the Company Code on infotype 1, which may or may not correspond to the Tax Company. For example, this screen shows that taxes and taxable wage are reported to the government under ‘Overseas’, and the description on the personnel area says the accounting goes to Company Code 001.

Each tax company is identified by an employer ID number for every tax authority it reports to. Those employer ID numbers (EIN’s) are entered in the ‘Define tax identification numbers by BSI tax company’ step (t5uth), and then assigned to a tax type within the tax authority in the ‘Define federal/state/local employer ID number’ step (table t5uti). SAP Payroll will not calculate a tax if the corresponding EIN does not exist in these tables.

Load Tax Data

This section is primarily for the first-time system setup, where we copy some data from the BSI Tax Calculation system into SAP tables. It is normally maintained by periodic updates to the system that come from SAP.

Tax Data Maintenance – Tax Authorities

The ‘Check tax authorities’ step (table t5utz) is used to configure certain options for each tax authority. This data is delivered by SAP and normally it is also updated by them as new tax authorities come into existence. You might want to customize some options here to tailor the system to your needs.

The ‘Sort no.’ controls the sequence in which the tax authorities will be displayed in select lists. The ‘W4’ indicator controls whether of not you want to require an infotype 210 for the tax authority, make it optional, or not allow one to exist. The IRS column is to indicate whther of not you want to apply the IRS 10-exemption limit rule to the authority. The ‘NoUS’ column is used to indicate US Territories & Possesions, such as Puerto Rico and the US Virgin Islands. The next IMG steps - ‘Check sort number for authority’, ‘Check W-4 and exemption limit indicators’, and ‘Check status of territories’ are just different views on this same information.

‘Check tax authority mapping’ (table BTXTAXC) is where we map the SAP Tax Authority code to the BSI Tax Authority code. This is normally maintained by SAP and does not require customer maintenance. BSI has its own codes for each tax authority, but lets the customer create whatever codes they want to use. Those customer-defined codes are mapped to the BSI codes here.

Each tax authority can have its own set of valid filing status codes, and these are controlled in the ‘Define valid filings statuses’ step (table t5utk). This data is generally maintained and updated by SAP.

Tax Data Maintenance – Tax Types

Each tax authority can have one of more different types of tax they collect. All the various tax types are defined in this step.

‘Check tax types’ (table t5utt) is a list of all valid tax types, and ‘Maintain tax types per tax authority’ (table t5utd) is where we define which tax types are valid for each authority.

Tax Data Maintenance – Tax Areas

A Tax Area is simply a collection of tax authorities that are applicable to a given location. For example, if you live inside Cincinnati, your tax area would include Cincinnati, Ohio and Federal. SAP assigns tax areas to resident and work locations.

The views for defining tax areas for work and resident locations are very similar. SAP delivers these tax areas with the system, and updates them as new ones come into existence. The ‘Maintain work-related tax areas’ (table t5utb) is where we define valid tax areas for the work location.

For each tax area we define the tax authorities that correspond to it in the ‘Maintain tax authorities per work tax area’ step (table t5utw). So here we see that work tax area AL0H includes tax authorities Alabama and Jefferson.

Resident tax areas are setup in a similar manner, but stored in table t5uta. Likewise, resident tax areas are stored in table t5utr. Resident tax areas have additional functionality that enables the system to suggest a list of tax areas that may be valid for the employee, based on the employee’s zip code. The ‘Maintain zip code ranges per residence tax area’ (table t5utf) specifies a range of zip codes for each tax authority. When a new infotype 207 is created, the system will search this table with the employee’s zip code to get a list of tax areas that might be appropriate for the employee. Although a zip code range exists for work tax areas, there is no other system functionality to support that process (i.e it doesn’t work).

Tax Data Maintenance – Tax Models

The Tax Model is where we define the taxability of wages in SAP Payroll. The ‘model’ is a set of three SAP configuration tables. The first step ‘Define tax authority model’ (table t5ute) is where we associate each tax authority with a two digit model number. The model number is just an arbitrary two digit number that was chosen at the time the system was first setup. If a tax authority changes the way it taxes earnings or deductions, then you would create a new tax model for it, using the effective dates in t5ute.

The second step is ‘Define taxability model’, or table t5utm. In this table we link each taxable wagetype to a tax model. There are four aspects to this link – the resident, work and unemployment taxation of the wagetype, and the taxation for different groups of employees (the tax modifier). The link to the wagetype is via processing class 71 – called the taxability class. For each taxability class we specify if the wagetype is taxable for the tax authority an employee lives in, works in, and for unemployment taxes. These three settings can be customized per tax modifier. For example, we may tax wages for every tax authority for regular employees, but only tax wages for Federal for expatriates. In that case, we put expatriates and regular employees in different tax modifiers, and control the assignment of wagetypes to tax authorities via table t5utm.

The tax modifier is determined in payroll in rule ZUDG (tax schema ZUA2).

Tax Modifiers
Tax Modifier	Employee Group
U1	Domestic employees & other retiree payments
U2	No longer used (was Sundor)
U3	US Expatriates
U4	Retiree stock options (pay types L and S)
U5	No longer used (was Outbound expats)
U6	Never used
U7	Any employee (expat or regular) whose resident tax infotype (208) is set to Puerto Rico

Table t5utm is where we link the tax authority and tax types to the wagetype:

· Tax model: The code for a tax authority, from t5ute

· Res/wrk/UI: R = resident tax, W = work tax, U = unemployment tax

· Tax Modif: The tax modifier for the employee

· Tax Class: The processing class 71 value for the wagetype

· Tax type combination: A code from t5uty that specifies which tax types the wagetype is taxable for

The third step is where we tell SAP which types of tax to use for each row in t5utm. Table t5uty (define tax type combinations) is where we define codes to represent a set of tax types. In t5utm, if a tax class is taxable for a particular combination of resident, work, unemployment and tax modifier, the system then gets the tax type combo value and looks it up in t5uty to see which types of tax to use. This is how SAP knows which /3xx wagetypes it needs to build. For example, tax type combo 06 would tell the system to build wagetypes /303, /304, /305 and /306.

The Tax Model Diagram shows how the tables, infotypes and wagetypes come together to tell the system which /3xx taxable wagetypes to create:

Tax Model Diagram

Useful Reports

SAP has a standard program RPUTMDU0 (HR -> Payroll -> Americas -> USA -> Subsequent activities -> Period independent -> Tools -> Tax utilities -> Expand tax models) that reads the tax model tables and shows which tax types are used for each line of t5utm. There is also a standard report that displays all the tax authorities in the system (Display tax authorities on the Tax Utilities menu, or program RPUAUTU1, or view table t5utz via transaction se16).

Tax Data Maintenance – Unemployment Insurance

Every state in the US collects an unemployment tax to fund unemployment insurance claims. This is an employer-paid tax, so there is not effect on the employee. However, each state has its own tax rate and that tax rate can vary from one company to another in the state. The company-specific tax rate is call the ‘experience rate’ because it’s based on the state’s experience in paying out unemployment claims for employees laid-off from a company. The more people a company lays-off, the higher the experience rate. This experience rate can change every quarter.

Client XXX does not pay unemployment taxes based on what is calculated in SAP. Instead, the total taxable unemployment wages are multiplied by the experience rate outside of SAP when the quarterly unemployment tax returns are filed.

Some states requires companies to report their unemployment wages per physical site within the state – this is called Multiple Worksite Reporting and is controlled via the worksite field on infotype 209. Again, Client XXX does not use SAP for its worksite reporting so that part of the system is not used.

Tax Data Maintenance – Tax Overrides

SAP and BSI allow companies to override certain parts of the tax calculation. Most of the configuration is done is BSI; the one piece of it done in SAP is to define employee override groups. These groups also need to be setup in BSI (Tax Factory). The employee override group can then be entered into infotype 234 or set dynamically in a rule in payroll.

The override groups and rules allow you to override the tax calculation formula so that you can withhold taxes at rates different than the standard ones provided by BSI. This is currently used for some stock option and relocation payments.

Tax Data Maintenance – Symbolic Account Split

SAP gives you an option to post a given tax type to different FI/CO accounts based on which tax authority or tax level (Fed, state, local) it belongs to. For example, Federal taxes are posted to one account, and state/local taxes posted to another. The process is simple – look at every tax wagetype and then copy its contents to another wagetype that is then posted to the correct account. At Client XXX there are three tax-posting wagetypes – 9TAF (Federal), 9TAS (state) and 9TAL (local), generated in rule ZUHF in the tax schema ZUA2.

Priority of Tax Wagetypes

When deducting tax, the system follows a certain order or priority, This is defined in the ‘Maintain priority of tax wagetypes’ step, or table t5us0. Generally there is no need to maintain this table, since it is delivered by SAP to take Federal taxes first, then state, then local. There are other settings in this table to control how taxes are deducted when not enough money is present, and whether or not the tax wagetype is from regular income or tip income.

Tax Wagetypes

Descriptions of tax wagetypes

These wagetypes store the results of tax calculations; other than the wagetypes for employee taxes, they are not really linked to the amount of cash the employee receives.

Wagetype	Description	Explanation	Notes
/3xx	Taxable earnings	This is the amount of earnings (payments) that is taxable for each authority and tax type. It does not include pre-tax deductions.	Some tax authorities require the company top report these wages. Other than that, they are not used in the tax calculation process.
/6xx	Reportable wages	These amounts are the /3xx earnings minus the pre-tax deductions. These amounts are sent to BSI for taxation.	States require companies to report their /610 unemployment wages every quarter.
/7xx	Taxable wages	These are the amounts that are taxed for each authority & tax type. These wages reflect tax caps (i.e. for FICA and unemployment) and reciprocity. The /7xx wagetypes are returned to SAP from BSI.	These amounts are the ones reported on the W-2.
/4xx	Taxes	These amounts are for employee and employer taxes, based on the /7xx wages, as calculated by BSI.	Contains employee-paid and employer-paid taxes (processing class 72 determines this)
/Qxx	Taxable not taxed wages	Certain wages can be reported as taxable, but no tax is required to be taken from them.	Imputed income on group-term life insurance is a good example of a taxable-not-taxed earning.
/Nxx	Uncollected taxes	There are cases where an employee has taxable income, but not enough money to pay for the taxes on it. Instead of /4xx taxes, SAP records the amount of uncollected tax in /Nxx wagetypes. (Taxable wages are not always cash wages).	Uncollected FICA and Medicare taxes will try to balance out in future payrolls, and others do not.
/Ixx	Not reduced wages	In some cases the system is able to deduct a pre-tax deduction but does not have enough taxable income to offset it. The amount of taxable income that could not be offset (i.e. reduced) is stored in the /Ixx wagetypes.	The system will try to reduce wages in the next payroll by these amounts. If an employee has /Ixx wagetypes, then their FICA/Medicare and other flat-rate taxes wont tie back to their /7xx wages (i.e /703 * 6.2% <> /403).

Linking tax wagetypes to other tax data

Each tax wagetype also has a split indicator set, and this links it to the tax authority it is reportable to. For example, we could have two or three /401 wagetypes in a payroll, and the split links us to the TAX table in the payroll result that tells us the tax authority it is reportable to. In the following case we see that a split of ‘01’ links us to Federal in the TAX table, and split ‘02’ links us to OH (this is from the Display Payroll Results tool, or report RPCLSTRU):

RT (Results Table)

The two-digit number in the ‘C1’ column in the RT links us to the ‘SS’ column in the TAX table. So when the C1 split is 01, we know that wagetype is linked to tax authority FED. When C1 is 02, then the wagetype is linked to tax authority OH.

The TAX table also shows us the data used to calculate taxes in that payroll result. For Federal, we see that this person had 13 tax exemptions, filed Married, and this was used for his resident and unemployment tax calculations. If they were exempt from any taxes, we would see that in the ‘Tex indicator’ line – there would be an exemption indicator under each ‘Tax type’ that was exempted.

TAX Table

Gross to Net Wagetypes

These wagetypes control the amount of cash the employee receives. The various wagetypes used to make payments and take deductions all cumulate, or add into these wagetypes. These gross-to-net wagetypes therefore may or may not have anything to do with taxable wages or taxes. They simply keep track of how much money to pay the employee.

Wagetype	Description	Explanation	Notes
/101	Total Gross	This contains all the cash payments to an employee – whether those payments are taxable or not.
/110	Total EE Deductions	All employee deductions that were taken from the employee’s pay for the current pay period.
/5U0	Total EE Taxes	All employee taxes taken from the pay this pay period
/560	Net Pay	The total amount of net pay for the employee.	If the employee deposits their pay into multiple accounts, then there will be a /559 for each account. The sum of /559 equals /560.

Gross-Ups

Cash or Regular Gross-ups

A gross-up is a guaranteed net payment of a taxable wage to the employee. For example, the company wants to pay a $100 award to an employee, and since that is taxable income, the employee owes taxes on it. So we know that is the employee is to get $100 in net pay, we need to have a higher gross, or taxable, amount. This amount is added to taxable income, and when taxes are deducted from it we get back to the original $100 net payment.

In SAP there are two wagetypes for a gross-up – the net wagetype and the gross wagetype. The net wagetype does not really pay anything – it is not cumulated to /101 (Total Gross), so it does not add any cash income to the payroll. And although it is not taxable, it has processing classes 68, 69 and 71 set so that we know what to include in the gross-up. The link between the net and gross wagetype is stored in the ‘1^st der. WT’ field in table t512w; the gross wagetype will be coded into the ‘1^st derived wagetype’ field on the net wagetype.

The gross wagetype does cumulate to /101, and it does add to taxable wages. Once taxes are deducted from the gross, we end up back to the net amount. For example, a $100 net might gross-up to $160. Then SAP would deduct $60 in tax from that, leaving a net pay of $100.

No-pay Gross-ups

Sometimes employees are paid some sort of taxable income outside the system – relocation expenses for example. In that case, we want to increase their taxable income to record that ‘net’ payment that was made to them, but we don’t want to pay them any ‘cash’ money. In these cases SAP can process non-cash, or ‘no-pay’ gross-ups. The net and the gross do not generate any cash payments to the employee, but the gross-up does add to taxable wages.

$100 in the net wagetype. SAP then grosses-up that amount to $160, but the gross-wagetype does not cumulate to /101, so it does not pay anything to the employee. However, we still have $60 in taxes to deduct, so SAP generates a third wagetype, a cash payment, to exactly offset the amount of tax. For a no-pay net it generates $160 in gross, and $60 in a cash payment that equals the $60 in tax. There is a zero net effect on the employee.

In the wagetype table t512w, we see the tax payment wagetype in the ‘2^nd der. WT’ field. In this case, the net is 270E, the gross is 270F and the tax payment is 270G.

For a $100 no-pay gross-up, we enter the net wagetype and then the system generates the gross and the tax payment when payroll runs.

Period 1 in 1
Wagetype	Description	Amount	Notes
/101	Total gross	$60	Since 270G is a cash payment, it is cumulated into /101
/5U0	Total EE Tax	$60	Actual employee tax deducted from employee
/560	Net Pay	$0
270E	Tax Equal Net	$100	No-pay net
270F	Tax Equal Gross	$160	No-pay gross – no cumulation to /101
270G	Tax Equal Tax	$60	Cash payment to cover $60 in expected employee tax

Problems with Gross-ups

If the employee has a claim when a no-pay gross-up is processed, the cash payment for taxes will first go to satisfy the claim, instead of offsetting taxes. Claims always come before taxes. In the $100 no-pay gross-up example, we would then have $100 net, $160 gross, zero net payment, and uncollected taxes.

Period 1 in 1
Wagetype	Description	Amount	Notes
/101	Total gross	$60
/5U0	Total EE Tax	$0
/Nxx	Uncoll EE tax	$60	The $60 in 270G was used to pay off the existing claim first, so there was no money leftover to pay for taxes. Now the employee’s taxes are not in balance with their wages.
/560	Net Pay	$0
/561	Claim	$60
/563	Claim paid	$60
270E	Tax Equal Net	$100	No-pay net
270F	Tax Equal Gross	$160	No-pay gross
270G	Tax Equal Tax	$60	Cash payment to cover $60 in expected employee tax

Reconciling Taxable Wages – No Retrocalculation

Many times we have to reconcile the taxable wages back to the wages paid to the employee. To do this, identify all the taxable wagetypes in the RT and add them together. Taxation may be different from one authority and one tax type to another. You can use the ZP_TAXMODEL program to determine which wagetypes are taxable for the various tax authorities, tax types, and tax modifiers.

When reconciling the wages, be sure to keep in mind which ones are taxable vs. taxable-not-taxed. Wagetypes that are ‘taxable’ will go into /3xx, /6xx and /7xx. Taxable-not-taxed wagetypes will cumulate into /Qxx. The W-2 adds the /7xx and /Qxx wagetypes together for reporting.

When balancing taxes to the taxable wages, also be aware of any uncollected taxes that may be present.

Retrocalculations

Cash vs Tax Perspective

In both current-period and retro-period calculations, there really is no direct link between cash wages and taxable wages. It is best to think of them as two separate processes.

Gross to Net Equation

For every payroll period the net pay can be calculated with this equation:

/101 - /110 - /5U0 + /552 + /561 - /563 = /560

Or in friendlier terms:

Total cash payments – total employee deductions – total employee taxes + retro differences + claim – claims paid = net pay.

Forming Retro Differences

Using the gross-to-net equation as a guide, an abbreviated payroll result could look like the table below. One exception is that we don’t put accounts on /101, /110 and /5U0 – instead we account for their individual components such as base pay, overtime, cafeteria deduction, withholding tax and so on.

Period 1
Wagetype	Amount	Debit	Credit
/101	$1000	$1000
/110	$200		$300
/5U0	$300		$300
/560	$500		$500

Wagetype amounts can change retroactively. For example, if an employee was underpaid by 8 hours of overtime in a previous period, the amount of the overtime wagetype would increase retroactively. Since overtime is a cash payment, it would cause /101 to increase retroactively, showing that we now need to pay the employee $100 more in this case. But, in a retrocalculated period we can not change the amount of net pay, since that pay was already transferred to the bank (or paid via check). The difference between what was paid originally vs what should now be paid is put into a wagetype called ‘retro differences’, or /551. This keeps the retro payroll period in balance (i.e. debits equal credits).

Period 1 in 2
Wagetype	Amount	Debit	Credit
/101	$1100	$1100
/110	$200		$200
/5U0	$300		$300
/560	$500		$500
/551	$-100		$100

Then in the current period, the system sums all the /551 wagetypes from the retro periods, multiplies by negative 1 and places that amount in /552. If positive, this adds to the amount of net pay, if negative then it will reduce net pay. /551 and /552 should always exactly offset each other.

Period 2 in 2
Wagetype	Amount	Debit	Credit
/101	$1000	$1000
/110	$200		$200
/5U0	$310		$310
/560	$590		$590
/552	$100	$100

Claims

Retro differences (wagetype /552) is added to total net pay (wagetype /560) in the current period. If /552 is negative, it could reduce /560 to a negative amount, which is not allowed (can’t have negative net pay). The amount it would go negative is the amount that can not be recovered in the current period, and that amount is stored in /561 – a Claim. The claim is the amount of money the employee still owes the company because they don’t have enough to pay it back.

For example, assume the employee was really on leave of absence beginning in period 1, so they would have had a total gross of zero, but they were originally paid $1000. In that case, the results would look like:

Period 1 in 2
Wagetype	Amount	Debit	Credit
/101	$0	$0
/110	$200		$200
/5U0	$300		$300
/560	$500		$500
/551	$1000	$1000

In period 2, the employee is still on leave of absence, so no payments, deductions or taxes are taken. The $1000 overpayment from period 1 in 2 is stored as a claim, since there is no net-pay to offset it.

Period 2 in 2
Wagetype	Amount	Debit	Credit
/101	$0	$0
/110	$0		$0
/5U0	$0		$0
/560	$0		$0
/552	$-1000		$1000
/561	$1000	$1000

The claim (/561) is the amount the employee owes the company. In every subsequent payroll the system will apply money towards paying off the claim, before it uses the money for any deductions or taxes. For example, in period 3 the employee gets paid $600, and all of that gets allocated to reduce the claim.

Period 3 in 3
Wagetype	Amount	Debit	Credit
/101	$600	$600
/110	$0		$0
/5U0	$0		$0
/560	$0		$0
/561	$400	$400
/563	$1000		$1000

Taxation of Retrocalculations

Tax When Paid (TWP) vs Tax When Earned (TWE)

Since SAP’s payroll system has retrocalculation functionality, it can happen that we change payments in the past that affect taxable wages. This is something that tax authorities never expect, and don’t really recognize. Tax authorities want companies to tax payments based on when the employee has ‘constructive receipt’ of the wages. Constructive receipt in SAP terms means that we tax the wages when they are paid, not when they are earned. The tax when paid date corresponds to the check date and/or period end date depending on the infotype.

So when SAP does retroactively change wages in the past, those changes are rolled forward to the current period and taxed there. However, the taxable wagetypes change in the retro periods. For example, in the first retrocalculation case /101 increase in period 1 in 2, because the overtime wagetype increased. But that increase was not taxed in period 1 in 2, it was rolled forward to period 2 in 2 and taxed there (which is why taxes are higher there).

There are some cases where wages are taxed when earned – gross-ups/gross-downs, retroactive changes in tax areas, and NAMC’s

Balanced & Unbalanced Offsets

The changes in taxable wagetypes are carried forward from retro period to the current period in table XDFRT (you can view that table in the payroll clusters display report). In the current period, the payroll program sums together all the XDFRT entries and then one by one sums them to the current period’s taxable wages – either increasing or decreasing taxable wages in the current period. It will continue doing this as long as the taxable wages in the current period do not go below zero. The wages it can clear go to the BAL table (BAL for balanced offsets). The entries it can not clear go to the UNB (unbalanced offsets) table. Every subsequent payroll will read in the previous period’s UNB entries and try to clear them against current taxable income.

SAP creates in each pay period a wagetype called ‘Good money’, wagetype /5PY. It contains the total amount of taxable wages that can be worked with. So if /5PY is zero or negative then no wages can be cleared, as is the case with employees who have claims.

When trying to reconcile regular wagetypes to taxable wages in the current period, the equation to be used is ‘current period taxable wages’ + differences in BAL table = taxable wages.

Tax Priority & Caps

Function UTPRI controls two things – the priority of taking taxes, and the creation of uncollected taxes. It behaves one way in current period calculations and another way in retro periods. In a retro period, the function will let payroll take additional payroll taxes up to the amount of total gross (/101) in the original period. For example, if an employee retroactively went from residing and working in Blue Ash to residing in Blue Ash and working in Cincinnati, the system would retroactively take an additional 1.1% in Cincinnati tax, as long as the amount of total tax in the retro period was not greater than the amount of /101 in the original period. If it was greater than /101, then the difference gets placed into uncollected taxes. The documentation for this function can be viewed with transactions PDSY or PE04.

Retroactive changes to gross-ups

Client XXX use of no-pay gross-ups presents problems for the UTPRI function in retro calculations. For example, if a no-pay gross-up retroactively increases, and the employee has no other cash money (i.e. 3121L expats) then it’s likely you will get uncollected taxes: the gross goes up retroactively since gross-ups are tax-when-earned, and the cash payment for taxes increases to cover the additional amount of tax. However, the UTPRI function compares total tax to the original total gross and finds that the amount of tax now exceeds the amount of total gross, and it reduces the employee taxes (creating uncollected tax). However, the amount of the cash payment to cover taxes does not go down, and the difference between that and total tax results in a net payment to the employee. For example:

Period 1 in 1
Wagetype	Description	Amount	Notes
/101	Total gross	$1000
/5U0	Total EE Tax	$1000
/560	Net Pay	$0
270E	Tax Equal Net	$20000	No-pay net
270F	Tax Equal Gross	$21000	No-pay gross
270G	Tax Equal Tax	$1000	Cash payment to cover $1000 in employee tax

Then in period 2 we retroactively increase 270E to $30000:

Period 1 in 2
Wagetype	Description	Amount	Notes
/101	Total gross	$1500
/5U0	Total EE Tax	$1000	Capped at $1000; the value of /101 in the original period
/Nxx	Uncoll Tax	$500	The amount of taxes it could not take
/551	Retro differences	$-500	/101 - /110 - /5U0 + /551 has to equal /560, so /551 is set to balance this equation
/560	Net Pay	$0
270E	Tax Equal Net	$30000	No-pay net
270F	Tax Equal Gross	$31500	No-pay gross
270G	Tax Equal Tax	$1500	Cash payment to cover $1500 in expected employee tax

And assuming the employee had no other transaction in period 2, he gets paid $500:

Period 2 in 2
Wagetype	Description	Amount	Notes
/101	Total gross	$0
/5U0	Total EE Tax	$0
/552	Retro differences	$500	The sum of /551 times -1
/560	Net Pay	$500	/101 - /110 - /5U0 + /552 = net pay

To minimize the problems with retroactive changes to gross-ups affecting net pay or creating claims, we wrote a new payroll function ($RGUF) that ‘tricks’ the system so that if gross-ups change retroactively it always has enough money to cover taxes, so no retro differences are created. The example listed above should not happen in Client XXX system because of this enhancement.

Crossing Years

When a payroll retro crosses from the current year into a previous year then special processing takes place for taxes. SAP will not allow taxes in the previous year to change from their original values. For example, if you process a January correction check that retro’s back into the previous year and something causes taxes to change, SAP will reset those tax amounts back to their original value. This is done by the payroll function UOTX0 – keep old taxes in retro. This exception to this function is that it does let you change tax amounts via NAMC’s (infotype 221).

In this example, we’ll show what happens when a no-pay gross-up changes retroactively in the previous year. In the original period 12 a no-pay gross-up of $30,000 was processed:

Period 12 in 12
Wagetype	Description	Amount	Notes
/101	Total gross	$1500
/5U0	Total EE Tax	$1500
/560	Net Pay	$0
270E	Tax Equal Net	$30000	No-pay net
270F	Tax Equal Gross	$31500	No-pay gross
270G	Tax Equal Tax	$1500	Cash payment to cover $1500 in expected employee tax

Then in period 1, someone changed period 12’s 270E to $20,000 from $30,000. Total cash payments go down but the taxes remain the same. Wagetype 270G – the cash payment to cover employee taxes on the gross-up – is now $1,000. But, the system keeps the total tax amount at $1,500 because we are crossing years. To balance out the payroll, we get a /551 wagetype for $500.

Period 12 in 1
Wagetype	Description	Amount	Notes
/101	Total gross	$1000
/5U0	Total EE Tax	$1500	Kept at $1,500 – the amount of tax in the original period (12 in 12)
/551	Retro differences	$500	/101 - /110 - /5U0 + /551 has to equal /560, so /551 is set to balance this equation.
/560	Net Pay	$0
270E	Tax Equal Net	$20000	No-pay net
270F	Tax Equal Gross	$21000	No-pay gross
270G	Tax Equal Tax	$1000	Cash payment to cover $1500 in expected employee tax

In period 1, the employee had no other pay, and they receive a claim for the difference in tax from period 12 in 12 and 12 in 1. The employee ‘owes’ $500 because we reduced their tax payment but did not reduce their actual taxes in period 12 in 1.

Period 1 in 1
Wagetype	Description	Amount	Notes
/101	Total gross	$0
/5U0	Total EE Tax	$0
/552	Retro differences	$-500	The sum of /551 times -1
/560	Net Pay	$0
/561	Claim	$500

W-2 Corrections (W-2C)

Once W-2’s are run and finalized, any change to taxable wages or taxes in the previous year will cause a W-2C (W-2 correction) form to be produced. The ‘finalized’ date for W-2’s is stored in the system, and can be viewed via the Tax Reporter (PU19) menu path Tools -> Set filing date (after selecting the tax company and tax form W-2). You can also view the filing date by using the Data Browser (SE16) on v_t5xy_a, enter the tax company and use tax form ‘z_w2_01’.

Thursday, January 28, 2016

Tax Data Maintenance – Unemployment Insurance

Tax Data Maintenance – Symbolic Account Split