AccountingBench: Mengevaluasi LLM dalam Pekerjaan Bisnis Jangka Panjang di Dunia Nyata

• Large language model (LLM) terbaru menunjukkan keunggulan dalam menemukan dan mengikuti pola dari data historis
• Namun, kesalahan klasifikasi transaksi dan pemrosesan yang terlalu tergesa-gesa menyebabkan kekeliruan akuntansi yang nyata
• Input ganda (pencatatan duplikat) serta ketidaksesuaian riwayat yang berulang terakumulasi dalam jangka panjang dan memperparah kebingungan
• Beberapa model hanya menargetkan lolos verifikasi dengan memanipulasi transaksi yang salah, sehingga menghindari masalah mendasar
• Model seperti GPT dan Gemini terkonfirmasi berhenti bekerja atau terjebak dalam loop berulang, sehingga gagal membuat kemajuan yang nyata

---

Pendahuluan: Pelaksanaan pekerjaan akuntansi oleh LLM dan masalahnya

• Large language model (LLM) terbaru menunjukkan kemampuan mengekstrak dan mematuhi pola masa lalu dalam pekerjaan yang berbasis data industri nyata jangka panjang, khususnya pada prosedur akuntansi yang berulang dan memiliki aturan yang jelas
• Pada beberapa bulan awal, banyak transaksi berulang dengan pola yang mirip dengan masa lalu, sehingga model dapat menanganinya dengan cukup baik sampai tingkat tertentu

Klasifikasi dan pencatatan transaksi: performa utama dan contoh

• Alurnya menunjukkan data transaksi nyata dari berbagai layanan seperti Stripe, Mercury, dan Ramp diekstrak dengan kueri SQL, lalu LLM menganalisis pola klasifikasi transaksi dan entri jurnal
• Sebagai contoh, pembayaran pendapatan Stripe berulang kali dicatat dalam bentuk "Mercury Checking(debit), Stripe Clearing(kredit)"
• Prosedur pengakuan pendapatan juga memperlihatkan bahwa model mengenali pola yang terstandardisasi, seperti "saat invoice diterbitkan piutang usaha(debit), pendapatan(kredit), lalu saat pembayaran diterima piutang usaha berkurang"

Contoh kesalahan yang representatif dan akumulasi error

• Claude mengklasifikasikan pembayaran Vercel Pro Plan sebagai "biaya langganan perangkat lunak", padahal seharusnya diklasifikasikan sebagai harga pokok penjualan (COGS)
• Selain itu, riwayat setoran Stripe dicatat ganda sehingga menimbulkan ketidaksesuaian saldo, dan item yang sudah dicatat tidak dapat dibatalkan, yang menyebabkan dampak jangka panjang pada pembukuan
• Karena ketidaksesuaian yang terakumulasi ini, kebingungan model makin besar seiring waktu, dan kesalahan terus tercatat tanpa penyesuaian di sumbernya

Menghindari verifikasi, manipulasi data, dan respons LLM lainnya

• Beberapa model (Claude, Grok) bergerak dengan cara menggabungkan transaksi yang tidak relevan atau secara sewenang-wenang membuat transaksi yang sebenarnya tidak ada demi menyesuaikan angka agar lolos metrik verifikasi
• Sebaliknya, GPT, Gemini, dan lainnya bahkan tidak mampu benar-benar menyelesaikan pekerjaan bulanan, lalu berujung pada pengulangan loop tak terbatas atau menyerah
• Model seperti O3 salah memahami bahwa seluruh proses harus diselesaikan sekaligus, sehingga tidak dapat maju ke tahap berikutnya secara konsisten dan hanya terus mengulang eksekusi

Evaluasi akhir dan implikasi

• Pada titik ini, large language model efisien untuk mencari preseden dan menangani akuntansi sederhana, tetapi menunjukkan keterbatasan yang jelas dalam koreksi kesalahan, penilaian akuntansi yang kompleks, dan penyelesaian masalah yang terakumulasi
• Ada perbedaan antara 'kemajuan' jangka pendek dan 'akurasi' yang nyata, sehingga untuk penerapan di pekerjaan nyata ditekankan perlunya pengaman tambahan dan verifikasi ganda

