Although SAP offers excellent courses in Financial Accounting (FI) and Human Resources (HR), I have yet to see any formal training on how to connect the two modules, which requires both configuration and programming to work. Finding someone knowledgeable in both modules can be difficult or costly. Therefore, I’m offering an explanation of what is involved in a successful implementation, all learned the hard way, through first-hand experiences. Your approach to developing this interface must take many factors into account: people, politics, technology, custom needs of each organization, and geographic proximity of FI/HR end users. I will take you through the decision-making process. It is divided into four parts:

• First, I’ll give you an overview of the data flow between these modules.
• Using the example of a sample multinational company, Company A, I’ll describe the information involved in integrating HR and FI. You will see how Company A tracks employee deductions and employer contributions to a dental plan and adds withholding tax for the state of Colorado. I will also show the steps to running the transfer of data between HR and FI.
• I’ll explain how symbolic accounts relate wage types in HR to accounts in FI.
• I will end with a list of tips to help you avoid four common traps.

Data Flow Between HR and FI

Before you start to build the HR-FI connection, you should be aware of the data involved. Here is a bird’s-eye view: In SAP, data flows from HR to FI and also from FI to HR. FI provides HR data to the following areas, which affects the available options when setting up the postings back to FI:

• Chart of accounts/cost centers (used to meet the company’s decision-making needs regarding HR expense information)
• House banks
• Direct deposit bank information
• Payment methods (direct deposit vs. check)
• Document types (used to identify documents that are to be kept for the same length of time)

This data can reside in either the same R/3 instance, if the HR and FI systems are both run from the same physical implementation, or in separate instances. Since R/3 systems often have a global element, many companies use separate instances. Those companies must ensure that data is passed via an interface from one instance to another so that both systems will be in sync. For help in deciding whether to integrate this data using one instance, or to interface these two modules, each in its own instance, see the sidebar, “Should You Integrate or Interface HR with FI?” below. In turn, HR provides data to FI in the form of postings. Postings provide information regarding HR-related costs to FI for bookkeeping. They either debit or credit specific FI accounts. Anything of monetary significance within HR must be handled for these postings to be complete, no matter what system or software you are using for accounting. These postings ensure that accounting has correct and complete information, enabling it to balance its books. If you remember taking Accounting 101 in college, you recall just how exhilarating it can be posting debits and credits between accounts, making sure you end up with a zero balance. (Yes, I’m speaking sarcastically here. Chances are, that is why you passed up the opportunity to become a CPA for an exciting career in the world of information technology or HR.) As dry a subject as this may be, you must exercise extreme care with HR postings. Any overlooked or wrongly posted items will improperly reflect on the costs of employees and their paid/ accrued benefits. This, in turn, leads to a situation I call “accounts deceivable,” which results in bad decisions in areas such as staff deployment, compensation, and benefits. Posting accounts can exist for the following:

• EE (employee): amount to be paid, broken out by wage type.
• ER (employer) or between cost centers: dollar value of accumulated leave balances, wage types collected, wage types paid by company, cost of time for employees on loan.
• Financial institutions (bank, credit union): deposits, loan principal, and interest.
• Government and regulatory agencies: taxes due.
• Third-party administrators and benefits carriers: premiums paid by EE or ER.
• Vendors: value of hours worked by consultants.

Sample Posting Procedures

Let’s look at the posting procedures for Company A, a multinational company with staff in the United States, whose HR data needs to be processed. See Figure 1, which illustrates the following, pertinent information about the company’s structure and systems for supporting HR and FI:

• Structure: Parent Company A is headquartered in Germany and has two daughter companies, B and C. All three companies have staff in the U.S. as well as in Europe. Company C is the IT service provider for companies A and B.
• HR processing: Company A does the HR processing for itself and its daughter companies. While its HR system in Germany handles staff working in Europe, a separate HR instance in the United States processes the payroll and benefits for U.S. staff from these companies. This setup allows for on-site HR and IT support from staff that is knowledgeable in U.S. payroll and available during U.S. business hours. (An interface between the U.S. and global HR systems ensures that U.S. staff is considered in the worldwide headcount).
• FI processing: Company A does its worldwide accounting using a global FI system in Germany. HR information about U.S. staff from all three companies must be passed to this system so that it can provide consolidated payments to vendors and government agencies. Company A’s FI system also handles the HR postings for companies A and B. This information is required at a detailed level by Company A to relate individual postings to checks, which are cut for payments.
• The HR postings for Company C need to be handled in a different manner, based on Company C’s management’s needs. Company C has its own, separate FI system instance in Germany to process the costs associated with the IT services provided to companies A and B. HR-related costs for U.S. employees from Company C pass through Com- pany A’s FI system to C’s FI system, which summarizes it as needed.
• As an additional wrinkle, each company has its own posting rules and cost centers for each type of HR posting.
• This is a simplified version of an actual company’s requirements. Many companies have far more complicated requirements. However, this serves as a starting point, although there will be additional requirements to consider, depending on how the organization wishes to account for, and make decisions on, its HR costs.

