Mengukur AI di Bidang Keuangan: Waktu Tutup Buku, Biaya per Faktur, dan Akurasi Prakiraan

Oleh Jane Ha · Diperbarui 11 Oktober 2026

Mengukur AI di keuangan berarti memilih sekumpulan kecil metrik operasional yang sudah dipercaya keuangan (jumlah hari tutup buku, biaya per faktur, kesalahan prakiraan), mencatat masing-masing sebelum alat dijalankan, dan membandingkan dengan definisi yang sama sesudahnya. Alatnya sendiri jarang menjadi bagian tersulit. Bagian tersulit adalah membuktikan, kepada CFO atau auditor, bahwa angkanya bergerak karena AI dan bukan karena kuartal yang sepi, karyawan baru, atau definisi yang berubah.

Panduan ini ditujukan bagi controller (kepala akuntansi), direktur keuangan, dan pemimpin FP&A yang sedang menjalankan satu atau lebih uji coba (pilot) AI, atau akan segera memulai, dan perlu melaporkan hasilnya. Panduan ini bertumpu pada panduan proses untuk tutup buku akhir bulan, utang usaha, dan FP&A. Jika Anda masih di awal perjalanan, pertanyaan yang lebih luas tentang mengapa ROI AI sulit dibuktikan adalah pendamping yang berguna.

Fakta Utama

• Survei tolok ukur Akuntansi Umum dari APQC, yang dilaporkan CFO.com pada 2018, menempatkan 25% organisasi teratas pada 4,8 hari kalender atau kurang untuk tutup buku, median pada 6,4 hari, dan 25% terbawah pada 10 hari atau lebih, dari 2.300 responden (CFO.com).
• Dalam ukuran itu, waktu siklus berjalan dari menjalankan neraca saldo hingga menyelesaikan laporan keuangan konsolidasian, dan menghitung baik pekerjaan aktif maupun waktu menunggu (CFO.com).
• Laporan State of ePayables 2025 dari Ardent Partners, berdasarkan 204 pemimpin AP dan keuangan, menempatkan tim AP terbaik di kelasnya pada $2,65 per faktur dibandingkan rata-rata $12,42 (Ardent Partners).
• Panduan buku teks prakiraan mendefinisikan MAPE sebagai rata-rata kesalahan persentase absolut, dan memperingatkan bahwa ukuran persentase menjadi tak hingga atau tak terdefinisi ketika nilai aktual nol dan tidak stabil ketika mendekati nol (Hyndman dan Athanasopoulos).
• Teks yang sama menyatakan bahwa set pengujian idealnya setidaknya sebesar horizon prakiraan terpanjang yang Anda butuhkan, dan menjelaskan evaluasi rolling-origin, di mana setiap prakiraan hanya memakai data yang lebih awal (Hyndman dan Athanasopoulos).

Mengapa Tim Keuangan Membutuhkan Rencana Pengukuran Sebelum Uji Coba

Kebanyakan uji coba AI di keuangan dinilai berdasarkan perasaan. Staf AP berkata lebih cepat, controller berkata tutup buku "terasa lebih mulus," dan enam bulan kemudian tak seorang pun bisa mengatakan seberapa besar. Itu masalah karena dua alasan.

Pertama, anggaran. Alat yang tidak bisa menunjukkan hasil dipangkas pada siklus perencanaan berikutnya, meskipun sebenarnya membantu. Kedua, kontrol. Jika langkah AI menyentuh pelaporan keuangan, Anda akan membutuhkan bukti bahwa ia bekerja dalam toleransi, yang oleh panduan pengendalian internal didaftar sebagai hasil backtest (uji historis) dan akurasi. Pengukuran memenuhi dua fungsi sekaligus.

Kabar baiknya, keuangan sudah memiliki metrik yang dipahami dengan baik. Anda tidak membutuhkan kartu skor AI baru. Anda membutuhkan kartu skor lama dengan baseline yang bersih.

Tiga Metrik Jangkar

Waktu tutup buku

Waktu tutup buku adalah jumlah hari kalender antara menjalankan neraca saldo dan menyelesaikan laporan keuangan konsolidasian. Itulah definisi di balik ukuran APQC di atas, dan ia mencakup waktu menunggu, bukan hanya pekerjaan langsung.

Sebaran tolok ukur ini adalah konteks yang berguna. Median 6,4 hari dengan kuartil teratas pada 4,8 atau kurang dan kuartil terbawah pada 10 atau lebih berarti selisih antara tutup buku yang baik dan yang lambat adalah beberapa hari. Tetapi itu laporan tahun 2018 dari satu pertanyaan survei, jadi pakai untuk menempatkan diri secara kasar, bukan untuk menetapkan target. Tren Anda sendiri lebih penting daripada median siapa pun.

