Chart of Accounts and General Ledger Setup

Overview

• What you’ll learn:
  • How iDempiere’s accounting foundation works — Accounting Schema, Account Elements, and the Chart of Accounts
  • How account combinations, default accounts, and tree hierarchies control where transactions are posted
  • How documents generate journal entries, how the General Ledger stores postings, and how to create manual GL Journals
• Prerequisites: Lessons 1–25 (particularly understanding of documents like invoices, payments, and material receipts)
• Estimated reading time: 22 minutes

Introduction

Every business transaction in iDempiere — a sales invoice, a purchase order receipt, a bank payment, a manufacturing cost collector — ultimately results in accounting entries. The financial management module is not a separate system bolted on top of operations; it is deeply integrated into every transactional window. When you complete a shipment, the system automatically generates journal entries debiting Cost of Goods Sold and crediting Inventory. When you post a vendor invoice, the system debits Expense (or Inventory) and credits Accounts Payable.

But before any of this automatic posting can happen, you need a properly configured accounting foundation. This lesson covers that foundation: the Accounting Schema, Chart of Accounts, Account Elements, valid account combinations, default accounts, tree hierarchies, and the General Ledger.

Accounting Schema (C_AcctSchema)

The Accounting Schema is the top-level accounting configuration object in iDempiere. It defines the overall accounting framework for a client, including:

• Name: A descriptive name (e.g., “US GAAP Accrual Basis” or “IFRS Schema”)
• GAAP: The accounting standard this schema follows (International GAAP, US GAAP, German HGB, French PCG, or Custom)
• Costing Method: The default product costing method — Standard Cost, Average Cost, FIFO, LIFO, or Last PO Price
• Cost Type: Current costs, planned costs, or both
• Currency: The base currency for this accounting schema — all journal entries are recorded in this currency (with source currency also stored for multi-currency transactions)
• Period Type: Calendar year, fiscal year, or custom period definitions
• Commitment Type: Whether to generate accounting for purchase commitments (encumbrance accounting)

A client can have multiple accounting schemas. This is common for multinational organizations that must maintain books under more than one accounting standard (e.g., local GAAP and IFRS simultaneously). One schema is designated as the primary schema, and others serve as secondary schemas. All document postings generate entries in all active schemas.

The Accounting Schema is configured in the Accounting Schema window under Performance Analysis → Accounting Rules.

Schema Elements

The Accounting Schema also defines which accounting dimensions (called Schema Elements) are active. The mandatory dimension is the Account (natural account). Optional dimensions include:

• Organization: For inter-departmental or inter-division reporting
• Business Partner: For tracking receivables/payables by partner
• Product: For product-level profitability analysis
• Project: For project accounting
• Campaign: For marketing campaign tracking
• Sales Region: For geographic analysis
• Activity: For activity-based costing
• User-defined elements (User1, User2): Custom dimensions for specific business needs

Each active dimension becomes a segment in the account combination, enabling detailed multi-dimensional financial analysis.

Account Element (C_Element)

The Account Element defines the type of chart you are using. It is the container for all individual account values. In most implementations, you will have a single Account Element representing your Chart of Accounts, but iDempiere supports multiple elements for organizations with complex multi-segment account structures.

Key fields on the Account Element:

• Name: The name of the element (e.g., “Natural Account”)
• Element Type: “Account” for the natural account segment (there are also “User Defined” types for custom segments)
• Tree: The tree structure used to organize accounts hierarchically (for rollup reporting)
• Balancing: Whether this element must balance (debits must equal credits within each value of this element)

Element Values — The Chart of Accounts (C_ElementValue)

Element Values are the individual accounts in your chart of accounts. Each C_ElementValue record represents one account — Assets, Accounts Receivable, Revenue, Cost of Goods Sold, and so on. This is where the Chart of Accounts is actually defined.

Key Fields

• Search Key (Value): The account number or code (e.g., “1000”, “1100”, “4000”). This follows your chart’s numbering convention.
• Name: The descriptive account name (e.g., “Cash”, “Accounts Receivable”, “Sales Revenue”)
• Account Type: The fundamental classification of this account:
  • Asset (A): Resources owned — cash, inventory, equipment, receivables
  • Liability (L): Obligations owed — accounts payable, loans, accrued expenses
  • Owner’s Equity (O): Net worth — retained earnings, capital stock
  • Revenue (R): Income earned — sales, service revenue, interest income
  • Expense (E): Costs incurred — COGS, salaries, rent, utilities
  • Memo (M): Statistical accounts that do not affect the financial statements
