Ocuula
Integer arithmetic

Why Payment Splits Don't Add Up
The Hidden Cost of Floating-Point Math

Every split payment calculation using standard programming math or spreadsheet formulas introduces tiny rounding errors. A single pesewa lost per transaction is invisible — until you scale.

Side-by-side

Floating-point vs Integer arithmetic

IEEE 754 floating-point cannot represent most decimal fractions exactly. Spreadsheets and most programming languages use it by default. Ocuula converts every amount to the smallest currency unit and distributes remainders predictably.

ScenarioFloating-pointInteger (Ocuula)
GHS 100 split 3 ways (equal)
GHS 33.33 each → total GHS 99.99
1p lost
3,333p each → 1p remainder to first recipient
0p lost
GHS 1,000 split 7 ways (equal)
GHS 142.86 each → total GHS 999.99
1p lost
14,285p × 7 = 99,999p + 1p remainder
0p lost
GHS 50.50 split 3 ways (equal)
GHS 16.83 each → total GHS 50.49
1p lost
1,683p each + 1p remainder → total 5,050p
0p lost
GHS 10,000 split 365 ways (daily)
GHS 27.39 each → total GHS 9,997.35
GHS 2.65
27p each + remainder distribution
0p lost
Waterfall: GHS 500 split 50/30/20
GHS 250.00 + GHS 150.00 + GHS 100.00
0p (coincidence)
25,000p + 15,000p + 10,000p = 50,000p
0p guaranteed

The cost adds up

Cumulative rounding loss at scale

One pesewa per transaction sounds trivial. At volume, it becomes real money that should have reached your recipients.

10,000 transactions/month

GHS 120+ lost per year

100,000 transactions/month

GHS 1,200+ lost per year

1,000,000 transactions/month

GHS 12,000+ lost per year

These estimates assume 1p lost per transaction on average. Real loss varies by split type — waterfall and tiered splits compound rounding across every tier, increasing the gap.

Frequently asked questions

Rounding errors, explained

How does integer arithmetic work?

Instead of calculating with decimals (e.g. GHS 33.33), Ocuula converts every amount to the smallest currency unit — pesewas for GHS. A GHS 100 split three ways becomes 10,000 pesewas ÷ 3 = 3,333 pesewas each with 1 pesewa remainder. That remainder is distributed predictably, so the full GHS 100 is accounted for. No floating-point rounding, no lost value.

Can I test this without signing up?

Yes. Ocuula's sandbox is fully functional and requires no credentials, no Moolre account, and no payment information. You can create routing rules, simulate payments, and inspect the exact integer math — including remainder distribution — in your browser.

Does Ocuula handle all Ghanaian currency units?

Yes. Every financial calculation runs as integers in the smallest currency unit. For GHS that is pesewas (1 GHS = 100 pesewas). The system also supports USD cents, NGN kobo, and any other decimal currency — all converted to their smallest unit before any arithmetic runs.

How much money do rounding errors actually cost?

A single pesewa lost per transaction is invisible. At 10,000 transactions per month, that's GHS 100 annually. At scale — 1M transactions with GHS 100 average split value — the cumulative loss can reach GHS 1,000+ per year. For waterfall or tiered splits where remainders cascade across multiple levels, the losses multiply.

Don't banks and payment providers handle this automatically?

No. Moolre and other payment processors transfer funds exactly as instructed — they do not correct rounding errors in split calculations. If your system sends three payments of GHS 33.33 for a GHS 100 transaction, Moolre sends GHS 33.33 each time. The missing 1 pesewa is gone. Ocuula ensures every pesewa reaches a recipient.

See every pesewa accounted for

Run a real percentage split in our sandbox and inspect the integer arithmetic. No credentials needed.