Pembulatan mata uang di aplikasi keuangan: simpan uang dengan aman

Mengapa bug satu sen terjadi

Bug satu sen adalah jenis kesalahan yang langsung diperhatikan pengguna. Total keranjang menunjukkan $19.99 pada daftar produk, tapi menjadi $20.00 saat checkout. Refund sebesar $14.38 tiba sebagai $14.37. Baris faktur menulis “Tax: $1.45”, namun total akhir terlihat seperti ditambahkan dengan aturan pajak yang berbeda.

Masalah ini biasanya berasal dari perbedaan pembulatan kecil yang menumpuk. Uang bukan sekadar “angka”. Ada aturannya: berapa banyak tempat desimal yang dipakai suatu mata uang, kapan Anda membulatkan, dan apakah Anda membulatkan per baris item atau pada total akhir. Jika aplikasi Anda membuat pilihan yang berbeda di tempat yang berbeda, satu sen bisa muncul atau lenyap.

Biasanya juga masalah ini hanya muncul kadang-kadang, sehingga sulit di-debug. Input yang sama bisa menghasilkan selisih sen berbeda tergantung pengaturan perangkat atau lokal, urutan operasi, atau bagaimana nilai dikonversi antar tipe.

Pemicu umum meliputi menghitung dengan float dan membulatkan “di akhir” (tetapi “akhir” tidak sama di semua tempat), menerapkan pajak per item di satu layar dan pada subtotal di layar lain, mencampur mata uang atau kurs dan melakukan pembulatan pada langkah yang tidak konsisten, atau memformat nilai untuk tampilan lalu secara tidak sengaja mengurai kembali sebagai angka.

Dampaknya paling terasa di tempat kepercayaan rapuh dan jumlah diaudit: total checkout, refund, faktur, langganan, tip, payout, dan laporan pengeluaran. Selisih satu sen dapat menyebabkan kegagalan pembayaran, kerepotan rekonsiliasi, dan tiket dukungan dengan klaim seperti “aplikasi Anda mencuri uang saya.”

Tujuannya sederhana: input yang sama harus menghasilkan sen yang sama di mana saja. Barang yang sama, pajak yang sama, diskon yang sama, aturan pembulatan yang sama, tidak peduli layar, perangkat, bahasa, atau ekspor.

Contoh: jika dua barang seharga $9.99 memiliki pajak 7.25%, tentukan apakah Anda membulatkan pajak per item atau pada subtotal, lalu lakukan dengan cara yang sama di backend, UI web, dan aplikasi mobile. Konsistensi mencegah momen “mengapa berbeda di sini?”

Mengapa float berisiko untuk uang

Sebagian besar bahasa pemrograman menyimpan nilai float dan double dalam biner. Banyak harga desimal tidak dapat direpresentasikan secara tepat dalam biner, jadi angka yang Anda kira tersimpan sering sedikit lebih tinggi atau lebih rendah.

Contoh klasik adalah 0.1 + 0.2. Di banyak sistem itu menjadi 0.30000000000000004. Itu terlihat tidak berbahaya, tapi logika uang biasanya adalah rangkaian: harga item, diskon, pajak, biaya, lalu pembulatan akhir. Kesalahan kecil dapat mengubah keputusan pembulatan dan menciptakan selisih satu sen.

Gejala yang sering terlihat saat pembulatan uang salah:

• Nilai seperti 9.989999 atau 19.9000001 muncul di log atau respons API.
• Total bergeser setelah menambah banyak item, meskipun setiap item tampak baik.
• Total refund tidak cocok dengan charge asli sebesar $0.01.
• Total keranjang yang sama berbeda antara web, mobile, dan backend.

Pemformatan sering menyembunyikan masalah. Jika Anda mencetak 9.989999 dengan dua desimal, itu tampil 9.99, sehingga semuanya tampak benar. Bug muncul nanti ketika Anda menjumlah banyak nilai, membandingkan total, atau membulatkan setelah pajak. Itu sebabnya tim terkadang mengirimkan fitur dan hanya menemukannya saat rekonsiliasi dengan penyedia pembayaran atau ekspor akuntansi.

Aturan praktis sederhana: jangan menyimpan atau menjumlah uang sebagai angka floating-point. Perlakukan uang sebagai jumlah integer dari unit minor mata uang (seperti sen), atau gunakan tipe desimal yang menjamin aritmetika desimal tepat.

Jika Anda membangun backend, web app, atau mobile (termasuk di platform no-code seperti AppMaster), pegang prinsip yang sama di mana-mana: simpan nilai yang tepat, hitung pada nilai yang tepat, dan format hanya untuk tampilan di akhir.

