PeopleSoft Chart of Accounts SCO & STO

Overview

The Chart of Accounts (COA) is the backbone of any financial system. In PeopleSoft Financial Management, the COA is split into two distinct structures:

• SCO Standard Chart of Accounts: The primary accounting framework used for reporting, consolidation, and external compliance.
• STO Supplemental Chart of Accounts: An auxiliary structure that allows organizations to capture additional dimensions without affecting the primary financial statements.

Both structures are defined in PeopleSoft using the GL_ACCOUNT table, but they serve different purposes and are maintained through separate components. Understanding the relationship between SCO and STO enables flexible reporting, better segregation of duties, and smoother integration with other ERP modules.

SCO Standard Chart of Accounts

The SCO represents the official set of accounts that your organization publishes to external stakeholders and uses for statutory reporting. Key characteristics include:

• Hierarchy: Often organized in a multilevel hierarchy (e.g., Segment1 = Company, Segment2 = Department, Segment3 = Account).
• Stability: Changes are controlled through a rigorous changemanagement process because they affect audited financial statements.
• Mapping: Directly tied to the General Ledger, Accounts Payable, Accounts Receivable, and Asset Management modules.

In PeopleSoft, the SCO is maintained via the Chart of AccountsSetup (GL112000) component. When you create a new account, you define:

Because the SCO is the source for statutory reporting, it must comply with external frameworks such as GAAP, IFRS, or local tax regulations.

STO Supplemental Chart of Accounts

The STO provides a flexible way to capture additional financial dimensions that are not part of the official SCO. Typical uses include:

• Tracking projectspecific costs without creating a separate SCO account.
• Recording internal cost allocations (e.g., intercompany, costcenter, or program codes).
• Supporting temporary reporting requirements for management dashboards.

PeopleSoft manages the STO through Supplemental Chart of AccountsSetup (GL115000). Unlike the SCO, STO accounts can be added or retired with minimal impact on audited statements.

Key fields for an STO record are similar to SCO but include:

When a transaction is posted, you can supply both an SCO account (required) and an STO account (optional). The STO value is stored in the STO_ACCOUNT column of the GL_JOURNAL_LINE table, allowing it to be used in adhoc queries and custom reports.

Implementation Tips

1. Design a Logical Hierarchy

Start with a clear definition of the SCO hierarchy. Common approaches:

• Segment1 = Business Unit, Segment2 = Department, Segment3 = Account.
• Segment1 = Region, Segment2 = Cost Center, Segment3 = Account.

Document the hierarchy in a spreadsheet before building it in PeopleSoft.

2. Define STO Purpose Early

Identify the dimensions that will live in the STO (e.g., Projects, Grants, Cost Pools). Create a naming convention that differentiates STO accounts from SCO accounts.

3. Use SameLevel vs. CrossLevel Mapping

If an STO account always maps to a single SCO account, use a samelevel relationship (populate Parent Account field). For crosslevel mapping (e.g., a project expense can hit multiple cost centers), consider using GL_ACCOUNTING_JOURNAL rules or custom validation scripts.

4. Leverage PeopleSoft Security

Control who can create or modify SCO vs. STO accounts:

• Assign GL Account Maintenance role for SCO changes.
• Grant GL Supplemental Account Maintenance role for STO updates.

5. Test Reporting Scenarios

After loading test data, run the following standard reports to ensure both structures work:

• General Ledger Detail verifies SCO posting.
• Journal Distribution confirms STO values appear when selected.
• Custom SQL Report includes STO_ACCOUNT for adhoc analysis.

Best Practices for Maintaining SCO & STO

• Separate Governance: Use a formal changerequest process for SCO accounts; keep STO adjustments lightweight and managed by functional owners.
• Consistent Naming: Prefix STO accounts (e.g., PROJ_, GRNT_) to avoid confusion with SCO codes.
• Periodic Review: Conduct an annual reconciliation of inactive STO accounts to prevent data bloat.
• Document Mapping Rules: Keep a reference table that shows which STO accounts link to which SCO accounts, especially for audit trails.
• Performance Considerations: Limit the number of active STO accounts to a manageable level; excessive STO rows can slow journal entry processing.
• Training: Provide endusers with quick reference guides that illustrate where to enter STO values in transaction screens (e.g., Journal Entry, Payables Invoice).

By following these guidelines, organizations can enjoy the flexibility of supplemental accounts without compromising the integrity of their primary financial statements.