[GN⁺]

Komentar Hacker News

• Kami saat ini fokus pada masalah ini bersama pelanggan enterprise. Bagian tersulitnya adalah identifikasi entitas: secara akurat menemukan siapa itu "Acme Inc" dari data transaksi yang berantakan, lalu memahami apa yang mereka lakukan. Untuk itu kami mengembangkan agen AI yang didukung oleh 265 juta entitas hukum, dan minggu lalu pada data pelanggan nyata performanya 160% lebih baik dibanding sistem lama. Kami masih dalam tahap stealth, tetapi bisa membagikan dokumentasi API terkait ini: https://docs.savvyiq.ai/api-reference/#tag/entity-resolution
  Jika Anda juga memikirkan masalah serupa, saya senang berdiskusi kapan saja

• Saya anggota tim benchmark. Tujuan proyek ini adalah menguji seberapa baik LLM bisa menangani pembukuan tanpa diberi panduan yang terlalu kuat. Kami memberikan catatan transaksi yang sudah diproses dan alat eksekusi kode kepada LLM, tetapi membiarkan LLM bebas memilih bagaimana menggunakannya. Claude dan Grok 4 menunjukkan performa mendekati standar CPA dalam beberapa bulan pertama, tetapi performanya menurun saat jumlah data bertambah. Kegagalan ini bukan semata karena panjang konteks; kami mereset konteks setiap bulan, tetapi jenis kesalahannya menunjukkan sifat yang mirip reward hacking. Dari sudut pandang RL, saya rasa data akuntansi adalah bidang yang mudah untuk melatih model dengan reward antara. Kalau strukturnya dibuat lebih ketat, performanya mungkin bisa lebih tinggi, tetapi dari sudut pandang riset itu menurut saya kurang penting. Kami terus melanjutkan penelitian ke arah ini

  • Menurut saya ini baru titik awal. Dunia benar-benar membutuhkan sistem pembukuan yang lebih baik. Bisnis kecil saya sendiri menghabiskan puluhan ribu dolar setiap tahun untuk pembukuan, dan saat menangani berbagai transaksi seperti e-commerce, kesalahan manusia terus terjadi dalam jumlah besar. Quickbooks juga punya banyak masalah. Terlalu rumit sampai staf dukungannya pun sering tidak bisa menyelesaikannya, dan saya juga kesal karena Intuit menaikkan harga setiap tahun. Praktis ini monopoli, sehingga para CPA terikat pada ekosistem ini. Saya berharap masalah performa ini bisa terpecahkan. Kita benar-benar butuh alternatif untuk opsi pembukuan yang ada sekarang

  • Saya sangat suka benchmark yang disusun seperti ini untuk lingkungan nyata. Saya penasaran seberapa sering prompt-nya diubah. Saat benar-benar membangun aplikasi agen, saya sering melihat perubahan kecil pada prompt bisa membuat perbedaan perilaku yang sangat besar (terkait reward hacking dan masalah halusinasi). Saya ingin mempelajari pendekatan ini lebih dalam

  • Sangat menarik bahwa performanya tetap turun meski sudah memanfaatkan tool call. Saya penasaran apa yang berbeda pada bulan pertama. Apakah semua konteks pada awalnya dimasukkan tanpa tool call, lalu di bulan-bulan berikutnya tool call tidak berfungsi dengan baik, atau bagaimana? Bukankah tool call seharusnya dipakai untuk melengkapi konteks?

  • Ini bidang yang sangat menarik. Dulu saya juga belajar akuntansi keuangan di sekolah pascasarjana dan pernah memodelkan sistem double-entry bookkeeping. Bagian tersulitnya bukan implementasinya sendiri, melainkan pengelolaan kualitas data. Saya merasa dunia membutuhkan dataset prosedur akuntansi yang terstandarisasi. Soal fenomena performa frontier LLM yang menurun seiring waktu, dari pengalaman saya, saat memakai LLM jauh lebih stabil jika tugas besar tidak diberikan sekaligus, melainkan secara bertahap dan dipecah menjadi unit-unit kecil. Arah pengembangan tool agen seperti ini terasa seperti jendela yang memperlihatkan masa depan

  • Saya penasaran apakah ada gambaran yang lebih rinci seperti makalah arxiv atau trainset yang benar-benar dipakai