Postings for Company C

Associated postings to Company A’s FI system are required for each deduction from the employee’s (EE’s) paycheck and each contribution by the employer (ER) so that the company can track and later remit amounts to be paid to vendors, taxing authorities, etc. (The remittance process can be manual or automatic.) This information must be posted to accounts set up to make it possible to know how much both sources have contributed. Wage types consist of four digits. The sample company uses wage type format 40XX for EE payments to benefits plans and format 45XX for those relating to ER payments, where XX is a number assigned to the specific benefit plan. As the dental plan is number 02, wage type 4002 is for the EE payment for the dental plan, while 4502 is for the ER portion. A U.S. employee has $20 deducted from her paycheck via wage type 4001 towards a dental plan’s premium. Her employer, Company C, contributes an additional $100 per month via wage type 4501. The system keeps track of which plan is in effect for the employee and relates this to a particular vendor based on benefits configuration. These amounts are passed to Company A’s FI system and flow to Company C. Each month, appropriate payment is made by Company A to the provider of the dental plan services for all employees of companies A, B, and C. Accounting postings represent this flow from each of the various employee and employer wage types. Other postings ensure the cost for each employee flows to the employee’s company using the appropriate cost center. (The account specifics vary by company.)

Steps for Running the Transfer:

The method and timing of passing data from HR to FI depends on several factors, such as:

• The number of instances.
• Technical requirements, such as volume of data, available bandwidth, and downtime for scheduled system maintenance. (Consult with your technical experts to develop an appropriate procedure.)
• Deadlines from accounting for monthly closings.
• Auditors’ requirements to ensure all data is successfully transferred and to prevent multiple transfers of the same data.

In my example, FI is decoupled from HR. (Note: If the HR and FI systems were more tightly coupled, the programs used to transfer data to FI would change. For instance, RPCIPE00 would be used instead of RPCIPI00.) Therefore, take the following steps to get the data over to FI (there is separate processing in separate systems at different times): After payroll evaluation is completed, the HR system runs these jobs:

• RPCIPX00 to transfer data for FI/CO and accounts payable (A/P) via IDoc.
• RPCIPT00 to download the file.
• Custom job ZPIPFICO to meet the company’s specific need to split data to different FI systems for various sub-companies.

The data then is transferred to the FI server, and the FI system runs the following jobs:

• RPCIPT00 to upload file from HR system.
• RPCIPI00 to input data into FI.

Along the way, check to make sure all data is properly transferred. Keep backup copies of data “just in case.” At my company, HR wrote custom reports to demonstrate how data is accumulated by wage type, in case problems or questions should arise once this data gets to FI.

Handling Tax-Related Wage Types for Postings

I will now show you how to add the withholding tax for a taxing authority, such as Colorado, in four easy steps.

Step 1: Select Rule for Wage Types

To break out postings by whether tax is paid by employee or employer, the schema must select the rule to use for the wage types. The sample company uses custom created rules ZTA2 (employee tax) and ZTA9 (employer tax). See Figure 2.

Step 2: Break Down Rules by Tax Level

Each rule from Step 1 is further broken down by tax level (federal, Social Security, Medicare). Figure 3 shows how ZTA2 employee tax is broken down. Make use of the comments to document what you have done.

Step 3: Create Wage Type

Create a wage type for each tax authority that needs withholding (state and local). Use a name that reflects which tax authority is involved. Figure 4 shows the different possible combinations for rule ZTAE with the two-character state abbreviation in the name.

Step 4: (Optional, but Recommended): Document the Date

Document the date you add authorities for future troubleshooting. On line 80, the comment (i.e., the text following the double quotation mark) indicates that withholding for Colorado was added on November 1999, when the company added a Denver office. Whenever you add new tax authorities, repeat Steps 3 and 4 as needed.

Symbolic Accounts

To complete the “handshake” between the HR and FI modules, you must associate the wage type data gathered on the HR side with the appropriate accounts on the FI side. You do not assign wage types directly to accounts; otherwise, you must make changes to the affected wage types each time there is a change to an HR-related account in FI’s chart of accounts. Instead, use symbolic accounts to make this association. Each symbolic account indicates to what type of account the related wage types should correspond (expense, balance sheet, account payables, etc.) and if it is dependent on employee grouping. For instance, salaries may post to the cost center, while stock option cash may just post to an FI account. This provides a way of distinguishing between amounts that impact P&L and those that are balance sheet items. If employee grouping is used, you must also define the conditions for assigning employees to these groupings. This is accomplished through work on both the HR and FI side:

