What Is the Epicor GL Structure? Segments & GL Accounts

The general ledger (GL) structure in Epicor Kinetic determines how financial transactions are classified, recorded, and reported. A well-designed structure gives finance teams visibility into expenses, revenue, departments, and business units while supporting accurate financial statements and period-end reporting. 

Understanding what the Epicor GL structure consists of means understanding three connected elements: the chart of accounts (COA), the segments that make up an account, and the GL account records that define valid account combinations. This guide explains how these elements work, what to know about the Epicor Kinetic GLAccount table, and how to create a new GL account without disrupting existing accounting workflows. 

What Is the Epicor GL Structure? 

The Epicor GL structure is the framework that defines how general ledger accounts are organized and how financial transactions are classified. It includes the chart of accounts, the segment structure, the permitted segment values, and the valid combinations used to record transactions. 

For example, a fictional account code such as 6100-02-01 could represent: 

• 6100: Office supplies expense 

• 02: Sales department 

• 01: Main operating division 

This example is illustrative, not a standard Epicor account format. 

The GL structure determines where transactions are recorded, while ledger transactions contain the actual debits, credits, and financial activity. The distinction matters: creating a new account defines where future transactions may be posted, but it does not itself create a journal entry or change an account balance. 

According to Deloitte's guidance on chart-of-accounts design, a well-designed COA supports statutory reporting, management reporting, financial consolidation, and consistent data definitions across an organization. 

How GL Segments Work in Epicor Kinetic 

What Is a GL Segment? 

A GL segment is an individual component of an account code. Depending on the organization's configuration, segments can represent the natural account, division, department, or another accounting dimension. 

In Epicor Kinetic, the chart-of-accounts structure defines the segments available for a particular COA. Segment values then provide the valid codes that users can select when creating accounts. 

For example, an organization might configure these segments: 

The actual segment labels, order, and permitted values depend on the organization's configuration. 

How Segment Values Combine Into a GL Account 

Individual segment values can combine to form a complete GL account. Using the fictional example above, 6100-02-01 represents office supplies expense for a particular division and department. 

This structure enables finance teams to analyze spending by both account type and organizational responsibility without creating a separate natural account for every department. 

Epicor's training material, Understanding Chart of Accounts Segment Values and GL Accounts, explains that General Ledger Account Maintenance defines valid combinations of account segments for a chart of accounts. 

Not every possible combination must necessarily be available. Organizations can control which combinations are valid, helping prevent transactions from being coded to inappropriate departments or divisions. 

Segment Lengths, Separators, and Validation Rules 

Account formatting depends on the configured chart of accounts. Segment lengths, display order, separators, permitted values, and validation behavior should be checked in the target Kinetic environment. 

A system might display a segmented account using hyphens, while an integration or data-management workflow may represent the same account using separate segment fields or a different delimiter. 

For example, Epicor-related technical references show GL account values represented through fields such as SegValue1, SegValue2, and SegValue3. Some data-management workflows also use a pipe character to separate account segments. 

Do not assume that an account code copied from a report, spreadsheet, or external system can be pasted into every Epicor field without conversion or validation. 

Before adding an account, confirm: 

• The correct chart of accounts is selected. 

• Each required segment value exists and is active. 

• The combination complies with the organization's accounting rules. 

• The account format matches the configuration expected by the relevant screen or integration. 

GL Segments vs. Subaccounts and Dimensions 

These terms are related but not interchangeable in every ERP system. 

A segment is a component of an account structure. A subaccount may refer to a secondary accounting classification, depending on the system. A dimension is a broader term for an attribute used to classify financial activity, such as a department, location, or project. 

Epicor Kinetic uses a configured COA structure and may support additional accounting dimensions or dynamic segments depending on the implementation. Epicor training material distinguishes GL accounts, which include the natural account and controlled segments, from dynamic segments. 

The practical rule is to use the terminology and configuration established in your own Epicor environment rather than assuming that a concept from another ERP maps directly to Kinetic. 

What Is a GL Account in Epicor? 

Chart of Accounts and GL Account Records 

The chart of accounts establishes the accounting structure. A GL account record represents a valid account within that structure, including the applicable segment combination and account properties. 

For instance, an organization may already have the natural account for office supplies but need to create a valid combination for a newly established department. Depending on its configuration, it may need to add the missing segment value, create the account combination, or complete both steps. 

