Banyak bisnis sudah punya sistem akuntansi atau ERP internal yang rapi — tapi satu langkah di awal prosesnya masih manual: mengambil data mutasi rekening dari aplikasi bank, mengekspornya ke file, lalu mengimpornya satu per satu ke sistem akuntansi. Langkah ini sering luput diperhatikan karena terlihat kecil, padahal justru di sinilah banyak kesalahan rekonsiliasi bermula.
Artikel ini membahas, pada level konsep dan arsitektur, bagaimana proses itu bisa digantikan dengan integrasi langsung lewat Partner API — tanpa perlu membahas kode secara literal, cukup memahami bagaimana alur datanya bekerja.
Masalah dengan alur export-import manual
Pola yang umum terjadi: staf finance login ke aplikasi bank, membuka menu mutasi, mengunduh file (biasanya CSV atau Excel), lalu membuka sistem akuntansi internal dan mengimpor file tersebut secara manual — sering kali untuk setiap rekening, setiap hari atau setiap minggu. Prosesnya berulang, rawan terlewat, dan setiap kali format file dari bank sedikit berubah, proses impor bisa gagal tanpa pemberitahuan yang jelas.
Masalah yang lebih mendasar: data yang diimpor selalu adalah data masa lalu pada saat file diunduh. Antara waktu transaksi terjadi dan waktu data itu akhirnya masuk ke sistem akuntansi, selalu ada jeda — jeda yang bisa berjam-jam, bisa juga berhari-hari tergantung seberapa rajin stafnya.
Bagaimana integrasi via API mengubah alur ini
Alih-alih manusia yang mengekspor dan mengimpor file secara manual, sistem akuntansi internal bisa “menjemput” data mutasi itu sendiri lewat panggilan API, secara terjadwal atau near real-time. Secara konseptual, ada dua pola arsitektur yang umum dipakai:
- Pull terjadwal — sistem akuntansi internal memanggil endpoint mutasi secara berkala (misalnya setiap beberapa menit atau setiap jam) untuk mengambil transaksi baru, lalu menyimpannya ke basis data internal.
- Push via webhook ke antrian internal — begitu ada mutasi baru, notifikasi dikirim ke endpoint webhook milik sistem internal, yang kemudian memasukkan data itu ke antrian pemrosesan (message queue) sebelum akhirnya dicocokkan dengan data internal.
Kedua pola ini bisa dikombinasikan: webhook untuk mendapat sinyal cepat bahwa ada transaksi baru, dan pull berkala sebagai mekanisme “jaring pengaman” untuk memastikan tidak ada data yang terlewat jika satu notifikasi webhook gagal terkirim. Kami membahas penanganan kegagalan webhook secara lebih detail di menangani kegagalan webhook: retry, antrian, dan audit log.
Mencocokkan mutasi dengan invoice secara otomatis
Setelah data mutasi masuk ke sistem internal, langkah berikutnya adalah pencocokan (matching) dengan data invoice atau tagihan yang sudah ada. Secara konsep, proses ini biasanya mencocokkan nominal transaksi dan rentang waktu transaksi dengan invoice yang berstatus belum lunas. Begitu kecocokan ditemukan, status invoice bisa diperbarui otomatis menjadi lunas, tanpa staf finance perlu membuka dua aplikasi berbeda dan membandingkannya satu per satu.
Transaksi yang tidak cocok dengan invoice manapun — misalnya nominal yang sedikit berbeda, atau transfer dari pengirim yang tidak dikenali — tetap bisa ditandai untuk ditinjau manual. Intinya bukan menghilangkan campur tangan manusia sepenuhnya, tapi memindahkan tenaga manusia dari pekerjaan berulang (mencocokkan satu per satu) ke pekerjaan yang memang butuh penilaian (menyelesaikan kasus yang tidak jelas).
Export/import manual
Terhubung via API
Partner API Mutasiku bersifat read-only untuk data mutasi — endpoint yang tersedia hanya untuk mengambil data, bukan untuk memindahkan dana. Detail teknis lengkap tentang autentikasi dan format responsnya ada di dokumentasi Partner API.
Hal yang perlu disiapkan sebelum integrasi
Sebelum tim developer internal mulai membangun integrasi ini, ada beberapa hal yang perlu disepakati lebih dulu, bukan sekadar teknis tapi juga proses bisnisnya:
| Aspek | Pertanyaan yang perlu dijawab |
|---|---|
| Frekuensi pengambilan data | Apakah cukup setiap jam, atau butuh mendekati real-time lewat webhook? |
| Aturan pencocokan | Berdasarkan apa invoice dicocokkan — nominal persis, rentang nominal, atau kombinasi dengan referensi pengirim? |
| Penanganan data tidak cocok | Siapa yang meninjau transaksi yang tidak otomatis ter-matching, dan lewat jalur apa? |
| Penyimpanan data mentah | Apakah data mutasi mentah tetap disimpan terpisah dari hasil pencocokan, untuk keperluan audit? |
Integrasi semacam ini tidak harus dibangun sekaligus sempurna. Banyak tim memulai dengan pull terjadwal sederhana, lalu menambahkan webhook dan logika pencocokan otomatis setelah pola transaksi mereka lebih dipahami. Yang penting, begitu alur ini berjalan, waktu staf finance yang sebelumnya habis untuk ekspor-impor manual bisa dialihkan ke pekerjaan yang benar-benar membutuhkan analisis manusia.