Change of Functional Currency Due to the Rupiahization of Domestic Transactions in Indonesia

When revaluing foreign exchange for receivables and payables at month-end, if the gain or loss compared to the previous month’s assets is significant, the separation method updates the invoice price to the latest valuation amount. If the gain or loss compared to the acquisition cost is significant, the reversal method reverses the valuation to the acquisition cost at the beginning of the following month.

The Temperature Gap Between Accounting and Taxation

Since July 2015, the Bank of Indonesia (BI) has mandated that domestic transactions in Indonesia be conducted primarily in rupiah.
However, according to an accounting staff member I recently met at a client’s office in Bandung, by applying to BI and obtaining approval, certain transactions with specific partners can exceptionally be conducted in US dollars. They mentioned having visited BI in Jakarta for this application.
That said, this is considered a gray-area workaround. BI’s fundamental policy remains unchanged, and there are likely restrictions based on the size of the applying company, the transaction partner, or the transaction volume.
On the taxation side, however, if the Indonesian Tax Office (Kantor Pajak) permits reporting in US dollars, companies must continue dollar-based reporting for five years. For example, a company that began accounting in January 2011 is required to submit dollar-based tax reports until the end of its fifth period in December 2016.
This means that BI’s push for rupiah-based accounting contrasts with the Tax Office’s policy, creating a temperature gap. The issue here is that even if the accounting system switches to rupiah in January 2016, dollar-based financial statements and tax reports are still required for one year.

The base currency for accounting is called the Functional Currency (Base Currency), while the currency used for tax reporting is known as the Presentation Currency.

Foreign Exchange Differences in Foreign Currency Transactions

To fulfill the one-year tax reporting obligation, conversion to the presentation currency is necessary, resulting in three foreign exchange conversion flows within accounting operations: "Foreign Currency → Functional Currency → Presentation Currency."

The foreign exchange gain/loss from revaluing A/P (Accounts Payable) debt at the month-end rate is called Unrealized Forex Gain, as it represents a "latent profit"—a potential (valuation-based) profit at a given point in time.
In contrast, the foreign exchange gain/loss at A/P settlement is distinguished as Realized Forex Gain. This requires clarity on what causes the confirmed exchange gain/loss upon settlement or conversion (e.g., dollar conversion), such as which invoice or journal entry it originates from.
However, if the transaction rate uses the previous month-end rate as a uniform Flat Rate, the settlement rate is already the prior month-end rate, so no realized gain/loss occurs.

Timing of Conversion to Presentation Currency

The purpose of converting financial statements from a rupiah-based Functional Currency to a dollar-based Presentation Currency is, as mentioned, for tax reporting or preparing Consolidated Financial Statements.
In systems supporting multiple functional currencies, journal entries are generated in multiple functional currencies with each transaction input. Conversion to the presentation currency occurs via batch processing at month-end (or period-end), using either the Historical Rate, Last Rate (period-end rate), or Average Rate.

When the conversion rate is the transaction rate, conversion occurs at the journal entry level. However, the settlement exchange gain/loss or month-end revaluation mentioned above corrects the impact of yen (foreign currency) fluctuations on rupiah, rendering it meaningless for the presentation currency (dollar).
Thus, implementing accurate conversion to the presentation currency via month-end batch processing is extremely challenging, distinguishing it from systems supporting multiple functional currencies.

Key Points for Implementing Accounting Systems in Indonesia

Compliance with International Financial Reporting Standards (IFRS)

Accounting systems used by Japanese companies in Indonesia broadly fall into low-cost local vendor systems, mid-range foreign systems (from the US, Japan, Europe), and high-end systems like SAP (Germany).
When implementing accounting systems in Indonesia, compliance with IFRS (International Financial Reporting Standards) has long been emphasized. Indonesia has encouraged IFRS awareness relatively early, with higher consciousness than Japan regarding revenue/expense recognition standards, fair value measurement, and fixed asset depreciation methods.
IFRS aims to provide investors and creditors with information necessary for assessing enterprise value.
To this end, it involves fair value measurement of fixed asset impairments/revaluations and marketable financial assets, ensuring the Balance Sheet (B/S) accurately reflects whether the company’s asset condition can generate profits commensurate with its investments.
While IFRS-based financial reporting is needed for consolidated financial statements at Japanese headquarters, the Indonesian Tax Office may not align with this, requiring tax reports to follow local standards.
Thus, an ideal accounting system should implement a multi-standard ledger function, allowing journal entries to be allocated for both Japanese headquarters and Indonesian local reporting.

