Multi-Currency

The Three-Currency Model Explained

The short answer Most businesses operate in one currency. But a Bitcoin business inherently operates in at least two (your home currency and BTC), and many also report in a third (a parent company's currency, an investor's currency, etc.). BitBooks handles all of this with three currency "slots": | Slot | Purpose | Required? | |---|---|---| | Transactional | The currency a specific transaction actually happened in | Per transaction | | Functional | Your books' main currency. Reports default to this. | Yes (one per organization) | | Reporting (secondary) | A second currency that shows alongside the functional currency on reports | Optional | That's the three-currency model. Let's unpack each one with examples. Why three? Imagine a Canadian Bitcoin business. It mostly operates in Canadian dollars: rent is in CAD, salaries are in CAD, the bank account is in CAD. But it also accepts Lightning payments in BTC, occasionally invoices a US customer in USD, and reports to a US parent company that wants to see everything in USD. In a system that only understands one currency, you'd be doing manual conversion all over the place. Someone paid you 0.05 BTC? You convert to CAD, lose the original BTC information. Now your books say "you received CAD$3,000," but your accountant looking back at year-end has no record that this was actually a Bitcoin payment, no Bitcoin gain/loss tracking, no trail of the original transaction. The three-currency model keeps all three numbers without losing any. Slot 1: Transactional currency This is the currency the transaction actually happened in. A coffee customer paid you 12,500 sats? The transactional currency is BTC, the amount is 12,500 sats. You wired CAD$5,000 to a vendor? Transactional currency is CAD, amount is 5,000. You bought office supplies in pesos on a business trip? Transactional currency is MXN, amount is whatever you paid. The transactional currency stays attached to the original transaction forever. It never gets lost or overwritten. Slot 2: Functional currency The functional currency is your organization's main currency. It's the currency you think in, do most of your business in, and want your books to be denominated in. For a US-based business, this is almost always USD. For a Canadian business, CAD. For a UK business, GBP. For a European business, EUR. For a pure Bitcoin treasury company, BTC. You set this once, when you create your organization (see Setting Up Your First Organization). What the functional currency does: - It's the default currency for new transactions when you don't specify one - Reports (P&L, Balance Sheet, etc.) default to displaying numbers in this currency - When transactions in other currencies happen, BitBooks converts them to the functional currency at the appropriate exchange rate - Tax filings (which are typically in your home currency) use this currency Example. If your functional currency is USD and you record a transaction for €1,000 EUR, BitBooks looks up the EUR/USD rate at the transaction date and stores both: the original €1,000 and the converted USD equivalent (say $1,080). Reports in USD show $1,080. If you ever need the original EUR back, it's still there. Slot 3: Reporting (secondary) currency The reporting currency is an optional second currency that shows alongside your functional currency. When would you use this? - Canadian business reporting to a US parent. Functional CAD, Reporting USD. - European subsidiary of a UK group. Functional EUR, Reporting GBP. - Bitcoin-functional treasury that wants to show USD equivalents. Functional BTC, Reporting USD. - Stakeholder communication. Investors who think in USD even if you operate in CAD. When set, every report shows two numbers per line: the functional value and the reporting value, side by side. Stakeholders can read either one and be on the same page. If you don't have a use case, leave the reporting currency blank. You can always add one later. A worked example Let's run through a single transaction in a Canadian business with these settings: - Functional currency: CAD - Reporting currency: USD You receive a Lightning payment of 0.0008 BTC from a customer. What gets stored: - Transactional currency: BTC - Transactional amount: 0.0008 BTC - Exchange rate at the time: 1 BTC = $90,000 CAD = $66,000 USD - Functional value: 0.0008 × $90,000 = $72.00 CAD - Reporting value: 0.0008 × $66,000 = $52.80 USD What appears on reports: - A P&L in CAD: shows $72.00 in revenue - A P&L in USD (the reporting currency view): shows $52.80 - The transaction detail page: shows all three (BTC, CAD, USD) with the exchange rates BitBooks used You never lose information. Anyone reading the books can answer: how much BTC did we receive? How much was that in CAD? How much in USD? All three answers are there. Setting your functional currency Done at organization setup. To change later: 1. Go to Admin → Settings 2. Find Primary accounting currency 3. Pick a new value 4. Click Save If your organization already has transactions, BitBooks will ask for an effective date and an audit reason (a free-text explanation of why the change is happening). This is required by accounting standards: a functional currency change is a material event that affects how historical numbers are interpreted. Admin Settings showing the primary currency dropdown and the audit-reason text area that appears when changing After the change, transactions before the effective date keep their old functional value. Transactions on or after the effective date use the new functional currency. Reports clearly indicate when the change happened. Setting your reporting currency Same place, Admin → Settings. Find Secondary reporting currency. Pick one (or "None"). Click Save. Unlike the functional currency, you can change the reporting currency at any time without an audit trail. It's a display preference, not an accounting decision. How exchange rates are picked BitBooks fetches exchange rates from external providers. For fiat-to-fiat conversions (USD/EUR, CAD/USD, etc.), the default provider is Open Exchange Rates. For Bitcoin pricing, CoinGecko is the default. Each transaction is "rate-pinned" at the moment of posting. That means: the rate used at the time of posting is saved with the transaction and never changes, even if the live rate changes later. This is required for accurate accounting (you can't retroactively change historical rates). If a rate provider is temporarily unavailable, transactions might land in a "Pending rate" state, meaning the conversion hasn't been resolved yet. BitBooks shows a warning at the top of the Transactions and Journal Entries pages when this happens, with a "Retry pending" button to refetch. Banner across the top of Transactions page reading "X rates pending" with a Retry button Common questions "My functional currency is BTC. How does that work for tax filings?" Most jurisdictions require tax filings in the local fiat currency. If you're functional in BTC, you'll need to convert to your home currency (USD, CAD, etc.) for tax purposes. Setting a reporting currency to your local fiat keeps that view always available, ready to export. "Can I change a single transaction's exchange rate?" Yes, on the transaction detail page, but only while the transaction is a Draft. Once Posted, the rate is locked. To correct a posted transaction's rate, reverse it and post a corrected version. "Why is my BTC balance value changing every minute?" That's the live BTC price moving, which BitBooks displays on the Insights page in your reporting currency. Your actual BTC balance (the number of sats or BTC) doesn't change. Only its dollar equivalent fluctuates as the market moves. Where to go next - Setting Your Functional Currency for the deeper how-to - How Exchange Rates Work in BitBooks for the rate-fetching mechanics - Tracking Bitcoin Value Changes for FX revaluation runs (capturing unrealized gains and losses) - BTC Display Modes if you want to change how BTC amounts appear on screen

Setting Your Functional Currency

What functional currency is The functional currency is your organization's main currency. Reports default to it. Tax filings use it. When transactions in other currencies happen, BitBooks converts to it. Most US businesses pick USD. Most Canadian businesses pick CAD. Most UK businesses pick GBP. Pure Bitcoin treasuries sometimes pick BTC. Whichever currency you primarily think and operate in. Each organization has exactly one functional currency. You set it at organization creation (with a sensible default), and you can change it later if needed (with extra steps). For the broader picture, see The Three-Currency Model Explained. Picking the right one A few questions to ask: What currency do you bill customers in? If most of your invoices are in USD, your functional currency is USD. If you're a Canadian business billing Canadian customers in CAD, that's CAD. What currency do you pay your costs in? If your rent, salaries, and software bills are in CAD, that's CAD-functional even if you also have some Bitcoin operations. What currency does your tax authority require? Most countries require tax filings in their national currency. If you're in the US, USD is the safe pick. Canada, CAD. The functional currency aligns nicely with tax reporting if it's your home currency. Can I pick BTC? Yes. Some Bitcoin treasuries pick BTC as functional. Their books are denominated in BTC, with USD as a secondary reporting currency for stakeholder views. This is a valid choice if your operations are largely Bitcoin-denominated. For most small businesses operating in fiat, USD/CAD/EUR is more practical. How to set it at creation When you create a new organization (Admin → Organizations → Add Organization), the wizard asks for: - Functional currency type: FIAT or BITCOIN - If FIAT: the specific code (USD, EUR, CAD, etc.) Pick and save. The organization is now operating in that currency. Org creation wizard step 1 with the functional currency dropdown You can change later if needed, but get it right initially when possible. Where the functional currency shows up After setup, the functional currency drives: - The default currency for new transactions when you don't specify one - The functional value calculated for every transaction (BitBooks converts the transactional currency to functional using the rate at the transaction date) - The default currency for reports (P&L, Balance Sheet, etc.) - The threshold currency for approval limits (in some configurations) - Tax-friendly export formats You'll see your functional currency labeled explicitly in many places: report headers, settings, the organization summary. Changing the functional currency later Possible but more involved than just picking a new value. See Changing Your Functional Currency After Going Live for the full flow. The short version: 1. Go to Admin → Settings 2. Change the Primary accounting currency dropdown to the new value 3. BitBooks asks for an effective date (when the change takes effect) 4. BitBooks asks for an audit reason (a free-text explanation of why) 5. Save After save: - Transactions before the effective date keep their old functional value - Transactions on or after the effective date use the new functional currency - Reports are clearly labeled showing the change This is required by accounting standards. A functional currency change is a material event; the audit trail makes it visible to anyone reading historical reports later. Functional vs Transactional currency Don't confuse the two: - Transactional currency = the currency a specific transaction happened in - Functional currency = your books' main currency A USD-functional business can have transactional entries in EUR, BTC, GBP, CAD, etc. Each transaction stays in its native (transactional) currency, AND BitBooks computes the equivalent functional value (USD). So if you run a USD-functional business and receive €1,000: - Transactional: €1,000 EUR - Functional: $1,080 USD (using the EUR/USD rate) Both are stored. Reports default to USD. Detailed views show both. Functional currency for Bitcoin businesses Most Bitcoin businesses are functional in their local fiat (USD, CAD, etc.) and just have BTC as one of many transactional currencies. The Bitcoin operations show up as BTC-denominated transactions converted to USD on reports. Functional-in-BTC is a niche choice. It makes sense if: - Your reserves are denominated in BTC and you think of value in BTC - Your cost structure is in BTC (rare; most labor and rent are fiat) - You're explicitly a "Bitcoin treasury" company Functional-in-BTC has a few quirks: - Tax filings will need to be translated to your local fiat (BitBooks does this through the reporting currency) - Day-to-day fiat costs (paying staff, paying rent) appear as foreign-currency transactions converted to BTC - The BTC display modes (Sats, BTC, etc.) become more central If you're not sure, start with your local fiat. You can always change later. Common questions "Can I run two organizations with different functional currencies?" Yes. Each organization is independent. One can be USD-functional, another CAD-functional, a third BTC-functional. Switch between them in the sidebar dropdown. "What happens if I have transactions before the change date in the new currency?" After a functional currency change, BitBooks shows historical transactions in their original functional currency context. New reports cover both ranges with appropriate labels. Talk to your accountant about how to present mid-year changes; they may want to provide both pre-change and post-change views. "Why does this need an audit reason?" A functional currency change affects how readers interpret historical numbers. The audit reason makes it explicit: why was this changed, by whom, and when. Required by IFRS and GAAP for material accounting changes. Where to go next - The Three-Currency Model Explained for the broader currency framework - Setting Your Reporting Currency for the optional secondary view - Changing Your Functional Currency After Going Live for the change flow - How Exchange Rates Work in BitBooks for rate fetching

Setting Your Reporting Currency

What the reporting currency is The reporting currency is an optional second currency that shows alongside your functional currency on reports. Your books stay in your functional currency (USD, CAD, EUR, etc.). The reporting currency is a parallel display: every line on every report can also be shown in the reporting currency, translated using the exchange rate at the report's date. It's the answer to "I do business in CAD but my parent company wants to see USD." For the broader picture, see The Three-Currency Model Explained. When to set one Common cases: - Cross-border parent. Canadian sub reporting to US parent. Functional CAD, Reporting USD. - International investors. UK business with US investors. Functional GBP, Reporting USD. - Bitcoin-functional + fiat reporting. A treasury company that books in BTC but stakeholders think in USD. Functional BTC, Reporting USD. - Multinational consolidation. A group of subs that all report in the parent's currency. If none of these apply: skip it. Functional currency alone is enough. Most small businesses don't set a reporting currency. How to set it 1. Admin → Settings 2. Find Secondary reporting currency 3. Pick from the dropdown (USD, EUR, GBP, CAD, AUD, CHF, CNY, etc.) or leave blank for none 4. Save The change applies immediately. Reports now offer a toggle between functional and reporting currency display. Admin Settings showing the Secondary reporting currency dropdown Where it appears Once set, the reporting currency shows up: - On the Insights page, KPIs and balances can be shown in either currency - On reports (P&L, Balance Sheet, etc.), there's a currency toggle at the top - On wallet snapshots, balances are shown in their native currency with the reporting currency equivalent in smaller text - On exports (PDF, Excel), the reporting currency view is selectable You're never forced to use one or the other. The toggle lets you flip. How translation happens The reporting currency view is a translation of the functional currency numbers, not a re-recording. For each report: - BitBooks looks up the functional → reporting rate at the report's end date - Multiplies every functional value by that rate - Displays the result The underlying entries don't change. They keep their original transactional and functional values. Only the display is translated. This is consistent with how IFRS and GAAP handle reporting-currency translation. The functional currency is the "real" denomination; the reporting currency is a convenience view. Which rate is used For a Balance Sheet "as of December 31," the rate used is the December 31 rate (the closing rate). For a P&L "for January through December," there's a choice: - Closing rate (the rate at December 31). Simple but introduces some FX distortion in the P&L. - Period average (the average rate over the period). More accurate for income statement translation under some standards. - Historical per transaction (each transaction translated at its own date's rate). Most accurate but computationally heavier. The default is Historical per transaction. You can change in Admin → Settings under FX translation method. Changing the reporting currency Unlike the functional currency, the reporting currency can be changed any time without an audit reason. It's a display preference. 1. Admin → Settings 2. Pick a different reporting currency or set to None 3. Save All historical reports re-translate using the new currency. No data changes; just the display. Common scenarios Canadian sub reporting to US parent - Functional: CAD - Reporting: USD - Books are kept in CAD (matches Canadian operations) - Parent sees consolidated reports in USD with CAD as detail Bitcoin treasury with fiat investors - Functional: BTC - Reporting: USD - Books are denominated in sats and BTC (matches treasury thinking) - Investors see USD equivalents alongside Multi-currency e-commerce - Functional: USD (where the business is incorporated) - Reporting: EUR (for the European shareholder block) - Three-way visibility: USD on the books, EUR for the shareholders, transactional currencies preserved per entry What the reporting currency does NOT do - It doesn't change tax filings. Most jurisdictions require filings in the local currency. Use the functional currency view for those. - It doesn't add a new column to every transaction. It's a translation at the report level. - It doesn't affect how new transactions are entered. You enter transactions in the wallet's native currency. The reporting display computes from the functional value. Common questions "Why is my Balance Sheet's functional total slightly different from the reporting total?" Translation at different rates. Each line's reporting value is computed using the line's rate. Aggregating produces a slightly different total than translating the aggregate. This is normal and expected; small differences are accounting-standard-acceptable. "Can I have two reporting currencies (one for Europe, one for the US)?" Not yet. One reporting currency at a time. Workaround: switch the reporting currency for each export. "How do I export a report in the reporting currency?" On the report, toggle to reporting currency, then click Export. The exported PDF/Excel reflects the displayed currency. Where to go next - Setting Your Functional Currency for the primary currency choice - The Three-Currency Model for the broader framework - How Currency Conversion Works for the rate mechanics - Multi-Currency Reports for the detailed report-level view

