Panduan
Menyambungkan Sistem Logistik ke Akuntansi: Empat Keputusan yang Menentukan Hasilnya
Pertanyaan "bisa integrasi dengan Accurate?" hampir selalu dijawab "bisa", dan jawaban itu benar sekaligus tidak berguna. Yang menentukan berhasil atau tidaknya adalah empat keputusan yang jarang ditanyakan sebelum kontrak ditandatangani.
- Tentukan sistem mana yang jadi sumber kebenaran untuk tiap jenis data, sebelum menyentuh teknis apa pun.
- Data induk yang tidak seragam adalah penyebab kegagalan integrasi yang paling umum, bukan API.
- Sinkronisasi dua arah jauh lebih mahal untuk dipelihara daripada satu arah, dan jarang sepadan.
- Tanpa penanganan kegagalan yang terlihat, integrasi akan berhenti diam-diam dan baru ketahuan saat tutup buku.
Dalam setiap proses pemilihan sistem logistik, ada satu pertanyaan yang pasti muncul: "Bisa integrasi dengan software akuntansi kami?" Jawabannya hampir selalu "bisa". Jawaban itu benar, dan hampir tidak berguna, seperti menjawab "bisa" untuk pertanyaan apakah dua kota bisa dihubungkan jalan.
Yang menentukan hasilnya bukan kemampuan teknis, melainkan empat keputusan desain yang biasanya baru dibicarakan setelah proyek berjalan, saat mengubahnya sudah mahal.
Dasar: sumber kebenaran tunggal dan sifat idempoten
Perancangan basis data punya prinsip lama bahwa satu fakta sebaiknya disimpan di satu tempat. Ketika fakta yang sama hidup di dua sistem yang keduanya boleh mengubahnya, perbedaan di antara keduanya bukan kemungkinan melainkan kepastian, dan yang tersisa hanya pertanyaan kapan.
Prinsip kedua datang dari sistem terdistribusi. Sebuah operasi disebut idempoten bila menjalankannya berulang kali memberi hasil yang sama dengan menjalankannya sekali. Ini penting karena integrasi pasti pernah gagal di tengah jalan, dan pemulihannya menuntut pengiriman ulang. Tanpa sifat idempoten, satu kali kirim ulang menggandakan transaksi, dan kerusakan akibat pemulihan menjadi lebih besar daripada kerusakan aslinya.
Keputusan 1: sistem mana yang jadi sumber kebenaran
Kalau data customer ada di sistem logistik dan juga di software akuntansi, dan keduanya bisa diedit, maka suatu saat keduanya akan berbeda. Bukan mungkin, pasti. Pertanyaannya hanya kapan, dan versi mana yang akhirnya dipercaya.
Karena itu keputusan pertama, sebelum apa pun yang bersifat teknis: untuk setiap jenis data, tetapkan satu sistem yang berhak mengubahnya. Sistem lain hanya menerima.
| Jenis data | Sumber kebenaran | Alasan |
|---|---|---|
| Data customer & vendor | Akuntansi | NPWP, alamat pajak, dan termin hidup di sana |
| Data job & shipment | Logistik | Akuntansi tidak punya konsep ini |
| Tarif jual & beli | Logistik | Berubah jauh lebih sering daripada siklus akuntansi |
| Invoice | Logistik menerbitkan, akuntansi mencatat | Nomor faktur pajak tetap dari akuntansi |
| Pembayaran masuk | Akuntansi | Rekonsiliasi bank terjadi di sana |
| Chart of account | Akuntansi | Tidak boleh ada duanya |
Baris kelima sering memicu perdebatan. Tim operasional ingin melihat status pembayaran di sistem logistik agar bisa menahan pengiriman untuk customer yang menunggak. Itu kebutuhan yang sah, tapi jawabannya adalah menampilkan data dari akuntansi, bukan memungkinkan pengeditannya di sana.
Keputusan 2: menyeragamkan data induk lebih dulu
Ini penyebab kegagalan integrasi yang paling sering, dan paling membosankan, sehingga paling sering ditunda.
Di sistem logistik, customer tercatat sebagai "PT Maju Jaya". Di akuntansi, "PT. Maju Jaya Sentosa". Keduanya merujuk perusahaan yang sama. Tidak ada API yang bisa menebak itu. Integrasi akan gagal mencocokkan, lalu membuat entitas baru, dan sekarang Anda punya dua customer di akuntansi dengan piutang yang terpecah.
Cara praktis: pakai satu pengenal unik yang tidak bergantung pada penulisan nama. NPWP adalah kandidat terbaik untuk entitas berbadan hukum di Indonesia, karena ia tunggal, tidak berubah, dan sudah ada di kedua sistem untuk keperluan pajak.
Keputusan 3: satu arah atau dua arah
Sinkronisasi dua arah terdengar lebih canggih dan lebih fleksibel. Ia juga jauh lebih mahal untuk dipelihara, karena setiap perubahan di kedua sisi harus memiliki aturan penyelesaian konflik.
Contohnya konkret: alamat customer diubah di sistem logistik pukul 10.00, dan diubah berbeda di akuntansi pukul 10.05. Mana yang menang? Yang terbaru? Yang berasal dari sumber kebenaran? Yang diubah oleh pengguna dengan peran lebih tinggi? Setiap jawaban punya konsekuensi, dan semuanya harus diputuskan di muka, untuk setiap kolom.
Untuk sebagian besar perusahaan logistik, arus satu arah per jenis data sudah cukup dan jauh 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.
Keputusan 4: apa yang terjadi ketika integrasi gagal
Integrasi akan gagal. Server akuntansi diperbarui, jaringan putus, ada field yang tiba-tiba wajib diisi. Pertanyaannya bukan apakah, melainkan apa yang terjadi setelahnya.
Pola kegagalan yang paling merusak adalah kegagalan senyap: integrasi berhenti bekerja, tidak ada yang diberi tahu, dan operasional berjalan normal selama tiga minggu. Baru saat tutup buku ketahuan ada 60 invoice yang tidak pernah masuk ke akuntansi. Merekonstruksinya memakan waktu berhari-hari, dan sebagian data sudah berubah.
“Integrasi yang gagal dengan berisik jauh lebih murah daripada integrasi yang gagal dengan sopan.”
Yang harus ada, dan layak ditanyakan ke vendor mana pun sebelum kontrak:
- Antrean yang terlihat, berisi transaksi yang gagal dikirim, dengan alasan kegagalan yang bisa dibaca orang non-teknis.
- Percobaan ulang otomatis untuk kegagalan sementara, dengan jeda bertingkat.
- Pemberitahuan aktif ke orang tertentu, bukan hanya catatan di log yang tidak pernah dibuka.
- Kemampuan mengirim ulang secara manual setelah masalah diperbaiki, tanpa perlu memanggil vendor.
- Pencegahan duplikasi, sehingga kirim ulang tidak menghasilkan dua entri untuk transaksi yang sama.
Poin terakhir sering terlewat dan menimbulkan masalah yang lebih parah daripada kegagalan aslinya. Kalau sistem tidak punya penanda unik per transaksi, satu kali kirim ulang bisa menggandakan pendapatan Anda di pembukuan.
Soal faktur pajak, yang selalu jadi bagian tersulit
Di Indonesia, penomoran faktur pajak punya aturan tersendiri dan konsekuensi kepatuhan yang nyata. Ini alasan kuat untuk membiarkan penerbitan faktur pajak tetap di sistem akuntansi atau aplikasi pajak, meskipun invoice komersialnya disusun di sistem logistik.
Pola yang biasanya paling aman: sistem logistik menyusun invoice beserta seluruh rinciannya, mengirimkannya ke akuntansi, lalu akuntansi menerbitkan faktur pajak dan mengembalikan nomornya. Sistem logistik menyimpan nomor itu untuk keperluan rujukan dan penagihan.
Godaannya adalah memindahkan penomoran ke sistem logistik agar semuanya di satu tempat. Sebaiknya ditahan. Aturan perpajakan berubah, dan software pajak yang memang khusus dibuat untuk itu akan menyesuaikan lebih cepat daripada sistem logistik yang kebetulan juga menangani pajak.
Kapan integrasi tidak sepadan
Integrasi punya biaya tetap: pembangunan, pengujian, dan (yang paling sering diremehkan) pemeliharaan setiap kali salah satu sistem diperbarui.
Kalau Anda menerbitkan 40 invoice sebulan, memasukkannya secara manual memakan waktu beberapa jam, dan tidak ada integrasi yang bisa menandinginya secara ekonomi. Titik impasnya biasanya baru terlampaui pada volume beberapa ratus transaksi per bulan, atau ketika kesalahan penyalinan mulai muncul secara teratur.
Pertanyaan yang Sering Muncul
Berapa lama waktu yang wajar untuk integrasi ke software akuntansi?
Bagian teknisnya biasanya bukan yang terlama. Yang menentukan durasi adalah pembersihan data induk dan penyepakatan pemetaan akun. Kalau vendor memberikan estimasi tanpa lebih dulu memeriksa daftar customer dan chart of account Anda, estimasi itu belum memperhitungkan bagian yang paling memakan waktu.
Apakah semua software akuntansi punya API?
Sebagian besar produk populer di Indonesia menyediakan API atau setidaknya mekanisme impor terstruktur, tetapi cakupan dan batasannya berbeda-beda, ada yang membatasi frekuensi panggilan, ada yang tidak mengekspos semua jenis transaksi. Minta dokumentasi API-nya sebelum kontrak, bukan sesudah, dan pastikan jenis transaksi yang Anda butuhkan memang tersedia.
Bagaimana menangani perbedaan periode antara operasional dan akuntansi?
Sepakati aturan tanggal pengakuan sejak awal: apakah transaksi memakai tanggal job selesai atau tanggal invoice. Selisih ini yang paling sering menimbulkan perbedaan angka antara laporan operasional dan laporan keuangan di akhir bulan, dan perbedaan itu akan terus muncul setiap periode kalau aturannya tidak pernah ditulis.
Apakah lebih baik memakai satu sistem yang mencakup logistik dan akuntansi sekaligus?
Ada nilainya, tidak ada integrasi yang perlu dipelihara, dan tidak ada selisih periode. Tetapi modul akuntansi di dalam sistem logistik biasanya kalah matang dibanding software akuntansi khusus, terutama pada urusan perpajakan lokal yang aturannya sering berubah. Untuk perusahaan yang akuntannya sudah nyaman dengan alat yang ada, integrasi umumnya lebih murah daripada migrasi.