Aturan Main Integrasi Sistem Logistik dan Akuntansi

Pertanyaan "bisa integrasi dengan Accurate, Jurnal, atau SAP?" hampir selalu dijawab "bisa" oleh vendor mana pun, dan jawaban itu memang benar. Yang jarang didokumentasikan di tahap itu adalah aturan main di baliknya: sistem mana yang berhak mengubah data apa, bagaimana tiap transaksi diposting ke bagan akun, apa yang terjadi saat pengiriman data gagal di tengah jalan, dan siapa yang menanggung setiap keputusan itu.

Referensi berikut menguraikan elemen-elemen tersebut satu per satu: sumber kebenaran data, bagan akun, peristiwa yang memicu pencatatan, data induk, arah sinkronisasi, penanganan kegagalan, faktur pajak, rekonsiliasi, dan pembagian tanggung jawab. Sebagian besar sudah harus disepakati sebelum kontrak integrasi diteken, bukan sesudah proyek berjalan.

Sumber kebenaran per jenis data

Sumber kebenaran (source of truth) adalah satu sistem yang dianggap berhak atas nilai akhir suatu data. Begitu sebuah data yang sama boleh diubah dari dua sistem sekaligus tanpa ada yang ditetapkan sebagai sumber kebenaran, perbedaan antara keduanya tinggal menunggu waktu untuk muncul. Ini prinsip desain sistem yang berlaku umum, bukan ketentuan yang khusus mengatur software logistik atau akuntansi.

Praktiknya, data customer yang sama sering tersimpan di sistem logistik maupun software akuntansi, dan di kedua tempat itu siapa saja dengan akses bisa mengeditnya. Karena itu, sebelum membahas hal teknis apa pun, tetapkan satu sistem yang berhak mengubah tiap jenis data. Sistem yang lain cukup menerima salinannya.

Pembagian di atas adalah praktik operasional yang lazim dipakai di lapangan, bukan ketentuan resmi -- kecuali baris faktur pajak, yang tunduk pada aturan perpajakan dan dibahas terpisah di bagian faktur pajak.

Baris kelima (pembayaran masuk) paling sering memicu perdebatan. Tim operasional ingin melihat status pembayaran langsung di sistem logistik supaya bisa menahan pengiriman untuk customer yang menunggak, dan itu kebutuhan yang wajar. Solusinya menampilkan data dari akuntansi di layar logistik secara read-only, tanpa memberi akses untuk mengeditnya di sana.

Bagan akun dan pemetaan transaksi

Bagan akun (chart of account) adalah daftar kode akun yang dipakai software akuntansi untuk mengelompokkan setiap transaksi keuangan. Konsisten dengan pembagian di atas, bagan akun tetap menjadi milik sistem akuntansi -- tidak digandakan atau dipelihara terpisah di sistem logistik.

Yang perlu disiapkan di sisi logistik adalah pemetaan yang deterministik: setiap kategori transaksi logistik (pendapatan trucking, pendapatan forwarding, biaya subkontraktor, denda demurrage, dan seterusnya) harus punya satu akun tujuan yang sudah ditentukan, bukan dipilih manual satu per satu saat invoice diposting.

Pemetaan ini idealnya didokumentasikan dan disepakati tim akuntansi sebelum data pertama mengalir. Mengubahnya setelah transaksi berjalan berarti mengoreksi ulang saldo yang sudah tercatat, dan itu pekerjaan yang jauh lebih mahal dibanding menetapkannya lebih dulu.

Peristiwa yang memicu pencatatan

Integrasi yang sehat memetakan setiap peristiwa operasional ke satu aturan pencatatan yang tetap, bukan menentukan efeknya secara ad hoc tiap kali transaksi terjadi.

Baris keempat dan kelima yang paling sering luput dari rancangan awal. Tim yang merancang integrasi biasanya fokus pada jalur normal -- job selesai, invoice terbit, dibayar -- dan baru memikirkan pembatalan atau revisi setelah kasus itu benar-benar terjadi. Aturan jurnal pembalik untuk kedua peristiwa itu sebaiknya sudah ditentukan sejak awal, bukan diputuskan dadakan saat sudah ada invoice yang perlu dikoreksi.

Data induk: penyelarasan sebelum sinkronisasi berjalan

Penyebab kegagalan integrasi yang paling sering terjadi bukan pada sisi teknis, melainkan pada data induk yang belum seragam antar sistem -- customer, vendor, dan kode barang yang tercatat dengan cara penulisan berbeda di masing-masing sistem.

