Lewati ke konten
Semua artikel

Karyawan AI untuk Proyeksi Arus Kas 13 Minggu: Temukan Minggu Saldo Menipis sebelum Terlambat

Panduan membuat proyeksi arus kas 13 minggu untuk UMKM: pisahkan laba dari kas, petakan tanggal penerimaan dan pembayaran, uji skenario, dan tandai saldo minimum dengan approval manusia.

AgentBuffTim AgentBuff

31 Oktober 202612 menit baca

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Proyeksi arus kas 13 minggu adalah jadwal bergulir yang memperkirakan saldo kas awal, uang yang benar-benar diperkirakan masuk, uang yang benar-benar diperkirakan keluar, dan saldo akhir untuk setiap minggu selama kira-kira satu kuartal. Tujuannya bukan menebak laba, melainkan melihat kapan bisnis mungkin kekurangan kas untuk membayar kewajiban—cukup dini untuk mengubah waktu belanja, menagih piutang, menegosiasikan termin, atau menyiapkan pendanaan secara bertanggung jawab.

Karyawan AI dapat mengumpulkan data dari rekening, invoice, tagihan, payroll, purchase order, dan kalender pembayaran; menormalisasi tanggal; membuat skenario; menandai saldo minimum; serta menjadwalkan pembaruan mingguan. Namun, ia tidak boleh mengubah tanggal pembayaran, memindahkan dana, mengambil pinjaman, atau menjanjikan pembayaran kepada pihak lain tanpa persetujuan manusia.

Aturan paling pentingnya: catat uang pada minggu ketika kas diperkirakan berpindah, bukan ketika penjualan dicatat atau invoice dibuat. Penjualan Rp30 juta yang baru dibayar 45 hari lagi tidak dapat membayar gaji Jumat ini.

Apa bedanya proyeksi arus kas, laporan arus kas, dan laba rugi?

Ketiga dokumen itu menjawab pertanyaan yang berbeda.

  • Laporan laba rugi menunjukkan pendapatan dan beban selama periode tertentu menurut kebijakan akuntansi yang digunakan.
  • Laporan arus kas menunjukkan perubahan kas historis dan mengklasifikasikan arus operasi, investasi, serta pendanaan.
  • Proyeksi arus kas memperkirakan penerimaan, pembayaran, dan saldo masa depan untuk membantu keputusan likuiditas.

IAS 7 menjelaskan bahwa laporan arus kas mengklasifikasikan arus menjadi aktivitas operasi, investasi, dan pendanaan. Standar tersebut juga membedakan transaksi kas dari transaksi nonkas. Baca ringkasan resmi IAS 7. Ikatan Akuntan Indonesia memuat prinsip klasifikasi serupa dalam ketentuan laporan arus kas. Lihat ringkasan PSAK tentang laporan arus kas.

Artikel ini membahas alat manajemen jangka pendek, bukan pengganti laporan keuangan formal. Usaha yang menggunakan SAK EMKM perlu memahami bahwa laporan arus kas bukan bagian dari komponen minimum SAK EMKM, meski dapat disajikan bila bermanfaat bagi pengguna. Lihat penjelasan IAI tentang SAK EMKM. Untuk pelaporan, pajak, pinjaman, atau keputusan material, libatkan akuntan atau penasihat yang kompeten.

Mengapa memilih 13 minggu?

Tiga belas minggu memberi kompromi praktis: cukup dekat untuk mengisi pembayaran dengan tanggal konkret, tetapi cukup panjang untuk melihat gaji, sewa, cicilan, pembelian stok, pajak, dan siklus penagihan beberapa kali ke depan.

Business Development Bank of Canada menyediakan kalkulator proyeksi 13 minggu dan menjelaskan bahwa model ini membandingkan kas masuk dan keluar dalam satu kuartal. BDC juga menyarankan pembaruan pada awal setiap minggu untuk memberi visibilitas yang lebih rapat daripada anggaran bulanan. Lihat kalkulator 13 minggu BDC dan panduan proyeksi kas BDC.

