Interest, one day at a time.

What a result establishes.

Offset Ledger compares a supplied interest charge with a calculation from your daily loan balances, eligible offset balances and annual rates. Its result is conditional on those records, the exact accrual period and the rounding convention you select.

No lender or product has yet been validated against a complete real account record. The tool accepts prepared daily records. It does not establish that a bank statement, exported transaction date or offset linkage has been interpreted correctly.

A match establishes arithmetic agreement with a selected model. A difference gives you a specific calculation to investigate; it does not establish a bank error or an entitlement to compensation.

The calculation.

For each included calendar day, enter the loan and eligible offset balances in dollars, and the annual rate as a percentage: enter 5.50 for 5.50%.

net loan dollars = max(loan − offset, 0)
exact daily interest in cents
  = max(loan − offset, 0) × annualRatePercent / 365

The percentage conversion divides by 100 and the dollars-to-cents conversion multiplies by 100, so those factors cancel. Offset balances above the loan balance produce zero interest in this model. They do not produce a credit.

The reconciliation keeps money and rates as exact fractions. Chart heights and axis labels use approximate display values. The divisor is always 365, including leap years; a covered leap day still needs its own row.

The two rounding choices are explicit hypotheses, not lender presets:

• Period-end half-up: add the exact daily fractions, then round the total to the nearest cent.
• Daily half-up: round each day's exact amount to the nearest cent, then add those whole cents.

Half-up sends an exact half cent to the higher cent. These choices do not exhaust every possible lender convention. Each selected total is compared individually with the supplied charge. An amount between two different totals does not count as a match.

The calculation uses the balances supplied for each day. Interest already debited to the loan, repayments, fees and other movements must already be reflected in those balances at the correct time. The tool does not rebuild or compound a loan balance from transactions.

Prepare a daily CSV.

Use exactly these four columns, in this order:

date,loan,offset,annualRatePercent
2026-09-01,140080,50000,5.50

This row is an invented illustration of the file format. It is not a real account record.

• Use Gregorian dates as YYYY-MM-DD, with exactly one row for every day from the entered start date through the end date, both included. Missing, duplicate and out-of-period dates are refused.
• Use plain nonnegative decimals, without currency symbols, thousands separators, spaces, formulas or exponent notation. Each numeric value may contain at most 32 characters and 12 decimal places.
• Supply the rate effective on each day, including every rate change. Use the eligible offset amount for this particular loan; account balances alone do not establish eligibility.
• Enter the observed charge separately in dollars, exactly representable in whole cents. Its accrual start and end dates must be known independently of the statement's date range or the day the charge was posted.
• A calculation accepts up to 3,660 days. The CSV file limit is 4 MiB. Bank PDFs and native bank CSV layouts are not supported formats.

No missing day, balance or rate is filled in. Having one row for each date proves coverage of the supplied file; it cannot prove that its contents are correct. Even matching opening and closing balances can miss omitted transactions that cancel overall but change balances during the period.

Six declarations stay with the report.

Before treating the comparison as a reconciliation under the selected model, confirm all six statements:

1. Complete period: the records cover every day of the entire interest accrual period.
2. End-of-day balances: the loan and offset figures reflect the correct end-of-day balances for interest, including movements on their effective days.
3. Effective rates: each annual rate is the rate applicable on that day, including changes during the period.
4. Eligible offsets: the offset amounts include only funds eligible to offset this loan on that day, with relevant linkage and eligibility accounted for.
5. Charge period: the observed amount is the interest charge for these exact accrual dates, with unrelated fees or adjustments separated.
6. Model accepted: you accept the stated daily-balance calculation, fixed 365 divisor and selected rounding hypotheses for this comparison.

These are your declarations. Checking them does not independently verify their truth. If any is unconfirmed, the report retains an insufficient-evidence interpretation even when the arithmetic happens to match. Invented examples remain labelled as examples.

Read the comparison narrowly.

For each convention, the difference is the observed charge minus the calculated charge. A positive difference means the supplied charge is higher under that model; a negative difference means it is lower. Recheck the source records, accrual dates, effective rates, eligible offsets and calculation rules before drawing a conclusion.

The no-offset comparator reruns the same supplied daily loan balances and rates with zero offset. Its difference shows the offset effect within that fixed history. It does not simulate the loan balance that would have developed without an offset: different interest charges could themselves change later balances. It is neither a compensation calculation nor a forecast.

Check a saved report offline.

Export the JSON report, then download the offline checker ZIP and extract it. The checker uses Python 3's standard library, with no installed packages or network connection required.

python3 check_report.py offset-report.json

You can first try the invented example report. The Python checker, browser calculation and CSV parser are also readable individually.

The report carries the supplied daily data, observed charge, selected conventions, declarations, exact daily calculations, totals and interpretation. The Python checker independently recomputes the fractions, rounded results and conditional interpretation. It checks the report's structure and SHA-256 self-digest without executing the browser's JavaScript.

A successful check establishes arithmetic and internal consistency only. It cannot authenticate bank records, prove completeness, establish lender rules or verify your declarations. The SHA-256 identifies report contents; it is not a signature. Someone can replace the contents and create a new, internally consistent report with a new digest.

Evidence, and what remains untested.

Macquarie's published interest examples use a $140,080 loan at 5.50% annually. They show $21.11 for one day without an offset and $13.57 with a $50,000 offset. Both amounts reproduce under this model.

Those are illustrative one-day formula checks. Both rounding hypotheses give the same result for one day, so these examples cannot establish monthly rounding or validate a complete customer charge.

Macquarie's home-loan terms describe end-of-day calculation and a 365 divisor in clause 3.1. Clause 3.4 says debited interest becomes part of the balance for future interest. Clause 4.10 permits interest to begin on a debit despite a processing delay. These details show why a transaction's displayed date is not sufficient evidence of its interest-effective date. No rounding rule was located in that booklet, and a current booklet alone cannot establish the agreement governing a historical account.

Macquarie's download instructions also say an export includes only transactions currently loaded on screen. A downloaded date range therefore needs its own completeness check.

Sources were checked on 21 September 2026. We have not yet benchmarked the tool against a complete real loan-and-offset record with documented rates, effective dates, accrual boundaries and observed charges. These source examples do not constitute supported-bank certification.

What a supported bank format would need.

Support would require an identified product and applicable terms, complete loan and offset histories, balance anchors, effective transaction dates, every rate change, offset-linkage history, and the exact accrual period behind an independently observed charge. Permission to use a record for validation and permission to publish it would be established separately.

The documented rules would then need to reproduce ordinary periods and periods containing repayments, rate changes, offset movements, interest debits and leap days. Choosing rules only because they make one statement match would not establish support. Any future bank-format support must identify the products and cases actually validated, together with remaining limits.

Your records stay in your browser.

The tool calculates locally. It does not send your entered data or imported file over the network, and does not save those inputs in browser storage. Downloaded reports contain your daily balances, rates and charge, so treat them as financial records when saving or sharing them. The offline checker reads the report locally and does not upload it.