Multi-Currency and Multi-Org Accounting

Overview

• What you’ll learn:
  • How iDempiere manages currencies, conversion rates, and the currency conversion process that occurs during document posting
  • How to handle multi-currency invoices, calculate unrealized gains and losses, and perform currency revaluation at period end
  • How to structure multi-organization environments, process inter-organization transactions, build organizational hierarchies, and perform financial consolidation with elimination entries
• Prerequisites: Lesson 37 — Cost Management and Costing Methods (understanding of accounting schemas and financial posting)
• Estimated reading time: 25 minutes

Introduction

Businesses that operate across borders or serve international customers face two fundamental accounting challenges. First, transactions occur in multiple currencies, and exchange rates fluctuate constantly — creating gains and losses that must be recognized in the financial statements. Second, organizations with multiple legal entities must consolidate their individual financial results into a single set of group-level statements, eliminating inter-company transactions that would otherwise inflate the group’s revenue and expenses.

iDempiere addresses both challenges with built-in multi-currency support and a flexible multi-organization architecture. This lesson explains how currency management and multi-org accounting work in practice, from the moment a foreign-currency invoice is entered through to the consolidated financial statements.

Currency Management

Every monetary transaction in iDempiere involves at least one currency, and many involve two or three. Understanding the currency types is the starting point.

Currency Types

• Functional Currency: The primary currency of the Accounting Schema — the currency in which the general ledger is maintained. For a US-based company, this is typically USD. All accounting entries are ultimately expressed in the functional currency. Each Accounting Schema has exactly one functional currency.
• Transaction Currency: The currency in which a specific business document is denominated. A sales invoice to a European customer might be in EUR, while a purchase order to a Japanese supplier might be in JPY. The transaction currency can differ from the functional currency.
• Reporting Currency: An additional currency used for financial reporting. A subsidiary in Brazil (functional currency BRL) might need to report in USD for the parent company. Reporting currencies are defined as additional Accounting Schemas linked to the primary schema.

C_Currency Table

The C_Currency table stores all currencies available in the system. Each currency record includes:

iDempiere ships with a comprehensive set of world currencies pre-loaded. Administrators typically need only to maintain exchange rates rather than create new currency records.

Conversion Rates (C_Conversion_Rate)

Exchange rates are stored in the C_Conversion_Rate table. Each rate record specifies the conversion factor between two currencies for a given date range and conversion type.

Key Fields

Conversion Rate Types

iDempiere supports multiple conversion rate types through the C_ConversionType table. Common types include:

• Spot: The current market exchange rate. Used for day-to-day transaction conversion. Updated daily (or more frequently for volatile currencies).
• Period End: The exchange rate at the close of an accounting period. Used for balance sheet revaluation of foreign-currency monetary items.
• Company: An internally defined rate that the organization uses for budgeting, planning, or transfer pricing. May differ from the market rate.
• Average: An average rate for a period, sometimes used for income statement conversion in consolidation.

Users can define additional conversion types for specific business requirements. Each document type can be configured to use a specific conversion type by default.

Maintaining Exchange Rates

Exchange rates can be maintained in several ways:

• Manual entry: An administrator enters rates through the Currency Conversion Rate window. This is the most common method for small to medium operations.
• Import: Rates can be imported in bulk from external sources (bank feeds, financial data providers) using the data import framework.
• Automatic feed: Custom integrations can pull rates from APIs (European Central Bank, Open Exchange Rates, etc.) and populate the conversion rate table automatically.

Currency Conversion During Document Posting

When a document with a foreign transaction currency is posted to the general ledger, iDempiere automatically converts the transaction amount to the functional currency. This conversion happens at the posting engine level and follows a specific sequence.

Conversion Process

1. Identify currencies: The posting engine compares the document’s transaction currency against the Accounting Schema’s functional currency.
2. Determine conversion type: The document type’s configured conversion type is used (or Spot as the default).
3. Look up the rate: The system searches the C_Conversion_Rate table for a matching record: source currency, target currency, conversion type, and date range that includes the document’s accounting date.
4. Apply the rate: Transaction amount x MultiplyRate = functional currency amount.
5. Generate accounting entries: Both the source (transaction currency) and the converted (functional currency) amounts are stored in the accounting entries (Fact_Acct table), which carries both AmtSourceDr/Cr and AmtAcctDr/Cr fields.