Angka 13 bukan aturan universal. Bisnis dengan transaksi harian dan saldo tipis mungkin memerlukan tampilan harian untuk dua minggu pertama. Usaha proyek dengan pembayaran bertahap mungkin memakai 13 minggu ditambah proyeksi bulanan 12 bulan. Yang penting, horizon sesuai dengan waktu yang dibutuhkan untuk mengambil tindakan.

Struktur minimum setiap baris kas

Sebelum membuat spreadsheet atau workflow, tentukan kontrak datanya. Setiap penerimaan atau pembayaran minimal memiliki:

  • ID transaksi atau sumber;
  • pihak terkait;
  • kategori arus kas;
  • jumlah bruto;
  • tanggal kas diperkirakan bergerak;
  • status: terikat, diharapkan, atau skenario;
  • sumber bukti;
  • pemilik tindak lanjut;
  • tanggal terakhir diverifikasi;
  • catatan pajak atau potongan bila relevan.

Pisahkan tanggal dokumen dari tanggal kas. Sebuah invoice dapat diterbitkan 1 November, jatuh tempo 30 November, dan berdasarkan riwayat pelanggan baru dibayar 10 Desember. Ketiga tanggal itu berguna, tetapi proyeksi baseline memerlukan asumsi tanggal penerimaan yang dinyatakan jelas.

Untuk pembayaran, pisahkan tanggal jatuh tempo, tanggal yang direncanakan, dan tanggal otorisasi. Jangan memindahkan pembayaran ke minggu lain hanya agar saldo terlihat positif.

Rumus inti yang harus dapat ditelusuri

Untuk setiap minggu:

Saldo akhir = saldo awal + total kas masuk − total kas keluar

Saldo akhir minggu pertama menjadi saldo awal minggu kedua. Bentuknya sederhana, tetapi definisi setiap unsur harus konsisten.

Saldo awal

Tentukan rekening dan dompet kas mana yang masuk cakupan. Jangan menjumlahkan rekening pribadi pemilik, limit kartu kredit, saldo marketplace yang belum dapat ditarik, dan deposit yang dibatasi seolah semuanya kas tersedia.

SAK EMKM menegaskan konsep entitas bisnis dan perlunya memisahkan kekayaan pribadi pemilik dari kekayaan usaha. Baca penjelasan IAI tentang SAK EMKM. Dalam workflow, buat daftar akun yang disetujui dan tandai dana terbatas secara terpisah.

Kas masuk

Kas masuk dapat mencakup penjualan tunai, penerimaan piutang, pencairan marketplace, modal pemilik, pinjaman yang sudah disetujui, pengembalian pajak, atau sumber lain. Jangan memasukkan penawaran, prospek, atau plafon pinjaman yang belum disetujui ke baseline.

Panduan pemerintah Australia membedakan penerimaan kas dari penjualan yang baru diperkirakan dan meminta angka estimasi diberi label serta penjelasan. Lihat panduan cash flow business.gov.au.

Kas keluar

Kas keluar mencakup pembayaran supplier, gaji, sewa, utilitas, iklan, pajak, cicilan pokok dan bunga, pembelian aset, refund, serta penarikan pemilik. Masukkan jumlah pada minggu pembayaran, bukan minggu barang diterima atau beban diakui.

Buffer minimum

Saldo di atas nol belum tentu aman. Tentukan batas kas minimum untuk kebutuhan yang tidak boleh terlambat, misalnya gaji, sewa, dan biaya operasi dasar. Batas ini adalah kebijakan internal, bukan angka universal. Karyawan AI boleh menandai pelanggaran batas; manusia yang menetapkan nilainya.

Workflow 10 langkah untuk karyawan AI

1. Bekukan cakupan dan tanggal cut-off

Tentukan entitas, rekening, mata uang, horizon, zona waktu, dan akhir minggu. Catat saldo pembuka pada waktu cut-off yang sama. Jika transaksi masih dalam proses, tandai statusnya; jangan hitung dua kali antara saldo bank dan daftar penerimaan.

