Allow the rounding a broker's own printed figures propagate

A real Scalable export refused to import at record 148: "buy gross -808.5599
does not equal quantity 6 times price 134.76, which is -808.56". Six NVIDIA
shares settled at 808.5599 against a printed price of 134.76, because the fill
was 134.759983 and the export printed the price to two places. One
ten-thousandth out, and the whole file was rejected.

The check held a gross to its own stated precision, which is only half the
story: the price is rounded too, and the file never says by how much. So the
allowance is now half a unit of the gross's stated precision plus one part in a
hundred thousand of the gross, compared against a product kept exact at 1e-16
rather than rounded first.

Measured over the complete export - 88 security rows - exactly one deviates at
all, by one part in eight million, eighty times inside the new bound. What the
bound still refuses is unchanged in kind: a price taken from the wrong share
class, and the misplaced decimal separator the check exists for, which misses
by four orders of magnitude. What it now accepts is the broker's own rounding,
including a whole cent once a gross stated to the cent passes about five hundred
euro, where a genuine one-cent error cannot be told from that rounding anyway.

The row is kept as a regression test alongside four grosses that must still be
refused: a cent, a euro, a wrong instrument's price, and a factor of ten.
This commit is contained in:
Lars Nolden
2026-09-12 12:20:19 +02:00
parent da817078f4
commit 635c11be56
4 changed files with 99 additions and 36 deletions
+1 -1
View File
@@ -202,7 +202,7 @@ Because a cash row's amount already includes the tax the broker withheld or refu
Two more traps there: a `DIVIDEND` row fills the share column with **the holding the dividend was paid on**, so adding it would double the position; and crypto carries a bare ticker like `DOGE` in `symbol`, with its real identifier only in the description. Both are handled, and a position row that resolves to neither is refused.
Only `Executed` rows import from Scalable: a cancelled retry is all zeros, so it passes every arithmetic check and would otherwise become a phantom trade. Every security row is verified against shares × price **to the precision the broker stated the amount at** — exactly, where the export prints the full product; to within a cent, where it prints the notional rounded. An unknown row type, a mismatched classifying column, a foreign settlement currency, an unresolvable security, or a failed check rejects the **whole file** with the record number, because each of those can move money that never moved.
Only `Executed` rows import from Scalable: a cancelled retry is all zeros, so it passes every arithmetic check and would otherwise become a phantom trade. Every security row is verified against shares × price, **allowing for the rounding the export's own figures propagate** — both the gross and the price are printed rounded, and neither says by how much. Across a complete real export of 88 security rows exactly one deviates at all, by one part in eight million; a misplaced decimal separator is four orders of magnitude outside the allowance. An unknown row type, a mismatched classifying column, a foreign settlement currency, an unresolvable security, or a failed check rejects the **whole file** with the record number, because each of those can move money that never moved.
Securities are registered by **ISIN** in **Instruments**. The ISIN is the identity; the name is editable display text, because one ISIN appears under several broker names over the years. Crypto is held under the ISIN-shaped identifier the broker issues for it. Set the account's **settlement IBAN** for an export that names no counterparty of its own, so deposits from your bank pair with the funding account instead of staying unpaired. They never become income either way — a broker record is excluded from spending and income analytics, from bulk reclassification, and from the AI entirely.