Sebagai ilustrasi: di sistem logistik, customer tercatat sebagai "PT Maju Jaya". Di akuntansi, namanya "PT. Maju Jaya Sentosa". Keduanya perusahaan yang sama, tapi tidak ada API yang bisa menebak itu sendiri. Integrasi gagal mencocokkan kedua nama, membuat entitas baru, dan sekarang ada dua customer di akuntansi dengan piutang yang terpecah jadi dua.

Cara praktis mengatasinya: pakai satu pengenal unik yang tidak bergantung pada cara penulisan nama. Untuk badan usaha di Indonesia, NPWP kandidat yang paling umum dipakai karena sifatnya tunggal, tidak berubah, dan sudah tersimpan di kedua sistem untuk keperluan pajak.

Arah aliran data: satu arah atau dua arah

Sinkronisasi dua arah kedengarannya lebih canggih dan fleksibel. Ia juga jauh lebih mahal dipelihara, karena setiap perubahan di kedua sisi butuh aturan penyelesaian konflik yang jelas.

Ilustrasinya: alamat customer diubah di sistem logistik pukul 10.00, lalu diubah lagi dengan versi berbeda di akuntansi pukul 10.05. Mana yang menang -- yang paling baru diubah, yang berasal dari sumber kebenaran, atau yang diubah pengguna dengan peran lebih tinggi? Tiap jawaban punya konsekuensi sendiri, dan idealnya sudah diputuskan di muka untuk tiap kolom data.

Untuk sebagian besar perusahaan logistik, arus satu arah per jenis data sudah cukup dan lebih tahan lama: data induk mengalir dari akuntansi ke logistik, transaksi mengalir dari logistik ke akuntansi. Tidak ada yang mengalir bolak-balik, sehingga tidak ada konflik yang perlu diselesaikan.

Idempotensi dan penanganan kegagalan

Idempotensi adalah sifat sebuah operasi yang hasil akhirnya tetap sama walau dijalankan berkali-kali, seperti halnya dijalankan sekali saja. Istilah ini berasal dari desain sistem terdistribusi dan API, bukan dari regulasi logistik maupun akuntansi, tapi relevan di sini karena kegagalan kirim-ulang data adalah risiko yang sulit dihindari sepenuhnya pada integrasi jangka panjang.

Integrasi akan terputus di tengah jalan pada suatu waktu -- koneksi internet putus, server sedang maintenance, atau kolom yang tiba-tiba jadi wajib diisi -- dan cara memulihkannya adalah mengirim ulang data yang tertunda. Tanpa sifat idempoten, satu kali kirim ulang saja bisa menggandakan transaksi, dan kerusakan dari "perbaikan" itu bisa lebih besar daripada kerusakan aslinya.

Pola kegagalan yang paling merusak adalah kegagalan senyap: integrasi berhenti bekerja tanpa pemberitahuan, sementara operasional tetap berjalan seperti biasa. Pola yang umum ditemui (disederhanakan sebagai ilustrasi, bukan catatan satu perusahaan tertentu): integrasi berhenti mengirim data selama beberapa minggu, dan baru ketahuan saat tutup buku karena puluhan invoice ternyata tidak pernah tercatat di akuntansi. Merekonstruksinya makan waktu berhari-hari, dan sebagian datanya sudah berubah sejak saat itu.

Berikut yang layak ditanyakan langsung ke vendor mana pun sebelum kontrak diteken:

• Antrean yang terlihat, menampilkan transaksi mana saja yang gagal terkirim lengkap dengan alasan kegagalan yang bisa dibaca orang non-teknis.
• Percobaan ulang otomatis untuk kegagalan yang sifatnya sementara, dengan jeda yang bertingkat.
• Pemberitahuan aktif ke orang yang bertanggung jawab, bukan sekadar catatan di log yang tidak pernah dibuka siapa pun.
• Kemampuan kirim ulang secara manual begitu masalahnya sudah dibereskan, tanpa harus menghubungi vendor lagi.
• Pencegahan duplikasi, supaya kirim ulang tidak berujung dua entri untuk transaksi yang sama.

Poin terakhir yang paling sering terlewat, padahal akibatnya bisa lebih parah daripada kegagalan aslinya. Kalau sistem tidak punya penanda unik per transaksi, satu kali kirim ulang saja cukup untuk menggandakan pendapatan yang tercatat di pembukuan.