Karyawan AI membuat lembar kontrol yang menjelaskan sumber setiap angka. Ini mencegah proyeksi berubah menjadi kumpulan angka tanpa asal.

2. Tarik saldo aktual dengan akses baca

Gunakan ekspor resmi atau koneksi baca-saja bila tersedia. Agen mencocokkan saldo buku dengan saldo bank dan menandai transaksi tertunda. Jika selisih belum selesai, jangan menyembunyikannya dalam “penyesuaian lain-lain”. Hubungkan dengan workflow rekonsiliasi keuangan UMKM untuk membersihkan saldo awal.

Batasi akses. Agen proyeksi tidak memerlukan hak transfer atau perubahan penerima pembayaran. Prinsip ini konsisten dengan panduan batas akses karyawan AI.

3. Bangun daftar kas masuk berdasarkan tanggal penerimaan

Gabungkan invoice terbuka, jadwal settlement marketplace, penjualan tunai, pembayaran bertahap, dan sumber lain. Untuk setiap penerimaan, simpan tanggal kontraktual serta tanggal baseline yang diperkirakan.

Gunakan riwayat pembayaran sebagai input, bukan kepastian. Jika pelanggan biasanya membayar 10 hari terlambat, baseline dapat memakai pola itu dengan label asumsi. Invoice yang sedang disengketakan masuk skenario risiko, bukan diperlakukan sama dengan invoice yang sudah dikonfirmasi.

Jika ada invoice lewat jatuh tempo, tautkan ke workflow penagihan invoice tanpa merusak hubungan pelanggan. Proyeksi menunjukkan dampak keterlambatan; workflow penagihan menjalankan tindak lanjut.

4. Bangun daftar kas keluar dari kewajiban nyata

Tarik tagihan supplier, payroll, sewa, utilitas, pajak, subscription, cicilan, purchase order terbuka, dan refund. Pisahkan:

  • terikat: kewajiban dengan jumlah dan tanggal jelas;
  • direncanakan: belanja yang sudah disetujui tetapi belum menjadi kewajiban;
  • opsional: pengeluaran yang dapat ditunda tanpa melanggar janji atau hukum;
  • skenario: biaya yang hanya muncul bila suatu kejadian terjadi.

Label ini bukan izin otomatis untuk menunda pembayaran. Ia membantu pemilik melihat pilihan sebelum mengambil keputusan.

5. Normalisasi kategori tanpa menghapus detail

Karyawan AI dapat menyatukan variasi nama seperti “Meta Ads”, “iklan IG”, dan “ads campaign” ke kategori pemasaran, sambil mempertahankan sumber asli. Hindari kategori “lain-lain” yang terlalu besar. Jika satu pos melewati ambang tertentu, pecah agar dapat ditindaklanjuti.

Untuk pembelian, tautkan PO, penerimaan, dan invoice bila tersedia. Panduan three-way matching membantu memastikan angka pembayaran tidak berasal dari tagihan yang belum cocok.

6. Susun baseline 13 minggu

Masukkan hanya penerimaan dan pembayaran yang didukung bukti atau asumsi eksplisit. Untuk penjualan masa depan, jangan menyalin forecast penjualan mentah menjadi kas masuk. Ubah berdasarkan metode pembayaran, jeda settlement, retur, pajak, dan pola penagihan.

BDC secara eksplisit mengingatkan agar penjualan tidak dianggap kas sampai waktu pembayaran yang diharapkan. Baca panduan perencanaan keuangan BDC.

7. Buat tiga skenario tanpa presisi palsu

Minimal buat:

  • baseline: asumsi paling masuk akal berdasarkan bukti;
  • tekanan: penerimaan terlambat dan/atau biaya penting meningkat;
  • pemulihan: tindakan yang sudah realistis, seperti penagihan lebih cepat atau penundaan belanja opsional yang disetujui.

Jangan menyebut skenario “optimistis” hanya dengan menaikkan penjualan 20% tanpa dasar. Setiap perubahan harus menunjuk pemicu dan pemilik keputusan.