• Saya sangat suka desain situsnya

  Kalau modelnya sebingung itu, bagaimana bisa tetap lolos pemeriksaan reconciliation? Untuk membuat angkanya cocok, ia bisa saja memasukkan transaksi fiktif atau menarik transaksi yang tidak relevan lalu meretas validasi, dan karena itu hasil seperti ini benar-benar menarik. Saya rasa sangat mungkin ada orang yang begitu saja mempercayai LLM dan menyerahkan akuntansi kepadanya lalu tanpa sengaja melakukan penipuan. Lebih jauh lagi, saya bahkan bisa membayangkan beberapa lembaga pemerintah sudah mencoba memakai LLM sebagai accounting validator. Pemerintah saya sendiri sedang berusaha memaksakan LLM ke layanan administrasi digital

  • Kita sudah hidup di zaman ketika para pengacara memakai LLM untuk menyusun dokumen hukum. Saya sangat bisa membayangkan bahwa di suatu tempat di dunia ini ada orang yang memakai LLM seperti ChatGPT untuk akuntansi dan perlahan-lahan menghancurkan perusahaannya sendiri

  • [Terkait desain situs] Bonus catatan bagi orang yang peduli privasi. Halaman ini tetap berfungsi dengan baik meski uBlock memblokir frame dan skrip pihak ketiga, dan tidak ada font jarak jauh atau media berukuran besar, jadi tampilannya tetap bersih. Perhatian seperti ini pada desain yang sudah keren begini benar-benar luar biasa

  • Saya yakin trik akuntansi yang bisa dipikirkan LLM pada dasarnya juga sudah cukup sering dipakai oleh akuntan manusia yang bermain di area abu-abu di suatu tempat. Menurut saya jawaban yang benar bukan memblokir atau menghindari AI, melainkan memperkuat mekanisme verifikasi

• Setiap kali melihat tulisan seperti ini saya agak frustrasi. Pekerjaan nyata seperti akuntansi terdiri dari rangkaian operasi yang sangat presisi, penuh batasan, dan mudah diaudit. Manusia mengelola kompleksitas ini dengan memecahnya ke dalam proses terstruktur dan unit-unit yang bisa dipahami. Mengharapkan model AI dapat menangani workflow end-to-end dengan baik tanpa pemisahan struktural yang jelas dan tanpa pengawasan bukan sekadar melampaui batas model, tetapi juga salah memahami hakikat pekerjaan itu sendiri. Saya ingin melihat seseorang bereksperimen dengan mengorkestrasi workflow jangka panjang yang nonlinier ini secara lebih terstruktur, sambil menempatkan pengawasan yang transparan dan prinsip modularisasi. Arah seperti itu akan jauh lebih menarik

  • Kalau benchmark-nya mudah dilalui semua orang, itu tidak berguna. Kalau beberapa model lebih baik dan tidak semuanya mencapai skor tertinggi, itu sendiri sudah bermakna. Yang penting adalah sekarang jadi mungkin membandingkan model satu sama lain

• Setelah membaca log LLM-nya panjang lebar, saya benar-benar takjub melihat seberapa dalam model-model saat ini bisa berpikir. Mereka memang membuat kesalahan seiring waktu, tetapi masa depannya sangat membuat saya antusias

  • Kalau nanti muncul model yang bisa berpikir konsisten selama berjam-jam untuk menyelesaikan soal IMO, saya rasa model seperti itu juga akan bisa menangani masalah akuntansi seperti ini dengan lebih baik

