Bitcoin accounting units look simple until a person moves between an exchange screen, a wallet, a spreadsheet, and a local-currency report. One service may show 0.001 BTC, another may show 100,000 satoshis, and a third may round a fiat value to two decimals. The unit is not a minor display choice: it determines whether a record can be reconciled later. This guide builds a unit-aware habit for overseas readers who need a clear personal ledger, without turning an educational example into tax or investment advice.

Start with the smallest native unit

Bitcoin divides one BTC into 100,000,000 satoshis, commonly shortened to sats. A balance of 0.000001 BTC is 100 sats, while 1,000,000 sats is 0.01 BTC. Record the integer satoshi amount whenever a tool exposes it, then display a friendly BTC conversion for reading. Integer storage avoids floating-point rounding in spreadsheets and scripts. If a platform uses a different label, write the platform label beside the numeric amount instead of assuming that every “unit” means a satoshi.

Separate asset units from money units

A BTC amount and its local-currency value answer different questions. The asset unit describes how much bitcoin moved; the fiat amount describes a quoted conversion at a particular time and source. Keep both columns, with currency code and timestamp, rather than replacing the asset amount with a dollar or euro estimate. Exchange rates vary by venue, spread, and time zone. A clean record therefore says “50,000 sats received” and separately notes the valuation method used for that record.

Build a ledger that survives translation

Multilingual households often translate labels when discussing a transfer. Keep a stable machine-readable field such as amount_sats, and provide translated labels only for the human-facing sheet. Include transaction ID, network, address role, fee in sats, and UTC time. Avoid comma and decimal conventions that change between locales; an English “1,234.5” can be misread in regions that use a comma as the decimal marker. Put the unit in the column header and repeat it in exported notes.

Handle fees and change outputs

The amount a recipient receives is not always the amount a sender spends. A transaction has inputs, outputs, and a miner fee; a change output can return value to the sender’s wallet. Record gross input value, recipient output, change output when identifiable, and fee. For a simple payment, the arithmetic should reconcile: inputs equal outputs plus fee. If an exchange hides those fields, save its statement and do not invent a network fee from a rounded account balance.

Check conversions before reporting

Before using a record for a report, convert the smallest unit back to the displayed amount and compare the platform statement. Test a few boundary values such as 1 sat, 100 sats, and 100,000,000 sats. Confirm that a CSV export has not converted an integer into scientific notation or rounded trailing zeros. If an app reports “0 BTC” for a tiny balance, inspect the raw transaction or a trusted explorer; a display threshold is not proof that the balance is zero.

A practical review routine

At month end, reconcile each deposit and withdrawal by transaction ID, then total sats separately from fiat valuations. Mark entries that are pending, reversed by a service, or missing a network identifier. Keep original exports read-only and work from a copy when adding translated notes. Never include a private key or recovery phrase in the ledger. The goal is a record another person can understand and verify, not a prediction about price or a substitute for local professional advice.

Operational worksheet

Use a two-sheet structure. The first sheet stores integer satoshis, transaction identifiers, network, fee, and UTC time. The second sheet translates those facts into a family-friendly display and keeps a linked valuation note. When importing a CSV, compare three rows manually: a whole BTC amount, a tiny satoshi amount, and a value with trailing zeros. Confirm that your spreadsheet treats the amount as an integer or fixed decimal, not a binary floating value. For a shared household record, assign one person to enter facts and another to reconcile against the statement. Record corrections as a new dated row instead of silently changing the old value. This process makes a later question answerable: what moved, when did it move, which service reported it, and what conversion was used? It also prevents a translated decimal separator from changing the amount. Keep a read-only original export and protect access to the working copy.