8. Tandai minggu risiko dan penyebabnya

Karyawan AI menghitung saldo akhir, saldo minimum, perubahan bersih, dan jarak terhadap buffer. Untuk minggu yang melanggar batas, tampilkan lima pendorong terbesar dan asumsi yang paling sensitif.

Peringatan yang baik berbunyi: “Saldo diproyeksikan turun di bawah buffer pada minggu 23 November karena settlement marketplace Rp18 juta bergeser satu minggu dan pembayaran kain Rp25 juta jatuh tempo.” Peringatan buruk hanya berkata: “Cash flow negatif.”

9. Buat paket keputusan, bukan tindakan otomatis

Untuk setiap celah, agen menyiapkan pilihan beserta konsekuensi:

  • mempercepat penagihan invoice tertentu;
  • meminta konfirmasi tanggal settlement;
  • menegosiasikan ulang termin sebelum jatuh tempo;
  • menunda belanja opsional;
  • mengubah jadwal pembelian;
  • menggunakan fasilitas pembiayaan yang sudah disetujui;
  • menambah modal dengan keputusan pemilik.

Karyawan AI tidak boleh mengirim komitmen, menunda gaji, mengubah pembayaran pajak, atau menarik kredit sendiri. Keputusan keuangan material memerlukan manusia dan, bila relevan, penasihat profesional.

10. Roll forward setiap minggu

Pada hari tetap, ganti minggu selesai dengan angka aktual, ukur selisih terhadap forecast, tambahkan satu minggu baru di ujung, dan perbarui asumsi. Simpan versi serta alasan perubahan.

Bandingkan forecast error per kategori dan waktu. Jika penerimaan pelanggan tertentu terus terlambat, perbaiki asumsi baseline. Jika biaya supplier sering meleset karena data masuk terlambat, benahi proses sumbernya—bukan sekadar formula.

Contoh: konveksi custom menjelang pesanan akhir tahun

Sebuah konveksi kecil memiliki saldo kas Rp80 juta. Dalam empat minggu, usaha itu akan menerima dua pembayaran proyek: Rp60 juta yang dijanjikan pada minggu kedua dan Rp45 juta pada minggu keempat. Pada sisi keluar, ada gaji Rp35 juta, pembelian kain Rp50 juta, cicilan mesin Rp8 juta, dan biaya operasi mingguan Rp7 juta.

Tanpa jadwal mingguan, total penerimaan dan pengeluaran satu bulan tampak seimbang. Namun, proyeksi menunjukkan pembelian kain jatuh sebelum pembayaran Rp60 juta masuk. Jika klien terlambat satu minggu, saldo turun di bawah buffer gaji.

Karyawan AI menyiapkan tiga skenario. Baseline memakai tanggal pembayaran yang dikonfirmasi. Skenario tekanan menggeser pembayaran klien satu minggu. Skenario pemulihan memecah pembelian kain sesuai jadwal produksi setelah supplier menyetujui termin baru. Pemilik konveksi meninjau bukti, menghubungi klien dan supplier sendiri, lalu menyetujui rencana.

Contoh ini ilustratif, bukan data pelanggan AgentBuff. Nilainya ada pada urutan kas: keputusan diambil sebelum saldo menipis, bukan setelah pembayaran gagal.

Kesalahan yang membuat forecast terlihat rapi tetapi menyesatkan

Menganggap invoice sama dengan kas

Invoice adalah hak tagih, bukan uang di rekening. Gunakan tanggal penerimaan yang diharapkan dan tampilkan keterlambatan sebagai skenario.

Menghitung limit kredit sebagai saldo

Fasilitas yang belum ditarik bukan kas. Tampilkan sebagai opsi pendanaan dengan syarat, biaya, dan approval terpisah.

Mencampur uang pribadi dan usaha

Campuran ini merusak saldo awal dan mengaburkan kemampuan bisnis membayar kewajibannya. Modal atau penarikan pemilik harus dicatat sebagai transaksi tersendiri.

Menutup selisih dengan “lain-lain”