Apa yang seharusnya digeser AI: jam rekonsiliasi dan pencocokan, jumlah entri jurnal manual, waktu yang dihabiskan mengejar jadwal, dan penyesuaian pascatutup buku. Apa yang tidak seharusnya digeser sendirian: langkah persetujuan resmi, yang tetap dikerjakan manusia.

Biaya per faktur

Biaya per faktur adalah biaya penuh (fully loaded) menjalankan proses AP dalam suatu periode dibagi jumlah faktur yang diproses pada periode itu. "Biaya penuh" adalah titik di mana tim berbeda pendapat. Sebagian hanya menghitung gaji staf AP, yang lain menambahkan perangkat lunak, biaya bank, overhead, dan waktu pemberi persetujuan di departemen lain.

Angka Ardent memberi gambaran sebarannya: $2,65 untuk tim terbaik di kelasnya dibandingkan rata-rata $12,42. Jangan menyalin angka itu ke dalam business case Anda. Sampel laporan, bauran faktur, dan definisi biayanya tidak akan sama dengan milik Anda. Jika vendor mengutip tolok ukur, tanyakan apa isi angka itu. Komponen biaya Anda sendiri yang menentukan, dan satu-satunya aturan adalah memakai komponen yang sama sebelum dan sesudah.

Apa yang seharusnya digeser AI: waktu sentuh per faktur, porsi faktur yang membutuhkan pengodean manual, waktu penanganan pengecualian, dan pembayaran ganda yang tertangkap. Volume juga penting. Jika jumlah faktur berlipat dua setelah akuisisi, total biaya mungkin naik sementara biaya per faktur turun, dan itu wajar, tetapi sebutkan hal itu dalam laporan.

Akurasi prakiraan

Akurasi prakiraan adalah seberapa dekat prakiraan dengan apa yang terjadi, diukur pada data yang belum pernah dilihat model. Ukuran buku teksnya adalah mean absolute error (MAE), root mean squared error (RMSE), dan mean absolute percentage error (MAPE). MAPE populer di keuangan karena berupa persentase, tetapi ia gagal di dekat nol, itulah sebabnya ia lebih cocok untuk pendapatan daripada arus kas bersih. Untuk baris yang melintasi nol, gunakan MAE atau ukuran terskala. Panduan prakiraan arus kas membahas pilihan itu lebih rinci.

Dua kebiasaan membuat metrik prakiraan jujur. Evaluasi pada periode yang ditahan, jangan pernah pada riwayat yang dipakai untuk melatih model, karena akurasi pada data latih selalu tampak lebih baik daripada akurasi sebenarnya. Dan bandingkan dengan baseline naif, seperti "bulan depan sama dengan bulan yang sama tahun lalu." Jika model AI tidak bisa mengalahkannya pada data Anda, ia belum membuktikan nilainya. Panduan FP&A menjelaskan mengapa metode yang lebih sederhana sering bertahan.

Apa yang seharusnya digeser AI: kesalahan per baris dan horizon, bias (apakah Anda secara konsisten memprakirakan terlalu tinggi atau terlalu rendah), dan jumlah hari dari akhir periode hingga paket prakiraan selesai.

Tabel Pengukuran

Gunakan ini sebagai kerangka kartu skor satu halaman. Tambahkan baris untuk proses Anda sendiri.

Cara Menetapkan Baseline, Langkah demi Langkah

1. Pilih satu proses dan dua atau tiga metrik. Tahan dorongan untuk mengukur semuanya. Waktu tutup buku dan jumlah jurnal manual untuk tutup buku, biaya per faktur dan tingkat tanpa sentuhan untuk AP, kesalahan dan bias untuk satu baris prakiraan.

   

2. Tuliskan definisinya. Di mana jam mulai dan berhenti? Biaya mana yang masuk? Faktur mana yang dikecualikan? Satu paragraf sekarang mencegah perdebatan nanti.

3. Tarik riwayatnya. Gunakan setidaknya enam periode jika bisa, agar satu bulan yang janggal tidak menentukan baseline. Catat apa pun yang tidak lazim: akuisisi, migrasi sistem, bulan yang padat hari libur.

4. Rekam sebelum ada yang mengubah prosesnya. Uji coba cenderung dimulai dengan antusiasme tanpa potret awal. Panduan kesiapan data adalah tempat memeriksa apakah data sumber untuk setiap metrik cukup bersih untuk dipercaya.

5. Tambahkan pembanding naif. Untuk prakiraan, nilai prakiraan "sama dengan tahun lalu" atau "nilai terakhir" pada periode yang sama. Untuk tutup buku, pembandingnya sekadar tren tahun lalu.

