Calculation Methodology & Data Policy

1. Start with the user problem, then the formula

We first define the question the calculator should answer, the inputs that materially affect the result and the assumptions that should be visible. Where useful, results include supporting metrics, formulas or breakdowns rather than only one final number.

2. Source hierarchy

When a calculator depends on law, tariffs, holidays or other changing external data, we prefer current official or authoritative sources where practical. Established technical data standards may be used for technical problems such as time zones. Values that genuinely vary by user, provider or market are requested from the user instead of being invented as a supposedly official current value.

• Official or authoritative data: preferred for rules, tariffs and regulated values.
• Established technical data: used where appropriate, for example time-zone data.
• User-provided values: used for costs or assumptions that vary by person or provider.
• No reliable current data: a tool may warn, limit the calculation or fail safely instead of silently presenting stale information as current.

3. Freshness and stale-data handling

Data-driven calculators do not all use the same refresh schedule. When data age can materially change a result, we aim to expose the source/date or apply a freshness rule.

Example — Currency Converter: if current sources are unavailable, the last successful browser cache may be used for up to 48 hours. The local rates.json source is rejected as current calculation data when it is more than 72 hours old.

4. Examples across selected tools

Water Bill: water, wastewater, taxes and tariff methods can be separated; local municipal rates are not presented as universal national rates. Business Days: Turkish and foreign holiday coverage are handled differently rather than assumed to be identical. Rising Sign: date, time, coordinates and time zone are combined, with IANA time-zone data and worldwide place search support; historical-data limitations are disclosed. Vehicle cost tools: fuel, fixed costs and depreciation are separated, while user-specific assumptions remain user inputs.

5. Testing and quality control

Testing varies by tool. Development may include benchmark calculations, invalid-input and boundary cases, JavaScript/schema checks, mobile overflow checks, copy/share/print behavior, language parity and manual browser review. Automated checks are useful, but they do not replace visual review: a page can be technically valid and still have a layout or interaction problem.

6. Turkish vs global English calculators

The English section does not automatically copy Turkey-specific tax, social-security or local-tariff logic and present it as global. When a calculation is truly country-neutral, the Turkish and English versions aim for the same core calculation and behavior. Country-specific rules remain scoped to the relevant market.

7. Software and AI assistance

Software tools and AI-assisted systems may be used during research, coding, testing, debugging or editing. They are not treated as authoritative sources by themselves. Formulas, data and behaviors that affect results are checked according to the tool context, and publication remains a manual decision.

8. Limits and high-impact decisions

Hesapica provides general information, planning estimates and comparison tools. For high-impact financial, tax, legal, health, credit or investment decisions, verify relevant figures with current official sources, contracts and qualified professionals when appropriate. A calculator result is not an official decision, quote or professional advice.

9. Corrections and feedback

If you notice a formula, data-date, link or usability problem, please use the Contact page. When a confirmed issue is found, we prefer targeted corrections rather than unnecessary changes to unrelated working behavior.

Last reviewed: October 9, 2026.