-**Amount derived from exact duration** (chosen). Totals stay correct and unit-invariant; the only cost is that a client multiplying the displayed per-minute rate by the quantity may land a sub-cent off the shown amount, which is invisible at the PDF's 2-dp rendering.
- Both import paths (the manual `ImportTimeEntriesDialog` and the silent `autoImportTime` effect) must use the same conversion helper so amounts cannot diverge by entry path.
`
hours
`
(90m →
`
1.5
`
) or
`
minutes
`
(90m →
`
90
`
) — and
`
unitPrice
`
is converted to match (per-hour rate, or per-minute rate rounded to 4 dp). We decided that a line's
`
amount
`
is always computed from the
**
exact duration
**
(
`
durationMinutes / 60 × hourlyRate
`
, rounded to 2 dp), independent of the displayed unit and the rounded per-minute
`
unitPrice
`
. This keeps invoice totals identical no matter which unit was picked and free of per-minute rounding drift — the unit changes only how a line
*
reads
*
, never what it sums to.
`
90 × 1.6667
`
and land on the shown amount). Rejected: the per-minute rate is lossy, so this reintroduces 1-cent drift into line amounts and the invoice total — the exact "complex math" issue #56 set out to remove.
). The duration-derived amount is therefore authoritative only until a row is manually edited. When a user only nudges values within rounding tolerance, the divergence from the duration-derived amount stays limited to rounding/precision differences (sub-cent) and does not surface at 2-dp display. Intentional, material edits to quantity or unitPrice will, by design, produce larger deviations — the recomputed
`
amount
`
then reflects the user's explicit values rather than the original duration.