Why the original currency amount should never disappear during bookkeeping.

The original amount and the booked amount are different facts

A foreign transaction has at least two monetary facts: what happened in the original currency and the SEK value used for Swedish bookkeeping. Replacing 10.44 USD with kronor would make the conversion visible by making the original event harder to reconstruct.

CODE59 keeps the selected original currency in the primary field, such as Belopp (USD). A separate read-only Bokförs som value shows SEK. Changing currency, event date, rate or source invalidates a prepared review so stale conversion facts cannot quietly survive into posting.

Physical purchase evidence: 10.44 USD → 104.18 SEK

On the Samsung test device, an outside-EU B2B service purchase used 10.44 USD as the original amount. A cached ECB rate of 9.9788639366 with source date 30 September 2026 produced 104.18 SEK. The transaction posted as voucher A-1.

Reopening A-1 retained the immutable FX facts and evidence hash. The test therefore checked more than arithmetic: it checked whether the explanation for the SEK amount survived after posting.

A manual-rate sale tests a different provenance path

A direct outside-EU B2B service sale used the same 10.44 USD original amount but a documented manual rate of 10.00. FigureDesk showed 104.40 SEK and posted A-2 with the manual-rate provenance frozen.

Automatic and manual rates are not interchangeable labels. The review and saved voucher need to preserve which path produced the conversion.

What must survive the workflow

The saved snapshot keeps original amount, currency, SEK amount, rate, effective date, actual source date, source and method. The ECB request itself remains smaller: currency and requested date are sent, not amount, counterparty, invoice, evidence or ledger data.

This separates the accounting record from the network lookup while still allowing a later reader to understand the conversion.

A currency control must not imply unsupported accounting

The shared FX panel appears only on the two narrow direct-payment routes verified for CODE59. Swedish transactions remain SEK-only. EU cases, goods, equipment, private-payment cases, uncertain locations, foreign invoices/settlements, credits and refunds remain blocked or require more facts.

That fail-closed boundary matters. A polished currency selector on an unsupported event could imply that the accounting treatment behind it had also been verified.

Recovery is part of the evidence

CODE59 also completed two destructive backup → clear → restore → restart cycles. Each used Android's visible document picker, cleared only Owner Test app data, restored through FigureDesk and compared database table counts after restart.

The second cycle included a controlled profile change, CYCLE2CHANGE. It returned exactly after restore, along with matching table counts. For local-first bookkeeping, recovery is part of whether records remain trustworthy.

Why CODE59 is still blocked

The automated baseline is strong: 152/152 JVM debug, 152/152 JVM release, successful lint/builds and 175 Samsung instrumentation tests with zero failures/errors. But the complete prescribed A–T physical matrix is still incomplete. Remaining physical work includes parts of PDF open/save/share, exhaustive save-feedback and broad product smoke.

That is why CODE59 is still BLOCKED, not release-certified. Strong evidence should clarify what is proven and what remains open.