Akuntansi Multi-Currency di ERP: Kurs, Laba Selisih, Rounding IDR

Pertama kali klien meminta saya menambahkan invoice USD ke ERP berbasis IDR, estimasi saya dua minggu. Perubahan skemanya selesai dua hari. Tiga bulan sisanya habis untuk semua hal di sekelilingnya: kurs mana yang berlaku di tanggal mana, apa yang terjadi saat invoice USD dibayar dengan kurs berbeda, bagaimana revaluasi akhir bulan bekerja, dan kenapa laporan AR aging tiba-tiba menampilkan customer berutang minus 37 rupiah. Multi-currency bukan sekadar field di form — ini subsistem akuntansi.

Artikel ini adalah desain yang saya harap saya punya sejak hari pertama, dibentuk dari pengalaman membangun AP/AR untuk ANCoraPRO di NestJS dan PostgreSQL: data model dua mata uang, pipeline kurs, laba rugi realized versus unrealized, dan realita rounding mata uang fungsional yang praktis tidak punya angka desimal.

Data Model: Setiap Line Membawa Dua Mata Uang

Aturan yang tidak bisa ditawar dari IAS 21, standar akuntansi yang mengatur efek selisih kurs: entitas membukukan dalam mata uang fungsionalnya — untuk perusahaan Indonesia, hampir selalu IDR — dan transaksi mata uang asing ditranslasikan dengan kurs pada tanggal transaksi. Skema Anda harus mencerminkan dualitas itu di setiap line moneter: nilai dokumen dalam mata uang transaksi, dan nilai yang dibukukan dalam mata uang fungsional, dikonversi sekali saat posting lalu dibekukan.

Dibekukan adalah kata kuncinya. Kelas bug multi-currency terbesar yang saya lihat di ERP custom adalah hanya menyimpan nilai asing lalu mengonversi saat dibaca, memakai kurs terkini. Akibatnya laporan berubah retroaktif setiap tabel kurs di-update, dan dua cetakan ledger yang sama tidak cocok. Simpan kurs yang dipakai, simpan nilai hasil konversi, dan jangan pernah menghitung ulang keduanya:

-- Every monetary line stores BOTH currencies, always
CREATE TABLE journal_line (
  id                  BIGSERIAL PRIMARY KEY,
  journal_entry_id    BIGINT NOT NULL REFERENCES journal_entry(id),
  account_id          BIGINT NOT NULL REFERENCES account(id),
  -- transaction (document) currency
  currency_code       CHAR(3) NOT NULL,        -- 'USD', 'SGD', ...
  amount_txn          NUMERIC(18,2) NOT NULL,  -- signed
  -- functional currency (IDR), converted at posting time
  exchange_rate       NUMERIC(18,6) NOT NULL,  -- rate USED, frozen
  amount_functional   NUMERIC(18,0) NOT NULL   -- IDR has no cents
);

-- The rate table keeps history; never overwrite a rate
CREATE TABLE exchange_rate (
  currency_code  CHAR(3) NOT NULL,
  rate_date      DATE NOT NULL,
  rate           NUMERIC(18,6) NOT NULL,  -- 1 unit -> IDR
  source         TEXT NOT NULL,           -- 'BI_JISDOR' | 'MANUAL'
  PRIMARY KEY (currency_code, rate_date)
);

Perhatikan amount_functional adalah NUMERIC tanpa desimal. IDR modern tidak punya subunit yang terpakai — sen ada di undang-undang tapi tidak di pembayaran — jadi membukukan nilai fungsional dalam rupiah utuh sejak awal menyelamatkan Anda dari saldo pecahan hantu di kemudian hari. Sisi mata uang transaksi tetap dua desimal karena USD, SGD, dan EUR memang memakainya.

Kurs: Satu Pipeline, Tiga Jenis Kurs

Keputusan desain kedua adalah kurs mana berlaku kapan. Dalam praktik di Indonesia Anda akan berurusan dengan sampai tiga keluarga kurs, dan tabel kurs Anda harus tahu yang mana:

• Kurs transaksi — kurs pada tanggal dokumen, dipakai membukukan invoice dan tagihan. Kebanyakan klien memakai kurs referensi JISDOR dari Bank Indonesia untuk USD; dipublikasikan per hari kerja dan paling tidak bisa diperdebatkan saat audit.
• Kurs pajak — Kementerian Keuangan menerbitkan kurs mingguan yang wajib dipakai untuk dokumen pajak. Invoice Anda bisa sah membawa satu kurs untuk akuntansi dan kurs lain untuk perhitungan PPN; desain untuk kedua field, jangan asumsikan sama.
• Kurs penutup — kurs pada tanggal neraca, dipakai merevaluasi saldo moneter terbuka di akhir bulan sesuai IAS 21. Inilah yang menggerakkan laba rugi unrealized.

