Prinsip Rekayasa untuk Membangun Sistem Keuangan
(substack.wasteman.codes)- Akuntansi tidak banyak berubah selama beberapa ratus tahun terakhir
- Meski begitu, masih ada banyak kebingungan tentang cara yang benar membangun perangkat lunak untuk sistem keuangan
- Tulisan ini membagikan pelajaran berdasarkan pengalaman membangun sistem keuangan di perusahaan besar
- Fokusnya adalah pada pembangunan sistem akuntansi, tetapi prinsip-prinsip ini juga berlaku untuk sistem keuangan yang lebih umum
Definisi istilah dasar keuangan
- Buku besar umum (General Ledger, GL): catatan akuntansi utama perusahaan yang merangkum semua transaksi keuangan selama periode tertentu. Ini dapat dianggap sebagai agregasi dari sub-ledger terkait
- Sub-ledger: berisi detail semua transaksi individual yang terkait dengan GL tertentu. Catatan dalam sub-ledger berisi data yang jauh lebih terperinci daripada buku besar umum (misalnya pelanggan tertentu, item tertentu dalam pesanan, dll.). Perbedaan data antara sub-ledger dan GL bergantung pada jenis bisnis dan volume data yang sedang dikelola. Beberapa perusahaan kecil bisa beroperasi tanpa sub-ledger, tetapi bila skalanya kecil, kemungkinan membutuhkan perangkat lunak khusus juga rendah
- Catatan keuangan (Financial Record): istilah kolektif untuk buku besar umum dan sub-ledger
- Materialitas (Material): menunjukkan apakah distorsi informasi dalam laporan keuangan dapat memengaruhi pengambilan keputusan pemangku kepentingan yang wajar. Definisi ini sengaja dibuat agak ambigu karena tiap perusahaan memiliki standar materialitas yang berbeda. Misalnya, sesuatu yang material bagi perusahaan dengan pendapatan tahunan $250 ribu mungkin tidak material bagi perusahaan dengan pendapatan tahunan $1 miliar. Dari sudut pandang desain, nilai utama konsep ini adalah untuk mengklasifikasikan berbagai kategori data keuangan
Alur Data Tingkat Tinggi
Business System --(Financial Events)--> Sub Ledger(s) --(Summarized Accounting Entries)--> General Ledger
Tiga tujuan utama sistem akuntansi
- Akurat (Accurate): catatan keuangan harus mencerminkan kondisi bisnis yang diketahui
- Contoh: jika menjual 10 produk seharga $9.99, maka total dalam catatan keuangan harus $99.90
- Ini tampak jelas, tetapi saat mengagregasikan ribuan hingga jutaan transaksi, penjumlahan sederhana antar sistem atau kesalahan pembulatan dapat menyebabkan ketidakakuratan yang material
-
Catatan Wasteman
- Orang bilang penamaan (naming) adalah masalah tersulit dalam ilmu komputer, tetapi saya rasa penjumlahan adalah yang kedua tersulit
- Selama beberapa tahun bekerja pada sistem keuangan berskala besar, saya sudah tak terhitung kali melihat bug yang sangat kecil menyebabkan perbedaan data yang besar
- Jangan mulai membahas penjumlahan pada float. Saya belajar dengan susah payah mengapa harus selalu memakai integer
- Catatan keuangan juga harus lengkap (complete)
- Lebih spesifiknya, sub-ledger dan buku besar umum harus merepresentasikan secara lengkap semua aktivitas bisnis yang terjadi pada titik waktu tertentu
- Jika ada peristiwa yang terjadi tetapi tidak ada dalam catatan keuangan, maka sistem tersebut tidak lengkap
- Ini bukan berarti eventual consistency tidak boleh digunakan
- Kita harus tahu kapan data menjadi lengkap agar bisa memberi tahu pemangku kepentingan bahwa data tersebut sudah final
-
Catatan Wasteman
- Menjamin kelengkapan juga merupakan masalah yang sangat sulit secara mengejutkan
- Saat sistem berkembang, data dapat berubah atau hilang secara tidak sengaja saat melewati beberapa sistem
- Dapat diaudit (Auditable): catatan keuangan harus mudah diaudit agar pemangku kepentingan dapat mendeteksi kesalahan dan mengukur kinerja bisnis dengan akurat
- Tepat waktu (Timely): sistem akuntansi harus memenuhi kebutuhan spesifik bisnis
- Bagi perusahaan kecil, membuang semua angka di akhir bulan mungkin sudah cukup, tetapi perusahaan besar umumnya menginginkan sistem yang nyaris real-time
- Ini memungkinkan mereka memantau kondisi keuangan sepanjang bulan, membuat keputusan berbasis data keuangan lebih cepat, dan mengurangi tekanan saat penutupan awal bulan/kuartal
- Apa pun kebutuhannya, sistem akuntansi kita harus memenuhi kebutuhan bisnis dan sesuai dengan apa yang mereka maksud sebagai tepat waktu
-
Catatan Wasteman
- Orang cenderung tersesat dalam perdebatan sistem batch vs streaming ketika membahas ketepatan waktu
- Menurut saya, bagi sebagian besar sistem, ini bukan perbedaan yang penting
- Ini penting jika Anda peduli pada latensi yang sangat pendek, dari hitungan detik hingga menit
- Namun mengejutkan betapa seringnya saya mendengar orang berdebat tentang apa yang harus dilakukan ketika konsumen sebenarnya tidak perlu melihat pembaruan lebih dari beberapa kali sehari
- Hanya karena diminta bukan berarti itu benar-benar dibutuhkan
Tiga prinsip rekayasa utama yang harus dipatuhi sistem akuntansi
- Immutability data dan durability
- Ini memungkinkan auditabilitas, sehingga membantu debugging dan akurasi
- Jika data bersifat immutable, kita dapat merekam keadaan sistem kapan saja
- Ini membuat perhitungan ulang dunia dari keadaan sebelumnya menjadi sangat mudah, karena tidak ada keadaan yang hilang
- Data yang sudah dinyatakan dalam catatan keuangan tidak boleh dihapus
- Semua koreksi pada sistem harus dinyatakan sebagai transaksi keuangan baru
- Contoh: jika ada bug dalam sistem sehingga layanan yang seharusnya $900 keliru dilaporkan terjual seharga $1000
- Untuk memperbaiki kesalahan ini, kita harus terlebih dahulu membalik entri akuntansi yang salah lalu mencatat ulang entri akuntansi dengan jumlah yang benar
- Data harus dicatat pada grain terkecil (Data recorded at the smallest grain)
- Mirip dengan prinsip di atas, ini juga sangat penting untuk memungkinkan jejak audit yang jelas
- Walaupun laporan keuangan dan buku besar umum bersifat agregat, semuanya dihitung dari peristiwa yang lebih terperinci
- Saat data tidak dipahami, kita membutuhkan data yang paling terperinci untuk men-debug apa masalahnya
- Menyimpan data pada tingkat granularitas terendah juga membuat koreksi data turunan dari dataset tersebut menjadi jauh lebih mudah
- Jika satu dataset immutable adalah sumber kebenaran inti untuk semua tampilan dari data tersebut,
- maka untuk memperbaiki tampilan, kita cukup memperbaiki datanya lalu menjalankan ulang pipeline yang menghasilkan tampilan tersebut
- Demikian pula, saat akuntan bersiap menutup pembukuan,
- mereka merekonsiliasi semua transaksi yang terjadi dan saldo akun untuk memverifikasi bahwa pembukuan akurat
- jika ditemukan ketidaksesuaian, mereka dapat menelusuri transaksi persis yang menyebabkan masalah
- Harus idempotent
- Setiap peristiwa keuangan hanya boleh diproses sekali, dan duplikasi dalam catatan keuangan akan menimbulkan ketidakakuratan yang jelas
- Karena itu, semua kode yang menghasilkan catatan keuangan harus bersifat idempotent
- Idempotent berarti sifat di mana hasil tidak berubah meskipun operasi diterapkan berkali-kali
- Artinya, meskipun peristiwa keuangan diproses beberapa kali, hasilnya harus sama dengan saat pertama diproses
Praktik terbaik
- Utamakan integer untuk merepresentasikan jumlah uang: operasi aritmetika menjadi jauh lebih mudah. Hindari float
- Dukung granularitas jumlah uang agar kehilangan presisi saat konversi mata uang bisa diminimalkan
- Jika hanya menangani dolar, merepresentasikannya dalam satuan sen mungkin sudah cukup
- Untuk bisnis global, gunakan micro-unit atau desimal seperti
DECIMAL(19, 4) - Desimal populer dalam sistem keuangan, tetapi dalam sistem keuangan periklanan, micro-unit adalah standar
- Gunakan metode pembulatan yang konsisten: cara pembulatan dapat menyebabkan perbedaan besar dari jumlah yang diharapkan
- Misalnya, semua nilai 5 ke atas dibulatkan ke digit signifikan berikutnya, sementara 4 ke bawah dibulatkan turun
- Atau selalu membulatkan ke atas
- Yang penting adalah menjaga konsistensi secara menyeluruh (jika selisih 1 sen per transaksi, pada 10 juta transaksi itu menjadi selisih $100k)
- Tunda konversi mata uang sebisa mungkin: mengonversi mata uang lebih awal dapat menyebabkan kehilangan presisi
- Tunda konversi mata uang sampai setelah agregasi terjadi dalam mata uang lokal
- Gunakan representasi integer untuk waktu: agak kontroversial, tetapi sangat direkomendasikan
- Berbagai library yang mem-parsing timestamp menjadi objek menanganinya dengan cara yang berbeda-beda
- Sebaiknya hindari kerumitan ini dan gunakan integer
- Unix timestamp atau datetime integer berbasis UTC juga bekerja dengan sangat baik
- Semakin sedikit transformasi data antar sistem, semakin baik
-
Catatan Wasteman
- Saya bahkan belum menyinggung bug terkait daylight saving time. Dengan memakai integer yang terus bertambah, ini bisa dihindari sepenuhnya
- Jika tetap bersikeras memakai datetime, setidaknya gunakan UTC. Mengejutkan betapa banyak perusahaan sangat besar yang masih menggunakan timestamp non-UTC
2 komentar
Ini benar-benar sangat berguna. Kalau konversi tipe (
decimal,float,double) dan pembulatan dilakukan begitu saja tanpa pemikiran matang atau diskusi di lingkungan kerja, akibatnya bisa besar.Komentar Hacker News
Menekankan pentingnya menggunakan metodologi pembulatan yang konsisten
Merekomendasikan metode merepresentasikan waktu sebagai bilangan bulat
Merekomendasikan penggunaan basis data relasional untuk sistem akuntansi
Tujuan utama sistem akuntansi adalah akurasi, keterauditan, dan ketepatan waktu
Pendapat tentang kelengkapan sistem akuntansi
Untuk bisnis global, disarankan menggunakan minimal 8 digit desimal
Menyebut pentingnya antarmuka pengguna (UI)
Menjelaskan perbedaan antara pemrosesan batch dan pemrosesan streaming
Berbagi pengalaman membangun sistem faktur dengan TypeScript
Merekomendasikan penggunaan kelas dari pustaka standar
Menjelaskan kesulitan pembulatan dan berbagi data
Berbagi pengalaman bekerja pada API untuk 10 bank terbesar di AS
Merekomendasikan "Accounting Patterns" karya Martin Fowler