• Account Sign: Natural sign for the account — Debit for Assets and Expenses, Credit for Liabilities, Equity, and Revenue. This controls how balances are displayed in reports.
• Is Summary: Whether this is a parent (grouping) account or a posting (detail) account. Only non-summary accounts can receive postings. Summary accounts are used for rollup totals in the tree hierarchy.
• Is Document Controlled: When checked, the account requires a business partner or document reference on every posting. This is typically set for Accounts Receivable and Accounts Payable accounts.
• Post Actual / Post Budget / Post Statistical: Controls what types of journal entries can post to this account.

Natural Account Segment

The natural account is the most important segment of any accounting combination. It answers the question “what type of financial event is this?” While other dimensions tell you who, where, or which project, the natural account tells you what — is this revenue? An expense? An asset? The natural account is the one mandatory element in every accounting schema.

A typical Chart of Accounts numbering convention:

Account Combinations (C_ValidCombination)

An Account Combination is a specific, validated combination of accounting dimension values. It is the full “address” for a financial posting. For example, if your schema has Organization, Account, and Product dimensions active, a valid combination might be:

Organization: HQ
Account:      4000 (Sales Revenue)
Product:      Oak Table

The C_ValidCombination table stores these pre-validated combinations. When a document is posted, the system constructs the account combination using default accounts, document attributes, and accounting rules, then looks up or creates the corresponding valid combination.

You generally do not create account combinations manually. They are generated automatically when:

• Default accounts are defined (see next section)
• Documents are posted for the first time with a new combination of dimension values
• GL Journal lines are entered with a new combination

Default Accounts

Default accounts are the key link between business transactions and the General Ledger. They tell iDempiere which accounts to debit and credit when a specific type of transaction occurs. Default accounts are configured at several levels:

Accounting Schema Defaults

The Accounting Schema window has a Defaults tab that defines fallback accounts used when no more specific default is available. These include:

• Intercompany Due To / Due From: For inter-organization transactions
• Suspense Balancing / Suspense Error: Catch-all accounts for unbalanced entries and posting errors
• Currency Balancing: For rounding differences in multi-currency conversions
• Retained Earnings: Where year-end net income is closed

Product Category Accounting

Each Product Category has an Accounting tab that defines product-related posting accounts:

• Product Asset: Inventory account (debit when goods are received)
• Product Expense: Expense account (debit for non-stocked items or services)
• Product COGS: Cost of Goods Sold (debit when goods are shipped to customers)
• Product Revenue: Revenue account (credit when customer invoices are posted)
• Work in Process: WIP account (debit during manufacturing, credit when finished goods are received)
• Floor Stock / Method Change / Usage Variance / Rate Variance: Manufacturing variance accounts

Business Partner Group Accounting

Each Business Partner Group has an Accounting tab defining:

• Customer Receivable: The AR account (debit on customer invoices)
• Customer Prepayment: Account for advance payments from customers
• Vendor Liability: The AP account (credit on vendor invoices)
• Vendor Prepayment: Account for advance payments to vendors
• Vendor Service Receivable: For accrual of services not yet invoiced
• Not Invoiced Receipts: Goods received but not yet invoiced (accrual account)

Bank Account Accounting

Each Bank Account has accounting defaults for:

• Bank In Transit: Temporary account for payments being processed
• Bank Asset: The actual bank account in the GL
• Bank Unallocated Receipt: For received funds not yet matched to invoices
• Bank Expense / Interest Revenue / Interest Expense: For bank charges and interest

Tax Accounting

Each Tax Rate definition has accounts for:

• Tax Due: Output tax collected from customers (liability)
• Tax Credit: Input tax paid to vendors (asset, offset against Tax Due)
• Tax Expense: Non-recoverable tax portions treated as expense

Charge Accounting

Each Charge defines a specific expense or revenue account for miscellaneous transactions (freight charges, handling fees, etc.).