Secara operasional saya memperlakukan kurs sebagai data referensi append-only dengan kolom source: fetch harian otomatis menulis baris BI_JISDOR, finance bisa memasukkan override MANUAL untuk mata uang yang tidak tercakup feed, dan tidak ada yang meng-update baris yang sudah ada. Kalau ada kurs salah, Anda memasukkan kurs koreksi dan mem-posting ulang dokumen terdampak secara sengaja — perbaikan retroaktif diam-diam adalah awal pembukuan berhenti rekonsil.

Laba Selisih Kurs Realized vs Unrealized: Dua Peristiwa Berbeda

Selisih kurs datang dalam tepat dua rasa, dan mencampuradukkannya adalah bug konseptual paling umum di modul multi-currency buatan sendiri:

Logika pelunasan layak diberi contoh kerja, karena invariant subledger yang dilindunginya adalah yang menjaga AR dan AP tetap jujur:

Worked example — realized FX gain on a USD invoice

Day 1   Invoice issued      USD 10,000  @ 16,200  = IDR 162,000,000
            DR  Accounts Receivable   162,000,000
            CR  Revenue               162,000,000

Day 35  Payment received    USD 10,000  @ 16,450  = IDR 164,500,000
            DR  Bank                  164,500,000
            CR  Accounts Receivable   162,000,000
            CR  FX Gain (realized)      2,500,000

The AR subledger must close to EXACTLY zero in BOTH currencies:
USD 10,000 - 10,000 = 0   and   IDR 162,000,000 - 162,000,000 = 0
The 2,500,000 difference NEVER touches AR — it goes to FX gain.

Invariant itu — open item harus menutup ke nol di mata uang transaksi DAN mata uang fungsional — adalah hal yang harus dites tanpa ampun. Setiap pembayaran parsial, setiap credit note, setiap write-off wajib mempertahankannya. Mesin akuntansi Odoo melakukan hal yang sama dengan jurnal exchange difference otomatisnya: selisih dibukukan ke akun FX khusus, tidak pernah ke piutangnya sendiri.

Revaluasi Akhir Bulan Tanpa Drama

FX unrealized adalah batch job, dan cara paling bersih yang saya temukan untuk menjalankannya di ERP custom adalah prosedur empat langkah yang sepenuhnya bisa dibalik:

1. Pilih semua item moneter terbuka dalam mata uang asing: line AR dan AP yang belum dibayar, rekening bank valas, uang muka dan deposit.
2. Revaluasi masing-masing dengan kurs penutup tanggal akhir periode dan hitung delta terhadap nilai buku fungsionalnya saat ini.
3. Posting satu jurnal revaluasi per mata uang, bertanggal hari terakhir periode, terhadap akun laba dan rugi FX unrealized.
4. Posting pembalik otomatis bertanggal hari pertama periode berikutnya. Pelunasan kemudian menghitung selisih realized terhadap kurs pembukuan asli, tidak terganggu noise revaluasi.

Realita Rounding IDR

Rounding terdengar seperti catatan kaki sampai trial balance Anda selisih 1 rupiah dan auditor ingin tahu kenapa. Aturan yang sekarang saya bangun sejak awal:

• Round di level line, sekali, saat posting — half-up ke rupiah utuh untuk nilai fungsional. Menjumlahkan line yang sudah dibulatkan itu stabil; membulatkan hasil penjumlahan tidak bisa direproduksi dari komponennya.
• Paksa jurnal balance setelah rounding: kalau debit dan kredit selisih beberapa rupiah akibat rounding per line, posting selisihnya ke akun rounding khusus secara otomatis. Jangan biarkan posting gagal atau, lebih buruk, mengakali line sungguhan.
• Simpan kurs dengan enam desimal. Kuotasi bergaya JISDOR membawa presisi lebih dari dua desimal, dan memotong kurs adalah sumber drift kumulatif diam-diam di akun bervolume tinggi.
• Selesaikan residu kecil otomatis: pembayaran yang menyisakan saldo terbuka di bawah ambang yang bisa dikonfigurasi, misal 100 rupiah, sebaiknya otomatis di-write-off ke akun rounding alih-alih menghantui AR aging selamanya.

Tidak ada ilmu komputer canggih di sini. Ini cuma soal memutuskan kebijakan secara eksplisit, mengodekannya di satu tempat — service posting — dan menolak membiarkan tiap layar berhitung sendiri-sendiri.

Intinya

Akuntansi multi-currency di ERP berdiri di empat kaki: penyimpanan dua mata uang dengan kurs yang dibekukan, pipeline kurs append-only yang disiplin, pemisahan ketat selisih realized dan unrealized, dan kebijakan rounding eksplisit yang ditegakkan di lapisan posting. Benahi itu semua dan sisanya — laporan, dashboard, aging — mengikuti dengan sendirinya, karena angka dasarnya bisa dipercaya.

Dan sebelum menulis kode apa pun, duduklah dengan akuntan klien selama satu jam dan sepakati kurs mana berlaku untuk dokumen mana. Percakapan itu lebih murah daripada refactor mana pun yang akan Anda lakukan.