Open your browser's developer console right now and type 0.1 + 0.2. Press enter. You will not see 0.3. You will see 0.30000000000000004. This is not a bug. It is how floating-point arithmetic works in every modern programming language, every spreadsheet application, and every database that uses float or double data types for numeric storage.
For most software, this imprecision is irrelevant. A physics simulation that is off by a quadrillionth of a unit produces the same visual result. A weather model that rounds a temperature by a fraction of a degree is still accurate. But for financial calculations — specifically for insurance commission tracking — these tiny errors are not harmless rounding noise. They compound silently across thousands of transactions until your books do not balance, your producer statements do not reconcile, and your carrier payments are off by amounts that are small enough to ignore individually but large enough to matter in aggregate.
This post explains why floating-point numbers are fundamentally unsuitable for commission math, what the correct approach looks like, and how PrizMova handles commission calculations with precision that survives splitting, overriding, reconciling, and reporting across your entire book of business.
The Floating-Point Problem, Explained Simply
Computers store numbers in binary (base 2). The number 0.1 in decimal cannot be represented exactly in binary, for the same reason that 1/3 cannot be represented exactly in decimal. When you write 1/3 in decimal, you get 0.333333... repeating forever. You have to round it somewhere. When a computer stores 0.1 in binary floating-point, it gets a similar infinitely repeating pattern that must be truncated to fit in 64 bits of memory.
The result is a number that is extraordinarily close to 0.1 but is not exactly 0.1. It is approximately 0.1000000000000000055511151231257827021181583404541015625. For a single calculation, the difference is negligible. But financial systems do not perform a single calculation. They perform thousands or millions of calculations, and each one carries forward the accumulated imprecision of every calculation before it.
Here is a concrete example from insurance commission tracking.
A Real-World Commission Calculation
Consider a straightforward commercial auto policy with the following terms:
- Written premium: $14,750.00
- Carrier commission rate: 12%
- Agency commission: $1,770.00
So far, no problem. But now this commission needs to be split among producers:
- Producer A (writing agent): 60% of commission = $1,062.00
- Producer B (account manager): 25% of commission = $442.50
- House account: 15% of commission = $265.50
Check: $1,062.00 + $442.50 + $265.50 = $1,770.00. The splits add up. But what happens when we run this through floating-point arithmetic?
// JavaScript floating-point math
const premium = 14750.00;
const commissionRate = 0.12;
const commission = premium * commissionRate;
// commission = 1770.0000000000002 (not 1770.00)
const producerA = commission * 0.60;
// producerA = 1062.0000000000001
const producerB = commission * 0.25;
// producerB = 442.50000000000006
const house = commission * 0.15;
// house = 265.50000000000003
const total = producerA + producerB + house;
// total = 1770.0000000000005 (does not equal commission)The individual errors are tiny. But they have two serious consequences. First, the splits do not add up to the total commission. When you reconcile producer payments against carrier statements, you will have unexplained variances. Second, when you round these values for display or payment, the rounding can go in either direction depending on the accumulated error, creating inconsistencies that are difficult to trace.
Now multiply this across an agency processing 3,000 policies per year, each with multiple commission entries (new business, renewals, endorsements, audits, cancellations), each potentially involving producer splits with override schedules. The cumulative error grows with every calculation, and because floating-point errors are not consistently biased in one direction, they do not cancel out. They accumulate randomly, creating reconciliation discrepancies that can take hours to investigate.
Why Spreadsheets Are Even Worse
Many agencies track commissions in spreadsheets, which introduces all of the floating-point problems described above plus several additional failure modes.
Excel and Google Sheets use 64-bit IEEE 754 floating-point numbers internally, the same representation that causes the 0.1 + 0.2 problem. The spreadsheet hides this by rounding display values to a configurable number of decimal places, so you see $1,770.00 even though the underlying value is $1,770.0000000000002. This creates a dangerous illusion of precision. The numbers on your screen look correct, but the values being used in downstream formulas carry the accumulated error.
Spreadsheets add further risks:
- Formula fragility. A single misplaced cell reference can cascade errors across an entire workbook. Unlike database constraints that reject invalid data, a spreadsheet will happily calculate a commission split that allocates 110% of the total because a formula is pointing at the wrong row.
- Version control chaos. When the commission spreadsheet lives on a shared drive, there is no reliable way to know which version is current. Producer disputes over commission amounts become he-said-she-said arguments about which version of the spreadsheet is authoritative.
- No audit trail. Spreadsheets do not log who changed what, when. A cell value can be overwritten and the previous value is gone forever. For agencies subject to regulatory examinations or carrier audits, this is a compliance liability.
- Scale limitations. A spreadsheet that tracks commissions for 500 policies is manageable. A spreadsheet that tracks commissions for 5,000 policies with producer splits, override schedules, and carrier reconciliation is a maintenance nightmare that consumes hours of staff time every month.
The core problem with spreadsheet-based commission tracking is not that it is inaccurate today. It is that you have no way to prove it is accurate, and no way to guarantee it will stay accurate tomorrow.
The BigInt/Cents Approach: How Correct Financial Math Works
The solution to floating-point imprecision in financial calculations is well-established in software engineering: store all monetary values as integers representing the smallest currency unit (cents for US dollars) and perform all arithmetic as integer operations.
Integer arithmetic in computers is exact. There is no rounding, no truncation, no accumulated imprecision. The number 177000 (representing $1,770.00 in cents) is stored and manipulated with perfect precision. Addition, subtraction, and multiplication of integers always produce exact results (within the integer range, which for 64-bit integers is approximately 92 quadrillion — more than enough for any conceivable commission calculation).
Here is the same commission calculation using the cents approach:
// Integer arithmetic in cents
const premiumCents = 1_475_000; // $14,750.00
const commissionCents = 177_000; // $1,770.00 (pre-calculated, exact)
const producerACents = 106_200; // 60% of 177000 = 106200 (exact)
const producerBCents = 44_250; // 25% of 177000 = 44250 (exact)
const houseCents = 26_550; // 15% of 177000 = 26550 (exact)
const totalCents = producerACents + producerBCents + houseCents;
// totalCents = 177000 (exactly equals commissionCents)The conversion to dollars only happens at the display layer, when the value is presented to a user on screen or printed on a statement. All storage, all calculations, all comparisons, and all reconciliation happen in integer cents, where math is exact.
Handling Percentages That Do Not Divide Evenly
The careful reader will notice a potential issue: what happens when a percentage split does not produce a whole number of cents? For example, a $100.00 commission split three ways produces $33.333... per producer. You cannot pay someone a third of a cent.
This is where a well-designed commission system needs explicit rounding rules. PrizMova handles this using a largest remainder method:
- Calculate each split's share using integer division (rounding down), accumulating the remainders.
- Sum the rounded-down shares. The total will be less than or equal to the original commission amount.
- Distribute the remaining cents one at a time to the splits with the largest remainders.
For a $100.00 commission split three ways: each share rounds down to $33.33 (3333 cents). The total is $99.99 (9999 cents), leaving 1 cent unallocated. That cent goes to the first producer (who had the largest remainder). Final allocation: $33.34, $33.33, $33.33. The splits add up to exactly $100.00. Every cent is accounted for. No floating-point involved.
This is deterministic, auditable, and precise. Every split always sums to the exact original amount. There are never unexplained pennies floating around in your books.
How PrizMova Handles Commission Tracking
PrizMova's commission management module is built entirely on integer arithmetic. Here is how we handle the major commission workflows that agencies deal with daily.
Commission Schedules
Commission rates vary by carrier, line of business, policy type, and sometimes by individual account. PrizMova supports multi-level commission schedules that define the expected commission rate for every combination of these variables. When a policy is bound, the system automatically matches it to the correct commission schedule and calculates the expected commission in cents.
Rates themselves are stored as basis points (hundredths of a percentage point) rather than percentages, eliminating yet another source of floating-point imprecision. A 12% commission rate is stored as 1200 basis points. A 12.5% rate is stored as 1250 basis points. This allows precise representation of rates down to 0.01% without any floating-point involvement.
Producer Splits with Overrides
Producer compensation in an insurance agency is rarely simple. A typical arrangement might involve a writing producer receiving 50% of new business commission and 40% of renewal commission, an account manager receiving 15%, a team lead receiving an override of 5% on all business written by their team, and the house retaining the balance. These splits can vary by line of business, by producer, and can change over time.
PrizMova models all of these relationships as structured data with effective dates, allowing the system to correctly calculate splits for any policy at any point in time. When splits change mid-term (for example, when a producer moves to a different team), the system applies the correct split schedule for each commission payment based on the payment's effective date, not the current date.
All split calculations use the integer/cents approach with the largest remainder method, guaranteeing that splits always sum to the exact commission amount regardless of how many producers are involved or how complex the override structure is.
Carrier Reconciliation
One of the most time-consuming tasks in agency accounting is reconciling commission payments from carriers against expected commissions. Carriers send statements (often in inconsistent formats) showing what they paid. The agency needs to match those payments against their internal records and investigate discrepancies.
When both the carrier and the agency use floating-point arithmetic, reconciliation becomes a nightmare of trivial rounding differences. Is a $0.01 variance a rounding difference or a genuine error? When you have 500 line items on a carrier statement and 47 of them are off by a penny, do you investigate all 47 or write them off? How do you distinguish a legitimate $0.02 variance from a coincidental combination of two rounding errors that happen to look like a legitimate variance?
PrizMova's reconciliation engine eliminates this ambiguity. Because our internal calculations are exact to the cent, any variance between our expected commission and the carrier's payment is a real discrepancy that warrants investigation. There are no rounding differences to filter out, no tolerance thresholds to configure, no pennies to write off. If the numbers do not match, something is actually wrong, and the system surfaces it for review.
The analytics dashboard provides carrier-level reconciliation metrics showing match rates, outstanding variances, and aging of unresolved discrepancies, giving agency principals visibility into carrier payment accuracy across their entire book.
Statement Generation
Producer statements are one of the most sensitive documents an agency produces. Errors on a producer statement directly affect people's compensation, and even small discrepancies erode trust between the agency and its producers. A producer who finds a $3.27 error on their statement will question every line item on every subsequent statement. The cost of that lost trust, measured in time spent answering questions and re-running reports, far exceeds the $3.27.
PrizMova generates producer statements directly from the integer-based commission ledger. Every line item on the statement traces back to a specific policy transaction with an exact cent amount. The statement total is the sum of exact integers, not a floating-point aggregation that might round differently depending on the order of operations. Producers can drill into any line item to see the underlying policy, the commission schedule that was applied, and the split calculation that determined their share.
The invoicing module uses the same integer-based calculations for agency billing, ensuring consistency between what the agency bills, what the carrier pays, and what the producers receive.
The Hidden Cost of Getting This Wrong
Agencies that tolerate commission tracking imprecision often justify it by arguing that the errors are small. And individually, they are. But the real cost is not the pennies. It is the time and trust.
Staff time spent reconciling. When your commission calculations have built-in imprecision, every reconciliation involves judgment calls about what constitutes a "real" variance versus a rounding difference. This turns what should be a systematic process into a manual investigation. Agencies report spending 15 to 25 hours per month on commission reconciliation when using spreadsheets or systems with floating-point math. With integer-based precision, reconciliation becomes a matching exercise that takes a fraction of the time.
Producer trust. Producers who find errors on their statements, even small ones, lose confidence in the agency's back office. This can affect retention of your best producers, who have options and will move to an agency that gets the details right. In a competitive market for talent, precise commission tracking is a surprisingly effective retention tool.
Carrier relationships. Agencies that consistently dispute carrier commission payments due to reconciliation variances strain their carrier relationships. Carriers have limited patience for agencies that cannot cleanly match payments against expectations. An agency that reconciles cleanly is an agency that is easier to do business with.
Audit risk. State insurance department examinations and carrier audits may review commission records. Unexplained variances, even small ones, raise questions. Having a system that produces mathematically exact records eliminates an entire category of audit findings.
The Bottom Line
Floating-point arithmetic is a solved problem in software engineering. The financial industry figured out decades ago that money must be stored and calculated as integers. Banks, stock exchanges, and payment processors all use integer arithmetic for the same reason: because precision is not optional when you are tracking other people's money.
Insurance commission tracking is no different. Every commission dollar flows through a chain of calculations — carrier payment to agency, agency split to producers, reconciliation against statements, reporting against budgets — and every link in that chain must be exact for the numbers to balance at the end.
If your current system uses floating-point math (and if you are using spreadsheets, it does), you are accumulating errors that you may not see yet but that are silently growing with every transaction. The fix is not more careful rounding or wider tolerance thresholds. The fix is integer arithmetic, applied consistently from the first commission calculation to the final producer statement.
That is exactly what PrizMova's commission tracking is built to do. Every amount in cents. Every calculation exact. Every statement that balances to the penny, every time.