Faktur pajak: satu-satunya bagian yang benar-benar diatur hukum

Penomoran faktur pajak diterbitkan melalui sistem e-Faktur yang dikelola Direktorat Jenderal Pajak (DJP), dengan format dan tata cara yang ditentukan secara resmi. Ini satu-satunya elemen dalam referensi ini yang benar-benar tunduk pada ketentuan hukum -- bagian lain di atas adalah praktik operasional yang lazim diikuti, bukan kewajiban.

Praktik yang berlaku umum di software akuntansi maupun aplikasi pajak di Indonesia adalah membiarkan penomoran itu diterbitkan dari sistem yang memang terhubung ke e-Faktur, bukan dari sistem logistik. Sebagian besar software akuntansi populer sudah menyediakan integrasi ke e-Faktur atau setidaknya ekspor yang sesuai formatnya.

Berdasarkan pengalaman mendampingi implementasi semacam ini, pola yang paling aman berjalan seperti berikut: sistem logistik menyusun invoice lengkap dengan rincian layanannya, mengirimkannya ke akuntansi, lalu akuntansi menerbitkan faktur pajak dan mengembalikan nomornya. Sistem logistik cukup menyimpan nomor itu untuk rujukan dan penagihan.

Godaan untuk memindahkan penomoran ke sistem logistik supaya semuanya tampak rapi di satu tempat kerap muncul. Sebaiknya godaan itu ditahan: aturan perpajakan berubah dari waktu ke waktu, dan aplikasi pajak yang memang dibuat khusus untuk itu biasanya menyesuaikan lebih cepat dibanding modul pajak di dalam sistem logistik.

Rekonsiliasi berkala

Rekonsiliasi adalah proses mencocokkan total transaksi di sistem logistik dengan total yang tercatat di ledger akuntansi, untuk menangkap transaksi yang gagal terkirim, tercatat dua kali, atau tercatat di periode yang berbeda.

Perbedaan periode adalah sumber selisih yang paling sering muncul saat rekonsiliasi. Penyebabnya biasanya aturan tanggal pengakuan yang belum disepakati: apakah sebuah transaksi dicatat berdasarkan tanggal job selesai atau tanggal invoice diterbitkan. Kalau aturan ini tidak dituliskan secara eksplisit di awal integrasi, selisih yang sama akan berulang setiap periode tutup buku.

Pemeriksaan minimum yang layak dijalankan setiap periode:

• Jumlah invoice yang diterbitkan di sistem logistik sama dengan jumlah entri piutang baru di akuntansi untuk periode yang sama.
• Total nilai invoice yang tercatat di kedua sistem tidak berselisih di luar toleransi pembulatan yang sudah disepakati.
• Status pembayaran (lunas/belum lunas) di sistem logistik konsisten dengan status di akuntansi, karena keduanya dipakai tim operasional untuk keputusan menahan pengiriman.
• Tidak ada transaksi yang tercatat dua kali akibat pengiriman ulang setelah kegagalan sebelumnya.

Rekonsiliasi semacam ini idealnya dijalankan sebelum tutup buku, bukan sesudahnya, supaya selisih masih bisa ditelusuri ke transaksi asalnya selagi datanya belum berubah lebih jauh.

Pembagian tanggung jawab

Tiap elemen di atas punya pemilik yang berbeda, dan integrasi yang paling sering bermasalah adalah yang tidak pernah menuliskan pembagian ini secara eksplisit.

Baris terakhir yang paling sering disalahpahami. Vendor sistem bisa membangun jembatan teknisnya, tapi tidak berwenang mengambil keputusan bisnis seperti mana identitas customer yang dianggap sama, atau kapan sebuah transaksi diakui sebagai pendapatan. Keputusan itu tetap ada di tangan tim internal, sebelum maupun sesudah integrasi berjalan.

Kapan integrasi belum layak dikerjakan

Membangun integrasi datang dengan biaya tetap: membangunnya, mengujinya, dan yang paling sering diremehkan, memeliharanya setiap kali salah satu sistem diperbarui.

Pada volume sekitar 40 invoice sebulan, memasukkannya satu per satu secara manual cuma makan waktu beberapa jam, dan integrasi jarang menang secara ekonomi dibanding itu. Titik impasnya baru terlampaui pada volume beberapa ratus transaksi per bulan, atau saat kesalahan salin-tempel mulai muncul secara teratur.