Bitcoin Features

BTC Display Modes: Sats, BTC, or Bitcoin

The short answer BitBooks shows Bitcoin amounts four different ways, and you pick which one your organization uses: | Mode | Same amount looks like | |---|---| | BTC High Precision | BTC 0.00050000 | | BTC Consequence (default) | BTC 0.00050 000 | | Bitcoins | 0.0005 Bitcoin | | Satoshis | 50,000 sats | All four are correct. They're just different ways of writing the same amount. Which one you pick depends on how you think about Bitcoin, and that varies by person, by team, and by use case. Why this exists Bitcoin is unusual: the smallest unit (a satoshi) is 100 millionth of the largest unit (a BTC). Compare to dollars, where the smallest unit (a cent) is just one hundredth of a dollar. That means a Bitcoin amount can span eight decimal places. 0.00050000 BTC is a perfectly normal price for, say, a coffee. Try writing that on a receipt without making someone's eyes glaze over. Different parts of the Bitcoin world handle this differently: - Lightning developers and merchants think in satoshis. A coffee is "5,000 sats." Easy to read, no decimals. The same way a US merchant says "$5" instead of "$0.0000... of a million dollars." - Long-term holders and treasuries think in BTC. They're moving 0.5, 1, 2 BTC at a time. Whole numbers are easier than 8-figure satoshi counts. - Spreadsheet-trained accountants want BTC with consistent decimal places so columns line up. "BTC 0.00050000" is awkward to read but adds up nicely when you stack 50 of them in a report. There's no universal right answer. So BitBooks lets you pick. What each mode does, with the same example Let's take an amount: fifty thousand satoshis. Same Bitcoin in all four cases, just displayed differently. BTC High Precision BTC 0.00050000 Eight decimal places, always. Use this when: - Your accountant insists on the most-precise standard format - You're exporting to systems that expect a fixed BTC format - You're auditing. Having every value in the same shape makes mismatches obvious Pros: unambiguous, consistent across reports. Cons: ugly to read for everyday amounts. A 50,000-sat coffee shouldn't need eight decimals. BTC Consequence (this is the default) BTC 0.00050 000 Same eight decimal places, but BitBooks adds a thin space every five digits to make it scannable. The pattern matches how some Bitcoin Core conventions display amounts. Use this when: - You want full precision but hate squinting at long decimal strings - You're showing reports to clients who are mildly Bitcoin-literate - This is a sensible default if you don't have strong feelings Pros: readable, full precision, professional. Cons: still asks the reader to count zeros. Bitcoins 0.0005 Bitcoin BTC with the trailing zeros removed and the word "Bitcoin" written out. Use this when: - You're moving meaningful BTC amounts (0.5, 1, 5 BTC) and the trailing zeros aren't useful - You're explaining a transaction to someone non-technical - You want the cleanest visual Pros: cleanest, most natural for human conversation. Cons: trailing-zero loss can hide precision in tiny amounts (0.00000001 BTC vs 0.00000010 BTC could look the same in casual reading). Satoshis 50,000 sats The amount in sats, with thousands separators (50,000 not 50000). Use this when: - You operate primarily in Lightning, where most amounts are under 100,000 sats - Your team thinks in sats and finds BTC formatting cumbersome - You're a developer or merchant where "$5 = 5,000 sats" is your everyday math Pros: integers only, no decimals to worry about, matches how most Lightning UIs display amounts. Cons: large amounts get long fast (1 BTC = 100,000,000 sats, that's a lot of digits). How to change it The setting lives at Admin → Settings. Admin Settings page showing the Bitcoin display preference dropdown with all four options Steps: 1. Click Admin in the sidebar 2. Make sure you're on the Settings tab (it's the default) 3. Scroll to Bitcoin display 4. Pick one of the four modes from the dropdown 5. Scroll to the bottom and click Save The change applies immediately. Reload any open BitBooks tabs to see amounts re-rendered in the new format. Per-organization, not per-user This setting belongs to the organization, not to you personally. That means: - Everyone on your team sees Bitcoin amounts the same way (good for consistency) - If you manage multiple organizations (e.g., a bookkeeper with several clients), each one can have its own setting - Switch organization in the sidebar dropdown, and the display mode switches with it If your team is split, say the founder thinks in BTC and the developer thinks in sats, you'll have to pick one. Most teams default to BTC Consequence for reports and rely on each person doing the mental conversion. The integers-only nature of sats makes it tempting, but BTC is what most accountants and tax preparers expect to see. What this setting does not affect A few things that don't change when you flip the display mode: - The actual amounts in your database. BitBooks always stores Bitcoin amounts in satoshis internally (as integers, for accuracy). The display mode only changes how those amounts are shown on the screen and in exports. - Fiat amounts. Dollars, euros, pounds, etc. are formatted by the Number format setting (US Standard 1,234.56 vs European 1.234,56), not by the BTC mode. - Reports for non-Bitcoin organizations. If your organization is set to USD-functional and you don't hold any BTC, the display mode setting effectively doesn't matter (there's no BTC to display). A quick decision guide Pick Satoshis if: - Your team is mostly Lightning-focused - Most of your transactions are small (under 100,000 sats) - You hate decimal points Pick Bitcoins if: - You're moving whole or half BTC routinely - You explain transactions to non-technical people often - You want the cleanest possible appearance Pick BTC Consequence if: - You're not sure - You produce reports that go to accountants - You want full precision visible without squinting Pick BTC High Precision if: - Your accountant requires standardized 8-decimal format - You're exporting to a system that expects rigid formatting A practical tip If you're unsure, start with BTC Consequence. It's the default for a reason. Most teams find it the right balance of precise and readable. You can always change it later, and the change is reversible (the underlying amounts don't change, just how they're shown). Where to go next - For the broader picture of how BitBooks handles Bitcoin, see How Exchange Rates Work - For tracking value changes on your Bitcoin holdings over time, see Tracking Bitcoin Gains and Losses - For other formatting settings (date format, time format, number format), see Organization Settings

Tracking Bitcoin Value Changes (FX Revaluation)

The problem You bought 2 BTC for $50,000 each in January. Total cost: $100,000. By December, BTC is at $80,000. Your 2 BTC is now worth $160,000. You haven't sold anything. No transaction happened. But the value of what you own has changed by $60,000. How should that show up in your books? Most accounting tools have no answer. They record the original $100,000 and never update it. Your year-end Balance Sheet says you own $100,000 of Bitcoin. Your investor looks at the news, sees BTC at $80,000, does the math: 2 BTC × $80,000 = $160,000. They ask "why does your Balance Sheet show $100,000?" That gap is the problem. BitBooks closes it through a feature called FX revaluation. What FX revaluation does FX revaluation is a periodic accounting action that: 1. Looks at every Bitcoin balance you hold 2. Compares the recorded value to the current market value 3. Books the difference as an unrealized gain or unrealized loss After revaluation, your Balance Sheet shows the current market value, your P&L shows the gain or loss, and your books reflect economic reality. The "FX" in "FX revaluation" stands for foreign exchange. The same logic applies to any non-functional currency, but for most users it's specifically Bitcoin. Realized vs unrealized Two important terms: - Unrealized gain/loss. The change in value of something you still own. Hasn't actually been "captured" because you haven't sold. Could go up or down again before you do. - Realized gain/loss. The change in value when you actually sell. The transaction that locks in the dollar amount. Both belong on the books, but they're different categories. A simple example: you bought 1 BTC at $50,000. BTC is now $70,000. If you do nothing, you have an unrealized gain of $20,000. If you sell that BTC at $70,000, the $20,000 is now realized. FX revaluation handles the unrealized side. The act of selling produces realized gains/losses through ordinary transaction entries (BitBooks calculates the gain when you record the sale). How often to revalue The common cadence: - Year-end. Mandatory for accurate annual financials. Most small businesses do only this. - Quarterly. Common for businesses that report to investors quarterly. - Monthly. Common for businesses with significant Bitcoin holdings or audited financials. - Daily. Rare. Some Bitcoin treasuries do this. The more often you revalue, the more "live" your Balance Sheet feels. The trade-off is more entries to manage. A good default for a small business: revalue once a year at year-end, plus an extra revaluation right before any major event (investor pitch, bank loan application, board meeting). How to run a revaluation in BitBooks 1. Go to Admin → FX Revaluation (or look for the Revaluations action in the Reports menu) 2. Pick the as-of date (the date the new values reflect) 3. Optionally pick the method: - Closing rate (use the rate at the as-of date, applied to all balances): the standard - Period average (use the average rate over the period): less common, mostly for income translation - Historical per transaction (each transaction stays at its original rate): the default for transactions; revaluation overrides this only on year-end positions 4. Pick the framework: IFRS or US GAAP. They handle some details differently. Default matches your organization's setting. 5. Click Preview FX Revaluation modal showing date selector, method dropdown, framework toggle, Preview button Preview shows what will happen The preview lists every Bitcoin balance, the recorded value, the new value at the as-of date, and the proposed gain or loss. You can review before committing. Bitcoin Hot Wallet BTC balance: 0.50 BTC Recorded value: $32,000.00 Market value: $40,000.00 Unrealized gain: +$8,000.00 Bitcoin Cold Storage BTC balance: 2.00 BTC Recorded value: $100,000.00 Market value: $160,000.00 Unrealized gain: +$60,000.00 TOTAL UNREALIZED GAIN: +$68,000.00 If the preview looks right, click Post Revaluation. BitBooks creates a journal entry that books the gain to a special account ("Unrealized FX Gain on Bitcoin" or similar) and updates the Bitcoin balance to current market value. Preview screen showing the table of wallets and gains, with the Post button at the bottom After posting The revaluation creates a Posted journal entry (you can see it in Journal Entries). Your reports update: - Balance Sheet: Bitcoin now shows current market value - P&L: An "Unrealized FX gain" line shows the impact for the period Subsequent transactions continue normally. The revaluation is a one-time correction; it doesn't keep updating in real time. Reversing a revaluation If you ran a revaluation by mistake, or with the wrong as-of date: 1. Go to the FX Revaluation page 2. Find the run in the history 3. Click Reverse Revaluation This creates a reversing entry that exactly cancels the revaluation. Both stay in the audit trail. You can then run a corrected revaluation. Some accounting framework details A few things differ between IFRS and US GAAP: | Topic | IFRS | US GAAP | |---|---|---| | Bitcoin classification | Indefinite-lived intangible (often) or financial asset (sometimes) | Indefinite-lived intangible asset (mostly) | | Unrealized gains | Generally recognized in P&L | Historically not recognized; only impairment was. Updated guidance now allows fair value. | | Currency translation | Per IAS 21, with specific rules for monetary vs non-monetary items | Per ASC 830 | If you're under US GAAP and your accountant follows older guidance ("Bitcoin can only be marked down, not up"), you'd revalue only when there's a loss. That's the conservative interpretation. If you follow newer guidance (FASB ASU 2023-08), you can mark Bitcoin to fair value. Most BitBooks users are on this path. If you're under IFRS, it depends on your classification. Most Bitcoin businesses classify under IAS 38 and revalue with gains and losses going through P&L. The framework affects which BitBooks tools you should use. Pick your organization's framework in Admin → Settings, and ask your accountant if you're uncertain. What revaluation does NOT do - It doesn't predict the future. The revalued amount is current at the as-of date. It will be different tomorrow as Bitcoin's price moves. That's why you re-revalue periodically. - It doesn't sell your Bitcoin. No actual transaction happens at your wallet. The Bitcoin amount in the wallet is unchanged. Only its dollar-equivalent on your books changes. - It doesn't apply to fiat currencies you operate in. If you have a CAD account and your functional currency is USD, the CAD/USD conversion happens through the normal exchange rate mechanism per transaction. Revaluation is mainly for Bitcoin and other foreign currency holdings at the snapshot moment. Common questions "My Bitcoin price dropped. Do I have to recognize the loss?" Under most frameworks, yes. Unrealized losses should be recognized through revaluation just like gains. Run the revaluation, the loss appears as a negative on your P&L. A loss is unpleasant to see, but recognizing it is the honest answer. Hiding it inflates your apparent equity and would mislead anyone reading the financials. "What if I don't run revaluation? What's the worst that happens?" Your Balance Sheet shows the wrong Bitcoin value. Reports look incorrect to anyone who knows what BTC is currently worth. Tax filings might be incorrect (depending on jurisdiction). For a hobby account, low stakes. For a business with serious Bitcoin holdings, real consequences. "My accountant says we should only revalue at year-end." Then revalue at year-end. The annual cycle satisfies most regulatory and tax requirements. Mid-year revaluations are optional and mostly for stakeholder communication. "How does this interact with selling Bitcoin?" When you sell, you record an ordinary transaction. The gain or loss on that sale is the difference between the sale price and the most recent revalued amount, not the original purchase price. This is correct because revaluation already booked the unrealized portion. Selling just realizes the rest. If you've never revalued, the gain/loss on sale is the difference between sale price and original cost. That's also correct. The two approaches just put the gain in different periods. Where to go next - The Three-Currency Model Explained for the multi-currency foundation - How Exchange Rates Work in BitBooks for where prices come from - Period Close for when revaluations should run as part of close - Profit & Loss Report to see the impact of revaluation on income - Balance Sheet to see Bitcoin at current market value after revaluation

How Exchange Rates Work in BitBooks

What an exchange rate does When a transaction happens in one currency but your books are kept in another, you need to convert. A €1,000 expense at a moment when 1 EUR = 1.08 USD becomes $1,080 on the USD-functional books. The rate is a translator. BitBooks fetches rates automatically and pins them to transactions so the conversion is locked in. Where rates come from BitBooks uses different data sources for different kinds of currencies: - Fiat-to-fiat rates (USD/EUR, CAD/USD, etc.) come from Open Exchange Rates by default - Bitcoin pricing (BTC/USD, BTC/EUR, etc.) comes from CoinGecko by default Both update frequently (multiple times per hour). When you post a transaction, BitBooks looks up the rate for the transaction's date and currency pair, stores it with the transaction, and uses it for the conversion. You can change the providers in Admin → Settings under exchange providers, but the defaults work for almost everyone. "Rate-pinned" transactions When a transaction is created, BitBooks fetches the rate at that moment and pins it to the transaction. The rate stays with the transaction forever, even if the live market rate changes later. This is required by accounting standards. Historical transactions should reflect the rate at the time of the transaction, not the rate today. The rate is stored on the transaction's journal entry line. If you ever need to see what rate was used, click the transaction and look at the line detail. How rates are bucketed Behind the scenes, BitBooks doesn't store a separate rate per transaction. It stores rates in time buckets: - Day-level buckets for most currencies (one rate per day) - 5-minute buckets for high-volatility currencies like BTC A transaction posted on 2026-05-01 looks up the bucket for that day (or that 5-minute window for BTC) and uses the rate from that bucket. Two transactions posted on the same day use the same rate. Why this matters: a rounding cent of difference between transactions on the same day usually isn't a bug, it's just different rate bucket alignment. When rates can be "Pending" Sometimes BitBooks tries to fetch a rate but can't. Reasons: - The rate provider's API was down at the moment of fetching - An obscure currency pair (rare currencies that providers don't cover daily) - A rate-limit on the provider that throttled us - A future-dated transaction (the rate doesn't exist yet) When this happens, the transaction's line is flagged rate pending. The conversion isn't resolved. The transaction is still recorded, but reports won't include the converted value (or will show it as 0) until the rate is fetched. Banner across the top of the Transactions page reading "X pending rates" with a Retry button To resolve pending rates: 1. Look for the pending rates banner at the top of Transactions or Journal Entries 2. Click Retry 3. BitBooks tries to fetch the rates again If the original problem (provider downtime) is over, the rates resolve and the transactions become fully calculated. For rates that fundamentally can't be fetched (unsupported currency, far-future date), you may need to enter a manual rate. See Wrong Exchange Rate on a Transaction. Manual rate override If the auto-fetched rate is wrong (e.g., you got a slightly different rate at the actual point of trade), you can override. In Advanced Mode (Journal Entries), open the entry, click into a multi-currency line, and enter a manual rate. The line stores the override; the conversion uses your value. The override is recorded for audit. Anyone reading the entry later can see that a manual rate was used and what it was. Multi-currency reports If you have a secondary reporting currency set, reports can be displayed in either functional or reporting currency. The display rate at the top of the report (functional → reporting) is the "as-of" rate at the report's end date. So a P&L for January 2026 displayed in USD when functional is CAD uses the CAD/USD rate at January 31, 2026 to translate. Note: this is a display-only translation. The underlying entries kept their original transactional rates. The reporting currency view is a re-presentation, not a re-recording. When rates affect gain/loss A few cases where exchange rates create gains or losses: You hold non-functional currency If your functional currency is USD but you have a CAD bank account, the value of that CAD balance in USD changes every day as the CAD/USD rate moves. Periodically, you book this change as an FX gain or loss via revaluation. See Tracking Bitcoin Value Changes (the same mechanism applies to fiat foreign currency). You sell at a different rate than you bought You bought BTC at $50,000 each. You sell at $80,000 each. The $30,000 per BTC difference is a realized gain. Recorded explicitly via Recording a Bitcoin Sale. Inflation between booking and payment Less common, mostly for businesses with long credit terms. You issued a CAD invoice for €1,000 worth of work in January. The customer paid in February. The CAD/EUR rate moved between the two dates. The difference is a small FX gain or loss on the receivable. Most small businesses ignore this kind of micro-gain unless amounts are material. Rate-fetch frequency BitBooks doesn't refetch every rate every minute. Rates are fetched: - On demand, when a transaction is posted in a currency pair we don't have a recent rate for - In batches, scheduled to keep recent rates fresh - On-retry, when you click Retry Pending Rates For most users, you never think about this. Rates are there when you need them. Common questions "My transaction shows a rate that doesn't match what I see on Google." Likely the rate is from a different time bucket or a different provider. Check the transaction's date and the provider used. For BTC specifically, CoinGecko aggregates across exchanges so it differs from any single exchange's price. "Can I change the default provider?" Yes, in Admin → Settings. You can pick alternate providers for primary and secondary rate fetches. Most users keep the defaults. "What if I have a transaction in a currency BitBooks doesn't support?" Rare but possible. Contact support to add the currency. As a workaround, you can manually enter the converted value in your functional currency directly, skipping the rate-fetch step. Where to go next - The Three-Currency Model for the broader currency framework - Tracking Bitcoin Value Changes for FX revaluation - Wrong Exchange Rate on a Transaction for fixing rate issues - Multi-Currency Reports for displaying reports in multiple currencies

Lightning vs On-Chain: How BitBooks Handles Both

What "Lightning" and "on-chain" mean Bitcoin has two settlement layers: - On-chain is the main Bitcoin network. Transactions are written to the blockchain. They're settled (with confirmations) within ~10 minutes to an hour. Used for larger amounts. - Lightning is a layer-2 network on top of Bitcoin. Transactions settle in seconds. Used for everyday payments, especially small amounts. A coffee shop typically uses Lightning (5,000 sats for a coffee, paid in 2 seconds). A treasury might use on-chain (moving 5 BTC to cold storage). Many businesses use both. How BitBooks treats them The same. To BitBooks, a Lightning sale and an on-chain sale are both "BTC came in." The accounting is identical: - Wallet balance goes up - Income account (Sales, etc.) goes up by the dollar equivalent - The transaction is recorded with its sat amount, date, and rate The wallet you assign matters (Lightning sales hit your Lightning wallet, on-chain sales hit your on-chain wallet), but the accounting structure is the same. What changes is some metadata: - Lightning transactions have a payment hash and a memo - On-chain transactions have a transaction ID (txid), an address, and a confirmation count BitBooks records what the wallet provider gives us. You don't have to think about it. Settlement and "cleared" status The biggest practical difference is settlement timing. Lightning Lightning payments settle in seconds. By the time they appear in BitBooks, they're effectively final. Cleared status: usually Cleared as soon as it imports. On-chain On-chain transactions need confirmations. Most wallets consider 1 confirmation enough for small amounts and 6+ for large amounts. A pending on-chain receive (0 confirmations) is Not cleared. It becomes Cleared once confirmed enough. A pending on-chain send is also Not cleared until it confirms. If a transaction has 0 confirmations, there's a small chance it never confirms (the network can drop unconfirmed transactions). Treat unconfirmed receives as provisional. Routing fees vs network fees Lightning routing fees Most Lightning wallets pay routing fees on your behalf (the recipient sees the gross amount, the fee is implicit in the path). For a 5,000-sat sale, you typically receive all 5,000 sats and the fee is invisible. For high-volume Lightning operations, you may want to track routing fees as a separate expense. Configure your wallet provider to surface fee data, then create a "Lightning Network Fees" expense account, and post a small entry per fee. Most small businesses ignore this. On-chain network fees On-chain transactions cost network fees, paid in sats. The fee scales with transaction size and current network congestion. When you send on-chain, the network fee is deducted from the amount sent. Example: you send 0.1 BTC, the recipient receives 0.0995, the 0.0005 went to network fees. To record the fee: - Bake it in. Just record the actual amounts sent and received. The fee is implicit. - Itemize. In Advanced Mode, three lines: receiver gets X, network fee is Y, total leaving your wallet is X+Y. Use this if you want fees on the P&L. The fee account would be "On-Chain Network Fees" under expenses (sub-type COST_OF_SALES if Bitcoin operations are central, or G&A if incidental). Different wallets for different layers Most Bitcoin businesses end up with at least two wallets: - A Lightning wallet for daily ops (Blink, Phoenix, Strike) - An on-chain wallet for treasury and larger transactions (Coinbase, hardware wallet, cold storage) BitBooks treats them as separate wallets. Each has its own balance, its own connector (or manual flow), its own sync settings. You can also have a Lightning + on-chain combo wallet that does both (some providers support this). In BitBooks, you'd typically still split it into two wallets if the underlying provider treats them as separate balances. Auto-sync support Currently: - Blink (custodial Lightning + on-chain) is supported via Bitcoin Connections - More providers being added For unsupported wallets (hardware wallets, self-custody software wallets), use Creating a Wallet by Hand and enter transactions manually or via CSV. Common questions "Should I record Lightning and on-chain to the same Sales account?" Either approach works: - One Sales account for all Bitcoin sales, regardless of layer. Simpler. - Two Sales accounts (Sales: Lightning, Sales: On-Chain) if you want to see each on the P&L separately. Useful for analyzing which channel is growing. Pick based on whether the distinction matters to your business decisions. "Do I need to track Lightning channel funding?" Only if you run your own Lightning node. For users of custodial Lightning (Blink, etc.), the provider handles channels and you don't see them. If you run your own node, channel funding is more accounting-aware: opening a channel locks BTC, closing returns it. You'd record these as transfers between your "Cold Storage" wallet and a "Lightning Channel Reserve" wallet. Talk to your accountant if this applies. "What about taproot, sidechains, drivechains, etc.?" These all eventually settle to on-chain Bitcoin. BitBooks treats them like any on-chain transaction: an amount, a date, a wallet. The protocol details don't affect bookkeeping. "What about stablecoins (USDT, USDC) on Lightning?" Some Lightning wallets support stablecoin transactions (Taproot Assets, others). When supported, BitBooks treats them as transactions in their own currency (USDT, USDC), separate from BTC. The wallet would need to expose them as a separate currency-balance. Where to go next - What is a Wallet in BitBooks? for the wallet model - Connecting Your Bitcoin Wallet for auto-sync setup - Recording a Lightning Payment Received for the Lightning entry walkthrough - Cleared, Uncleared, and Reconciled Transactions for confirmation status

The Bitcoin Connections System

What Bitcoin Connections is It's the BitBooks feature that lets you link a wallet provider (Blink today, more on the way) to your books for auto-sync. You set it up once per organization, then any number of wallets can connect through it. If you've already connected a wallet, you've used Bitcoin Connections. This article explains what's happening behind the scenes and the design choices that make it different from other accounting tools. For the step-by-step setup walkthrough, see Connecting Your Bitcoin Wallet. The big design decision: passwords stay on your device Most accounting tools that integrate with bank accounts or wallets do the following: 1. You give them your provider's username and password 2. They store it on their server (encrypted, but they have the key) 3. Their server signs in to the provider on your behalf This works, but it has a real privacy and risk trade-off: the accounting tool's server holds the keys to your wallet. If the server is hacked, attackers get every customer's wallet credentials. BitBooks takes a different approach for wallet credentials specifically: 1. You pick a vault password that locks your wallet credentials 2. The password never leaves your device. Ever. Not even during signup. 3. Your browser uses the password (locally, on your device) to derive a small key 4. That key locks the actual wallet credentials and BitBooks stores the locked version 5. To use the wallet credentials, the browser unlocks them on your device, sends a one-time-use unlock key for that one operation 6. The server never holds the unlocked credentials, never sees your password The trade-off: if you forget your vault password, no one at BitBooks can recover it for you. Your 12-word recovery code is the only way back in. What "vault password" means in practice When you click Add Connection for the first time, BitBooks asks you to pick a vault password. This password: - Is just for your wallet credentials (separate from your sign-in password) - Never leaves your device - Encrypts your wallet sign-in details (Blink password, Coinbase API key, etc.) before they're stored - Is used every time you add a NEW wallet connection (you re-enter to unlock the safe) - Is NOT used for ongoing auto-sync (already-connected wallets keep syncing without re-entry) The password is yours alone. We can't see it. We can't reset it. We can't recover from it if you lose it. If that sounds restrictive: it is, by design. The same trade-off Bitwarden, 1Password, and similar tools make. The 12-word recovery code Right after you set the vault password, BitBooks shows you 12 random English words. This is your recovery code. It's the only backup for the vault password. If you forget the password, the recovery code lets you set a new one and recover access to all connected wallets without losing them. If you lose BOTH the password AND the recovery code, the locked wallet credentials inside the vault are unrecoverable. You'd have to disconnect every wallet and reconnect, signing in to each provider fresh. The wallets themselves and their transaction history stay in BitBooks (no data loss); only the saved sign-in details are gone. Save the recovery code. The article Connecting Your Bitcoin Wallet lists where to save it. What the server actually stores For each Bitcoin Connection, the server stores: - A per-organization random salt (used in the browser-side key derivation; useless without the password) - A password verifier (a hash of the password-derived key; used to fail-fast on a wrong password without holding the password) - The encrypted wallet credentials (only the encrypted form; the unlocked form never reaches the server) - The opaque user ID at the wallet provider (so we know which provider account this connection belongs to) What the server does NOT store: - Your vault password - The unlocked wallet credentials - Your seed phrase (we never see it) - Your provider's master key (we use scoped read-only credentials) If a malicious actor got into the BitBooks server, they'd see the encrypted credentials but couldn't unlock them without the password (which isn't on the server). What happens during a sync When auto-sync runs: 1. Your browser (when you signed in earlier) had derived a per-wallet credentials key from your vault password 2. That credentials key is held in a secure session for the duration of your browser session 3. Sync uses the key to fetch wallet data from the provider 4. The provider returns transaction data 5. BitBooks records the transactions For server-side scheduled sync (when you're not online), the system uses a slightly different mechanism: a long-lived credential held by the provider that's scoped read-only. The vault password isn't needed for these scheduled fetches because the provider's own credential system handles it. The exact mechanism is provider-specific. The principle is consistent: minimize what the server holds, maximize what the user controls. Multiple wallets, one vault You can connect multiple wallets through the same Bitcoin Connections vault. Setup the vault once (with your password). Each subsequent connection just asks you to type your vault password to add the new wallet's credentials to the safe. You don't have a separate password per wallet. One password, one safe, many wallets. This is convenient and scales. It also means: if the vault password is compromised, all connected wallets' credentials are at risk. Pick a strong password. What happens if the underlying provider changes If your wallet provider (Blink, etc.) rotates an API key, changes their authentication system, or has a major breach, you may need to: 1. Reconnect the affected wallet (sign in to the provider again) 2. The reconnection updates the credentials inside your vault (you re-enter your vault password to authorize) 3. Sync resumes This is the normal flow. See Disconnecting or Re-syncing a Connected Wallet. The supported provider list Today: Blink (Lightning custodial). Plus the "xpub" mode for self-custody software wallets where you give us a public key only (we can read addresses, can't move anything). Coming: Strike, Coinbase, Kraken, others. Each one requires custom integration work; we add them based on customer demand. For unsupported providers, you can use manual wallets (no auto-sync, you enter transactions yourself or import CSV). The Bitcoin Connections system is opt-in. Common questions "Why does BitBooks use this complicated flow instead of just storing my Blink password?" For privacy. The server never sees your provider credentials. Most accounting tools choose convenience over this; we chose privacy where we could. "Can my BitBooks team see my wallet credentials?" No. The credentials are encrypted under your vault password, which only you have. Even other team members in your organization can't see them (each member has their own browser-side derivation). "What if BitBooks goes out of business?" The wallet data in your books is yours and exportable. The provider connections are just a fast way to import transactions; you'd lose those connections, but the underlying wallets at the providers (Blink, etc.) are unaffected. You'd reconnect to a new tool or do manual entry. Where to go next - Connecting Your Bitcoin Wallet for the setup walkthrough - Disconnecting or Re-syncing for managing connections - How Auto-Sync Works for the sync mechanics - Bitcoin Connection Sync Stopped Working for sync error recovery

Setting Spending Limits per Wallet

What spending limits do Spending limits are rules you set on a wallet that block transactions exceeding a threshold. If someone (or an auto-sync) tries to record a transaction that would violate the limit, BitBooks rejects it before it posts. The goals: - Prevent typos. Catching a $50,000 transaction that should have been $5,000 before it pollutes your books - Limit blast radius. If a team member's account is compromised, an attacker can't drain a wallet to zero through one big entry - Enforce policy. "No single transaction from the hot wallet over $10,000" becomes an enforced rule, not a hopeful guideline This is more important for Bitcoin than for traditional banking because Bitcoin transactions are usually irreversible. Once you send sats, they're gone. Limits prevent the catastrophic version of "oops." Where the limits live Currently, BitBooks supports an organization-wide approval threshold that applies to all transactions: - Approval threshold currency (e.g., USD) - Approval threshold amount (e.g., $10,000) Any transaction at or above this amount triggers an approval requirement before it can post. Set in Admin → Settings. Admin Settings showing the Approval Threshold Currency and Amount fields If you're below the threshold: the transaction posts normally. If at or above: the transaction lands in a Pending Approval state. An authorized user (Owner, Admin, or Accountant) needs to approve before it becomes Posted. Per-wallet limits (different thresholds per wallet) and per-day rolling limits are on the roadmap. For now, the org-wide threshold is the lever you have. How approval works When a transaction hits the threshold: 1. The user fills out the form normally 2. They click Save (or Save and post) 3. BitBooks sees the amount exceeds the threshold 4. The transaction lands as Pending Approval (a status between Draft and Posted) 5. Notifications fire to authorized approvers 6. An approver opens the transaction, reviews, clicks Approve 7. The transaction becomes Posted If the approver clicks Reject, the transaction is canceled. The submitter is notified and can re-create with corrected fields if needed. Setting the threshold 1. Admin → Settings 2. Find Approval Threshold Currency (pick one currency, e.g., USD) 3. Find Approval Threshold Amount (e.g., 10000) 4. Save The threshold applies to all transactions, regardless of which wallet's currency they're in. BitBooks converts the transaction's amount to the threshold currency using the rate at the transaction date, and compares. So a 0.15 BTC transaction at a moment when 1 BTC = $80,000 has a USD-equivalent of $12,000. If your threshold is $10,000 USD, this triggers approval. Set the threshold to a number that's high enough that day-to-day transactions sail through, but low enough that genuinely-large entries get a second pair of eyes. Disabling the threshold To turn off the approval requirement: clear the Approval Threshold Amount (or set it to zero) in Admin → Settings. All transactions then post directly without approval. This is useful when you have a small team where a single person is doing all the work and approval would just be self-approval. What approval doesn't do - It doesn't catch unauthorized small transactions. A pattern of $9,999 transactions stays under the threshold and posts directly. For pattern detection, you'd want monitoring tools beyond simple thresholds. - It doesn't add friction to auto-sync. Auto-imported transactions land as Drafts. Drafts don't post automatically; you review and post. The approval threshold applies when you (or a team member) tries to post a Draft above the threshold. - It doesn't prevent disconnection or settings changes. Approval is for transaction posting, not for organization-level changes. Those have their own role-based permission system. Common questions "Can I have a threshold per wallet (different rule for hot vs cold)?" Not yet. The threshold is org-wide. Per-wallet rules are on the roadmap. "Can I require approval from a specific person, not just anyone in an admin role?" Not yet. Any user with approval rights can approve. Specific routing (e.g., "the controller approves; the bookkeeper can't") is on the roadmap. "What if I'm the only person in my org? Approval would just be me approving myself." Set the threshold to a very high number (or zero) to effectively disable approval. For solo operators, the threshold mostly doesn't help. It becomes meaningful when you have at least two people. "Will approval slow down auto-sync?" No. Auto-sync creates Drafts, and Drafts don't trigger approval until you (or a team member) tries to post them. Sync is independent. "What happens to a Pending-Approval transaction if I leave it forever?" It sits there. Doesn't auto-post, doesn't auto-reject. Approver decides. Where to go next - Inviting Team Members for setting up the team that can approve - User Roles for which roles have approval rights - Audit Log to see who approved what and when - Draft vs Posted for the entry lifecycle including Pending Approval