Exchange Rates

The primary tax consideration when implementing an accounting system in Indonesia is the Value Added Tax (VAT), known locally as PPN (Pajak Pertambahan Nilai).
For tax calculations involving foreign currency transactions, companies must use the Tax Rate published weekly by the Tax Office (Kantor Pajak). Thus, the accounting system needs to maintain both Transaction Rates and Tax Rates in its exchange rate master, referencing the applicable rate during transaction input.
Foreign currency transaction exchange rates can be either the Daily Spot Rate (previous day’s rate) or the Flat Rate (fixed at the previous month-end rate). The former requires a mechanism to automatically generate exchange gain/loss entries at settlement.
At month-end, receivables, payables, cash, and deposits carried forward to the next month are revalued at the month-end rate via a Revaluation process in the system.

Faktur Pajak (Tax Invoice) Issuance Function

Indonesia adopts an invoice-based system rather than a ledger-based one, calculating tax amounts based on Faktur Pajak (Tax Invoices).
Faktur Pajak must be attached to invoices for tax payments or refund claims, but its format changes periodically, requiring system adjustments each time.
PPN payments or refunds are calculated based on Faktur Pajak, offsetting Output PPN (charged on sales) against Input PPN (charged on purchases). If Output PPN exceeds Input PPN, tax is paid; if Input PPN exceeds Output PPN, a refund is claimed.
Since 2019, Faktur Pajak has been issued via the desktop E-Faktur application, and from 2025, via the online coretax system, eliminating the need for layout adjustments in accounting systems.

Features of Multi-Currency Accounting Systems

Corporate transactions are recorded in the Original Currency (transaction currency) for accounting purposes but are converted to the Functional Currency (Base Currency) when posted to the General Ledger (G/L), retaining both transaction and functional currency amounts in the ledger.
In Indonesia, only rupiah or dollars are recognized as functional currencies. Transaction inputs are journalized in the transaction currency, converted to the functional currency upon posting, and the P/L and B/S are prepared in the functional currency. Tax reports to the Tax Office are also submitted in the functional currency (rupiah or dollar only).
Though termed multi-currency transactions, taxes are naturally paid in rupiah (the national currency). Tax payment amounts for foreign currency transactions are converted to rupiah using the Tax Rate published every Wednesday by the Tax Office (Kantor Pajak).
For a system to support multi-currency accounting, the following functions are required:

If submitting financial statements in both rupiah and yen for Japanese headquarters, a rupiah-based functional currency system must simultaneously generate entries treating non-yen currencies as foreign for yen-based statements.
To create Trial Balances (T/B) in both rupiah and dollars, separate ledgers are theoretically needed, but few commercial packages support multiple functional currencies.
However, as IFRS compliance becomes more critical, the demand for multiple functional currency support is expected to grow.
When offsetting entries to correct foreign currency transaction entries, failing to input the transaction rate can result in a zero balance in the transaction currency but a remaining balance in the functional currency, requiring caution.
To change the functional currency (e.g., from dollar to rupiah), all past realized exchange gain/loss entries (difference between occurrence and settlement rates) and unrealized exchange gain/loss entries (difference between occurrence and month-end rates) for receivables/payables must be deleted to revert to the acquisition valuation. After clearing at the settlement rate, realized exchange gains/losses in the new functional currency (rupiah) are recorded.
Since July 2015, the Bank of Indonesia has mandated that domestic cash and non-cash transactions be conducted in rupiah to stabilize exchange rates.

Exchange Gain/Loss Processing for Purchases and Settlements

For a company with a rupiah functional currency purchasing 100 yen (A/P liability), where the rate at occurrence is 1 yen = Rp.98 and at settlement becomes yen-strong at 1 yen = Rp.100, the entries are as follows:

To clear A/P in both transaction and functional currencies, the rate at purchase is applied at settlement.
Here, the increase from ￥100 at occurrence (￥100 x Rp.98 = Rp.9,800) to ￥100 at settlement (￥100 x Rp.100 = Rp.10,000)—Rp.200—is recorded as a foreign exchange loss.
In accounting systems allowing different currency accounts on debit and credit, the transaction currency may not balance, but the functional currency must always balance.
When implementing only the ledger module, the system automatically references the current day’s rate from the exchange rate master at settlement.
To apply the A/P occurrence rate for clearing and generate an exchange gain/loss entry based on the difference with the settlement rate, the system needs a function to manually adjust the rate on the debit side of the journal entry screen.

Exchange Gain/Loss Processing for Sales and Collections

Similarly, ensuring balance in the functional currency, exchange gains/losses are recorded in the functional currency.
For A/R (Accounts Receivable) from $1,000 at occurrence ($1,000 x Rp.9,000 = Rp.9,000,000) to $1,000 at collection ($1,000 x Rp.9,200 = Rp.9,200,000), the Rp.200,000 increase is recorded as a foreign exchange gain:

A/R and A/P Foreign Exchange Revaluation Before Month-End Closing

When carrying A/P and A/R balances forward to the next month, they must be revalued at the month-end rate.
If the mid-month rate is fixed at the previous month-end rate, A/R and A/P balances can be collectively revalued. However, if rates vary by transaction date, revaluation must be calculated against the rate at occurrence.
To record exchange gain/loss from revaluation as the difference from the beginning-of-year valuation, B/S assets in transaction currency are revalued at the month-end rate just before closing, then offset (re-classed) at the start of the next month.

The ￥100 at A/P occurrence (￥100 x Rp.98 = Rp.9,800) corresponds to ￥103.2 at the start of the next month (￥103.2 x Rp.95 = Rp.9,800), so the difference in functional currency is processed in transaction currency.

Process of Changing Functional Currency from Dollar to Rupiah

Since July 2015, domestic transactions have been mandated to be rupiah-based, inevitably shifting accounting to rupiah as well. Among Japanese manufacturers in Indonesia, a trend is emerging to change the functional currency of accounting systems from dollar to rupiah.
In 2015, beyond this functional currency issue, VAT reporting via Tax Invoices (Faktur Pajak) became fully online with e-Faktur, and contracts for domestic commerce were recommended to be in Indonesian, marking a year of significant business practice changes.
Changing the functional currency requires a cutoff at a specific point (typically the start of the fiscal year) to switch the system’s basic parameters from dollar to rupiah.

The workflow follows the above steps, but the key is aligning the opening balances of A/R and A/P accounts and the Trial Balance (T/B) in rupiah.
Adjustments like Debit Notes or Credit Notes for A/R and A/P are manageable, but processes impacting only the G/L, such as exchange or tax adjustments, can disrupt balance alignment.

Foreign Currency Revaluation

Foreign currency revaluation applies to A/R and A/P, as well as other current assets and liabilities. Changing the functional currency naturally swaps dollar and rupiah as the currencies subject to revaluation.
Cross-currencies like yen, Singapore dollar, and Thai baht relative to rupiah remain subject to conversion, but the base becomes rupiah.
For accounting transaction rates, the Bank of Indonesia’s middle rate (TTM) is commonly used for all buying and selling transactions. While Tokyo Mitsubishi’s (BOTM) TTM could be used, it’s a commercial bank rate, making BI’s rate safer.
Systems can differentiate between TTS (bank’s selling rate) for purchases and TTB (bank’s buying rate) for sales, but this can cause management issues if same-day buying and selling in foreign currency differ in functional currency.
Some companies use the previous month-end rate as a flat rate for the month’s transactions, avoiding realized exchange gains/losses at settlement but potentially incurring unrealized gains/losses during month-end revaluation.
In this case, the exchange rate master’s transaction rate retains the previous month-end rate at month-end, requiring a separate Revaluation rate alongside Transaction and Tax rates.

Separation Method vs. Reversal Method

Foreign currency revaluation methods include the Separation Method (separating acquisition cost) and the Reversal Method (maintaining acquisition cost).
In the Separation Method, the P/L reflects the gain/loss compared to the previous month-end, adjusting the B/S valuation monthly. In the Reversal Method, month-end revaluation entries are reversed at the start of the next month, resetting them, so the P/L reflects the gain/loss compared to the acquisition date, adjusting the B/S valuation monthly.