Symbolic Account to G/L Mapping Table in SAP

⚡ Smart Summary

Symbolic accounts in SAP link payroll wage types to the general ledger, letting the system post salary expenses and payables to the correct accounts using transactions OBYG, OBYE, and OBYU during the payroll posting run.

  • 🔘 Bridge role: A symbolic account is the connector that carries each wage type from Payroll into Financial Accounting.
  • ☑️ Assignment type: Every symbolic account carries a type that tells SAP whether it posts to an expense, balance sheet, or vendor account.
  • OBYG: Transaction OBYG maps symbolic accounts to balance sheet and liability G/L accounts.
  • 🧾 OBYE: Transaction OBYE maps symbolic accounts to expense accounts and asks for the employee grouping.
  • 🔗 OBYU: Transaction OBYU maps symbolic accounts to vendor accounts for third-party payables.
  • 🛠️ Posting run: PC00_M99_CIPE simulates and posts the mapped results to accounting once every symbolic account is assigned.

Mapping symbolic accounts to G/L accounts in SAP using OBYG and OBYE

Mapping a symbolic account to a general ledger account is the configuration step that lets SAP Payroll hand its results to Financial Accounting. Each wage type points to a symbolic account, and each symbolic account points to a real G/L account through transactions OBYG, OBYE, and OBYU.

What Is a Symbolic Account in SAP?

A symbolic account is a short, four-character key that acts as a bridge between SAP Payroll (part of SAP HR) and Financial Accounting. Payroll does not post directly to a general ledger account. Instead, every wage type that must reach the books is first assigned to a symbolic account, and the symbolic account is then mapped to the actual G/L account.

This two-step design keeps the payroll configuration independent of the chart of accounts. If the finance team renumbers a G/L account, only the symbolic-account mapping changes, and no wage type has to be touched. SAP stores the symbolic accounts and their assignment characteristics in table T52EK.

Each symbolic account carries an account assignment type that tells SAP what kind of account sits behind it:

  • Expense (cost) accounts for the salary and benefit costs the company incurs
  • Balance sheet accounts for the net pay, tax, and social-insurance amounts owed
  • Vendor accounts when a payable is settled through a third party

Symbolic Account Assignment Types and Their T-codes

The account assignment type recorded against each symbolic account decides which transaction is used to map it. Expense items are handled by OBYE, balance sheet items by OBYG, and vendor items by OBYU. The table below summarises the main types you will meet.

Assignment type Posts to Mapping transaction
C — Expense Payroll expense and cost accounts in the profit and loss statement OBYE
F — Balance sheet Payable and liability accounts such as net pay or tax payable OBYG
Q — Balance sheet with personnel number Employee-level balance sheet accounts OBYG
K — Vendor Vendor accounts in accounts payable OBYU

Because expense accounts are grouped by employee grouping, OBYE asks for the employee grouping in addition to the symbolic account and G/L account. OBYG and OBYU need only the chart of accounts, the symbolic account, and the target G/L or vendor account.

How to Map Symbolic Account to G/L Account

The following procedure maps a symbolic account to a balance sheet account with OBYG, then shows the small difference for OBYE. Both transactions open the same account-determination view; only the required fields differ.

Step 1) Enter transaction OBYG in the SAP transaction code box, as shown below.

SAP transaction code box with OBYG entered to map symbolic accounts to balance sheet accounts

Step 2) Enter the Chart of Accounts, then click Enter to confirm the entry shown in the next screen.

Chart of Accounts entry screen in transaction OBYG for symbolic account mapping

Step 3) In the next SAP screen, click Create to add a new symbolic-account assignment.

OBYG overview screen with the Create button used to add a new symbolic account assignment

Step 4) Enter the Symbolic account and the G/L account, then click Save to complete the mapping.

Entering the symbolic account and G/L account number before saving the OBYG mapping

Step 5) For transaction OBYE the process is the same, except that you must also enter the Employee Grouping, as shown below.

Transaction OBYE showing the Employee Grouping field alongside the symbolic and G/L account mapping

Once every symbolic account is mapped, the payroll-to-accounting link is complete and results can be posted to the ledger.

Posting Payroll Results to Accounting (PC00_M99_CIPE)

Mapping the accounts is configuration; transferring the numbers is a separate run. After a payroll is exited, the posting program reads each result, translates every wage type through its symbolic account into a G/L, vendor, or customer line, and creates an accounting document.

The usual sequence is straightforward:

  • Run PC00_M99_CIPE to create the posting run, starting in simulation mode
  • Review the simulated document for balance and account-determination errors
  • Switch to a productive run so SAP creates the posting run in the background
  • Use PCP0 to check, release, and post the run to Financial Accounting

The most common errors at this stage are a wage type with no symbolic account, a symbolic account that was never mapped, or a target G/L account that is blocked for posting. Each is fixed in the mapping transactions above, after which the run is repeated. The resulting documents then feed the standard FI reports and are visible in the FI tables that hold financial documents.

FAQs

The symbolic account keeps payroll configuration separate from the chart of accounts. Wage types point to symbolic accounts, so if a G/L number changes, only one mapping is updated and no wage type has to be reconfigured.

Symbolic accounts and their account assignment characteristics are held in table T52EK, maintained through view V_T52EK. The wage-type-to-symbolic-account links sit in the related posting configuration tables that the payroll posting program reads.

Yes. A single symbolic account can resolve to different G/L accounts depending on the employee grouping and posting rules, so the same wage cost can be split across cost centres or company codes without changing the wage type.

The payroll posting run fails for that wage type and reports an account-determination error. SAP cannot find a target G/L account, so the run stops. Assign the wage type to a symbolic account, then repeat the posting simulation.

Reopen OBYG, OBYE, or OBYU for the same chart of accounts, select the symbolic account, and overwrite the G/L account before saving. Existing posted documents are unaffected; only payroll runs posted after the change use the new account.

Machine learning proposes account assignments for new wage types from historical mappings, flags postings that break a pattern, and speeds reconciliation between payroll and the ledger. SAP delivers such capabilities through Business AI embedded in its finance and HR applications.

GitHub Copilot helps with the code around the run, not the SAP screens. It drafts ABAP, BAPI calls, and reconciliation scripts for symbolic-account mappings. Every generated posting must still be tested in a sandbox client before production.

Yes. Symbolic accounts, OBYG, OBYE, and OBYU remain the account-determination method in S/4HANA. The main change is the Universal Journal, table ACDOCA, which stores the posted document, so the mapping logic itself is unchanged.

Summarize this post with: