Why float64 Can Break Your Financial System and How Go Developers Should Fix It

Floating‑point "gentle trap"

In Go, float64 offers high performance but is disastrous for financial calculations because it cannot represent decimal fractions exactly.

package main
import "fmt"
func main() {
    var v1 = 0.1
    var v2 = 0.2
    var v3 = 0.3
    fmt.Println(v1 + v2 == v3) // prints false
}

Using float64 for amounts will cause mismatched reconciliation results.

Rule of thumb: Use int64 (cents) or a high‑precision decimal type for monetary values.

Method 1: Store amounts as integer cents

type Money int64 // unit: cents
price := Money(1999) // represents ¥19.99

Method 2: Use a high‑precision decimal library

import "github.com/shopspring/decimal"
price := decimal.NewFromFloat(19.99)
tax := price.Mul(decimal.NewFromFloat(0.13))
total := price.Add(tax)
fmt.Println(total.Round(2)) // 22.59

Rounding ≠ Simple Rounding

Go’s built‑in math.Round() performs classic half‑up rounding, but different regions adopt different rules.

import "math"
fmt.Println(math.Round(1.235*100) / 100) // 1.24
fmt.Println(math.Round(1.245*100) / 100) // 1.25

The shopspring/decimal library also supports banker's rounding (HalfEven) and other strategies:

import "github.com/shopspring/decimal"
v := decimal.NewFromFloat(1.245)
fmt.Println(v.Round(2))        // 1.25 (HalfUp)
fmt.Println(v.RoundBank(2))   // 1.24 (HalfEven)
fmt.Println(v.RoundCeil(2))    // 1.25 (Ceil)
fmt.Println(v.RoundFloor(2))   // 1.24 (Floor)

Chinese accounting standards usually use HalfUp, while many Western banks prefer HalfEven.

Tax and Discount Pitfalls

Incorrect use of float64 leads to subtle errors:

price := 99.995
 taxRate := 0.13
 tax := price * taxRate
 total := price + tax
 fmt.Printf("%.2f
", total) // prints 112.98 instead of 112.99

Fix it with decimal:

import "github.com/shopspring/decimal"
price := decimal.NewFromFloat(99.995)
taxRate := decimal.NewFromFloat(0.13)
tax := price.Mul(taxRate)
total := price.Add(tax).Round(2)
fmt.Println("应付:", total) // 112.99

A reusable helper can encapsulate the logic:

func CalcTotal(price, taxRate decimal.Decimal) decimal.Decimal {
    return price.Mul(taxRate).Add(price).Round(2)
}

Accumulation Errors in Reconciliation

Summing monetary values as floats can produce results like 39.97499999, which rounds to 39.97 and mismatches the expected 39.98.

Sum integer cents first, then divide by 100 – avoid converting to yuan before aggregation.

Round each intermediate amount to two decimals immediately.

Perform reconciliation using integer cents and convert to display format only at the end.

Rounding Rule Differences by Scenario

Sales amount & tax calculation: HalfUp (matches Chinese accounting standards).

Bank interest calculation: HalfEven (Western banking standard).

Rent or service fees: Ceil (round up to avoid loss).

Currency conversion: Floor (round down to prevent overpayment).

Define a global rounding strategy during system design and avoid mixing rules.

Practical Advice: Build a Money Utility Package

package moneyutil
import "github.com/shopspring/decimal"

func RoundMoney(amount decimal.Decimal) decimal.Decimal {
    return amount.Round(2)
}

func Add(a, b decimal.Decimal) decimal.Decimal {
    return a.Add(b).Round(2)
}

Use it consistently: total := moneyutil.Add(price, tax) This centralizes rounding logic and prevents future precision bugs.

Conclusion: The Technical Truth of Financial Systems

Using float64 leads to precision loss; inconsistent rounding causes mismatched records; cumulative floating‑point errors break reconciliation; tax and discount calculations require exact decimal arithmetic; undefined rounding policies increase audit risk. Adopt integer or decimal types, enforce a global rounding policy, and encapsulate money operations in a utility package.

“Am I just formatting for display, or am I actually performing a rounding operation?”