Epicor provides Chart of Account Structure Maintenance for defining the segment structure and General Ledger Account Maintenance for defining valid account combinations. 

These are separate activities. Changing the structure of a chart of accounts is not the same as creating an individual GL account. 

GL Account Controls and Attributes 

A GL account may have properties that determine whether it is available for use and how it behaves in the accounting system. 

Epicor's training material specifically discusses account activation, description overrides, and effective-from and effective-to dates. It also describes preserving an account's activation status during automatic updates. 

Other posting and reporting behaviors may depend on related configuration, including account categories, GL controls, books, and company settings. 

When creating an account, check the properties relevant to its intended use rather than assuming that a valid account code is sufficient. 

How GL Accounts Connect to Journals and Financial Reports 

GL accounts provide the classification framework for financial transactions. When transactions are posted, the resulting ledger entries affect account balances and contribute to financial reports. 

For example, an approved supplier invoice might debit an expense account and credit accounts payable. The specific accounts used depend on the transaction, GL controls, account assignments, and applicable accounting rules. 

If the expense is assigned to the wrong department, the entry may still balance while management reporting becomes inaccurate. Correct GL setup is therefore important for both accounting integrity and operational visibility.  

Epicor Kinetic GLAccount Table: Schema, Columns, and Fields 

What Is the GLAccount Table? 

The GLAccount table is an account-master data object in the Epicor ERP data model. It is distinct from transaction tables that record journal activity. 

Technical teams may inspect GL account data through supported reporting tools, Business Activity Queries (BAQs), or other approved data-access mechanisms. The precise table definition and relationships should be verified against the installed Kinetic release and the environment's data dictionary. 

This distinction is important because a field visible in a user interface may be calculated, formatted, or derived from related data rather than stored in the same form in the underlying table. 

Important GLAccount Fields and What They Mean 

The following table lists fields evidenced in Epicor-related technical references. It is a working field reference, not an exhaustive or release-certified database schema. Exact data types, lengths, nullability, and key definitions should be checked in the target environment. 

Epicor-related technical examples demonstrate the use of Company, COACode, GLAccount, and segment-value fields in account queries. However, these examples do not establish the full schema or all constraints for every Kinetic release. 

Do not infer SQL data types from field names. A field's actual type, size, required status, and key participation should be established through the data dictionary or an approved schema reference for your environment. 

How GLAccount Relates to Company and Chart-of-Accounts Configuration 

The company and chart-of-accounts context matter because an account code cannot be interpreted reliably without knowing the structure and configuration to which it belongs. 

For example, the same natural account value may be used across different departments, while different companies may have distinct account structures or mappings. The account master must be interpreted in conjunction with the relevant COA and company configuration. 

When building a BAQ or an integration, verify the applicable relationships and joins rather than assuming that the account code alone uniquely identifies every record across all companies and charts. 

GLAccount Table vs. Other GL-Related Tables 

The account master is only one part of the accounting data model. 

• Account master: Defines valid account records and their relevant attributes. 

  
  

• Chart-of-accounts configuration: Defines the segment structure and permitted segment values. 

  
  

• Journal and transaction records: Capture financial activity, including debit and credit amounts and applicable accounting periods. 

  
  

• Related accounting configuration: Can include books, fiscal calendars, account categories, and GL controls. 

A report that combines account descriptions with transaction amounts may therefore need to retrieve information from multiple data objects. 

How to Inspect GLAccount Data Safely 

For routine investigation, use approved tools such as BAQs, standard reports, or authorized read-only database access where supported. 

A practical inspection process is: 

1. Identify the Kinetic release and deployment model. 

   
   

2. Locate the relevant table and fields in the environment's data dictionary or schema tools. 

   
   

3. Confirm field types, primary keys, relationships, and company-specific behavior. 

   
   

4. Compare the underlying records with the corresponding values shown in GL Account Maintenance. 

   
   

5. Validate the query in a test environment before using it for reporting or integration. 

Avoid direct database writes to the account master. Account creation and changes should normally go through supported Epicor application functions or documented APIs, which can apply validation and maintain related records. Confirm the supported method for your particular release before making changes. 

How to Create a New GL Account in Epicor Kinetic 

The following workflow follows Epicor's documented training approach. Menu paths and screen layouts may differ by version, permissions, and customization. 

