Akuntan di perusahaan EMKL menghadapi kompleksitas yang berbeda dari bisnis jasa umum. Saat seorang akuntan bisnis restoran menutup buku — membandingkan penjualan dengan biaya bahan baku dan operasional — akuntan EMKL harus merekonsiliasi puluhan variabel: kasbon driver yang belum di-settle, nota hutang vendor yang muncul belakangan, biaya-biaya pelabuhan yang tidak terduga, dan ini semua harus dicocokkan ke Job Order yang spesifik.

Tidak heran jika banyak perusahaan EMKL mengalami closing bulanan yang memakan waktu 4–7 hari, dengan akuntan yang lembur hingga tengah malam di akhir bulan. Artikel ini membahas akar masalahnya dan bagaimana otomasi jurnal mengubah situasi ini secara fundamental.

Kekhususan Akuntansi EMKL yang Tidak Ditemukan di Bisnis Lain

1. P&L per Job Order — Bukan Hanya per Bulan

Ini adalah kebutuhan terpenting yang membuat akuntansi EMKL unik. Setiap Job Order adalah "mini-proyek" yang harus bisa dihitung profitabilitasnya secara individual:

  • Pendapatan per JO: Freight charge, handling fee, customs brokerage fee, dll. yang ditagihkan ke klien
  • Biaya per JO: Kasbon driver yang di-settle, nota hutang trucker, biaya pelabuhan, biaya customs, agen overseas, dll.
  • Gross profit per JO = Pendapatan – Biaya Langsung

Tanpa sistem yang terhubung, akuntan harus "menjahit" data dari spreadsheet ops, daftar kasbon, dan list nota hutang untuk menghitung ini — proses yang rawan error dan memakan waktu luar biasa.

2. Kasbon Driver: Uang Muka yang Harus Dipertanggungjawabkan

Kasbon adalah mekanisme uang jalan yang diberikan ke driver sebelum berangkat. Satu JO bisa melibatkan kasbon untuk:

  • Biaya solar perjalanan
  • Biaya tol
  • Biaya makan driver selama perjalanan
  • Uang "jasa" untuk proses di pelabuhan
  • Biaya tak terduga di jalan

Setelah delivery, driver harus menyerahkan semua bon untuk dicocokkan dengan jumlah kasbon yang diterima. Jika kasbon Rp 2 juta tapi bon hanya Rp 1,7 juta, sisa Rp 300rb harus dikembalikan. Jika pengeluaran melebihi kasbon, kelebihan bisa jadi tagihan ke perusahaan atau dipotong dari gaji.

Mengelola puluhan kasbon per bulan secara manual — apalagi jika driver tidak rapi menyimpan bon — adalah sumber kebocoran kas dan frustrasi operasional yang sangat nyata.

3. Nota Hutang Vendor yang Datang Belakangan

Berbeda dari bisnis ritel yang langsung bayar, EMKL sering membayar vendor (trucker, forwarder overseas, agen pelabuhan) berhari-hari atau berminggu-minggu setelah service diberikan. Tagihan dari pelabuhan bisa datang 2 minggu setelah barang berangkat. Tagihan trucker mungkin baru masuk di akhir bulan.

Ini menciptakan masalah: bagaimana menentukan biaya yang tepat untuk sebuah JO jika tagihan vendor belum semua masuk? Perusahaan yang mengelola ini secara manual sering menanggung under-reported costs di satu bulan dan over-reported di bulan berikutnya.

4. Multi-Currency untuk Transaksi Internasional

Freight internasional hampir selalu menggunakan USD untuk ocean freight. Biaya di pelabuhan asing mungkin dalam EUR atau JPY. Invoice ke klien bisa dalam IDR tapi ada komponen USD. Kurs berfluktuasi setiap hari.

Tanpa sistem yang mengelola multi-currency dengan benar, rekonsiliasi kurs menjadi mimpi buruk di akhir bulan — terutama untuk memenuhi standar PSAK yang mengharuskan penyesuaian kurs pada tanggal neraca.

Chart of Accounts yang Tepat untuk EMKL

Chart of accounts (COA) yang dirancang khusus untuk EMKL harus mencerminkan alur bisnis freight forwarding. Berikut struktur COA yang kami rekomendasikan:

KODE AKUNNAMA AKUNTIPECATATAN
PENDAPATAN
4-001Pendapatan FreightRevenuePer JO per moda
4-002Pendapatan HandlingRevenueBiaya penanganan kargo
4-003Pendapatan CustomsRevenueFee brokerage kepabeanan
BIAYA POKOK
5-001Biaya TruckingCOGSDari nota hutang trucker
5-002Biaya PelabuhanCOGSTHC, B/L, D/O
5-003Biaya CustomsCOGSBea masuk, PNBP
5-004Kasbon Driver — SettledCOGSOtomatis dari settlement
ASET LANCAR
1-101KasAssetKas fisik di kantor
1-102BankAssetPer rekening bank
1-201Piutang UsahaAssetPer pelanggan, per JO
1-301Kasbon Belum SettleAssetKasbon terbit belum di-settle

Bagaimana Jurnal Otomatis Bekerja di Sistem EMKL Terintegrasi

