Dividends Calculation Hardening
Why This Matters
Dividends are bound by company law: a board can only approve a dividend the company has the retained profit to cover, and declarations can never exceed what the board approved. Until now those limits held because the application enforced them correctly. This release adds a second, independent layer at the database itself, so a future code change, a race between requests, or a direct database edit cannot leave a board resolution in an arithmetically impossible state. The dividend tax estimator was also moved onto exact decimal arithmetic, closing a latent rounding risk without changing any figure it returns.
This is the same calculation-boundary standard already applied to invoices, now extended to the dividends domain.
Board Resolution Integrity
Four limits on dividend board resolutions are now enforced at the database layer, not just in the application:
-
Approved total must be positive. A resolution cannot approve a zero or negative dividend.
-
Profit sufficiency. The approved total cannot exceed the retained profit recorded at the time of the resolution.
-
No over-allocation. The remaining balance available to declare against a resolution cannot fall below zero.
-
Declared within approved. The cumulative amount declared against a resolution can never exceed the total the board approved.
Each is a hard limit. A write that would breach any of them is rejected outright rather than relying on application logic to catch it.
Enforced by database CHECK constraints plus application validation. Proof anchor: migration 084.
Dividend Tax Estimator
The dividend tax estimator now performs all arithmetic using exact decimal calculation with a single, consistent rounding rule, replacing the previous floating-point path. The estimator splits a gross dividend across the basic, higher, and additional rate bands after the dividend allowance, and reports the per-band breakdown and effective rate.
The change was verified to produce identical results to the previous implementation across a wide range of inputs, so no estimate a user sees changes. What changed is the removal of a latent risk that floating-point representation could, on certain inputs, shift a result by a penny.
The estimator remains an informational planning tool. It does not create records or journals, and it is not a Self Assessment figure.
Enforced by exact decimal arithmetic in the calculation service.
Operational Impact
- Board resolution limits hold even if application logic is bypassed, refactored, or raced.
- No existing dividend or board resolution required correction. All current records already satisfied the new limits, verified at migration time.
- Dividend tax estimates are unchanged in value and now free of floating-point rounding risk.
- No API request or response shapes changed. No action required by API consumers.
Files Changed
Backend: Dividends route and validation primitives, board resolution constraints (migration 084), axiom registry.
Frontend / Docs site: API reference regenerated for the dividends tax estimator.
Calculation correctness continues to move from application discipline to mechanical enforcement, domain by domain.