Dividend income

What is tracked

Income comes from the ledger and nowhere else. Every dividend and interest payment that reached one of your accounts is a row in the same activity ledger that holds your trades, and the income page is a reading of those rows — not an estimate derived from yields and share counts.

Rows arrive three ways: an IBKR import classifies each cash transaction it finds, a manually tracked portfolio can record a dividend by hand, and a paper book’s holdings pay in the same ledger as everything else. Withholding tax arrives as its own kind of row.

Trailing twelve months and year to date

Trailing 12M

The current calendar month plus the eleven before it, in UTC. The current month is partial by definition, so the figure climbs through it.

Year to date

From 1 January of the current year, in UTC.

Monthly pace

The trailing-twelve-month total divided by twelve.

Versus the prior year

Compared against the twelve months before the trailing window — and it says it needs more history rather than comparing against a partial one.

All of these are gross figures, before withholding. They are also signed: a reversed dividend subtracts instead of quietly counting twice, which means a month, or a payer, can legitimately show a negative total.

Income is also broken down by payer, with each one’s total, payment count, average payment, last payment date, and share of the whole. Cash interest is grouped per currency rather than being scattered across accounts.

The forward calendar

The calendar shows what you have received and what is expected next, about a hundred days ahead. Expected payments come from two very different places, and the page never mixes them up.

• Declared. The company has announced the payment and the per-share amount. The only thing Bitnora supplies is your share count.
• Estimated. Nothing has been announced, so the payment is projected from that holding’s own history: its established cadence, its typical lag between the ex-date and the payment, and its recent per-share amounts. Monthly payers use a short average because their amounts drift; everything else uses the most recent regular payment.

Estimates carry a ~ everywhere they appear, and never count as received. One-off special distributions are never projected forward — a single large payment must not be allowed to seed a recurring expectation.

Where a payer’s recent amounts have swung around, the estimate is marked Varies and dimmed, with a note that it is based on recent payments. That is the confidence signal made visible: a payer whose last year has been steady gets a plain figure, a payer whose payments have ranged widely gets a flag, and a payer whose cadence cannot be established at all gets flagged too.

A payment that has come due but has not appeared in the ledger yet keeps showing as expected for a short window, because the likeliest explanation is that your broker feed has not caught up. The honest limit of that: a dividend that was cut, or a position sold mid-cycle, has nothing to cancel it and reads as expected until it ages out.

Withholding tax

When a broker withholds tax before a dividend reaches you, that deduction is imported as its own ledger row and shown as its own figure. Where it is available, the page carries a gross total, the amount withheld, and the net — and it says plainly that withholding is deducted before the cash arrives.

What it is not: a tax calculation. Bitnora reports what your broker reported. There is no rate table, no treaty logic, no per-country handling, no reclaim tracking, and nothing here is tax advice or a substitute for the documents your broker issues.

Where the numbers say they are incomplete

Income is the part of the product most exposed to missing data, so it is also the part that talks most about its own gaps. Rather than quietly returning a smaller number, the page raises a note when:

• A payment arrived in a currency with no stored exchange rate for its date, so it is excluded from every figure. The note says how many and roughly how much, in their own currencies — they are never summed across currencies to produce a fake total.
• A payment had to be converted with the closest available rate rather than the one for its date.
• A broker import has not completed recently, so payments since then are missing.
• A sync keeps succeeding while importing nothing, which usually means the saved Flex query stopped covering trades and cash transactions.
• Payment history could not be loaded for a holding, so its upcoming income may be missing from the estimates.

The forward calendar also has honest edges. Interest is only projected once there is enough of a recent pattern to project from, a payer with no established cadence produces no estimate at all, and an estimate whose currency cannot be converted is dropped rather than shown at the wrong size.

You can see the whole thing running against a real book on the public demo.