• On the payroll side, a symbolic account is assigned to each wage type via a rule. If the symbolic account indicates that the assignment is employee-group dependent, feature PPMOD will indicate how to direct the wage type to the appropriate general ledger accounts, depending on the employee group. (Note: Feature PPMOD, as delivered, bases how this assignment is done on whether the employee is paid by the hour or salaried, as per the employee subgroup grouping for personnel calculation rules [ABART]. You can also use the employee grouping for account determination to base this assignment on the employee attributes from the workplace basic pay table [WPBP].)
• On the accounting side, the symbolic account is assigned to an account (G/L account, customer account, vendor account). (Note: Refer to SAP’s IMG Help for more information about this subject. The relationship between wage types and GL accounts is critical to developing an appropriate posting solution.)

Tips and Traps

Building the tie between HR and FI can turn out to be the most challenging aspect of managing an HR implementation project because of the different areas involved and the lack of guidelines on this subject. Although I learned many of the lessons the hard way, you can chart an easier course for yourself with these tips.

Trap 1: Improperly defined information requirements lead to a lack of the right data and reports.

Tips to avoid data retrieval shortfalls:

• Get upper management’s consensus on the level of detailed information it needs for decision-making. Consider local and global requirements and all levels in between.
• Identify a specific person in accounting who knows what the desired results should be. Have this person document out the posting rules. If there are multiple people, assign specific responsibility by area of focus. Obtain management buy-in when targeting the correct individual(s). Allow plenty of time — and budget. (Note: The amount of effort depends on the completeness of your current documentation and the complexity of these rules. It is good form to tell the folks in Accounting of their upcoming role and to respect their processing deadlines when planning for their involvement. You should map out each financial component of HR: Identify each wage type and add to the wage type catalog as required. Define to which accounts this must be debited/credited. Define clearing account usage. Consider how offset postings are to be used to result in zero balances, such as for family leave. Define rules for each company handled.)

Trap 2: Improperly defined posting requirements cause errors in posting.

Tips to avoid posting errors:

• Develop procedures to ensure account numbers are current, especially if HR and FI are separate instances and the company updates account numbers manually because of a low volume of changes or a budget shortfall. In that case, you need manual procedures for communicating changes.
• The level of detail/summarization must be appropriate for FI. If one FI system is a pass-through to another, both must be at the same level of detail.
• Carefully define and use symbolic accounts. If changes to the definition of the symbolic accounts later become necessary, map the changes using new symbolic accounts.
• Avoid changing the definition of the feature PPMOD retroactively since the reversal process uses the original definition. Instead, use new employee groupings or restrict the validity period.
• Pay attention to the +/- sign. Positive amounts from payroll should be posted with a positive sign to debit an account and with a negative sign to credit an account. Since this topic can become confusing, see that someone who understands FI and accounting principles discusses this with your HR staff.
• Ask if clearing accounts are used and, if so, how.
• Establish which system owns/updates which data.
• Keep in touch with organizational changes and their impact on posting.
• Post taxes by tax authority, not lumped together, if you want to have the ability to break them out later.
• If multiple FI systems are in use, find out the rules for each system.

Trap 3: Attitude can make it difficult to define these rules.

(HR and FI users can be continents apart, speaking different languages. Organizational structure or politics can get in the way, particularly if FI users are not included on the implementation team.) Tips to overcome attitude:

• Give legacy support and FI staff incentives to help define requirements and to adequately test.
• Involve proper levels of management early and often. Cross-team steering committee coordination (with members from each sub-company and owners of each involved instance of HR and FI) is worth fighting for.
• Introduce team players to each other. Include those not on location.
• Budget and plan for FI staff time on the project.
• Encourage frequent communication— face-to-face as needed.
• Learn and use the management
• structure to expedite results.
• Check on the true level of participation. People can appear to be participating but, in fact, could be falling short when it comes to details. This happens when staff is over-allocated.

Trap 4: Who really knows the posting rules?

(Rules can be undocumented, out-of-date, or unknown to HR staff.) Tips to facilitate definition of these rules:

• Management should assign responsible staff that can recognize errors and be held responsible for posting correctness.
• Rules must be carefully documented and signed off.
• Testing must be on both HR and FI sides. Incentives: Avoided overtime and pain to identify and fix problems after the “go-live”; the ability to pass an audit.