Aakvatech Limited - Multi-Currency Implications on Landed Cost Vouchers

Multi-currency accounting in ERPNext is powerful—but unforgiving when misconfigured. A common implementation error arises when expense accounts are defined in a foreign currency (e.g., USD) while oper

 · 5 min read

This article explains:

  1. How multi-currency works in ERPNext
  2. How Landed Cost Vouchers (LCV) behave in multi-currency environments
  3. Why GL balances balloon when account currency and document currency conflict
  4. How ERPNext should be configured and used correctly

1. Core Concepts: Currency Architecture in ERPNext

To understand the issue, we must distinguish four separate currency layers:

1.1 Company Base Currency

This is the reporting currency (e.g., TZS). All General Ledger (GL) entries are ultimately posted in base currency.

1.2 Account Currency

Each GL account may optionally have a fixed currency.

  • If no currency is set, the account inherits the company base currency.
  • If a currency is specified, transactions must respect that account currency.

If an account is defined in USD:

  • ERPNext expects the transaction to provide USD values.
  • It tracks balances both in USD (account currency) and TZS (base currency equivalent).

1.3 Document Currency

Each transaction (Purchase Invoice, Payment Entry, etc.) has its own currency.

Example:

  • Purchase Invoice Currency = TZS
  • Account Currency = USD

This creates a currency mismatch that must be resolved via exchange rate.

1.4 Exchange Rate

When document currency ≠ account currency, ERPNext requires an exchange rate to compute:

  • Account currency amount
  • Base currency amount
  • Correct GL posting

If exchange rate is missing or implied incorrectly, GL distortions occur.

2. How Landed Cost Voucher (LCV) Works

A Landed Cost Voucher reallocates additional costs (freight, clearing, insurance, etc.) into inventory valuation.

2.1 Accounting Flow of LCV

  1. Purchase Receipt records inventory at supplier invoice value.
  2. LCV allocates additional costs proportionally across items.
  3. ERPNext increases stock valuation.

  4. A GL entry is posted:

    • Debit: Stock / Inventory Account
    • Credit: Expense Clearing or Accrual Account

The LCV does not directly depend on the expense account currency unless the clearing account is foreign currency denominated.

2.2 Multi-Currency Behavior in LCV

If expenses are incurred in USD but base currency is TZS:

  • ERPNext converts USD → TZS using exchange rate.
  • Inventory valuation increases in TZS.
  • GL entries remain consistent if currencies are properly defined.

LCV handles currency conversion correctly because it explicitly calculates conversion during valuation adjustment.

3. What Went Wrong in the Scenario

Setup:

  • Company Base Currency = TZS
  • Expense Account Currency = USD
  • Purchase Invoices entered in TZS
  • No exchange rate defined at invoice level

What Happened:

When the Purchase Invoice was submitted:

  1. ERPNext saw:

    • Document currency = TZS
    • Account currency = USD

  2. Since the expense account was defined in USD:

    • ERPNext expected USD input.
    • It treated the TZS amount as if it were USD.

  3. GL Impact:

    • Debit posted as USD (account currency)
    • Base currency equivalent calculated incorrectly
    • Balance in USD ballooned

This happens because ERPNext assumes:

If account currency is fixed, document must align or explicitly convert.

Without a proper exchange rate defined at document level, ERPNext cannot intelligently infer conversion between TZS and USD.

4. Why ERPNext Behaves This Way

ERPNext’s accounting engine enforces strict currency discipline:

  • Account currency defines how balances are tracked.

  • GL entries must maintain:

    • Account currency balance
    • Base currency equivalent
    • Exchange difference reconciliation

If ERPNext automatically converted TZS to USD without explicit exchange rate, it would:

  • Introduce silent FX assumptions
  • Create reconciliation inconsistencies
  • Corrupt foreign currency revaluation logic

Therefore:

ERPNext does not auto-convert document currency into account currency unless an exchange rate is explicitly provided.

This is by design.

5. Correct Way to Handle Multi-Currency Expenses with LCV

There are two structurally correct approaches.

When to Use

If your Purchase Invoices are recorded in TZS and reporting is primarily in TZS.

Setup

  • Expense Account Currency = blank (inherits TZS)
  • Purchase Invoice Currency = TZS
  • LCV uses TZS amounts

Result

  • No exchange mismatch
  • Clean GL postings
  • No ballooning balances
  • FX handled only where truly required (e.g., foreign suppliers)

This is the simplest and most stable configuration.

Option 2: Proper Foreign Currency Handling

If the expense truly originates in USD (e.g., freight invoice from foreign clearing agent):

Required Configuration

  1. Expense Account Currency = USD
  2. Purchase Invoice Currency = USD
  3. Exchange Rate must be defined at invoice level
  4. Payment Entries must reflect currency correctly

Process Flow

  • Enter Purchase Invoice in USD.
  • ERPNext calculates TZS equivalent using exchange rate.

  • GL posts:

    • USD amount in account currency
    • TZS equivalent in base currency

LCV then:

  • Converts USD to TZS properly
  • Adjusts stock valuation in TZS
  • Maintains currency integrity

This ensures:

  • Correct foreign currency tracking
  • Accurate unrealized gain/loss computation
  • Proper revaluation support

6. What Should Not Be Done

Avoid this hybrid structure:

  • Expense Account = USD
  • Purchase Invoice = TZS
  • No exchange rate
  • Expect ERPNext to auto-convert

This creates:

  • Distorted USD balances
  • Inflated account values
  • Reconciliation nightmares
  • FX revaluation errors

ERPNext assumes:

If the account is USD, transactions should be USD unless explicitly converted.

7. Best Practice Guidelines for ERPNext Multi-Currency + LCV

7.1 Design Principles

  • Base currency accounts for local operational expenses.
  • Foreign currency accounts only for actual foreign-denominated obligations.
  • Never mix document currency and account currency casually.
  • Always define exchange rate when currencies differ.

7.2 LCV Specific Recommendations

  • Clearing accounts used in LCV should usually be base currency.

  • If using foreign currency expenses:

    • Invoice in foreign currency.
    • Let ERPNext compute conversion.
  • Perform regular foreign currency revaluation.

7.3 Internal Controls

  • Lock account currency once in production.
  • Avoid retroactive currency changes.
  • Validate exchange rates at invoice level.
  • Audit GL entries after initial configuration.

8. Conceptual Takeaway

ERPNext is structurally correct in its behavior.

The issue is not that it “does not support” local currency booking into foreign currency accounts. Rather:

ERPNext requires explicit currency alignment between document and account, with defined exchange rate logic.

When that discipline is followed:

  • LCV behaves correctly
  • Inventory valuation remains accurate
  • GL integrity is preserved
  • FX reporting remains consistent

When misaligned:

  • Account balances inflate
  • Foreign currency reports distort
  • Financial statements lose reliability

Conclusion

Multi-currency accounting in ERPNext demands architectural clarity.

For landed cost scenarios:

  • Use base currency accounts unless the expense truly originates in foreign currency.
  • If using foreign currency accounts, ensure the Purchase Invoice currency matches and exchange rates are defined.
  • Never rely on implicit or assumed currency conversion.

Proper configuration ensures:

  • Accurate inventory capitalization
  • Clean GL postings
  • Correct FX accounting
  • Stable financial reporting

In ERPNext, currency discipline is not optional—it is structural.

Published on
Mitesh P Cohksi

No comments yet.

Add a comment
Ctrl+Enter to add comment