Kategori besar tanpa rincian membuat masalah sumber data tidak terlihat. Setiap penyesuaian harus punya pemilik, bukti, dan tanggal penyelesaian.

Membiarkan agen mengubah asumsi diam-diam

Setiap perubahan tanggal, jumlah, atau status harus tercatat. Agen boleh merekomendasikan, tetapi baseline baru memerlukan approval.

Metrik yang layak dipantau

  • saldo kas minimum dalam 13 minggu;
  • minggu pertama saldo melanggar buffer;
  • forecast error penerimaan dan pembayaran;
  • persentase arus tanpa bukti atau pemilik;
  • jumlah invoice yang bergeser dari tanggal baseline;
  • konsentrasi penerimaan pada satu pelanggan atau kanal;
  • nilai pembayaran opsional versus terikat;
  • waktu penyelesaian selisih saldo awal;
  • perubahan asumsi yang belum disetujui.

Metrik bukan tujuan akhir. Gunakan untuk memperbaiki data dan mempercepat keputusan, bukan untuk menghasilkan kepastian palsu.

Peran AgentBuff dalam proyeksi arus kas

AgentBuff adalah platform Karyawan AI asal Indonesia, bukan sekadar chatbot. Pengguna mengelola agen lewat chat, memberi peran, skills, dan tools, menghubungkan aplikasi atau data kerja yang relevan, lalu menjalankan workflow serta tugas terjadwal untuk mengembalikan hasil kerja nyata.

Dalam workflow ini, agen dapat diberi peran analis kas dengan akses baca: mengumpulkan data yang diizinkan, menyusun forecast, menandai asumsi, mengirim pengingat pembaruan, dan menyiapkan paket keputusan. Pisahkan peran analisis dari hak memindahkan uang atau mengubah penerima pembayaran.

Mulailah dari satu rekening dan delapan sampai tiga belas minggu. Uji saldo awal, tanggal kas, dan roll-forward sebelum menambah sumber data. Jika ingin membangun alur tersebut, Anda dapat mendaftar AgentBuff dan menempatkan approval manusia pada perubahan asumsi serta tindakan keuangan.

Sumber dan bacaan utama


Tentang penulis: Nugraha Labib Mujaddid membangun AgentBuff untuk membantu individu dan bisnis Indonesia bekerja dengan karyawan AI.

Pertanyaan yang sering muncul

Apa itu proyeksi arus kas 13 minggu?

Proyeksi arus kas 13 minggu adalah rencana mingguan atas kas masuk, kas keluar, dan saldo penutup selama satu kuartal bergulir. Transaksi ditempatkan pada minggu uang diperkirakan benar-benar berpindah.

Apakah bisnis yang untung bisa kekurangan kas?

Bisa. Laba mencatat pendapatan dan beban menurut aturan akuntansi, sedangkan kas bergantung pada waktu pelanggan membayar dan bisnis mengeluarkan uang.

Apakah penjualan yang belum dibayar masuk forecast?

Masuk sebagai penerimaan pada minggu pembayaran yang realistis, bukan otomatis pada tanggal penjualan. Jika tanggalnya belum pasti, gunakan asumsi transparan dan uji skenario terlambat.

Seberapa sering forecast harus diperbarui?

Untuk bisnis dengan kas ketat, perbarui setidaknya mingguan: ganti perkiraan minggu yang selesai dengan angka aktual, perbarui asumsi, dan tambahkan minggu baru.

Bisakah karyawan AI memutuskan pembayaran mana yang ditunda?

Jangan secara otomatis. Karyawan AI dapat menyiapkan opsi, dampak, dan bukti, tetapi perubahan pembayaran, komitmen pemasok, atau penggunaan dana memerlukan keputusan manusia yang berwenang.

Apakah proyeksi ini menggantikan laporan keuangan atau akuntan?

Tidak. Forecast adalah alat pengambilan keputusan berbasis asumsi. Ia tidak menggantikan laporan keuangan formal, rekonsiliasi, kewajiban pajak, atau nasihat profesional.

Bagikan artikel ini
WhatsApp