Step 1: Confirm the Company and Chart of Accounts 

Start by verifying the company in which the account is required and identifying the correct COA. 

Check whether the account already exists under another valid combination. If the requirement concerns a new department or division, determine whether the missing component is a segment value, an account combination, or a change to the chart structure. 

Step 2: Define the Required Segment Values 

Check that every required segment value exists and is available for the intended use. 

If the department does not yet exist in the segment configuration, adding a complete account combination may not be enough. The required segment value may need to be created and approved first. 

Review numbering conventions and naming standards before introducing new values. 

Step 3: Open GL Account Maintenance 

Navigate to General Ledger Account Maintenance, using the menu path available in your Kinetic environment. 

Select the relevant chart of accounts. Epicor's training material describes selecting the COA before creating a new GL account, so the account inherits the appropriate segment structure. 

If the maintenance option is unavailable, check your permissions and the application's menu configuration. 

Step 4: Enter the Account and Configure Its Properties 

Create the new account and select the required segment values from the available options. 

For example, a company creating an office supplies expense account for a new department might select: 

• Natural account: 6100 

• Division: 02 

• Department: 07 

The resulting combination is illustrative only; your account values and formatting may differ. 

Enter the appropriate description and review the account's activation status and effective dates, where applicable. Also check any relevant account category, posting, and reporting configuration. 

Step 5: Save and Validate the Account 

Save the record through the supported maintenance screen. 

After saving, confirm that the account appears in the account search or maintenance list and that its segment values and description are correct. 

If the account is intended for a particular company or book, verify the corresponding configuration rather than assuming the account is automatically available everywhere. 

Step 6: Test Posting and Reporting 

Use a suitable test workflow to confirm that the account can be selected for the intended transaction. 

Validate the resulting accounting distribution and, where applicable, confirm that the transaction posts to the expected account and appears correctly in trial balances and financial reports. 

Testing should cover the relevant business process, not just whether the account record can be saved. 

Best Practices for Managing GL Accounts in Epicor 

A reliable GL structure needs ongoing governance, not just correct initial setup. 

• Standardize segment definitions. Document the meaning, permitted values, naming conventions, and ownership of every segment. 

  
  

• Establish approval procedures. Require an appropriate finance owner to approve new accounts and changes to existing account structures. 

  
  

• Avoid unnecessary account proliferation. Before creating another account, determine whether an existing account and an established segment can provide the reporting detail required. 

  
  

• Validate reporting requirements. Ensure that account changes support financial statements, departmental reporting, budgeting, and consolidation. 

  
  

• Maintain auditability. Document the business reason for changes, the approver, the effective date, and any downstream mappings that need updating. 

  
  

• Review automated coding rules. Ensure that transaction-coding systems use approved account combinations and do not introduce unsupported codes. 

These practices align with Deloitte's recommendations for strategic chart-of-accounts design, which emphasize consistent definitions, appropriate granularity, scalable structures, and centralized governance. 

How Hyperbots Invoice Processing HyperAgent Supports Accurate GL Coding in Epicor Kinetic 

Creating a new general ledger (GL) account in Epicor Kinetic is only one part of maintaining accurate financial records. Finance teams must also ensure that invoices are assigned to the appropriate expense accounts, departments, and other accounting dimensions according to the organization's chart of accounts and accounting policies. 

Hyperbots' Invoice Processing HyperAgent uses AI-powered finance automation to support invoice classification and GL coding. By considering invoice details, relevant historical transactions, ERP data, and organizational coding patterns, it can recommend appropriate GL accounts based on the available financial context rather than relying solely on vendor names or invoice descriptions. 

For example, consider an invoice for office supplies. The Invoice Processing HyperAgent can analyze the line descriptions and relevant historical coding patterns to recommend the appropriate expense account. If the organization's accounting policies also require a specific department, division, or cost center, those requirements need to be reflected in the configured coding rules and validation process. 

The same approach can support recurring expenses and invoices containing multiple expense categories. Instead of treating every invoice as a single transaction for coding purposes, line-level analysis can help distinguish expenses that belong to different accounts. Where the available information is insufficient or a recommendation requires additional validation, finance teams can review the transaction rather than relying on an unsupported classification. 

Case Study: How Hyperbots Integrates GL Coding With Epicor ERP 

The Hyperbots and Epicor ERP integration case study provides relevant context for how invoice automation can work alongside Epicor Kinetic's existing accounting processes. 