6. Jalankan paralel jika bisa. Selama beberapa siklus, biarkan proses lama dan proses berbantuan AI berjalan berdampingan. Bandingkan baris demi baris. Ini juga yang ingin dilihat auditor Anda.

7. Tahan pengujiannya. Untuk prakiraan, sisihkan periode terbaru yang tidak dilihat model, setidaknya sepanjang horizon terpanjang Anda, dan pakai evaluasi rolling-origin agar setiap prakiraan hanya melihat data yang lebih awal.

8. Laporkan menurut jadwal tetap. Metrik sama, definisi sama, setiap siklus. Tempatkan baseline di samping angka terkini setiap kali.

Contoh menurut Fungsi

Controller, tutup buku akhir bulan. Bayangkan perusahaan menengah yang controller-nya mencatat hari kalender dan entri jurnal manual untuk delapan tutup buku terakhir, serta mencatat rentangnya. Setelah menambahkan pencocokan otomatis pada akun bank dan antarperusahaan, controller melacak dua angka yang sama ditambah penyesuaian pascatutup buku. Sasarannya: hari turun, entri manual turun, dan penyesuaian datar. Penyesuaian yang datar itulah yang membuat tutup buku yang lebih cepat dapat dipercaya.

Manajer AP. Sebuah tim menghitung volume faktur bulanannya dan menuliskan setiap biaya yang dimasukkannya: gaji AP, perangkat lunak, biaya bank, dan sebagian waktu pengadaan. Setelah meluncurkan pengambilan dokumen, tim melaporkan biaya per faktur, tingkat tanpa sentuhan, dan tingkat koreksi peninjau. Tingkat koreksi adalah peringatan dini. Jika tingkat tanpa sentuhan naik sementara koreksi ikut naik, alat itu sedang mendorong kesalahan ke hilir.

Pemimpin FP&A. Tim menilai prakiraan pendapatan saat ini, prakiraan musiman naif, dan model pembelajaran mesin pada data ditahan 12 bulan terakhir. Misalkan model mengalahkan baseline naif pada beberapa lini produk dan kalah pada yang lain. Tim menerapkannya di tempat ia menang dan mempertahankan metode yang ada di tempat lain. Hasil campuran yang dilaporkan jujur lebih berharga daripada pernyataan menyeluruh "AI meningkatkan akurasi."

Kesalahan Umum

• Tanpa baseline. Kegagalan yang paling umum. Tanpa angka sebelumnya, setiap hasil hanyalah anekdot.

  

• Mengubah definisi di tengah proyek. Jika "tutup buku" dimulai pada langkah yang berbeda setelah go-live, hari yang dihemat sebagian hanyalah trik akuntansi.

• Mengukur kecepatan tanpa kualitas. Tutup buku lebih cepat dengan lebih banyak penyesuaian pascatutup buku, atau faktur lebih cepat dengan lebih banyak pembayaran ganda, bukanlah perbaikan. Selalu pasangkan metrik kecepatan dengan metrik kualitas. Panduan kontrol akurasi membahas sisi kualitasnya.

• Menilai prakiraan pada data latih. Akurasi pada data latih melebih-lebihkan akurasi sebenarnya.

• Memakai MAPE di mana nilai aktual menyentuh nol. Arus kas bersih dan baris biaya kecil menghasilkan persentase yang menyesatkan. Pilih ukuran yang menanganinya.

• Meminjam tolok ukur tanpa definisinya. "Rata-rata biaya per faktur" milik vendor mungkin menghitung biaya yang berbeda dari milik Anda. Bandingkan yang setara atau jangan membandingkan.

• Memberi AI kredit atas segalanya. Musiman, perubahan volume, staf baru, dan pembenahan proses semuanya menggeser angka ini. Jika memungkinkan, pertahankan kelompok kontrol, seperti satu entitas atau lini produk tanpa alat itu.

• Meratakan cerita menjadi rata-rata. Laporkan per baris, entitas, atau jenis faktur. Rata-rata yang kuat dapat menyembunyikan segmen di mana alat itu bekerja buruk.

• Mengabaikan sisi biaya. Perangkat lunak, implementasi, waktu tinjauan, dan pengerjaan ulang termasuk dalam ROI.

Yang Perlu Dilakukan Kuartal Ini

Pilih satu proses. Tulis definisi dua metrik dalam bahasa sederhana, tarik riwayat enam periode, dan nilai pembanding naif. Itu pekerjaan satu minggu, dan mengubah uji coba berikutnya dari cerita menjadi hasil. Lalu sepakati, sebelum peluncuran, hasil apa yang dihitung sebagai keberhasilan dan apa yang akan membuat Anda berhenti.