Tree Hierarchy (AD_Tree)

iDempiere uses tree structures (AD_Tree) to organize accounts hierarchically for reporting and rollup purposes. The account tree defines parent-child relationships between accounts:

1000 Current Assets (Summary)
├── 1100 Cash and Cash Equivalents (Summary)
│   ├── 1110 Petty Cash
│   ├── 1120 Operating Bank Account
│   └── 1130 Savings Account
├── 1200 Accounts Receivable (Summary)
│   ├── 1210 Trade Receivables
│   └── 1220 Other Receivables
└── 1300 Inventory (Summary)
    ├── 1310 Raw Materials
    ├── 1320 Work in Process
    └── 1330 Finished Goods

Summary (parent) accounts aggregate the balances of their child accounts in financial reports. You define the tree structure in the Tree Maintenance window by dragging accounts into the desired hierarchy, or through the Account Element Value window’s parent assignment.

The tree is referenced by the Account Element, and the Accounting Schema uses the element, thus linking the tree to all financial reporting within that schema.

Posting Logic — How Documents Become Journal Entries

Understanding how iDempiere transforms business documents into accounting entries is essential. The posting process follows a consistent pattern:

The Posting Trigger

When a document is completed (status changes to CO), the system automatically triggers the posting engine. The engine examines the document type and calls the appropriate posting logic. Each document type has its own posting class (Java code) that defines the debit/credit rules.

Example: Customer Invoice Posting

When a customer invoice for $1,000 (plus $100 tax) is completed, the posting engine generates:

The system determines each account by looking up the default accounts configured on the relevant master data (business partner group, product category, tax rate), then constructing valid account combinations that include the natural account plus any active dimensional segments.

Example: Material Receipt Posting

When goods are received from a vendor (material receipt completed):

Later, when the vendor invoice arrives and is matched to the receipt, the Not Invoiced Receipts account is reversed and Accounts Payable is credited.

Fact_Acct — The Actual Postings Table

All posted journal entries are stored in the Fact_Acct table. This is the most important table in iDempiere’s financial module — it is the General Ledger in table form. Key fields include:

• AD_Table_ID / Record_ID: Links back to the source document (invoice, payment, receipt, etc.)
• Account_ID: The natural account (C_ElementValue)
• C_AcctSchema_ID: Which accounting schema this posting belongs to
• DateAcct: The accounting date (determines the period)
• DateTrx: The transaction date
• AmtSourceDr / AmtSourceCr: Debit and credit amounts in the source (transaction) currency
• AmtAcctDr / AmtAcctCr: Debit and credit amounts in the accounting schema’s base currency
• C_Currency_ID: The source currency
• Qty: The quantity associated with the posting (for inventory-related entries)
• PostingType: Actual (A), Budget (B), Statistical (S), Commitment (E), or Reservation (R)

Dimensional fields on Fact_Acct mirror the schema elements: AD_Org_ID, C_BPartner_ID, M_Product_ID, C_Project_ID, C_Campaign_ID, C_SalesRegion_ID, C_Activity_ID, User1_ID, User2_ID. This enables multi-dimensional reporting directly from the posting table.

GL Journal — Manual Entries

While most accounting entries are generated automatically from business documents, some entries must be created manually. The GL Journal window (under Performance Analysis → Accounting Rules) is used for:

• Accruals and deferrals (prepaid expenses, deferred revenue)
• Depreciation entries (if not using a fixed assets module)
• Adjusting entries at period-end
• Reclassification entries (moving balances between accounts)
• Opening balance entries for system go-live
• Intercompany entries

GL Journal Structure

GL Journals have a two-level structure:

• GL Journal Batch (GL_JournalBatch): A container for grouping related journals. The batch has an accounting date, description, and document status. Batches can be posted or reversed as a unit.
• GL Journal (GL_Journal): The journal header, containing the accounting date, currency, GL Category, and document type. Each journal can have multiple lines.
• GL Journal Line (GL_JournalLine): Individual debit/credit entries. Each line specifies an account combination, debit amount, credit amount, and optional description.

The total debits on a journal must equal the total credits — the system enforces this when you complete the journal. Multi-currency journals are supported, with the system automatically calculating the accounting-currency amounts using the defined exchange rate.