Kunci dari akuntansi EMKL yang efisien adalah sistem yang men-trigger jurnal akuntansi secara otomatis setiap kali ada transaksi operasional — tanpa input ulang dari akuntan.

Contoh Alur Jurnal Otomatis

Ketika kasbon driver dicairkan (Rp 2.000.000):

  • Debit: Kasbon Belum Settle — Rp 2.000.000
  • Kredit: Kas — Rp 2.000.000
  • → Jurnal terposting otomatis, kasbon tercatat di buku

Ketika driver settle kasbon (bon total Rp 1.750.000, sisa Rp 250.000 dikembalikan):

  • Debit: Biaya Trucking (COGS) — Rp 1.750.000
  • Debit: Kas — Rp 250.000 (pengembalian)
  • Kredit: Kasbon Belum Settle — Rp 2.000.000
  • → Jurnal terposting otomatis, COGS terhubung ke JO yang tepat

Ketika nota hutang vendor diinput (trucker: Rp 4.500.000):

  • Debit: Biaya Trucking (COGS) — Rp 4.500.000
  • Kredit: Hutang Usaha — Rp 4.500.000
  • → Aging hutang terperbarui, laporan AP akurat
Dampak Jurnal Otomatis pada Closing
Saat akuntan membuka modul closing di akhir bulan, semua jurnal dari transaksi operasional sudah ada di buku. Tugas akuntan tinggal: review jurnal penyesuaian (depresiasi, akrual), validasi saldo akhir, dan generate laporan. Tidak ada lagi sesi marathon input jurnal manual.

AI Import Excel Kas: Konversi Ribuan Transaksi dalam Menit

Banyak perusahaan EMKL menerima laporan mutasi rekening bank dalam format Excel atau CSV. Memposting ratusan transaksi bank ke jurnal akuntansi secara manual bisa memakan waktu seharian.

Fitur AI Import Excel Kas di Deltasoft memungkinkan:

  1. Upload file Excel mutasi rekening bank
  2. AI membaca keterangan transaksi dan mencocokkan ke akun yang tepat berdasarkan pola historis
  3. Akuntan mereview dan mengkonfirmasi mapping dalam hitungan menit
  4. Jurnal terposting sekaligus ke GL

Proses yang biasanya 4–6 jam input manual selesai dalam 15–30 menit review.

68%
Closing Lebih Singkat
14h
Rata-rata Closing (dari 3–5 hari)
−82%
Error Jurnal Manual

Laporan Keuangan Wajib untuk Perusahaan EMKL

Dengan sistem terintegrasi, laporan berikut harus bisa di-generate kapan saja — tidak hanya di akhir bulan:

  • P&L per Job Order — profitabilitas setiap pengiriman, bukan hanya agregat
  • Laporan Laba Rugi Bulanan — perbandingan periode vs target
  • Aging Piutang — status penagihan per klien dengan segmentasi umur piutang
  • Aging Hutang — status kewajiban ke vendor berurut prioritas jatuh tempo
  • Laporan Arus Kas — visibility likuiditas real-time
  • Neraca — posisi keuangan perusahaan per tanggal berapapun
  • Laporan Kasbon — status semua kasbon yang belum di-settle per driver
Potong Waktu Closing Anda 68%
Deltasoft menggabungkan operasional EMKL dan akuntansi dalam satu sistem — jurnal terposting otomatis dari setiap transaksi. Closing bulanan dalam 14 jam.
Lihat demo akuntansi → Panduan pilih software EMKL

Pertanyaan yang Sering Ditanyakan

Tantangan unik akuntansi EMKL: (1) P&L per Job Order — setiap pengiriman harus dihitung profitabilitasnya; (2) kasbon driver yang harus direkonsiliasi dengan bon pengeluaran; (3) nota hutang vendor yang datang belakangan setelah JO selesai; (4) multi-currency untuk transaksi internasional; (5) jurnal yang harus mencerminkan status operasional real-time, bukan hanya invoice yang masuk.
Dengan sistem terintegrasi dan jurnal otomatis, closing bulanan EMKL seharusnya selesai dalam 14–24 jam kerja (1–2 hari). Tanpa sistem terintegrasi, rekonsiliasi manual antara data operasional, kasbon, dan akuntansi biasanya membutuhkan 3–5 hari penuh — bahkan lebih untuk perusahaan dengan volume tinggi.
Sistem EMKL terintegrasi seperti Deltasoft mencakup akuntansi GL, AR, AP, dan laporan keuangan lengkap — sehingga tidak perlu sistem akuntansi terpisah. Keunggulannya: jurnal terposting otomatis dari transaksi operasional tanpa input ulang. Ini berbeda dari menggunakan Accurate secara terpisah yang mengharuskan rekonsiliasi manual antara data ops dan data akuntansi.
P&L per Job Order = Pendapatan JO (semua fee yang ditagihkan ke klien untuk JO tersebut) dikurangi Biaya Langsung JO (kasbon driver yang di-settle, nota hutang vendor yang terhubung ke JO, biaya pelabuhan, dll.). Dalam sistem terintegrasi, ini terhitung otomatis karena setiap transaksi operasional sudah ter-tag ke nomor JO yang spesifik.