If no matching conversion rate is found, the posting fails with an error message indicating the missing rate. This is one of the most common posting errors in multi-currency environments and is resolved by entering the required rate.

Multi-Currency Invoice Example

Consider a US company (functional currency USD) receiving an invoice from a European supplier for EUR 10,000:

1. The invoice is entered with currency EUR and amount 10,000.
2. The invoice date is January 15, and the EUR/USD spot rate for that date is 1.0850.
3. When the invoice is posted, the accounting entries are:
   • Debit Expense/Inventory: EUR 10,000 (source) / USD 10,850 (accounting)
   • Credit Accounts Payable: EUR 10,000 (source) / USD 10,850 (accounting)
4. When the payment is made on February 10, the EUR/USD rate is 1.0920:
   • Debit Accounts Payable: EUR 10,000 (source) / USD 10,850 (accounting, original rate)
   • Credit Bank: EUR 10,000 (source) / USD 10,920 (accounting, payment date rate)
   • Debit Realized Exchange Loss: USD 70 (the difference: $10,920 – $10,850)

The $70 represents a realized exchange loss — the euro strengthened between the invoice date and payment date, so the company paid more in USD terms than originally recorded.

Unrealized Gain/Loss Calculation

At each reporting period end, open foreign-currency balances (unpaid invoices, outstanding receivables) must be revalued to the current exchange rate. The difference between the original booking rate and the period-end rate is an unrealized gain or loss — unrealized because the transaction has not yet settled.

Revaluation Process

1. Identify open items: Find all unpaid AP invoices and uncollected AR invoices denominated in foreign currencies.
2. Determine the period-end rate: Use the Period End conversion type rate for the reporting date.
3. Calculate the difference: For each open item, compare the original functional currency amount against the revalued amount at the period-end rate.
4. Generate revaluation entries:
   • If the foreign currency strengthened (liability increased): Debit Unrealized Exchange Loss, Credit Accounts Payable.
   • If the foreign currency weakened (liability decreased): Debit Accounts Payable, Credit Unrealized Exchange Gain.
   • The inverse logic applies for receivables.

Reversal of Unrealized Entries

Unrealized gain/loss entries are typically reversed at the beginning of the next period. When the transaction eventually settles, the full realized gain or loss is calculated against the original booking rate. This approach prevents double-counting: the unrealized entry is temporary (for accurate period-end reporting) and the realized entry at settlement is permanent.

Currency Revaluation Process in iDempiere

iDempiere provides a Currency Revaluation process that automates the unrealized gain/loss calculation. The process parameters include:

• Accounting Schema: The schema whose functional currency is the target.
• Currency Type: Typically “Period End” to use the closing rate.
• Revaluation Date: The period-end date for the revaluation.
• Account types to include: Typically Accounts Payable and Accounts Receivable, but can include bank accounts in foreign currencies.

The process generates a GL Journal with the revaluation entries, which can be reviewed before posting. The reversing entry for the next period opening can be generated automatically.

Multi-Organization Structure

iDempiere’s multi-organization architecture separates a single client into multiple independent (or semi-independent) organizational units. This structure is fundamental to multi-company accounting.

Client and Organization Hierarchy

The hierarchy follows this pattern:

• Client (Tenant): The top-level container. All organizations exist within a single client and share the same system dictionary, security model, and base configuration.
• Organization (*): The asterisk organization represents data shared across all organizations within the client. Master data defined at the * organization (products, business partners, chart of accounts) is visible to all organizations.
• Operating Organizations: Individual legal entities, divisions, branches, or departments. Each operating organization has its own transactions, inventory, and can have its own accounting configuration.

When to Use Multiple Organizations

Multiple organizations are appropriate when:

• Separate legal entities: A holding company with multiple subsidiaries that file separate tax returns and financial statements.
• Geographic divisions: Regional operations that need independent P&L tracking.
• Functional segmentation: Separating manufacturing, distribution, and retail operations for management reporting.
• Regulatory requirements: When regulations require separate books for different business activities.

Shared vs. Organization-Specific Data

Data in iDempiere falls into three categories in a multi-org setup:

• Shared (Org *): Master data like products, business partners, payment terms, and tax categories are typically shared. This ensures consistency and reduces maintenance.
• Organization-specific: Transactions (orders, invoices, payments), inventory, and accounting entries belong to specific organizations. This ensures clear ownership and accountability.
• Configurable: Some data (warehouses, price lists, bank accounts) can be shared or organization-specific depending on business requirements.

Inter-Organization Transactions

When organizations within the same client trade with each other — transferring goods, providing services, or allocating costs — inter-organization transactions are required.

Inter-Org Inventory Transfers

When Organization A transfers goods to Organization B:

1. A Distribution Order or Inventory Movement is created specifying the source org/warehouse and destination org/warehouse.
2. The system generates offsetting accounting entries:
   • Org A: Credit Inventory, Debit Inter-Org Due From B.
   • Org B: Debit Inventory, Credit Inter-Org Due To A.
3. The inter-org due-from/due-to accounts ensure that each organization’s books balance independently.

Inter-Org Invoicing

For internal service charges or transfer pricing between organizations:

1. Organization A creates an AR Invoice to Organization B (using B as the Business Partner).
2. Organization B creates a matching AP Invoice from Organization A.
3. Each organization recognizes the revenue/expense on its own books.
4. The inter-company receivable and payable are tracked in designated inter-org accounts.

Transfer pricing — the price at which inter-org transactions are valued — must comply with tax regulations. Many jurisdictions require arm’s-length pricing (prices comparable to those charged to external parties). The transfer price is set on the inter-org price list or configured through specific pricing rules.

Organizational Hierarchies

iDempiere supports Organization Hierarchies (AD_OrgInfo, AD_Tree) that define reporting relationships between organizations. A hierarchy might look like:

  Group Holding Company
  ├── Manufacturing Division
  │   ├── Plant North
  │   └── Plant South
  ├── Sales Division
  │   ├── Region East
  │   └── Region West
  └── Shared Services

Hierarchies serve two purposes:

• Reporting aggregation: Financial reports can be run at any level of the hierarchy, automatically summing the results of all child organizations.
• Security: Role-based access can be configured to grant access to a hierarchy node and all its children, simplifying permission management for divisional managers.

Financial Consolidation

Consolidation is the process of combining the financial statements of multiple organizations into a single set of group-level statements. This is required whenever a parent company owns subsidiaries and must report group results.

Consolidation Steps

1. Prepare individual statements: Each organization completes its period-end closing and generates its own trial balance, income statement, and balance sheet.
2. Currency translation: If organizations operate in different functional currencies, their financial statements must be translated to the group’s reporting currency. The translation uses:
   • Balance sheet accounts: Translated at the period-end (closing) rate.
   • Income statement accounts: Translated at the average rate for the period (or transaction-date rates if available).
   • Equity accounts: Translated at historical rates.
   • Translation adjustment: The balancing difference is recorded in a Currency Translation Adjustment (CTA) equity account.
3. Elimination entries: Inter-organization transactions must be eliminated to avoid double-counting:
   • Inter-org revenue and cost: If Org A sold $100,000 of goods to Org B, the consolidated statements must eliminate $100,000 of revenue from A and $100,000 of cost from B.
   • Inter-org receivables and payables: The due-from/due-to balances between organizations must net to zero in the consolidated balance sheet.
   • Inter-org profit in inventory: If Org B still holds inventory purchased from Org A at a markup, the unrealized inter-company profit must be eliminated from the consolidated inventory balance.
4. Produce consolidated statements: After translation and elimination, the remaining balances are summed across all organizations to produce the consolidated Balance Sheet, Income Statement, and Cash Flow Statement.

Consolidation in iDempiere

