Guide
How to choose a financial calculation engine
Judge a financial calculation engine on five things: what it computes and what it excludes, where its constants come from and when they were last checked, what happens every January when limits change, what evidence you get that a number is right, and whether you can pin a version so outputs do not move underneath you. Feature counts and calculator totals distinguish vendors far less than any of these.
Written by Worthune. Last reviewed . We sell one of the things described here — the caveats section says where that shows.
Method
What to ask
A list without a method is an opinion wearing a table’s clothes. These are the axes, including the one we are biased toward.
Ask what it excludes, not what it includes
Every model simplifies. A vendor who can hand you a written statement of what a calculator deliberately does not model is telling you they have thought about it; one who only lists features has not been asked before. This is the single most informative question on the list.
Ask where a constant comes from, and when it was checked
Pick one number — the 401(k) elective deferral limit will do — and ask for its primary source and the date someone last verified it against that source. The answer separates vendors faster than any feature comparison.
Ask what happens in January
Contribution limits and brackets change annually. Ask how you find out, whether it arrives as a version change or a silent edit, and how you would know if a value were missed. This is the recurring cost of the whole category and it is almost never on a pricing page.
Ask for evidence, not assurance
Everyone says their math is accurate. Ask what you can check: a specification, test cases you can run yourself, a changelog including their own bug fixes. A vendor who publishes their mistakes is more credible than one with no mistakes to report.
Ask whether you can pin a version
If behavior can change without a version change, your outputs can move between deploys and you will find out from a user. Version pinning plus a changelog is what makes an engine safe to depend on.
Ask what you get if the vendor disappears
Uncomfortable, and worth asking a small vendor especially. A published specification and a downloadable case set mean you could reimplement. A binary and a support address mean you could not.
Read this part
Where this list is weakest
- This list is written by a vendor, and it is weighted toward the axes we chose to compete on. A reader who cares mainly about calculator count or lead capture should weight it differently — and both are legitimate ways to buy.
- It says nothing about whether a model's financial judgment suits your users. That is a question for a person who knows your product, not for a procurement checklist.
Questions
Common questions
- Should we build our own financial calculators or license them?
- Build when the math is your differentiator, or when your models are unusual enough that nobody sells them. License when you want the arithmetic to be someone else's maintenance contract. The recurring cost of building is not writing the formula; it is the annual constants work and the regressions found after release.
- How do I validate a financial calculation engine before we ship?
- Ask for the specification and check that it is precise enough to reimplement from. Then run the vendor's own test cases against their API and confirm they pass. If a vendor cannot supply either, you are validating by trust, which is not validation.
- What should I ask a vendor whose API calculates numbers our customers rely on?
- What does this compute and what does it exclude; where does each constant come from and when was it last checked; how do behavior changes reach us; what can we run ourselves to confirm it is right; can we pin a version; and what would we have if you shut down. Six questions, and the answers vary more than the marketing does.
- Does an engine need to be open source to be trustworthy?
- No, but it needs to be checkable, and open source is one way to get there. The alternatives are a published specification precise enough to reimplement from, test cases you can run, and constants traceable to primary sources. A closed engine offering none of those is asking for trust rather than earning it.
Sources
Claims about named vendors are sourced and dated on their individual comparison pages under /vs.
Product names and trademarks belong to their owners and are used here only to identify what is being described. Nothing here implies endorsement or affiliation. Found something out of date? Tell us at support@worthune.com and we will re-check it.