How Currency Conversion Works

The conversion rule Whenever a transaction's transactional currency differs from your functional currency, BitBooks converts it. The rule is simple: Functional value = Transactional amount × Exchange rate at the transaction's date The rate is "pinned" to the transaction. It's stored permanently with the entry. Future rate changes don't affect the historical conversion. A worked example Functional currency: USD. You receive a transaction: - Transactional currency: EUR - Transactional amount: €1,000 - Date: 2026-04-15 - EUR/USD rate at 2026-04-15: 1.08 Conversion: Functional value = €1,000 × 1.08 = $1,080 The transaction is stored with both: - €1,000 (transactional) - $1,080 (functional) Reports default to the functional view ($1,080). The detail view shows both. Where rates come from For fiat-to-fiat conversions: Open Exchange Rates by default. For Bitcoin pricing: CoinGecko by default. You can change providers in Admin → Settings, but defaults work for everyone. See How Exchange Rates Work in BitBooks for the rate-fetching mechanics. When the rate is pinned The rate is locked in at one of three moments, depending on the transaction: 1. At post time for transactions that go straight to Posted status. The rate at that moment is recorded. 2. At creation time for Drafts. When you save a Draft, BitBooks fetches and stores the rate based on the date you set. Even if you wait 3 weeks before posting, the rate stays at the original date's rate. 3. At rate-resolution time for transactions whose initial fetch failed. If a transaction was created with a "pending" rate, the rate is fetched later when you click Retry. The pinned rate is the one resolved at retry, not at the original create time. (This is rare and usually only matters for stale rates.) Once pinned, the rate doesn't change. Subsequent market movements don't affect historical entries. The "rate timestamp" Each line of a journal entry has a rateTimestamp: the moment whose rate was used. Usually equal to the transaction's date and time. For day-bucket rates (most fiat): timestamp 2026-04-15T00:00:00Z gives the rate for April 15, regardless of the actual hour. For 5-minute-bucket rates (BTC): timestamp 2026-04-15T14:23:00Z gives the rate for that 5-minute window. If you want to verify the rate used on a transaction, click into the entry's detail and look at the rateTimestamp and exchange rate fields. Multi-currency journal entries A journal entry can have lines in different currencies. The journal entry has a header currency (the default for new lines) and individual line currencies that can override. For balance: the functional totals of debits and credits must equal. So a line of 0.1 BTC might balance against a line of $9,000 USD if 0.1 BTC happens to equal $9,000 in functional terms at that date. The transactional totals don't have to balance. (You can't add 0.1 BTC and $9,000 directly; they're different units.) The functional totals are what BitBooks checks. Multi-currency journal entry showing BTC and USD lines with the functional total at the bottom in green ("Balanced") Manual rate override If the auto-fetched rate is wrong (you got a slightly different rate at the actual point of trade, e.g., an exchange's bid/ask spread), override: 1. In a journal entry, click into the rate field next to a non-functional currency line 2. Enter the rate you actually used 3. Save The line's stored rate is yours. The conversion uses your value. The override is recorded for audit so anyone reading later can see "manual rate used" and what it was. For quick everyday transactions, don't bother. Use the auto rate. Manual override is for the cases where exact accuracy matters. Conversion in reports Reports compute their numbers from the functional values stored on each entry's lines. The reporting currency view (if set) re-translates from functional to reporting at the report's reference date. So a P&L for January 2026 in USD-functional shows numbers as the entries had them at the time. If you have a reporting currency of EUR, you can toggle to EUR and the report re-translates using the USD/EUR rate at January 31. This is a two-step translation: transactional → functional (at transaction time, locked) → reporting (at report time, recomputed). Conversion and gain/loss Conversion itself doesn't create gain/loss. The conversion is just a way to express the same transaction in a different currency. Gains and losses arise from: - Holding non-functional assets that change value (you hold BTC, BTC's price moves, you have unrealized gain/loss) - Settling at a different rate (you owe €1,000 booked at $1,080, you pay when EUR/USD rate has moved to 1.10, the actual cost is $1,100, you have a $20 FX loss) Both are handled by Tracking Bitcoin Value Changes (FX Revaluation) and similar mechanisms for foreign currency exposure. Common questions "My converted amount looks wrong by a few cents." Likely a rate-bucket alignment issue or a rounding artifact. Each line is computed independently; aggregating can produce small rounding differences from "the obvious answer." This is normal accounting behavior, not a bug. "Can I see what rate BitBooks used on a specific transaction?" Yes. Open the transaction's detail page (or click through to its underlying journal entry). The line shows the rate, the rate source provider, and the rate timestamp. "Why does my report say a total in USD when the transactions were all in BTC?" If your functional currency is USD, the report displays in USD using the conversion. The underlying transactions are still in BTC. Click any number to drill into the underlying entries to see both views. Where to go next - How Exchange Rates Work in BitBooks for the rate provider mechanics - The Three-Currency Model for the broader framework - Tracking Bitcoin Value Changes for the gain/loss handling - Setting Your Functional Currency and Setting Your Reporting Currency for the configuration

Changing Your Functional Currency After Going Live

When this happens You set up your organization with one functional currency, but circumstances changed. Common cases: - Your business expanded internationally and most operations are now in a different currency - You started in fiat and have transitioned to a Bitcoin-functional treasury - You realized at setup time you picked the wrong currency - Your accountant recommends a change for tax or reporting reasons This is a real but uncommon event. Most businesses set the functional currency once and never change it. Before you change A few things to do first: 1. Talk to your accountant. A functional currency change is a material accounting event. Get advice on whether and when to make the change, and how to handle it on your tax filings. 2. Reconcile and close any open periods. Make sure your books are clean before the switch. 3. Pick an effective date. The change needs an effective date. Common: the start of a fiscal year, the start of a quarter, or the date of the operational change that prompted the switch. 4. Document the reason. You'll need to provide a written audit reason in BitBooks. Think about what you'll write before you click. Don't make this change in the middle of tax season or on the day you're about to send reports to investors. How to change 1. Go to Admin → Settings 2. Find the Primary accounting currency dropdown 3. Pick the new value (or change the functional currency type from FIAT to BITCOIN, or vice versa) 4. The save button surfaces additional fields: Effective date and Audit reason 5. Fill in both 6. Click Save Admin Settings showing the currency dropdown changed and the audit-reason text area below The audit reason needs at least 40 characters. This isn't a hurdle for hurdle's sake; it's the minimum for a meaningful explanation. Examples of good audit reasons: - "Business is now primarily operating in EUR following acquisition by European parent. CFO approved on 2026-04-15. Effective date matches fiscal year start." - "Switching to BTC functional reflects treasury reserve restructuring. All ongoing operations are in BTC; fiat reporting handled via secondary reporting currency. Approved by board 2026-03-22." - "Initial setup mistakenly used USD instead of CAD. Business has always been Canadian-operating. Correcting from go-live date." What happens after the change Transactions before the effective date They keep their old functional currency. The functional values calculated under the old currency stay frozen. Transactions on or after the effective date They use the new functional currency. New entries posted from now on are denominated in the new currency. Reports Reports for periods entirely before the change use the old currency. Reports for periods entirely after the change use the new currency. Reports that span the change date are more complex; talk to your accountant about how to present them. BitBooks will show a notice indicating the change happened during the period. Underlying data The transactional currencies on each entry don't change. They were always whatever they were (BTC, EUR, etc.). What changes is the functional translation: pre-change entries translated under the old functional currency, post-change under the new. A worked example You're a Canadian sub of a US parent. You've been running CAD-functional. The parent acquires another business in the US and reorganizes; you're now reporting US-side directly. You decide to switch to USD-functional, effective 2026-07-01 (start of Q3). Before the change: - Functional: CAD - Q1 and Q2 reports: in CAD - 1,000 entries in the books After the change: - Functional: USD (effective 2026-07-01) - Q3 entries onward: in USD - Q1 + Q2 reports stay in CAD (historical record) - Q3 + Q4 reports are in USD - A 12-month "year to date" report at year-end requires combining; talk to your accountant about presentation What can prevent the change A few things would block or warn: - Open periods with unresolved entries. Reconcile and close before changing. - Pending exchange rates that haven't resolved. Retry pending rates first. - Unbalanced books. Run the Trial Balance; fix any imbalance first. - No audit reason provided. The form requires a reason of at least 40 characters. If BitBooks shows an error when you try to save, fix the underlying issue and retry. What if your org has no transactions yet? If you set up an organization, picked the wrong currency, and haven't entered anything, the change is no big deal. BitBooks recognizes that an empty org's currency change doesn't have audit implications. It allows the change without the audit reason gate. You'll see a different (simpler) save flow if your org is empty. Just pick the new currency and save. Currency change form on an empty org showing only the dropdown without the audit fields What can't be undone After a change, you can change again (back to the original currency, or to a third currency). Each change is a new event with its own effective date and audit reason. Both stay in the audit trail. You can't "delete" a past change. The history of changes is permanent. Common questions "Will my Bitcoin holdings revalue?" The Bitcoin amounts (in sats) don't change. The functional-currency representation does. Going from CAD to USD means BTC balances are now translated to USD instead of CAD. You may want to run an FX revaluation around the change date to formally book the impact. "Will I lose my historical reports?" No. Historical reports stay computable. They display in the functional currency that was effective during their period. The underlying entries are unchanged. "What if my year-end is right around the change?" Best practice: change at the start of a fiscal year, not mid-year. This avoids the awkward year-spanning translation. If you must change mid-year, talk to your accountant about how to present the year-end report. Where to go next - Setting Your Functional Currency for the initial setup - The Three-Currency Model for the broader framework - Tracking Bitcoin Value Changes if a revaluation is needed - Period Close for closing periods cleanly before the change