Pilih model uang yang cocok dengan mata uang nyata

Kebanyakan bug uang dimulai sebelum matematika: model data tidak cocok dengan cara kerja mata uang. Dapatkan model yang tepat sejak awal dan pembulatan menjadi masalah aturan, bukan tebak-tebakan.

Default paling aman adalah menyimpan uang sebagai integer pada minor unit mata uang. Untuk USD, itu berarti sen; untuk EUR, euro-sen. Database dan kode Anda menangani integer tepat, dan Anda hanya “menambahkan desimal” saat memformat untuk manusia.

Tidak semua mata uang punya 2 desimal, jadi model Anda harus peka terhadap mata uang. JPY punya 0 desimal minor (1 yen adalah unit terkecil). BHD umum menggunakan 3 desimal (1 dinar = 1000 fils). Jika Anda meng-hardcode “dua desimal di mana-mana”, Anda akan diam-diam membebani atau kurang membebani.

Rekam data uang praktis biasanya membutuhkan:

• amount_minor (integer, misalnya 1999 untuk $19.99)
• currency_code (string seperti USD, EUR, JPY)
• opsional minor_unit atau scale (0, 2, 3) jika sistem Anda tidak bisa selalu melihatnya

Simpan kode mata uang bersama setiap jumlah, bahkan di dalam tabel yang sama. Itu mencegah kesalahan ketika Anda menambahkan harga multi-mata uang, refund, atau laporan.

Juga tentukan di mana pembulatan diperbolehkan dan di mana dilarang. Satu kebijakan yang baik adalah: jangan membulatkan di dalam total internal, alokasi, ledger, atau konversi yang sedang berlangsung; bulatkan hanya pada batas yang ditentukan (seperti langkah pajak, langkah diskon, atau baris akhir invoice); dan selalu catat mode pembulatan yang digunakan (half up, half even, round down) supaya hasil bisa direproduksi.

Langkah demi langkah: terapkan uang sebagai integer minor-unit

Jika Anda ingin lebih sedikit kejutan, pilih satu bentuk internal untuk uang dan jangan ubah: simpan jumlah sebagai integer pada minor unit mata uang (sering kali sen).

Itu berarti $10.99 menjadi 1099 dengan mata uang USD. Untuk mata uang tanpa minor unit seperti JPY, 1.500 yen tetap 1500.

Jalur implementasi sederhana yang skala seiring pertumbuhan aplikasi Anda:

1. Database: simpan amount_minor sebagai integer 64-bit plus kode mata uang (seperti USD, EUR, JPY). Beri nama kolom dengan jelas agar tidak salah mengartikannya sebagai desimal.
2. Kontrak API: kirim dan terima { amount_minor: 1099, currency: "USD" }. Hindari string terformat seperti "$10.99" dan hindari JSON float.
3. Input UI: perlakukan apa yang diketik pengguna sebagai teks, bukan angka. Normalisasi (trim spasi, terima satu pemisah desimal), lalu konversi menggunakan digit minor-unit mata uang.
4. Semua matematika dalam integer: total, jumlah baris, diskon, biaya, dan pajak harus beroperasi hanya pada integer. Definisikan aturan seperti “diskon persentase dihitung lalu dibulatkan ke minor unit” dan terapkan secara konsisten.
5. Format hanya di akhir: saat menampilkan uang, konversi amount_minor ke string tampilan menggunakan aturan lokal dan mata uang. Jangan pernah mengurai keluaran terformat Anda sendiri kembali ke matematika.

Contoh penguraian praktis: untuk USD, ambil "12.3" dan perlakukan sebagai "12.30" sebelum mengonversi menjadi 1230. Untuk JPY, tolak desimal sejak awal.

Aturan pembulatan pajak, diskon, dan biaya

Kebanyakan perselisihan satu sen bukan kesalahan matematika. Mereka adalah kesalahan kebijakan. Dua sistem bisa sama-sama “benar” dan tetap tidak setuju jika mereka membulatkan pada waktu yang berbeda.

Tuliskan kebijakan pembulatan Anda dan gunakan di mana-mana: perhitungan, kwitansi, ekspor, dan refund. Pilihan umum termasuk rounding half-up (0.5 dibulatkan naik) dan half-even (0.5 dibulatkan ke cent genap terdekat). Beberapa biaya mengharuskan selalu ke atas (ceiling) agar Anda tidak kurang mengenakan biaya.

Total biasanya berubah berdasarkan beberapa keputusan: apakah Anda membulatkan per baris atau per invoice, apakah Anda mencampur aturan (misalnya pajak per baris tapi biaya pada invoice), dan apakah harga sudah termasuk pajak (Anda menghitung mundur neto dan pajak) atau belum termasuk pajak (Anda menghitung pajak dari neto).

