The shortcut most tools take
Most financial planning tools sold to Irish advisors were not designed for Ireland. They were designed for the UK, sometimes Australia, and localised after the fact. Localisation usually means updating tax rates in a configuration file, changing the currency symbol, and renaming "ISA" to "PRSA."
That works until an advisor needs to model something the original tool never anticipated: the interaction between PRSI contribution years and State Pension entitlement, or the effect of a redundancy payment on PAYE for the following year, or how DSP means-testing changes the net benefit of a particular protection product.
At that point, the advisor is back to a spreadsheet. The tool has hit the edge of its localisation and cannot help further.
What the Irish rules actually require
Irish financial planning has several constraints that do not translate cleanly from a UK base:
Revenue's PAYE, USC and PRSI calculations interact in ways that a UK National Insurance model cannot represent without custom code. The bands, reliefs and credits, including SRCOP, the employee tax credit and Class S PRSI for the self-employed, require Irish-specific logic at each step.
DSP welfare rates (State Pension Contributory, Carer's Benefit, Illness Benefit) are updated annually and affect protection-gap analysis directly. A correct protection-gap model needs the current DSP figures as a baseline, not a manually entered number that may be stale.
CPC 2012 sets out what a compliant financial plan looks like in Ireland: the structure of a cashflow statement, what must be disclosed, how assumptions must be presented. A report produced from a UK planning tool requires manual reformatting to meet this standard.
None of these are edge cases. They are the core of what an Irish financial advisor does on most client files.
Why a correct engine beats a corrected spreadsheet
The practical argument for a purpose-built engine is not speed, though it is faster. It is consistency.
When the logic is in the tool, every plan applies the same rules in the same way. There is no variation between advisors on what the marginal USC rate is at a given income level. There is no risk that last year's DSP figures are still in the spreadsheet template because no one updated the tab. There is no question about whether a client's CPC report was formatted to the current standard or the previous one.
Kinta uses Revenue 2026 PAYE, USC and PRSI rates, DSP 2026 welfare rates and the CPC 2012 reporting structure. These are not configurable overrides applied to a UK base. They are the rules the engine was written to compute.
What this means in practice
An advisor using Kinta can run a cashflow model for a client and be confident that the tax calculations reflect current Irish law, the protection-gap figures use current DSP baselines, and the output report meets CPC standards without further adjustment.
That removes a category of work, the correction layer, that adds time to every file and introduces the kind of error that is difficult to catch in a review.
We built Kinta's engine for Ireland first because the correction layer is not a problem that can be solved with better spreadsheet hygiene. It is a problem with starting from the wrong set of rules.