What Deterministic Logic Means for Finance Software

In finance software, close enough is not good enough. A tax calculation that is off by one penny is wrong. A VAT return that rounds incorrectly is wrong. A bank reconciliation that mismatches by any amount is wrong. Financial software must be deterministic — given the same inputs, it must always produce the same outputs, and those outputs must be provably correct.

This sounds obvious, but a surprising amount of financial software fails this test. Software that uses floating-point arithmetic for monetary calculations can produce rounding errors that accumulate over many transactions. Software that relies on AI for categorisation or calculation introduces probabilistic variability. Software that does not handle edge cases — negative amounts, zero-value transactions, multi-currency conversions — can produce incorrect results in situations that seem unlikely but inevitably occur.

At neart.ai, all monetary values are stored and calculated as integers in pence. This eliminates floating-point rounding errors entirely. £10.50 is stored as 1050 pence. Calculations are performed on integers. The result is converted to pounds and pence only for display. This is a fundamental architectural decision that prevents an entire class of errors.

Tax calculations follow explicit, documented rules. Every tax band, every threshold, every rate is defined as a constant in the codebase, sourced from HMRC publications. The calculation engine applies these rules in a defined sequence — gross income, less allowable deductions, equals taxable income, applied against tax bands, equals tax liability. Every step is logged and traceable. There is no machine learning, no heuristics, no approximation. The calculation is a function: given these inputs, this is the only possible output.

Rounding rules are specified explicitly. HMRC has specific rounding requirements for different submissions — some round down, some round to the nearest penny, some truncate. Each submission type uses the correct rounding rule, and the rule is documented and tested. A rounding error on a VAT return is not a minor bug — it is a submission that will be queried by HMRC.

Test coverage for financial calculations is not 80% or 90% — it is 100% of branches. Every code path through a calculation engine is tested with known inputs and expected outputs. Edge cases are tested explicitly: zero income, income at exact threshold boundaries, maximum values, negative adjustments, multi-period calculations. The test suite is the proof that the calculation engine is correct.

Reconciliation logic is similarly deterministic. When matching bank transactions to recorded transactions, the matching algorithm uses exact criteria — amount, date range, reference — and produces a definitive result: matched, unmatched, or ambiguous. Ambiguous matches are presented to the user for manual resolution rather than auto-resolved by the system. This prevents the false confidence of automatic matching that silently gets it wrong.

The alternative to deterministic logic is trust in the system. "The software probably got it right." For enterprise customers with large compliance teams, this trust can be verified. For sole traders and small businesses who rely entirely on their software, unverifiable trust is not acceptable. They need to know that the numbers are right, not hope that they are.

This commitment to deterministic logic has cost implications. It requires more upfront specification, more thorough testing, and more careful implementation than a probabilistic approach. But the benefit is a system that can be trusted completely for financial accuracy — and that trust is the foundation of everything else we build.