GL Category

Every GL Journal is assigned a GL Category that classifies the type of entry (e.g., “Manual”, “Adjustment”, “Accrual”, “Revaluation”). GL Categories are defined in the GL Category window and are used for filtering and reporting. iDempiere also automatically assigns GL Categories to system-generated postings based on the document type.

Period Management

Accounting periods control when transactions can be posted. iDempiere uses a calendar-based period system:

• Calendar (C_Calendar): Defines the fiscal year structure for the organization
• Year (C_Year): A fiscal year within the calendar
• Period (C_Period): Typically one month, with a start date and end date

Each period has a Period Status that controls posting:

• Never Opened (N): The period has not been opened yet — no postings allowed
• Open (O): Transactions can be posted to this period
• Close (C): The period is closed — standard users cannot post, but it can be reopened
• Permanently Closed (P): The period is permanently closed — no further postings under any circumstances

Period control can be configured at the document type level through Period Control records, allowing granular control. For example, you might close AP for a period while keeping GL Journals open for adjustments.

Multiple Accounting Schemas

As mentioned earlier, iDempiere supports multiple accounting schemas for parallel accounting. Common scenarios include:

• Local GAAP + IFRS: A company maintaining books under both the local accounting standard and International Financial Reporting Standards
• Different currencies: A subsidiary maintaining books in local currency but also in the parent company’s reporting currency
• Tax vs. Management accounting: Separate schemas with different depreciation methods or cost allocations

When multiple schemas are active, every document posting generates Fact_Acct entries for each schema. Reports can be run against any schema, providing a complete, independent set of financial statements for each accounting framework.

Example: Setting Up a Chart of Accounts from Scratch

Here is a step-by-step walkthrough of creating an accounting foundation in iDempiere:

Step 1: Create the Account Element

• Open the Account Element window
• Create a new element named “Natural Account”
• Set Element Type to “Account”
• The system will automatically create a tree for this element

Step 2: Define Element Values (Accounts)

• On the Element Value tab, create your chart of accounts
• Start with summary (parent) accounts for major categories: Assets, Liabilities, Equity, Revenue, Expenses
• Then create detail (posting) accounts under each summary account
• Set the Account Type, Account Sign, and Is Summary flag correctly for each account
• Mark AR and AP accounts as Document Controlled

Step 3: Organize the Tree Hierarchy

• Open Tree Maintenance and select the account tree
• Arrange accounts into the desired parent-child hierarchy
• Verify that summary accounts properly contain their child accounts

Step 4: Configure the Accounting Schema

• Open the Accounting Schema window
• Set the GAAP type, costing method, and base currency
• On the Schema Element tab, ensure the Account element is active and pointing to your element
• Activate any additional dimensions you need (Organization, Product, Project, etc.)
• On the Defaults tab, set the system-level default accounts

Step 5: Set Default Accounts on Master Data

• Open each Product Category and configure the Accounting tab with appropriate inventory, COGS, revenue, and expense accounts
• Open each Business Partner Group and configure the Accounting tab with AR and AP accounts
• Open each Bank Account and configure the Accounting tab with the bank asset account
• Open each Tax Rate and configure the Accounting tab with tax due, tax credit, and tax expense accounts

Step 6: Define the Calendar and Periods

• Open the Calendar, Year, Period window
• Create a calendar for the organization
• Create a year and use the “Create Periods” process to automatically generate 12 monthly periods
• Open the current period

Step 7: Test with a GL Journal

• Create a GL Journal with a simple debit/credit entry
• Complete it and verify the posting in the Fact_Acct records
• Run a Trial Balance report to see your entry reflected

Summary

The accounting foundation in iDempiere consists of several interrelated components: the Accounting Schema defines the framework and dimensions, Account Elements and Element Values define the Chart of Accounts, Account Combinations provide the full address for every posting, Default Accounts link business transactions to the GL, and the Tree Hierarchy enables rollup reporting. Documents automatically generate journal entries in the Fact_Acct table, while GL Journals handle manual entries. Period Management controls when postings can occur, and multiple schemas support parallel accounting under different standards.

With this foundation in place, the next lesson covers Accounts Payable and Accounts Receivable — the daily transaction processing that generates most of the activity in your General Ledger.