The integration is designed to use Epicor's native business objects and service layer rather than treating the ERP as a destination for a generic flat-file import. According to the integration documentation, relevant master data, including GL accounts, is synchronized from Epicor to Hyperbots. This helps Epicor remain the source of truth for account configuration. 

The integration also distinguishes between PO-backed and non-PO invoice lines. For non-PO lines, the GL account predicted by Hyperbots is written to the invoice line. PO-backed lines follow the receipt-matching workflow, using receipt and purchase order information rather than relying exclusively on an independently predicted account. The integration supports invoices containing both types of lines. 

Before posting, the integration follows Epicor's own validation and posting processes. These include pre-post checks, and the system reports the invoice as posted only after Epicor confirms the posted status. The documented workflow also includes error handling and rollback when an invoice write fails, helping prevent incomplete invoice records from being left behind. 

These integration details matter because accurate GL coding is not just about recommending an account. The recommended coding must fit the configured account structure and work within the ERP's transaction, validation, and posting requirements. 

For Epicor Kinetic users, the objective is to apply existing accounting logic more consistently, not to create arbitrary GL accounts or bypass financial controls. Customer-specific field mappings and GL structures can be handled through configuration, according to the integration documentation, while the exact coding rules and validation requirements should align with the customer's Epicor environment. 

By reducing repetitive manual classification and supporting more consistent coding decisions, the Invoice Processing HyperAgent can help finance teams process invoices more efficiently while maintaining the integrity of their general ledger data. 

Build a Reliable GL Structure in Epicor Kinetic 

A reliable Epicor GL structure starts with a well-designed chart of accounts, clearly defined segments, and valid account combinations. Understanding how GL account records relate to configuration and transaction data helps finance and ERP administrators create accounts correctly and troubleshoot availability or reporting issues. 

The GLAccount table can support technical analysis, but its exact schema should always be validated against the installed Kinetic release before building queries or integrations. Supported account-maintenance workflows, controlled changes, and thorough testing remain essential. 

As transaction volumes grow, consistent GL coding becomes just as important as sound account design. Hyperbots' Invoice Processing HyperAgent uses AI-powered capabilities to support GL coding based on relevant historical finance data, transaction context, and organizational coding patterns, while Epicor remains the system of record for accounting and reporting. 

Want to see how AI-powered finance automation can work with your Epicor environment? Request a demo of Hyperbots to explore how its AI HyperAgents can support your finance workflows and help improve GL coding consistency without replacing your existing ERP. 

Frequently Asked Questions (FAQs)

Q1. What is the Epicor GL structure? 

The Epicor GL structure defines how general ledger accounts are organized through the chart of accounts, segment values, and valid account combinations. It provides the framework for classifying transactions and generating financial reports. 

Q2. How do GL segments work in Epicor Kinetic? 

GL segments are the individual components of an account code. Depending on the configured chart of accounts, they may represent the natural account, department, division, or other accounting dimensions. Valid combinations are defined through the relevant account-maintenance configuration. 

Q3. How do I create a new GL account in Epicor? 

Open General Ledger Account Maintenance, select the appropriate chart of accounts, choose the required segment values, enter the account description and applicable properties, and save the account. Then test it in the intended transaction and reporting workflows. 

Q4. What is the Epicor Kinetic GLAccount table? 

The GLAccount table represents GL account master data in the Epicor ERP data model. It should be distinguished from transaction records that capture journal activity. Its complete schema and relationships should be verified against the relevant Kinetic release. 

Q5. Which columns and fields are available in the GLAccount table? 

Technical references identify fields such as Company, COACode, GLAccount, SegValue1, SegValue2, and SegValue3, as well as Active in account-query examples. This is not an exhaustive field list. Consult the installed environment's data dictionary to verify the full schema, field types, and keys. 

Q6. Can I create a GL account directly in the database? 

Direct database writes should not be treated as the standard account-creation method. Use supported Epicor application functions or documented APIs, and verify the appropriate method for your release. Direct writes may bypass validation or related application logic. 

Q7. Why might a new GL account not appear in a transaction entry screen? 

Possible causes include an inactive account, invalid segment combinations, an incorrect company or chart of accounts, book or GL control configuration, effective dates, or transaction-specific selection rules. Check these settings before assuming that the account record itself is defective.