iDempiere supports consolidation through several mechanisms:

• Multi-org reporting: Financial reports can be run for the * (all) organization, which automatically sums all organizations’ balances.
• Reporting currency schema: A secondary Accounting Schema in the group reporting currency can be configured to maintain parallel accounting entries translated at appropriate rates.
• GL Journal for eliminations: Elimination entries are created as GL Journals posted to the parent organization, debiting and crediting the appropriate elimination accounts.

Practical Example: Multi-Company Setup

Consider a group with the following structure:

• Parent Corp (US): Holding company, functional currency USD.
• Mfg GmbH (Germany): Manufacturing subsidiary, functional currency EUR.
• Sales Ltd (UK): Sales subsidiary, functional currency GBP.

Transaction Flow

1. Mfg GmbH manufactures a product at a cost of EUR 80 per unit.
2. Mfg GmbH sells 1,000 units to Sales Ltd at a transfer price of EUR 100 per unit. Mfg GmbH records EUR 100,000 revenue; Sales Ltd records EUR 100,000 cost (converted to GBP at the transaction date rate).
3. Sales Ltd sells 800 units to external customers at GBP 120 per unit. Sales Ltd records GBP 96,000 revenue.
4. At period end, Sales Ltd still holds 200 units in inventory, valued at the transfer price.

Consolidation

1. Translate Mfg GmbH’s EUR statements and Sales Ltd’s GBP statements to USD using appropriate rates.
2. Eliminate the inter-company sale: remove EUR 100,000 revenue from Mfg GmbH and EUR 100,000 COGS from Sales Ltd. The net effect on consolidated P&L is zero for this transaction.
3. Eliminate inter-company receivable/payable: the EUR 100,000 receivable on Mfg GmbH’s books and the corresponding payable on Sales Ltd’s books net to zero.
4. Eliminate unrealized profit in inventory: The 200 units Sales Ltd holds were purchased at EUR 100 (transfer price) but cost EUR 80 to manufacture. The EUR 20 x 200 = EUR 4,000 unrealized inter-company profit must be removed from consolidated inventory.
5. The consolidated result shows only the external revenue (Sales Ltd’s GBP 96,000 translated to USD), the manufacturing cost (Mfg GmbH’s EUR 80 x 800 units for goods sold externally, translated to USD), and the correct inventory valuation for the 200 units at manufacturing cost.

Key Takeaways

• Every transaction in iDempiere carries both a transaction currency and a functional currency amount; the conversion happens automatically during posting using rates from C_Conversion_Rate, matched by currency pair, date, and conversion type.
• Multiple conversion rate types (Spot, Period End, Company, Average) allow different rates for different purposes — daily transactions use Spot, period-end revaluation uses Period End, and budget comparisons can use Company rates.
• Unrealized gains and losses on open foreign-currency items must be recognized at each period end through the currency revaluation process, with the entries reversed at the start of the next period to avoid double-counting when the transactions eventually settle.
• Multi-organization structures separate legal entities, divisions, or branches within a single client, with shared master data at the * organization and transaction-level data owned by individual organizations.
• Inter-organization transactions require offsetting due-from/due-to entries to keep each organization’s books balanced, and transfer pricing must comply with applicable tax regulations.
• Financial consolidation combines the results of all organizations after translating foreign-currency statements and eliminating inter-company revenue, costs, receivables, payables, and unrealized profit in inventory.

What’s Next

The final lesson in this series covers Financial Reporting and Analysis — how to build custom financial reports using iDempiere’s report builder, perform period-end and year-end closing, manage budgets, and create Balance Sheet and P&L reports tailored to your organization’s needs.

  集團控股公司
  ├── 製造事業部
  │   ├── 北方工廠
  │   └── 南方工廠
  ├── 銷售事業部
  │   ├── 東區
  │   └── 西區
  └── 共享服務

  グループ持株会社
  ├── 製造事業部
  │   ├── 北部工場
  │   └── 南部工場
  ├── 営業事業部
  │   ├── 東部地域
  │   └── 西部地域
  └── シェアードサービス