Diskon menambah cabang keputusan lain. “Diskon 10%” yang diterapkan sebelum pajak mengurangi basis kena pajak, sedangkan diskon setelah pajak mengurangi yang dibayar pelanggan tapi mungkin tidak mengubah pajak yang dilaporkan, tergantung yurisdiksi dan kontrak.

Contoh kecil menunjukkan mengapa aturan ketat penting. Dua item $9.99, pajak 7.5%. Jika Anda membulatkan pajak per baris, pajak tiap baris adalah $0.75 (9.99 x 0.075 = 0.74925). Total pajak menjadi $1.50. Jika Anda menghitung pajak dari total invoice, pajak juga $1.50 di contoh ini, tapi ubah sedikit harga dan Anda akan melihat selisih 1 sen.

Tulis aturan itu dengan bahasa sederhana supaya dukungan dan bagian keuangan bisa menjelaskannya. Lalu gunakan helper yang sama untuk pajak, biaya, diskon, dan refund.

Konversi mata uang tanpa membuat totals bergeser

Matematika multi-mata-uang adalah tempat pilihan pembulatan kecil dapat perlahan mengubah total. Tujuannya sederhana: konversi sekali, bulat dengan sengaja, dan simpan fakta asli untuk nanti.

Simpan kurs dengan presisi eksplisit. Pola umum adalah integer berskala, seperti “rate_micro” di mana 1.234567 disimpan sebagai 1234567 dengan skala 1.000.000. Opsi lain adalah tipe desimal tetap, tapi tetap tuliskan skala dalam field supaya tidak bisa ditebak.

Pilih mata uang dasar untuk pelaporan dan akuntansi (sering mata uang perusahaan Anda). Konversi jumlah masuk ke mata uang dasar untuk ledger dan analitik, tapi simpan jumlah dan mata uang asli bersamanya. Dengan begitu, Anda bisa menjelaskan setiap angka nanti.

Aturan yang mencegah drift:

• Konversi hanya satu arah untuk akuntansi (asing ke base), dan hindari konversi bolak-balik.
• Tentukan waktu pembulatan: bulat per baris item saat Anda harus menampilkan total baris, atau bulat pada akhir saat Anda hanya menampilkan grand total.
• Gunakan satu mode pembulatan secara konsisten dan dokumentasikan.
• Simpan jumlah asli, mata uang, dan kurs tepat yang digunakan untuk transaksi.

Contoh: pelanggan membayar 19.99 EUR, dan Anda menyimpannya sebagai 1999 minor units dengan currency=EUR. Anda juga menyimpan rate yang digunakan saat checkout (misalnya EUR ke USD dalam unit mikro). Ledger Anda menyimpan jumlah USD yang dikonversi (dibulatkan sesuai aturan yang dipilih), tapi refund menggunakan jumlah EUR asli dan mata uang yang tersimpan, bukan rekonversi dari USD. Itu mencegah tiket “kenapa saya mendapat 19.98 EUR kembali?”.

Pemformatan dan tampilan di berbagai perangkat

Tahap akhir adalah layar. Nilai bisa benar di penyimpanan namun terlihat salah jika pemformatan berbeda antara web dan mobile.

Locale yang berbeda mengharapkan tanda baca dan posisi simbol yang berbeda. Misalnya, banyak pengguna AS membaca $1,234.50, sementara di banyak bagian Eropa mereka mengharapkan 1.234,50 € (nilai sama, pemisah berbeda dan posisi simbol berbeda). Jika Anda memformat secara hardcode, Anda akan membingungkan orang dan menimbulkan pekerjaan dukungan.

Pegang satu aturan di mana-mana: format di tepi (edge), bukan di inti. Sumber kebenaran Anda harus berupa (kode mata uang, integer minor units). Hanya konversi ke string untuk tampilan. Jangan pernah mengurai string terformat kembali menjadi uang. Di situlah pembulatan, pemangkasan, dan kejutan lokal masuk.

Untuk jumlah negatif seperti refund, pilih gaya konsisten dan gunakan di mana-mana. Beberapa sistem menunjukkan -$12.34, yang lain menunjukkan ($12.34). Keduanya sah. Berganti gaya antar layar terlihat seperti kesalahan.

Kontrak lintas-perangkat sederhana yang bekerja baik:

• Bawa mata uang sebagai kode ISO (seperti USD, EUR), bukan hanya simbol.
• Format menggunakan locale perangkat secara default, tapi izinkan override dalam aplikasi.
• Tampilkan kode mata uang di samping jumlah pada layar multi-mata-uang (mis. 12.34 USD).
• Perlakukan pemformatan input terpisah dari pemformatan tampilan.
• Bulat sekali, berdasarkan aturan uang Anda, sebelum memformat.

Contoh: pelanggan melihat refund 10,00 EUR di mobile, lalu membuka order yang sama di desktop dan melihat -€10. Jika Anda juga menampilkan kodenya (10,00 EUR) dan menjaga gaya negatif konsisten, mereka tidak akan bertanya apakah itu berubah.

Contoh: checkout, pajak, dan refund tanpa kejutan

Keranjang sederhana:

• Item A: $4.99 (499 cents)
• Item B: $2.50 (250 cents)
• Item C: $1.20 (120 cents)

Subtotal = 869 cents ($8.69). Terapkan diskon 10% terlebih dahulu: 869 x 10% = 86.9 cents, dibulatkan menjadi 87 cents. Subtotal setelah diskon = 782 cents ($7.82). Sekarang terapkan pajak 8.875%.

Di sinilah aturan pembulatan bisa mengubah sen akhir.

Jika Anda menghitung pajak pada total invoice: 782 x 8.875% = 69.4025 cents, dibulatkan menjadi 69 cents.

Jika Anda menghitung pajak per baris (setelah diskon) dan membulatkan setiap baris:

• Item A: $4.49 pajak = 39.84875 cents, dibulatkan menjadi 40
• Item B: $2.25 pajak = 19.96875 cents, dibulatkan menjadi 20
• Item C: $1.08 pajak = 9.585 cents, dibulatkan menjadi 10

Total pajak per baris = 70 cents. Keranjang yang sama, tarif yang sama, aturan valid berbeda, selisih 1 sen.

Tambahkan biaya pengiriman setelah pajak, misalnya 399 cents ($3.99). Total menjadi $12.50 (pajak pada level invoice) atau $12.51 (pajak per baris). Pilih satu aturan, dokumentasikan, dan pertahankan konsistensi.

Sekarang refund Item B saja. Refund harga diskonnya (225 cents) plus pajak yang melekat padanya. Dengan pajak per baris, itu 225 + 20 = 245 cents ($2.45). Total tersisa masih rekonsiliasi dengan tepat.

Untuk menjelaskan perbedaan nanti, log nilai-nilai ini untuk setiap charge dan refund:

• net cents per baris, pajak cents per baris, dan mode pembulatan
• diskon invoice cents dan bagaimana dialokasikan
• tarif pajak dan dasar kena pajak cents yang digunakan
• pengiriman/biaya cents dan apakah itu kena pajak
• total akhir cents dan refund cents

Cara menguji perhitungan uang

Kebanyakan bug uang bukan “bug matematika”. Mereka adalah bug pembulatan, urutan, dan pemformatan yang baru muncul untuk keranjang atau tanggal tertentu. Tes yang baik membuat kasus-kasus itu membosankan.

Mulailah dengan tes golden: input tetap dengan output yang diharapkan dalam minor unit (seperti cents). Buat assertion ketat. Jika item 199 cents dan pajak 15 cents, tes harus memeriksa nilai integer, bukan string yang diformat.

Sekumpulan golden kecil bisa menutup banyak kasus:

• Satu baris item dengan pajak, lalu diskon, lalu biaya (cek setiap pembulatan menengah)
• Banyak baris item di mana pajak dibulatkan per baris vs pada subtotal (verifikasi aturan yang dipilih)
• Refund dan refund parsial (verifikasi tanda dan arah pembulatan)
• Konversi putar-balik (A ke B ke A) dengan kebijakan yang ditentukan tentang di mana pembulatan terjadi
• Nilai edge (item 1 cent, kuantitas besar, total sangat besar)

Lalu tambahkan pemeriksaan berbasis properti (atau tes acak sederhana) untuk menangkap kejutan. Alih-alih satu angka yang diharapkan, assertion memeriksa invarians: total = jumlah baris, tidak ada minor unit fraksional, dan “total = subtotal + pajak + biaya - diskon” selalu berlaku.

Pengujian lintas-platform penting karena hasil bisa berbeda antara backend dan klien. Jika Anda punya backend Go dengan web Vue dan mobile Kotlin/SwiftUI, jalankan vektor tes yang sama di setiap lapisan dan bandingkan output integer, bukan string UI.

Akhirnya, uji kasus berbasis waktu. Simpan tarif pajak yang digunakan pada invoice dan verifikasi invoice lama dihitung ulang menjadi hasil yang sama meski tarif berubah. Di sinilah bug “dulu cocok” lahir.

Perangkap umum yang harus dihindari

Kebanyakan bug satu sen bukan kesalahan matematika. Mereka adalah kesalahan kebijakan: kode melakukan persis apa yang Anda perintahkan, hanya bukan apa yang diharapkan bagian keuangan.

Perangkap yang patut diwaspadai:

• Membulatkan terlalu dini: Jika Anda membulatkan setiap baris item, lalu membulatkan subtotal, lalu membulatkan pajak, total bisa bergeser. Tentukan aturan (mis. pajak per baris vs pada total invoice) dan bulatkan hanya di tempat kebijakan Anda mengizinkan.
• Mencampur mata uang dalam satu jumlah: Menambahkan USD dan EUR dalam field “total” tampak aman sampai refund, pelaporan, atau rekonsiliasi. Tandai jumlah dengan mata uangnya, dan konversi menggunakan rate yang disepakati sebelum penjumlahan lintas-mata-uang.
• Mengurai input pengguna secara salah: Pengguna mengetik “1,000.50”, “1 000,50”, atau “10.0”. Jika parser Anda mengasumsikan satu format, Anda mungkin diam-diam mengenakan 100050 alih-alih 1000.50, atau menghapus nol yang diakhiri. Normalisasi input, validasi, dan simpan sebagai minor units.
• Menggunakan string terformat di API atau database: “$1,234.56” hanya untuk tampilan. Jika API Anda menerima itu, sistem lain mungkin mengurai berbeda. Kirim integer (minor units) plus kode mata uang, dan biarkan setiap klien memformat secara lokal.
• Tidak versioning aturan pajak atau tabel rate: Tarif pajak berubah, pengecualian berubah, dan aturan pembulatan berubah. Jika Anda menimpa rate lama, invoice lama menjadi tidak mungkin direproduksi. Simpan versi atau tanggal efektif dengan setiap perhitungan.

Pemeriksaan realitas cepat: checkout dibuat pada hari Senin menggunakan tarif pajak bulan lalu; pengguna direfund pada hari Jumat setelah tarif berubah. Jika Anda tidak menyimpan versi aturan pajak dan kebijakan pembulatan asli, refund Anda tidak akan cocok dengan kwitansi asli.

Daftar periksa cepat dan langkah berikutnya

Jika Anda ingin lebih sedikit kejutan, perlakukan uang sebagai sistem kecil dengan input, aturan, dan output yang jelas. Kebanyakan bug satu sen bertahan karena tidak ada yang menuliskan di mana pembulatan diperbolehkan.

Daftar periksa sebelum rilis:

• Simpan jumlah di minor units (seperti integer cents) di mana-mana: database, logika bisnis, dan API.
• Lakukan semua matematika dalam integer, dan konversi ke format tampilan hanya di akhir.
• Pilih satu titik pembulatan per jenis perhitungan (pajak, diskon, biaya, FX) dan terapkan di satu tempat.
• Format menggunakan aturan mata uang yang benar (desimal, pemisah, nilai negatif) secara konsisten di web dan mobile.
• Tambahkan tes untuk kasus tepi: 0.01, desimal berulang dalam konversi, refund, capture parsial, dan keranjang besar.

Tuliskan satu kebijakan pembulatan per tipe perhitungan. Contoh: “Diskon dibulatkan per baris item ke cent terdekat; pajak dibulatkan pada total invoice; refund mengulang jalur pembulatan asli.” Letakkan kebijakan ini dekat kode dan di dokumen tim supaya tidak menyimpang.

Tambahkan log ringan untuk setiap langkah uang yang penting. Tangkap input, nama kebijakan yang dipakai, dan output dalam minor units. Saat pelanggan melapor “saya dikenai biaya satu sen lebih banyak”, Anda ingin satu baris yang menjelaskan alasannya.

Rencanakan audit kecil sebelum mengganti logika di produksi. Hitung ulang total pada sampel pesanan historis, lalu bandingkan hasil lama vs baru dan hitung ketidaksesuaian. Tinjau beberapa ketidaksesuaian secara manual untuk memastikan sesuai kebijakan baru.

Jika Anda ingin membangun alur end-to-end semacam ini tanpa menulis ulang aturan yang sama tiga kali, AppMaster (appmaster.io) dirancang untuk aplikasi lengkap dengan logika backend bersama. Anda bisa memodelkan jumlah sebagai integer minor-unit di PostgreSQL lewat Data Designer, menerapkan langkah pembulatan dan pajak sekali di Business Process, lalu gunakan logika yang sama di web dan native mobile UI.