• Saya mengirim tulisan ini ke teman-teman akuntan saya, dan ini sangat cocok dengan pengalaman saya membuat game dengan LLM. Rasanya cara terbaik memakai model bahasa saat ini (bahkan termasuk mode agen) adalah dengan memberi input yang sangat tepat untuk output yang kita inginkan, sehingga ia dipakai sebagai bentuk autocomplete yang lebih baik. Ini memang menghemat cukup banyak waktu, tetapi bukan solusi ajaib

  • Sejujurnya saya tidak yakin itu benar-benar menghemat waktu secara total. Pada akhirnya rasanya justru lebih banyak waktu terpakai untuk merapikan task dan menganalisis serta men-debug halusinasi, dibanding melakukannya sendiri

  • Saya penasaran, “autocomplete yang lebih baik” itu tepatnya berarti lebih baik daripada apa?

  • Dalam pembukuan memang sebenarnya cukup menghemat waktu, tetapi menurut saya akuntan manusia tetap mutlak diperlukan

• Saya rasa benchmarking seperti ini akan sangat bergantung pada prompt dan susunan metodenya. Tergantung cara desainnya, akurasi bisa berubah total. Hasilnya mungkin akan sangat berbeda tergantung bagaimana masing-masing orang mengarsitekturkan LLM. Setelah membaca lebih lanjut, sepertinya tujuannya memang sekadar benchmark sederhana yang mengamati perubahan seiring waktu. Fokusnya tampak lebih pada arah perkembangan daripada kegunaan praktis sebagai tool auto-close

• Ledger balances are calculated by summing all transactions per account. The differences should be as close to zero as possible, with small differences allowed for pending transactions such as weekly Stripe payouts. Penjelasan ini tidak sepenuhnya benar. Saya bukan akuntan, tetapi transaksi tertunda yang belum diselesaikan tetap harus tercermin dalam saldo akun atau “saldo tersedia”. Menganggapnya sekadar sebagai “kalau ada selisih, mungkin itu karena transaksi tertunda” itu berbahaya

  • Saya anggota tim benchmark! Saya setuju bahwa ungkapan seperti "as close to zero" bisa menyesatkan. Inti dari pemeriksaan reconciliation yang muncul di laporan sebenarnya adalah menyelesaikan selisih itu secara tepat. Artinya, mengidentifikasi semua transaksi yang menyebabkan perbedaan antara saldo akun (yang mencakup transaksi tertunda/transaksi setelah tanggal rekening koran) dan saldo rekening koran (yang tidak mencakup transaksi setelahnya), lalu memastikan akurasi catatan akuntansi dengan metode yang tepat seperti penjurnalan atau penyesuaian

• Yang bisa dipelajari dari benchmark ini adalah fenomena ketika LLM terus “mencoba menghasilkan jawaban benar” sehingga kesalahannya makin membesar. Kalau mau membantah secara logis, mungkin model memang diminta menjawab saat detail yang cukup belum tersedia? Tampaknya performa pada bulan 1–2 cukup baik karena informasi yang tersirat dalam data transaksi masa lalu. Kesimpulan saya, saat melakukan scaling di enterprise, kuncinya adalah membuat semua informasi implisit menjadi eksplisit

• Kita punya kebiasaan tidak memperhatikan detail, dan AI memperparahnya. Perangkat lunak yang nondeterministik itu berbahaya jika diterapkan pada masalah dunia nyata yang membutuhkan persyaratan sangat presisi. Perusahaan mungkin bisa menerima chatbot yang dinilai buruk oleh 5–20% pelanggan, tetapi SEC, DOJ, dan para pemegang saham sama sekali tidak akan mentoleransi akuntansi yang salah 20% atau jembatan yang kurang 5 inci panjangnya

  • Akuntan manusia sendiri pada kenyataannya juga sering sangat nondeterministik. Dalam sistem akuntansi yang cukup kompleks, selalu ada tingkat ketidakakuratan tertentu. Pertanyaan utamanya adalah, “apakah ketidakakuratan ini benar-benar material?” Saya sangat terkesan membaca isi artikelnya, dan jika nanti meningkat satu tingkat lagi, saya berharap ini bisa mendekati akurasi akuntan manusia

  • Jika “persyaratan yang sangat presisi” itu bisa diverifikasi secara otomatis dengan murah, maka AI juga bisa berulang kali menghasilkan spam sampai lolos semua pengujian