Methodology

1. How MoneyTools Calculators Work

MoneyTools currently includes multiple calculator engines across investment, loans, mortgage, savings, business, and salary categories. Each calculator page is connected to a specific calculation engine in the codebase, so methodology is calculator-specific rather than one universal formula for all tools.

In the current implementation, each calculator page takes user inputs, runs the matching TypeScript calculation function, and displays the computed output. Formula, assumptions, and worked-example content are also shown on each calculator page.

2. Inputs and User-Provided Information

Calculator results depend directly on user-provided values such as principal, rate, years, payment amount, costs, revenue, churn, or salary period. Changing an input changes the result.

The calculator engines include input validation (for example, requiring positive loan amounts, valid churn ranges, or non-negative balances where appropriate). If inputs are invalid, the engine throws an error and the page does not render a result for that calculation state.

3. Formulas and Calculations

MoneyTools uses formula logic that varies by calculator type. Examples from the current engines include:

• Compound-interest and savings-family tools using future-value style compounding logic with periodic contributions
• Loan and mortgage tools using amortization payment formulas and month-by-month schedules
• ROI/CAGR/APY tools using percentage-return and compounding-rate formulas
• Business tools such as break-even, markup/margin, ROAS, and LTV:CAC using their respective financial ratio formulas
• Salary conversion using pay-period conversion rules (hourly, daily, weekly, bi-weekly, semi-monthly, monthly, annual)

Some engines are closed-form, while others use iterative period-by-period calculations (for example, amortization schedules, debt payoff sequencing, and contribution-based growth projections).

4. Assumptions

Assumptions are not identical across calculators. Each calculator has its own assumptions shown on its page, and the underlying engine reflects that scope.

Examples present in the current implementation include:

• Fixed-rate assumptions in many growth and amortization scenarios unless otherwise modeled
• Periodic contribution timing (end-of-period or beginning-of-period depending on the tool)
• Salary conversion assumptions such as user-entered hours/week and weeks/year
• Business metric assumptions based on provided margin, churn, spend, and customer values

5. Rounding and Precision

In the calculator engines, intermediate steps are generally computed using JavaScript numeric precision without forced rounding at every step. Display formatting is applied when showing output values in the UI.

Currency and numeric display formatting is handled by utility formatters, including configured decimal places for currency and percentages. Some amortization-style engines also apply final payment reconciliation so remaining balance does not persist due to tiny residual values.

6. Currency and Financial Data

MoneyTools calculator math is separate from the homepage Live Financial Snapshot.

The Live Financial Snapshot displays third-party data feeds (currency rates, market quotes, and weather). These feeds are not the core mathematical methodology of the calculators.

Third-party snapshot sources in the current implementation are:

• open.er-api.com (foreign exchange rates)
• Yahoo Finance quote API at query1.finance.yahoo.com (market data)
• api.open-meteo.com (weather data)

7. Calculator-Specific Differences

Not all calculators behave the same way. The current engines include materially different logic, for example:

• Debt Payoff compares avalanche vs snowball ordering and simulates monthly payoff flow
• Personal Loan computes an effective APR adjustment when origination fees are included
• Mortgage Amortization models optional extra monthly principal payments and payoff acceleration
• Investment includes inflation-adjusted value outputs in addition to nominal growth
• APY includes APR↔APY conversion logic and compounding-frequency comparisons

8. Examples and Interpretation

Each calculator page includes formula notes and a worked example to help interpretation. These examples are illustrative only.

Practical interpretation guidance: treat results as scenario calculations, then stress-test with alternative inputs (for example different rates, contribution amounts, fees, or time horizons) before making financial decisions.

9. Validation and Quality Checks

The repository includes unit tests for calculator engines under lib/calculators/__tests__/, configured through Vitest.

In addition, calculator engines use explicit input checks and error handling to prevent invalid numeric scenarios from being shown as normal results.

10. Limitations

MoneyTools does not model every real-world variable in every calculator. Depending on the tool, omitted variables may include taxes, changing rates, transaction costs, penalties, contract-specific rules, or jurisdiction-specific regulations.

11. When Results May Differ From Real-World Results

Calculated outputs may differ from actual outcomes due to factors such as:

• Rate changes over time (interest, yield, borrowing cost, inflation)
• Fees, taxes, penalties, and closing or servicing costs
• Lender underwriting criteria and product-specific contract terms
• Country/jurisdiction differences in legal and tax treatment
• Timing differences (payment dates, compounding intervals, settlement timing)
• Data timing and availability constraints for third-party snapshot feeds

12. Reporting an Error

If you suspect a calculation issue, report it through the Contact page and include:

• The calculator name and page URL
• The exact input values used
• The displayed result and what you expected instead
• The basis for comparison (for example a manual calculation or source reference)

Providing reproducible input/output details helps isolate whether the issue is input-related, interpretation-related, or a calculation defect.

13. Methodology Updates

This page is intended to track the active implementation. When calculator logic, assumptions, or data integrations change, methodology text should be reviewed and updated to stay aligned with shipped behavior.