Why Interest results differ in Philippines

The top 5 reasons results differ

Run this scenario in DocketMath using the Interest calculator.

If you’re using DocketMath (Interest) for the Philippines (PH) and your interest totals don’t match another person’s spreadsheet, it’s usually because the other calculation is using different jurisdiction-aware inputs or a different interest computation setup. Interest math is deterministic—same inputs and same rules should produce the same output.

Here are the top 5 reasons results often differ:

1. **Different interest type (legal vs. contractual vs. stipulated)

   • “Interest” isn’t always one single formula.
   • One model may treat interest as contractual (driven by what the parties agreed to in writing), while another applies legal/court-type interest logic (driven by rule-based assumptions).
   • In DocketMath, the calculator’s mode and logic determine how interest is computed, so the totals can diverge even when principal, dates, and rate look similar.

2. Wrong start date for interest accrual

   • The start date is a common root cause in PH interest calculations.
   • Different tools may start accrual from:

     • date of default,
     • date of demand, or
     • a contractually agreed due date.
   • Because interest may be calculated day-by-day or compounded, shifting the start date even slightly can cascade into a noticeably different final total.

3. Compounding vs. simple interest

   • Some spreadsheets use simple interest (interest is calculated only on principal), while others use compounded interest (principal effectively grows as interest accrues).
   • When compounding is enabled (monthly/daily or another frequency), the final amount can move substantially.
   • In DocketMath, confirm the compounding frequency and whether interest is treated as reinvested into subsequent periods.

4. Day-count convention and partial period handling

   • Different calculators handle partial months/days differently, including:

     • “inclusive” vs. “exclusive” day counting,
     • 30/360-style approaches vs. actual/actual day counting,
     • edge cases at boundaries (e.g., end dates that land on month-ends).
   • Even with the same rate, the time-window math can produce different totals if the underlying basis differs.

5. **Payment application / allocation order (interest vs. principal)

   • If there are partial payments, installment remittances, or credits, the allocation order can change everything.
   • Two common allocation styles:

     • payments applied first to interest, then remaining balance to principal, or
     • different allocation logic based on the model’s assumptions.
   • If payment timing or allocation differs, two calculators can produce different interest totals even if the headline inputs match.

Pitfall to watch: A “small” date mismatch like using June 30 vs. July 1 as the accrual start date can compound into a large difference by the end date.

How to isolate the variable

Use a quick, controlled diagnostic approach inside DocketMath starting at /tools/interest. The goal is to change one factor at a time until you find which setting causes the mismatch.

1. Lock the core inputs Keep these identical across runs:

   • Principal (amount)
   • Interest rate
   • Accrual start date
   • End date (or maturity)
   • Compounding setting (simple vs. compounded; frequency)
   • Payment schedule (if any): dates and amounts

2. Run a baseline

   • Open /tools/interest in DocketMath.
   • Record:

     • total interest,
     • and any period breakdown the tool shows (if available).

3. Change only one variable at a time If your output doesn’t match the reference spreadsheet, try this sequence:

   • Start date first: adjust by +1 day (or to the other tool’s exact start date).
   • Compounding next: switch simple ↔ compounded and align compounding frequency.
   • Day-count basis / partial-day handling: if the DocketMath UI exposes it, match the convention used by the reference.
   • Payments last: if there are payments, align both payment dates and allocation logic assumptions.

4. Use a simple difference table Compare two runs and track the delta:

   Scenario	Change made	What to check	Expected outcome
   Run A	Baseline	Match reference settings	Same total (or very close)
   Run B	Start date + 1 day	accrual boundary	small shift grows over time
   Run C	Simple → Compounded	compounding frequency	larger gap possible
   Run D	Payment allocation	interest vs. principal application	material total change

5. Sanity-check with a “no-payment” test

   • Temporarily remove payments (if your scenario allows it as a diagnostic step).
   • If interest now matches the reference, the mismatch is likely in payment allocation or payment timing.

Gentle note: This is a modeling/inputs check, not legal advice. Interest can be sensitive to the underlying agreement and the specific assumptions the other spreadsheet is using.

Next steps

Once you’ve isolated the cause, you can move from “different numbers” to “explained numbers”:

• Confirm what the reference calculation is modeling

  • Is it contractual interest or a legal/rule-based style calculation?
• Verify dates line-by-line

  • Accrual start date, end date, and any payment dates must align to the same day-count logic.
• Verify compounding settings

  • Simple vs. compounded, plus the exact compounding frequency.
• Verify payment timing and allocation

  • If payments exist, ensure both models apply the same order (interest-first vs. principal-first) and credit date.
• Document your final DocketMath settings

  • So you can reproduce the exact result later.

If you want a fast starting point, open /tools/interest and apply the single-variable approach above. The first setting that moves the result toward the reference tells you where the discrepancy comes from.

Related reading

• Interest rule lens: Maine — The rule in plain language and why it matters
• Common interest mistakes in Rhode Island — Common errors and how to avoid them
• Worked example: interest in Maine — Worked example with real statute citations