Home Transactions & Journal Entries

Transactions & Journal Entries

Recording what happens in your business.
By Miguel Abascal
• 12 articles

Draft vs Posted: What's the Difference?

The short answer Every entry in BitBooks (whether it's a transaction or a journal entry) lives in one of four states: | Status | What it means | Can you change it? | |---|---|---| | Draft | Started but not finalized, like writing in pencil | Yes, freely | | Posted | Finalized, like writing in pen | No (you reverse, you don't edit) | | Approved | Posted and approved by an authorized user | No | | Reversed | Was posted, then undone with a reversing entry | No (the reversal is permanent too) | The most important distinction is Draft vs Posted. The other two are variations of Posted. Why this matters (the "why" first) Imagine you're keeping the books for a coffee shop. On Monday you start typing in the weekend's sales. Coffee, pastries, tips. You get to one sale and realize you don't remember whether the customer paid in cash or by card. You leave the entry half-finished and go check the receipt drawer. Now: should that half-finished sale show up in the books? If yes, your Monday morning P&L includes a sale you haven't actually verified. Your balance is off. Your accountant sees a number that isn't real. If no, you're free to leave it incomplete, fix it later, and only commit it to the books once you're sure. That's what Draft means. Drafts are work in progress, hidden from your real numbers. They sit in BitBooks waiting for you to finish them, but they don't affect your reports until you say so. Posted is the opposite. Posted means you've reviewed it, you're sure, and it's part of the permanent record. Once posted, an entry becomes part of your real books. It's included in every report, the basis for tax filings, the source of truth. Different rules for different stages of certainty. That's the whole idea. What each status looks like Draft You see Drafts everywhere, on the Transactions page, on the Journal Entries page, in lists. They're marked with a Draft badge. Transactions table row with a Draft badge highlighted What's true about a Draft: - It's saved (you can leave the page and come back to it) - It's invisible to your reports (P&L, Balance Sheet, Trial Balance, none of them include Drafts) - It can be edited freely. Change any field, update the amount, add a memo, switch the wallet - It can be deleted. If you decide it's not real, just delete it When entries land as Drafts: - Auto-imports from Bitcoin Connections start as Drafts. You review, then post. - Bulk imports from CSV or QuickBooks start as Drafts. - Anything you create with "Save and continue" instead of "Save and post" stays as a Draft. Posted A Posted entry has been committed to the books. What's true about a Posted entry: - It shows up on every relevant report - It can't be edited (the values are now permanent) - It can't be deleted (you'd lose the audit trail) - It can be reversed, which creates a new, opposite entry that cancels out the original. Both stay in the record. What you can still change on a Posted entry, with limits: - Memo: yes, you can update the memo (it's a note, not a number) - Attachments: yes, you can attach a receipt after posting - Contact: yes, you can re-link to a different vendor or customer (the system tracks this in the audit log) - Amount, date, accounts, currencies: no. Those are the actual accounting values. To change them, you reverse the original and post a new entry. Posted journal entry detail view, with "Reverse" button visible Approved Some organizations require a second person to approve an entry after it's posted. This is common for: - Large amounts - Sensitive accounts (e.g., owner draws, salary) - Operations where one person enters and another reviews If your organization uses approvals, you'll see an Approve action on Posted entries. After someone approves, the status changes from Posted to Approved. From a numbers perspective, Approved is the same as Posted. Both are part of the books. The difference is the paper trail showing two people signed off. Reversed When you reverse a Posted entry, BitBooks creates a second, opposite entry that cancels out the first. Both entries stay visible. Why both? Because the audit trail matters. If you just deleted the original, anyone reading the books later (your accountant, an auditor, the IRS) wouldn't know it had ever existed. With a reversal, the original is preserved, and the reversal makes it clear what happened: "This was wrong, and here's the correction." After a reversal, the original entry's status flips to Reversed, and the new entry shows a link back to it. Reversed entry showing the link to the reversal entry, like a chain icon A real example Here's how a typical entry flows through these states: Monday, 9 AM The Blink connector imports yesterday's sales. Six new transactions land in your Transactions page, all marked Draft. Monday, 9:15 AM You open the first one. The amount is right (12,500 sats received from a customer). The date is right. But the contact is blank. Blink doesn't know who paid you. You set the contact to "Cash Customer" (a generic catch-all). You set the category to "Sales, Coffee." You click Save and post. Status: Posted. The 12,500 sats now show up in your P&L for Monday under Sales. Monday, 9:20 AM Same thing for the next five transactions. Tuesday, 2 PM You realize one of yesterday's posts had the wrong amount. You had categorized a 50,000-sat tip as a sale when it was actually a tip (a different account). The Posted entry is locked. So you click Reverse. BitBooks creates a reversing entry that cancels out the original. The original's status changes to Reversed. You then create a new entry with the right account ("Tips Received") and post that. Result: your books are now correct, and there's a permanent trail showing what happened. When you'd use each status deliberately Save as Draft when: - You're not sure about a detail (the contact, the category, the amount) - You're entering a batch of transactions and want to review them all before committing - You're handing the entries to a bookkeeper for review - You want to attach a receipt before posting Post immediately when: - The entry is straightforward and you've reviewed it - It's coming from a trusted source (an auto-sync, a CSV import you've already validated) - You're ready for it to show up on reports Reverse instead of editing when: - You discover a Posted entry was wrong - The original was already used in a report you sent out (so you need a paper trail of the correction) How posting works in BitBooks You'll see these options on most save buttons: - Save: saves as Draft (or whatever the current status is) - Save and post: saves and immediately posts - Save and new: saves and clears the form for the next entry You can also post several Drafts at once. On the Transactions or Journal Entries page, tick the rows you want, then click Bulk Post. Useful at month-end when you have a stack of imports to commit. Transactions table with multiple rows ticked and the Bulk Post button visible at top Common confusions, cleared up "If a Draft doesn't show on my reports, why does it exist?" So you can prepare entries before they're real. Without Drafts, every entry would either be live immediately (which means typos and half-finished entries pollute your books) or live nowhere (which means you can't save your work). Drafts give you a safe staging area. "Can I edit a Posted entry's amount if I notice a typo right after posting?" No, even if it was 5 seconds ago. The whole point of "Posted" is that the amount stops being changeable. Reverse it and re-post with the correct amount. "What if my whole month was wrong? Do I have to reverse 200 entries?" Practically, no. That's painful. Talk to your accountant and to support. Often the right move is to make a smaller number of correcting entries that net to the right total. That's how a real-world accountant fixes a category-wide mistake. "Why can't I delete Posted entries?" Because the books are supposed to be permanent. If you could delete entries, anyone could "fix" history by erasing inconvenient ones. The reversal pattern is a stronger compromise. You can correct anything, but the original always stays visible. Where to go next - See Creating a Transaction for how to make new entries - See Bulk Posting Drafts for the month-end cleanup workflow - See Reversing a Posted Entry for the full reversal procedure - See Period Close for how to lock everything before tax time

Last updated on May 03, 2026

Creating a Transaction (Simple Mode)

Simple Mode vs Advanced Mode BitBooks gives you two ways to record what happened: - Simple Mode is the Transactions page. You fill in a form (wallet, amount, what it was for) and BitBooks figures out the accounting bookkeeping behind the scenes. Designed for people who don't want to think about debits and credits. Perfect for daily entry. - Advanced Mode is the Journal Entries page. You write the debits and credits yourself. Designed for accountants and bookkeepers who want full control. Both arrive at the same place. They produce the same entries in the books. The form is just different. This article is about Simple Mode. For Advanced Mode see Creating a Journal Entry (Advanced Mode). When Simple Mode is the right choice Use Simple Mode for: - A customer paid you (cash or Bitcoin) - You paid a vendor - You bought something with the company card - You moved money between two of your own wallets - Any everyday transaction where one wallet is involved Skip Simple Mode and use Advanced Mode for: - Adjustments where neither side is a wallet (e.g., depreciation, accruals) - Multi-line journal entries that touch 3+ accounts in unusual ways - Year-end closing entries Step by step Step 1. Open the Transactions page Click Transactions in the left sidebar. Sidebar with Transactions item highlighted, transactions table visible You'll see a list of recent transactions. To create a new one, click New Transaction at the top right. Step 2. Pick the type of transaction A modal opens with three options at the top: - Standard. Money in or money out of one wallet. The most common. - Split. Money in or out of one wallet, allocated across multiple categories. (E.g., a single $200 charge that's $150 office supplies and $50 marketing.) - Transfer. Money moving from one of your wallets to another of your wallets. We'll cover Standard here. Split and Transfer have their own dedicated articles. Smart Transaction modal with the Standard / Split / Transfer mode picker visible Step 3. Fill in the basics | Field | What to put | |---|---| | Wallet | The wallet the money came in or went out of | | Direction | "Money in" (you received) or "Money out" (you paid) | | Amount | How much, in the wallet's native currency | | Date | When the transaction happened | | Time (optional) | Useful for Lightning transactions where order of events matters | The currency is determined automatically by the wallet. If the wallet is BTC, the amount is in BTC (or sats, depending on your display preference). Step 4. Pick a contact The contact is the other party in the transaction: - Money in: who paid you (a customer) - Money out: who you paid (a vendor) If the contact already exists in your contacts list, type to search and select. If they're new, click Add new contact to create one on the spot without leaving the form. Contact picker dropdown showing autocomplete with an "Add new contact" option at the bottom For one-off cash sales where you don't track individual customers, you can leave this blank or use a generic contact like "Walk-in Customer." Step 5. Pick the category (account) This tells BitBooks what kind of business activity this transaction represents: - "Sales: Coffee" if a customer paid for coffee - "Office Supplies" if you bought pens - "Software Subscriptions" if you paid for Slack - "Rent" if you paid your landlord The category determines where this transaction shows up on your P&L. If you put a coffee sale into "Sales: Coffee," it appears under Sales income. If you accidentally put it into "Refunds," it lowers your sales instead. The dropdown shows all your accounts grouped by type (Income, Expense, etc.). Type to search. If the right category doesn't exist, you can create a new one from Admin → Chart of Accounts, then come back here. Category dropdown open, showing accounts grouped by type (Income, Expense, Asset, etc.) Step 6. Fill in optional fields A few fields you can use as helpful but aren't required: - Memo. Free text. Use it for context: "Invoice #1234," "Tip not included," "Refund of yesterday's order." - To/From address. A Bitcoin address or wallet identifier if the transaction was on-chain or has a specific destination. - Reference number. BitBooks auto-generates one (e.g., TX-000142). You can override if you have an external reference. - Receipts. Drag-and-drop a PDF, JPG, or PNG to attach a receipt. Useful for expense audit later. Lower portion of transaction modal showing memo field, to/from field, and receipt drop zone Step 7. Save Three save options at the bottom: - Save: keeps it as a Draft (you'll review and post later) - Save and post: saves and immediately makes it Posted (final) - Save and new: saves and clears the form for the next transaction (great for batch entry) Modal footer with the three save buttons visible If you're not 100% sure about the category or the contact, save as Draft. You can always edit and post later. See Draft vs Posted for the full explanation. A worked example You're the bookkeeper for a Bitcoin-friendly café. A customer just paid 25,000 sats for a $20 coffee order. 1. Open Transactions → New Transaction 2. Mode: Standard 3. Wallet: Blink Lightning Hot 4. Direction: Money in 5. Amount: 25,000 (sats) 6. Date: today 7. Contact: Cash Customer (you don't track individual coffee customers) 8. Category: Sales: Coffee 9. Memo: "morning rush" 10. Save and post Done. The transaction appears in the table. The 25,000 sats is added to your Blink wallet's balance. Sales income on your P&L goes up by the dollar equivalent ($20). What "Smart" means in the modal name The modal is called the "Smart Transaction Modal" because it figures out things for you: - Currency. It looks at the wallet you picked and uses that wallet's currency. - Exchange rate. If the transaction is in BTC and your reporting currency is USD, BitBooks fetches the current BTC/USD rate and pins it to this transaction. - Bookkeeping (debits and credits). You don't see them, but BitBooks creates the right journal entry behind the scenes. Debit one account, credit another, balanced. - Reference number. Auto-generated. You can't break the bookkeeping rules from Simple Mode. Every transaction is guaranteed to balance. Editing or deleting If the transaction is a Draft: - Click it in the table to open it - Edit any field - Save again, or delete If the transaction is Posted: - Editable fields are limited (memo, attachments, contact) - Amount, date, accounts, currencies are locked - To change a locked field, reverse the transaction and post a new one. See Reversing a Posted Entry. Common questions "I picked the wrong wallet. Can I change it?" If it's a Draft, yes. Just open it, change the wallet, save. If it's Posted, no. Reverse the original and post a new one with the right wallet. "What if the customer paid in cash but I'm tracking it in BitBooks?" You probably have a wallet called "Cash on Hand." Use that. The mechanics are identical to any other wallet, just no auto-sync (you record cash transactions by hand). "What does 'Status' mean on the Transactions table?" Each transaction has two statuses: - Status (Complete, Incomplete, Pending, Failed, Reversed). The state of the actual transaction. - Cleared status (Not Cleared, Cleared, Reconciled). Whether the transaction has settled at your wallet provider and been reviewed against the wallet's statement. For most transactions, Status will be Complete and Cleared status will start as Not Cleared, then move to Cleared after the first reconciliation. See Cleared, Uncleared, and Reconciled Transactions. Where to go next - Draft vs Posted for the lifecycle of every entry - Splitting a Transaction Across Multiple Accounts for split mode - Recording a Wallet-to-Wallet Transfer for transfer mode - Creating a Journal Entry (Advanced Mode) when Simple Mode isn't expressive enough - The 10 Transaction Templates for shortcuts to common transaction shapes

Last updated on May 03, 2026

Creating a Journal Entry (Advanced Mode)

What "Advanced Mode" gives you The Journal Entries page is the accountant's view. Instead of filling in a friendly form ("which wallet, how much, what was it for?"), you write the underlying journal entry directly: which accounts to debit, which accounts to credit, in which currencies, for what amounts. Anything you can do in Simple Mode you can do in Advanced Mode. The reverse isn't true. Advanced Mode is more expressive: - Multi-line entries that touch 3, 4, or 10 accounts - No-wallet entries like depreciation, accruals, prepaid expenses - Foreign currency entries with explicit exchange rates - Reversing entries done by hand (rather than the automatic reversal flow) - Year-end closing entries If you're an accountant or bookkeeper, this is your home. When to use Advanced Mode Use Advanced Mode for: - Adjustments at month-end or year-end (depreciation, accruals, prepaid amortization) - Closing entries (rolling P&L into Retained Earnings) - Entries that touch only equity accounts (owner contributions, dividends) - Anything where neither side is a wallet - Entries where you need to manually pin an exchange rate - Complex multi-line entries that don't fit Simple Mode's shape For everyday transactions, use Simple Mode. It's faster and harder to mess up. Step by step Step 1. Open the Journal Entries page Click Journal Entries in the left sidebar. Sidebar with Journal Entries highlighted, table of past entries visible You'll see a table of past journal entries. Each row shows: reference number, date, currency, memo, status, debit total, credit total. To create a new entry, click New Journal Entry at the top right. Step 2. Fill in the header | Field | What it means | |---|---| | Date | When the entry takes effect | | Currency | The native currency for the entry's amounts | | Reference number | Auto-generated (JE-000142, etc.). Editable if you have an external reference | | Memo | Free text describing the purpose | The currency you pick here is the currency the entry's amounts will be entered in. You can have lines in multiple currencies (more on that below) but the header currency is the default. Step 3. Add lines A journal entry has 2 or more lines. Each line either debits or credits an account. For each line: | Field | What to put | |---|---| | Account | The chart of accounts entry this line affects | | Debit | An amount, if this is a debit line | | Credit | An amount, if this is a credit line | | Currency | The currency for this line (defaults to header currency) | | Memo | Optional per-line memo | | Contact | Optional per-line contact | Click + Add Line to add more rows. Journal entry modal with three lines: a debit, a credit, and a partial third line being added Step 4. Make sure debits = credits The bottom of the form shows running totals: Total Debits and Total Credits. They must be equal before you can post. If they're not equal, BitBooks will block posting until you fix it. The form turns the difference red so it's easy to spot. Modal footer showing "Debits: 1,000.00, Credits: 1,000.00, Balanced ✓" in green Step 5. Save Same options as Simple Mode: - Save: keeps as Draft - Save and post: commits to the books - Save and new: saves and opens a fresh form If your books use approvals (a second person reviews each entry), the post action puts the entry into Posted status. Approval is then a separate action by another user. A worked example: depreciation At the end of the year, you need to record depreciation on a $5,000 piece of office equipment over 5 years. That's $1,000 per year, or $83.33 per month. This isn't a transaction with a vendor. No money changes hands. It's an internal accounting entry. Simple Mode can't handle it, but Advanced Mode can: | Account | Debit | Credit | |---|---|---| | Depreciation Expense | $83.33 | | | Accumulated Depreciation: Office Equipment | | $83.33 | Memo: "December 2026 monthly depreciation, office equipment." Both totals: $83.33. Balanced. Save and post. What this does: - The expense account goes up by $83.33 (the cost of the asset wearing out, recognized this month) - The "accumulated depreciation" contra-account goes up by $83.33 (recording the running total of value lost over time) - Office Equipment's net book value drops by $83.33 A worked example: owner contribution The owner just put $10,000 of their own money into the business bank account. | Account | Debit | Credit | |---|---|---| | Cash on Hand (the bank account) | $10,000 | | | Owner's Capital | | $10,000 | Memo: "Initial founder contribution." This isn't really a "transaction" in the customer-or-vendor sense. It's an equity event. Advanced Mode is the natural place for it. Multi-currency entries If you need a single entry that involves multiple currencies (e.g., recording a Bitcoin purchase that affects both your USD bank account and your BTC wallet), you can mix currencies on different lines. For each line, pick the currency. BitBooks looks up the appropriate rate and computes the functional-currency value automatically. The total-debits and total-credits check happens in your functional currency, not the line currencies. So a line of 0.1 BTC and a line of $9,000 USD might balance perfectly if 0.1 BTC happens to equal $9,000 at the entry's date. Multi-currency entry showing one line in BTC and one in USD with the functional-currency totals at the bottom When pinning the rate is up to you By default BitBooks fetches the rate at the entry's date and uses that. If you want to override (e.g., you actually executed at a slightly different rate), you can: - Click the rate next to a multi-currency line - Enter the rate you actually used - Save The line stays in its native currency, but the conversion uses your manual rate. The override is recorded for audit. Statuses (same as Simple Mode) Journal entries follow the same lifecycle as transactions: - Draft. Saved but not committed. Doesn't show on reports. - Posted. Committed. Locked except for memo/attachments/contact. - Approved. Posted and signed off (if your org uses approvals). - Reversed. Was Posted, now cancelled out by a reversing entry. See Draft vs Posted for the full explanation. Editing rules - Drafts: edit anything freely - Posted: edit memo and attachments; everything else requires reversal For correcting a wrong Posted entry, click Reverse on the entry. BitBooks creates an automatic reversing entry that exactly cancels the original. Then post a new correct entry. Both stay visible for the audit trail. Bulk posting If you have many Drafts to post (e.g., after a CSV import), you don't have to click into each one: 1. On the Journal Entries page, tick the rows you want to post 2. Click Bulk Post at the top of the table BitBooks runs through them in order and posts each. If any fail (e.g., one is unbalanced), the others still post and you get a list of which failed. Journal entries table with multiple rows ticked and the Bulk Post button visible Common questions "Can I have a journal entry with no contact?" Yes. Most internal entries (depreciation, closing, equity adjustments) have no contact. Leave it blank. "Can I have a journal entry with negative amounts?" No. Use a credit instead of a negative debit. The two are mathematically equivalent in double-entry bookkeeping; the credit form is the convention. "Why can't I delete a Posted entry?" To preserve the audit trail. Use Reverse instead. See Draft vs Posted for why. "My entry is balanced but BitBooks won't let me post." Check the functional currency totals at the bottom (not the line-currency totals). If you have lines in multiple currencies, the functional totals are what matter, and they might be off by a rounding cent due to rate conversion. Fix by adjusting one line by the rounding amount, or by setting an explicit rate that resolves the rounding. Where to go next - Creating a Transaction (Simple Mode) for everyday entries - Reversing a Posted Entry for the formal correction flow - Bulk Posting Drafts for month-end batch processing - How Exchange Rates Work in BitBooks for the multi-currency mechanics - Period Close for year-end procedures that often involve journal entries

Last updated on May 03, 2026

Simple Mode vs Advanced Mode: When to Use Each

The two tools BitBooks has two entry tools that produce the same kinds of entries in the books: - Simple Mode lives on the Transactions page. A friendly form. Pick a wallet, pick what it was for, pick an amount, save. - Advanced Mode lives on the Journal Entries page. The accountant's view. You write the underlying debits and credits yourself. Same data, two different forms. Which one you should open depends on what you're trying to do. Use Simple Mode when - A transaction touched one wallet (money came in, money went out, or you transferred between two wallets) - You don't want to think about debits and credits - You're entering the kind of transaction a normal business does every day (sales, expenses, payments) - You're new to bookkeeping Simple Mode handles the bookkeeping for you. You can't break the rules. 90% of entries should go through Simple Mode. It's the everyday tool. Use Advanced Mode when - You need a multi-line entry that touches several accounts in unusual ways - The entry doesn't involve a wallet at all (depreciation, accruals, prepaid amortization) - You need to manually pin an exchange rate - You're posting closing entries at year-end - You're recording an equity event (owner contributions, dividends, stock issues) - Your accountant told you to use a journal entry Advanced Mode is more flexible but requires you to know what debits and credits to use. A quick decision tree Ask yourself: 1. Is at least one side of this transaction a wallet? - Yes → Simple Mode - No → Advanced Mode 2. Does it touch only one wallet, or move between two? - One wallet → Simple Mode (Standard or Split) - Two wallets → Simple Mode (Transfer) 3. Is it a multi-line entry that doesn't fit Standard / Split / Transfer? - Yes → Advanced Mode 4. Is it a non-cash event (depreciation, accrual, etc.)? - Yes → Advanced Mode When in doubt, try Simple Mode first. If you find yourself wanting fields it doesn't have, that's the signal to switch to Advanced Mode. Are the entries different? In the database, no. Every transaction recorded in BitBooks ultimately becomes a journal entry with debits and credits. Simple Mode just builds that journal entry behind the scenes. That means: - A transaction created in Simple Mode and a journal entry created in Advanced Mode that have the same amounts and accounts produce identical results on reports - You can view a Simple Mode transaction's underlying journal entry by clicking through (it's the same data) - Reports don't distinguish between the two tools The choice is purely about which form is easier for you to fill in. Examples side by side A coffee shop sale of 25,000 sats Simple Mode: Wallet: Blink Lightning Hot Direction: Money in Amount: 25,000 sats Contact: Cash Customer Category: Sales: Coffee Advanced Mode (same outcome): | Account | Debit | Credit | | Blink Lightning Hot | 25,000 sats | | Sales: Coffee | | 25,000 sats | Both produce the same record. Simple Mode is faster. Year-end depreciation of $83.33 Simple Mode: Can't do this. There's no wallet involved. Advanced Mode: | Account | Debit | Credit | | Depreciation Expense | $83.33 | | | Accumulated Depreciation | | $83.33 | Has to be Advanced Mode. Owner contributes $10,000 Simple Mode: Wallet: Cash on Hand Direction: Money in Amount: $10,000 Contact: (Owner's name) Category: Owner's Capital This works! The bank account is a wallet, so Simple Mode handles it. Advanced Mode (same outcome): | Account | Debit | Credit | | Cash on Hand | $10,000 | | | Owner's Capital | | $10,000 | Either tool works. Pick whichever you prefer. Switching mid-flow You can't take a transaction created in Simple Mode and "convert" it to Advanced. They're really the same underlying data, just viewed differently. You CAN view a Simple Mode transaction's journal entry. Open the transaction, look for "View Journal Entry" or click through. That opens the same data in the Journal Entries view. If you want to edit it as a journal entry (not as a transaction), the cleanest approach is: reverse the original, post a new journal entry from scratch in Advanced Mode. Common questions "My team is split between Simple and Advanced. Is that OK?" Yes. Different team members can use different tools for the same kinds of transactions. The bookkeeper might prefer Advanced for control; a sales rep might prefer Simple for speed. The reports come out the same. "Is Advanced Mode faster than Simple Mode for an experienced accountant?" For some kinds of entries (multi-line journal entries, adjustments), yes. For everyday Standard transactions, Simple Mode is faster because you don't have to manually balance debits and credits. "Will future versions remove one of these?" No. Both serve real purposes. Simple Mode for ease of use, Advanced Mode for power. Most accounting tools have something like this; we just made the distinction explicit. Where to go next - Creating a Transaction (Simple Mode) for the Simple Mode walkthrough - Creating a Journal Entry (Advanced Mode) for the Advanced Mode walkthrough - The 10 Transaction Templates for shortcuts to common Simple Mode entries - Draft vs Posted for what happens after you save

Last updated on May 02, 2026

Recording a Bitcoin Purchase

What this is You moved fiat (USD, EUR, CAD, etc.) out of one of your accounts to acquire Bitcoin. The Bitcoin landed in one of your wallets. This is a Bitcoin purchase. Examples: - You bought 0.1 BTC on Coinbase using $9,000 USD from your Coinbase USD balance - You sent $5,000 from your bank account to River Financial and they delivered BTC to your hardware wallet - You used Strike to convert $200 USD to sats and the sats landed in your Strike wallet The accounting question: how do you record this in BitBooks so the books are correct? The clean answer: a Transfer A Bitcoin purchase is conceptually a transfer between two of your wallets: - Money out of the fiat wallet (the USD account) - Money in to the Bitcoin wallet (the BTC wallet) The exchange rate is locked in by the actual prices at the time of purchase. In BitBooks: 1. Transactions → New Transaction 2. Mode: Transfer 3. From wallet: your fiat wallet (e.g., "Coinbase USD") 4. From amount: the dollar amount you sent (e.g., $9,000) 5. To wallet: your Bitcoin wallet (e.g., "Coinbase BTC" or "Trezor Cold") 6. To amount: the BTC amount you received (e.g., 0.1 BTC) 7. Date: when the purchase happened 8. Memo: useful context, like "Coinbase market buy" or "DCA buy via Strike" Smart Transaction Modal in Transfer mode showing both From and To fields filled in for a USD-to-BTC transfer Save and post. Why this is a Transfer, not a Sale Some new users want to record this as "sales income" because dollars came in to their BTC wallet. That's wrong. You didn't earn dollars. You owned dollars and now you own Bitcoin. In accounting terms: - Sales = revenue from operations (selling a product or service) - Purchase of Bitcoin = a swap of one asset for another. Revenue is unchanged. Recording it as a transfer keeps your P&L accurate. Your revenue line shows what your business earned, not what you reorganized between your own accounts. What about the exchange rate? The exchange rate is implied by the From and To amounts: - $9,000 / 0.1 BTC = $90,000 per BTC BitBooks records this rate as the cost basis for the Bitcoin you just acquired. It's stored permanently with the transaction. When you eventually sell or revalue the Bitcoin, this is the rate used to compute gains and losses. If the exchange rate matters to your accounting (it almost always does for tax purposes), use the actual exchange rate at the time of the trade, not the market rate. Exchanges add spreads and fees. Your real cost is what you paid, not what BTC was on CoinGecko. What about exchange fees? Most exchanges charge a fee. Two ways to handle it: Option A: Bake the fee into the rate If Coinbase charged you $9,000 to receive 0.0995 BTC (0.0005 BTC less due to fees), record: - From: $9,000 - To: 0.0995 BTC The fee is implicit in the higher effective rate ($90,452 per BTC instead of $90,000). Your books are correct, but the fee isn't itemized. Option B: Show the fee separately If you want the fee as its own line: 1. Use Advanced Mode (Journal Entries) instead of Simple Mode 2. Three lines: debit BTC wallet (the actual amount received), debit Exchange Fees (the fee amount), credit USD wallet (the total paid) This gives you visibility into how much exchange fees cost over time. Worth it if you trade often. For occasional buyers, Option A is fine. Common scenarios Buying via your bank to a custodial wallet Money out of your bank, BTC into Coinbase. Two-step in real life (the bank wire, then the Coinbase trade) but you can record as a single transfer if both happened on the same day. If they happened on different days (wire on Monday, trade on Tuesday), record them separately: 1. Monday: Transfer from bank to "Coinbase USD" (your USD balance at Coinbase) 2. Tuesday: Transfer from "Coinbase USD" to "Coinbase BTC" Two wallets at Coinbase: one for USD, one for BTC. They're separate balances. Dollar-cost averaging (DCA) You buy a small amount every week. Each one is its own transfer. They all stack as separate transactions, each with its own rate. For tax accounting, this gives you the granular cost basis BitBooks needs to compute gains and losses correctly when you eventually sell. Buying with stablecoin If you trade USDC for BTC: same Transfer pattern, but the From wallet is your USDC balance (also tracked in BitBooks as a wallet). What if my wallet auto-syncs? Many providers (Coinbase, Strike, etc.) auto-import the trade as two transactions: one debit to USD, one credit to BTC. They show up in BitBooks as a pair of Drafts. Two ways to handle: 1. Use the auto-imported pair as-is. Post both. They each touch one side of the trade. Make sure they have the same date and memo so they group naturally. 2. Replace with a Transfer. Delete the two Drafts. Create one Transfer transaction. Cleaner record, less clutter. We recommend option 2 for clarity, but either works. On gain/loss A Bitcoin purchase doesn't create gain or loss. You traded $9,000 worth of dollars for $9,000 worth of Bitcoin. The Bitcoin's value will fluctuate from here, but at the moment of purchase, gain = 0. Gains/losses appear later when: - You sell the Bitcoin (realized gain/loss) - You revalue the Bitcoin to current market price (unrealized gain/loss) See Recording a Bitcoin Sale and Tracking Bitcoin Value Changes. Where to go next - Recording a Bitcoin Sale for the inverse transaction - Recording a Wallet-to-Wallet Transfer for the general transfer pattern - Tracking Bitcoin Value Changes for FX revaluation accounting - The 10 Transaction Templates for shortcuts to common Bitcoin transactions

Last updated on May 03, 2026

Recording a Bitcoin Sale

What this is You moved Bitcoin out of one of your wallets to receive fiat. The Bitcoin left your business; the fiat (USD, EUR, etc.) came in. Examples: - You sold 0.5 BTC on Coinbase and received $40,000 USD - You spent BTC to a Bitcoin ATM and got cash - You sent BTC to a third party in exchange for them sending you USD via wire This is the inverse of Recording a Bitcoin Purchase. The bookkeeping is similar but with one extra wrinkle: gain or loss. Step 1: record the sale itself as a Transfer Like a purchase, a sale is conceptually a transfer between two of your wallets: - BTC out of your Bitcoin wallet - Fiat in to your USD wallet (or wherever the proceeds went) In BitBooks: 1. Transactions → New Transaction 2. Mode: Transfer 3. From wallet: your Bitcoin wallet (e.g., "Coinbase BTC") 4. From amount: BTC you sold (e.g., 0.5 BTC) 5. To wallet: your USD wallet (e.g., "Coinbase USD") 6. To amount: USD received (e.g., $40,000) 7. Date: when the trade settled 8. Memo: useful context Transfer transaction modal showing BTC out + USD in The implied exchange rate is $40,000 / 0.5 = $80,000 per BTC. This is what you actually got, not the market rate at that exact moment. They're often close but not identical. Step 2: realized gain or loss Here's where a sale differs from a purchase. When you sell Bitcoin, you typically realize a gain or loss because the price you sold at differs from the price you originally paid. Suppose you bought 0.5 BTC at $50,000 each (cost basis: $25,000). You just sold them for $40,000 each (proceeds: $20,000 worse... wait, $40,000 each means $20,000 total per BTC. Let me redo this). Let me use a cleaner example. You bought 0.5 BTC at $50,000 each. Cost basis: $25,000 total. Today you sell those 0.5 BTC at $80,000 each. Proceeds: $40,000. Gain = Proceeds - Cost Basis = $40,000 - $25,000 = $15,000 realized gain This needs to land in your books somewhere. Your P&L should show the $15,000 gain. How BitBooks handles it For now, BitBooks doesn't auto-compute realized gains during a Transfer. You'll need to record the gain explicitly. Two paths: Path A: a separate journal entry for the gain After the Transfer transaction, create a journal entry: | Account | Debit | Credit | |---|---|---| | BTC Hot Wallet (or wherever the BTC was sourced from) | | $15,000 | | Realized FX Gain on Bitcoin | | $15,000 | Wait, that's not balanced. Let me redo. Actually, the gain comes from the Transfer step itself if the Transfer was recorded at the original cost basis. The cleaner way is: 1. Record the Transfer at cost basis: 0.5 BTC for $25,000 (the cost-basis dollar value) 2. Record a second entry recognizing the additional $15,000 of cash: | Account | Debit | Credit | |---|---|---| | Cash on Hand | $15,000 | | | Realized FX Gain on Bitcoin | | $15,000 | Now the books reflect: BTC gone, $40,000 cash in, $15,000 of that recorded as gain. Path B: use Advanced Mode for one combined entry In Advanced Mode (Journal Entries), do everything as one entry: | Account | Debit | Credit | |---|---|---| | Cash on Hand | $40,000 | | | BTC Hot Wallet (at cost basis) | | $25,000 | | Realized FX Gain on Bitcoin | | $15,000 | This is the cleanest record: one entry, all sides visible, gain explicitly booked. Where to find the cost basis If you ran an FX revaluation recently, the most recent revalued amount is the basis (gain after the revaluation is the difference between sale price and the post-revaluation amount). If you've never revalued, the cost basis is the price you originally paid (which BitBooks recorded with each purchase transaction). For taxable purposes, you'll typically use a specific cost-basis method (FIFO, LIFO, specific identification, etc.). Talk to your tax preparer about which method applies to your jurisdiction. BitBooks records purchase prices, but you choose how to apply them to sales. What if it's a loss instead? Same structure, opposite sign. Replace "Realized FX Gain" with "Realized FX Loss" (an Expense account, or contra-revenue, depending on how your chart is set up): | Account | Debit | Credit | |---|---|---| | Cash on Hand | $25,000 | | | Realized FX Loss on Bitcoin | $5,000 | | | BTC Hot Wallet (at $30,000 cost basis) | | $30,000 | Now $30,000 of BTC left, $25,000 of cash came in, $5,000 of that decline is recognized as a loss. Common scenarios Selling on a custodial exchange Same Transfer + gain/loss pattern. The exchange might also charge a fee. Bake the fee into the rate (Path A above) or itemize it (Path B with a Fees line). Spending Bitcoin (using BTC to pay a vendor) Different flow. This isn't really a sale; it's an expense paid in BTC. Record as a regular expense transaction with the BTC wallet on the "money out" side. The exchange rate at the moment of the spend determines the dollar value of the expense. If you previously recorded the BTC at a different basis, you may also have a realized gain or loss. For most one-off spends, this complexity isn't worth it. Many small businesses ignore the gain/loss on individual spends and only track gain/loss when they explicitly sell BTC for fiat. Talk to your accountant. Selling at a tax loss Useful for tax-loss harvesting. Same accounting; just be aware of wash-sale rules in some jurisdictions (you can't immediately re-buy and claim the loss). Where to go next - Recording a Bitcoin Purchase for the inverse transaction - Tracking Bitcoin Value Changes for FX revaluation accounting - Capital Gains Tracking for Bitcoin Holdings for the tax-side picture - Recording a Wallet-to-Wallet Transfer for the general transfer pattern

Last updated on May 03, 2026

Recording a Lightning Payment Received

What this looks like A customer paid you using Lightning. Sats arrived in your Lightning wallet (Blink, Phoenix, Strike, etc.). You need to record it as revenue. Three ways this happens: 1. Auto-import via Bitcoin Connections. Your wallet provider syncs to BitBooks, the receive shows up as a Draft, you review and post. 2. You enter it manually because you haven't connected the wallet, or because you're recording an off-platform Lightning payment. 3. A pair of imported entries that you need to merge or simplify. If auto-sync caught it The simplest case. The Draft is sitting in your Transactions page waiting for review. Open it: 1. Confirm the amount (5,000 sats, 12,500 sats, whatever) 2. Confirm the date is correct 3. Set the contact (the customer who paid) 4. Set the category (Sales: Coffee, Service Revenue, Tips Received, depending on what the payment was for) 5. Optional memo (invoice number, what they bought) 6. Click Save and post Done. The Lightning payment is now revenue on your books. Smart Transaction Modal opened on a Lightning receive Draft, showing the auto-imported amount and the user filling in the contact and category fields If you're entering it manually 1. Transactions → New Transaction 2. Mode: Standard 3. Wallet: your Lightning wallet 4. Direction: Money in 5. Amount: the sats received 6. Date: when the payment came in 7. Time (optional): the exact moment if it matters 8. Contact: the customer 9. Category: the income account (Sales, Service Revenue, etc.) 10. Save and post The entry behaves identically to an auto-imported one, just without the round trip to the wallet provider. What "category" should I use? Depends on what the payment was for: | Payment was for | Category | |---|---| | A product (coffee, beer, merchandise) | Sales (or a sub-account like "Sales: Coffee") | | A service (consulting hour, design work) | Service Revenue | | A tip on top of a sale | Tips Received (separate from Sales) | | A refund of something the customer previously paid for | Sales with a negative amount, OR Refunds Issued | | A donation | Donations Received (Other Income) | | A loan from the customer | NOT income; record as Liability instead | When in doubt, use Sales. You can re-categorize later by reversing and re-posting. What about the exchange rate? BitBooks fetches the BTC/USD (or BTC/your-currency) rate at the moment of the transaction. The rate is "pinned" to that transaction; it doesn't keep changing as the market moves. So a 12,500-sat payment received when BTC is at $80,000 records as: - 12,500 sats (the actual amount) - $10.00 (12,500 sats × $80,000 / 100,000,000 sats/BTC) The dollar value shows up on the P&L as Sales. The sats stay in your wallet. Lightning fees Some Lightning wallets pass Lightning routing fees to you (the recipient takes a slight discount). Some charge them as a separate fee. Most consumer-friendly wallets (Blink, etc.) pay the fees themselves and you receive the gross amount. If a fee was deducted, it'll show up either as part of the receive (you got 12,500 sats but the customer sent 12,510, the 10-sat fee is implicit) or as a separate small expense entry. For most small businesses, Lightning fees aren't material and you can ignore the breakdown. Record the gross sales amount and move on. For high-volume Lightning operations where fees matter, see Lightning vs On-Chain for fee accounting patterns. A worked example A coffee customer scans a Lightning invoice for 5,000 sats. The payment lands in your Blink wallet 3 seconds later. Auto-imported flow [Draft] Amount: 5,000 sats Direction: Money in Wallet: Blink Lightning Hot Date: 2026-05-01 Contact: (blank) Category: (blank, or Suspense) You open the Draft. You set: - Contact: Cash Customer (you don't track individual coffee customers) - Category: Sales: Coffee - Memo: "5k sats latte" Save and post. The 5,000 sats are now in your Blink balance and your Sales: Coffee revenue increased by ~$4 (assuming BTC at $80,000). Common questions "What if the customer paid me and immediately disputed it?" Lightning payments are settled and final. There's no chargeback equivalent. If the customer paid then ate the latte and walked out, the payment stands. If you want to refund, send sats back as a separate transaction (record as a refund expense in your books). "My Lightning payment is in 'Pending' status forever. What now?" Lightning payments usually settle within seconds. If yours is stuck pending, the payment failed at the routing layer. Check with your wallet provider. The sats will return to the sender automatically. If BitBooks shows it as Pending and you know it actually settled, click into the transaction and update the cleared status to Cleared. "How do I track which customer paid which invoice?" Use the Reference number field or Memo field to record the invoice number. Then your P&L drill-down shows which invoices generated which revenue. For more formal invoice tracking, use the Payments page (payment requests) and link receipts to them. See Adding and Managing Contacts. Where to go next - The 10 Transaction Templates for shortcuts to common transaction shapes - Bitcoin Connections for setting up auto-import from Lightning wallets - Draft vs Posted for the entry lifecycle - Lightning vs On-Chain for the broader Bitcoin accounting picture

Last updated on May 03, 2026

Recording a Wallet-to-Wallet Transfer

What a transfer is A transfer is moving money from one of YOUR wallets to another of YOUR wallets. No third party. Examples: - Moving 0.1 BTC from your Lightning hot wallet to cold storage - Moving USD from your operating bank account to a savings account - Sending sats from Blink to your hardware wallet - Buying or selling Bitcoin (which is a transfer between your fiat wallet and your BTC wallet, see Recording a Bitcoin Purchase) This is different from paying a vendor, receiving from a customer, or any transaction with someone outside your business. Why transfers need their own treatment If you recorded a transfer as two separate transactions (one money-out from the source wallet, one money-in to the destination wallet), they'd each look like real business activity: - The money-out might be classified as an expense - The money-in might be classified as income That would inflate both expenses AND income. The P&L would show $1,000 of "revenue" and $1,000 of "spending" that didn't actually happen. Transfers neutralize this. A transfer doesn't appear on your P&L at all. It's just a movement of money between your own pockets, no impact on profit. How to record a transfer 1. Transactions → New Transaction 2. Mode: Transfer 3. Pick the From wallet and From amount 4. Pick the To wallet and To amount 5. Date and optional memo 6. Save and post Smart Transaction Modal in Transfer mode showing both From and To sides side by side Same currency vs different currency Same-currency transfer Both wallets are in the same currency (USD to USD, BTC to BTC, etc.). - From amount = To amount - The amount is the same on both sides - No exchange rate to worry about Example: moving $5,000 from operating checking to savings. Different-currency transfer (a buy or sell) The wallets are in different currencies (USD to BTC, BTC to USD, etc.). - From and To amounts are different (because they're different units) - An implicit exchange rate is set by the ratio - This is how you record a Bitcoin purchase or sale Example: $9,000 USD to 0.1 BTC. Implicit rate: $90,000 per BTC. See Recording a Bitcoin Purchase and Recording a Bitcoin Sale for the buy/sell scenarios. Transfer fees Many transfers charge a fee: - On-chain Bitcoin transfers cost network fees - Wires between banks cost bank fees - ACH transfers are usually free - Lightning transfers are usually free or near-free Three ways to handle the fee: Bake it in If you send 0.1 BTC and 0.0995 arrives (0.0005 lost to network fee), record: - From amount: 0.1 BTC - To amount: 0.0995 BTC The fee is implicit in the amount difference. Itemize as expense In Advanced Mode (Journal Entries), do three lines: | Account | Debit | Credit | |---|---|---| | Cold Storage Wallet | 0.0995 BTC (in fiat value) | | | Network Fees Expense | 0.0005 BTC (in fiat value) | | | Hot Wallet | | 0.1 BTC (in fiat value) | Now the fee shows up on your P&L as an expense. Ignore for small fees If the fee is negligible (sub-dollar Lightning routing fee), most small businesses don't bother itemizing. Bake it in and move on. Linked transfers If you record both sides of a transfer separately (as two transactions instead of one), BitBooks can link them so they're treated as a transfer pair. The "Link transfer" feature on the Transactions page lets you select two opposite-direction transactions in different wallets and pair them. They then appear as a transfer rather than as two unrelated movements. This is useful when: - Auto-sync imported the two sides separately and you want to merge them - You forgot to use Transfer mode and recorded the two sides as Standard transactions Link Transfer modal showing two transactions selected for pairing Transfers and the Trial Balance A transfer is internally balanced: the From side reduces one wallet, the To side increases another, and the totals match. The Trial Balance treats it like any other balanced entry. If you have multi-currency transfers (different From and To currencies), the balancing happens in your functional currency using the exchange rate. As long as the rate at the time was correct, the Trial Balance stays balanced. Common scenarios Moving sats from hot to cold Most common Bitcoin business transfer. Click Transfer, From: hot wallet, To: cold storage, amount: same on both sides, save. Sweeping a bank account into a savings account Same pattern, USD to USD instead of BTC to BTC. Bitcoin purchase via exchange A multi-step transfer chain: 1. Bank → Coinbase USD balance (transfer) 2. Coinbase USD → Coinbase BTC (transfer at the trade rate, this is the actual purchase) 3. Coinbase BTC → Hardware wallet (transfer of BTC) Each step is its own transfer. Together they tell the full story. Returning a transfer (correction) If you accidentally sent BTC to the wrong wallet and need to send it back, that's another transfer. Record it. Both transfers stay in the audit log. What a transfer is NOT - A sale to a customer (use a Standard transaction with money-in direction and a customer contact) - A purchase from a vendor (use a Standard transaction with money-out direction and a vendor contact) - A payroll payment (use a Standard transaction or a journal entry, depending on payroll setup) - A loan repayment (Standard transaction with the lender as contact) If the other party is someone outside your business, it's not a transfer. Where to go next - Recording a Bitcoin Purchase for the buy-side transfer pattern - Recording a Bitcoin Sale for the sell-side transfer pattern - Creating a Transaction (Simple Mode) for the general entry tool - Linking Two Transactions as a Transfer for after-the-fact pairing

Last updated on May 03, 2026

Splitting a Transaction Across Multiple Accounts

When to split A "split" is one transaction that touches multiple categories on one side. Example: you spent $200 on the company credit card. The receipt was for office supplies ($150) AND a marketing item ($50). One charge, two purposes. Without a split, you'd record it as one transaction and pick a single category, which is wrong (you'd inflate one and miss the other). Or you'd create two separate transactions for $150 and $50, which doesn't match what actually appeared on your card statement (one $200 charge). A Split transaction solves this. One transaction, $200 total, with two categories sharing the amount. How splits work A Split transaction has: - One wallet (the source or destination) - One total amount - Multiple line items, each with its own category and sub-amount - The line items add up to the total Example: Wallet: Company Credit Card Direction: Money out Total amount: $200 Line items: Office Supplies $150 Marketing $50 Total of line items: $150 + $50 = $200. Matches. How to create a split 1. Transactions → New Transaction 2. Mode: Split 3. Pick the wallet 4. Pick the direction (money in or out) 5. Enter the total amount 6. Date and contact (optional) 7. In the lines section, click Add line for each category 8. Pick the category and the amount for each line 9. Make sure the line totals match the transaction total 10. Save and post Smart Transaction Modal in Split mode with three line items visible, each with category and amount If line totals don't match the transaction total, the form shows a difference and won't let you post. When you'd use Split Common cases: - A single credit card charge that covered multiple categories - A single bank deposit that combined multiple sources of revenue - A vendor invoice that itemized different services - A wire that paid both rent and utilities in one go - A customer payment that covered an invoice + a tip Anywhere one payment / receipt represents multiple business reasons. When NOT to use Split - Money flowing between two of your own wallets. Use Transfer instead. - A payment to multiple vendors. Each vendor is a separate transaction (different contacts). - A long itemized invoice. If you have 30 line items, that's painful as a Split. Either summarize at a higher level (a few categories that sum to the total) or use the Payment Requests feature, which is designed for itemized invoices. Splits and the Chart of Accounts Each line item targets a single account from the Chart of Accounts. The split affects all those accounts simultaneously. In the example above: - Office Supplies (Expense account) goes up by $150 - Marketing (Expense account) goes up by $50 - Company Credit Card (Liability account) goes up by $200 (you owe more) All in one transaction. Editing a split If the transaction is a Draft, you can edit anything: change line totals, add or remove lines, change the total. Just make sure the math still balances. If the transaction is Posted, the line items are locked along with the rest. Reverse and re-post to make changes. A worked example You bought groceries for an event. Receipt: - Cheese platter: $80 (food for the event) - Disposable plates: $20 (supplies for the event) - A small lunch for yourself while shopping: $15 (your meal, NOT a business expense, you'll reimburse the company personally) The credit card was charged $115. Two ways to handle this: Option A: split the business portion Record only the business expense. Create a Standard transaction (not a Split) for $100, category "Event Supplies." The $15 personal lunch is an owner draw or a personal repayment to the company, recorded separately. This is cleaner if you'll repay personally. Option B: full split with owner-draw line If the credit card statement shows the full $115 and you want it all in BitBooks: Wallet: Company Credit Card Total: $115 Lines: Event Supplies (cheese) $80 Event Supplies (plates) $20 Owner's Draw $15 The $15 to Owner's Draw means: company spent $15 that wasn't business; this counts as the owner taking $15 from the company. The owner separately deposits $15 to repay, which becomes another transaction. Either approach works. Option A is simpler. Option B is more rigorous. Splits with line-level contacts You can set a different contact per line in a split if needed. Most splits use the same contact (the vendor) for all lines, so the per-line contact field isn't usually filled. But it's there if you need it. Example: a wire to a third-party processor that handled payments to multiple vendors. The wire's main contact is the processor; each line might have a different vendor as its line contact. Where to go next - Creating a Transaction (Simple Mode) for the general entry tool - Recording a Wallet-to-Wallet Transfer for transfers (the third Simple Mode mode) - The 10 Transaction Templates for shortcuts to common shapes - Creating a Journal Entry (Advanced Mode) for the most flexible entry tool

Last updated on May 03, 2026

Bulk Posting Drafts

When you'd bulk post You don't post Drafts one at a time when you have many. Common situations: - A wallet auto-synced and dropped 50 new Drafts into Transactions - You imported a CSV bank statement that produced 30 Drafts - You imported from QuickBooks and have hundreds of historical Drafts to commit - Month-end cleanup: review and post anything still sitting as Draft Bulk posting takes one click instead of 30 or 100. How to bulk post on Transactions 1. Click Transactions in the left sidebar 2. Filter to the Drafts you want to post (use the filter bar: status = Draft, plus any wallet or date filters) 3. Tick the checkbox at the start of each row you want to post 4. Or tick the header checkbox to select all visible rows 5. Click Bulk Post at the top of the table Transactions table with 5 rows ticked and the Bulk Post button visible at the top BitBooks runs through the selected rows and posts each one. The status changes from Draft to Posted on each. The page refreshes to show the new state. How to bulk post on Journal Entries Same flow on the Journal Entries page: 1. Journal Entries in the sidebar 2. Filter or search to the Drafts you want 3. Tick rows 4. Click Bulk Post What can prevent a bulk post from succeeding A few reasons a row might not post during a bulk run: - Unbalanced. A journal entry whose debits don't equal credits can't post. Fix and retry. - Missing required fields. A transaction without a wallet, amount, or category can't post. Open the Draft and complete it. - In a locked period. If the entry's date is in a closed period (before the Journal Lock Date), posting fails. Either change the date to current period or unlock the period briefly. - Pending exchange rates. If an entry needs a rate that hasn't been fetched yet, it'll be skipped. Use Retry pending rates at the top of the page to refetch. When some rows fail, the bulk post completes the rest. You see a summary: "X of Y posted successfully. Z failed." Click into the failed ones to see why. Reviewing before bulk posting For a stack of auto-imported Drafts, the typical workflow: 1. Sort by date (oldest first or newest first) 2. Filter by wallet (one wallet at a time is easier to mentally batch) 3. Skim each row: amount looks right, date looks right 4. For each row, set the contact and category if blank 5. Once a row is "ready" (all fields filled, looks correct), tick it 6. After ticking everything you've reviewed, click Bulk Post Don't bulk post 50 Drafts you haven't looked at. The whole point of Drafts is review-before-commit. Use the bulk action AFTER review, not as a substitute for it. Bulk operations on Posted entries A separate set of bulk operations applies to already-Posted entries. Most common: - Bulk reverse. Tick rows, click Reverse. BitBooks creates reversing entries for each. This is rare. You're more likely to reverse one bad entry at a time. But if a whole batch of imports turned out wrong (e.g., the wrong wallet, wrong period), bulk reversing can save you 50 clicks. Filtering tips for bulk operations The Transactions filter bar supports: - Status: Draft, Posted, Approved, Reversed, etc. - Wallet: one wallet or all - Date range: any range - Contact: one contact or all - Category (account): one or all - Direction: money in / money out - Cleared status: Not Cleared / Cleared / Reconciled Combine to narrow down. "All Drafts in the Blink wallet from the last 30 days" gets you exactly what you want before the bulk post. Filter bar with multiple filters set, narrowing to a specific subset A worked example You connected Blink for the first time. The initial sync pulls 600 Lightning transactions from the past 12 months as Drafts. Manual approach: review and post each one, taking maybe 30 seconds per Draft. That's 5 hours. Bulk approach: 1. Filter Transactions to: status = Draft, wallet = Blink Lightning Hot, last 12 months 2. Skim through. Most are easy categorization (small Lightning sales, all should go to Sales: Coffee or similar). 3. Use a default contact ("Cash Customer") for all walk-in customers 4. For the unusual ones (refunds, larger amounts), open and categorize individually 5. After tagging the Sales ones with their category, select all of them, click Bulk Post 6. Repeat for the unusual ones (a smaller batch) Total time: maybe 1-2 hours for 600 Drafts. Common questions "Can I bulk-edit Drafts (e.g., set the same category on 50 rows at once)?" Not in the current UI. The workaround: tick the rows, do them one at a time but quickly. Bulk-edit is on the roadmap. "What happens if I bulk post 50 entries and the system crashes halfway?" Each post is its own request. The ones that succeeded stay Posted. The ones that hadn't been processed yet stay as Drafts. Re-run bulk post on the remaining Drafts. "Can I bulk archive Drafts I don't want?" Yes (delete, not archive, since Drafts can be deleted). Tick the rows, click Bulk Delete. Use carefully; deletion is permanent. Where to go next - Draft vs Posted for what these statuses mean - Reversing a Posted Entry for undoing a posted entry - How Auto-Sync Works for where auto-imported Drafts come from - Importing Bank Statements for CSV-imported Drafts

Last updated on May 03, 2026

Reversing a Posted Entry

What "reversing" means You posted an entry. Later you realized it was wrong. The posted entry is locked, you can't just edit the amount or delete it. Reversing is the right way to fix it. It creates a new entry that exactly cancels the original. Both stay in the books, with a clear paper trail of what happened. Original (wrong): $1,000 to Office Supplies [POSTED → REVERSED] Reversal (auto-generated): -$1,000 to Office Supplies [POSTED, references original] Net effect on books: zero After reversing, you typically post a new corrected entry alongside. Why reverse instead of edit or delete Editing a posted entry would rewrite history. Reports you've already shared (with investors, auditors, the IRS) used the original. If the original silently changed, those reports become wrong with no notice. Deleting would erase history. Same problem, worse: the original is gone with no trace. Reversing is the audit-friendly answer. The original stays. The fix is visible. Anyone reading the books later understands exactly what happened. This is the same convention used in QuickBooks, Xero, every double-entry accounting tool. How to reverse Reversing one entry 1. Open the entry (Transaction or Journal Entry) 2. Click Reverse 3. Confirm the reversal Posted journal entry detail view with the Reverse button highlighted in the toolbar BitBooks creates the reversing entry automatically. The original's status changes to Reversed. The reversing entry shows up as a new Posted entry, dated today (not the original's date), with a link back to the original. Reversing several at once On the Transactions or Journal Entries page, tick the rows you want to reverse, click Bulk Reverse. BitBooks creates a reversing entry for each. Use carefully. Bulk reversing is rare; it's mostly for cleanup after a wrong-batch import. What the reversing entry contains Same accounts as the original, but with debits and credits swapped: Original: | Account | Debit | Credit | |---|---|---| | Office Supplies | $1,000 | | | Cash on Hand | | $1,000 | Reversing entry (auto-generated): | Account | Debit | Credit | |---|---|---| | Cash on Hand | $1,000 | | | Office Supplies | | $1,000 | The reversing entry's date is today (or whatever date you specified). Its memo references the original ("Reversal of JE-000142"). The link between the two is preserved so you can navigate back and forth. After reversing: post the corrected entry Reversing only undoes. To replace with a correct entry, you post a new one separately. For example, if the original was wrong because the amount should have been $100 not $1,000: 1. Reverse the original (cancels the wrong $1,000 entry) 2. Post a new entry: $100 to Office Supplies, dated correctly Now the books show: - The wrong $1,000 entry (status: Reversed) - The reversing entry (status: Posted, neutralizes the original) - The corrected $100 entry (status: Posted, the right number) Net effect: $100 of office supplies, exactly what you wanted. Plus a clear audit trail of what happened. When reversing isn't enough A few scenarios where reversal alone doesn't solve the problem: The original belongs in a closed period If the original entry is dated in a period that's now locked (Journal Lock Date passed it), the reversing entry lands in the current period (today's date). That means: - The closed period's books stay exactly as they were (good) - The current period absorbs the correction (good for the audit trail) - But the corrected entry, if dated in the closed period, can't post (locked) The fix: post the correction in the CURRENT period too, accepting that the wrong number stays in the closed period. Or unlock the period briefly to post the correction in its original period (rewriting history, use sparingly). The original was a category-wide mistake on many entries If you discover that 200 entries went to "Office Supplies" when they should have been "Software Subscriptions," reversing all 200 and posting 200 corrections is painful. The accountant move: post a single summarizing journal entry that moves the cumulative amount from Office Supplies to Software Subscriptions. The original 200 entries stay Posted (incorrectly categorized), but the books net out correctly because of the one large reclassification. | Account | Debit | Credit | |---|---|---| | Software Subscriptions | $X (the cumulative wrong amount) | | | Office Supplies | | $X | Now Software Subscriptions has the right total, Office Supplies is back to its right total. The original 200 entries stay as historical record but the net is correct. What gets preserved After a reversal, you can still see: - The original entry (with status Reversed) - The reversing entry (linked from the original) - All metadata of both: who created, who posted, who reversed, when, with what memo - Audit log entries for the reversal action Nothing is lost. The audit trail tells the full story. Common questions "Can I reverse a Reversed entry?" Effectively, yes. If you reverse a reversal, you're un-doing the un-do. The original is back to net effect. Mostly useful when you reversed by mistake. "Will reversing affect prior reports I've already shared?" The reversing entry is dated today. If you re-run a report covering today, you'll see the reversal. Reports for the period of the original (e.g., last month) include the original and, if the reversal is also in that period (it isn't by default), the reversal. By design, reports for closed periods stay stable. "Can I reverse a Draft?" You don't need to. Drafts can be edited or deleted directly. Reversal is for entries already Posted. Where to go next - Draft vs Posted for the entry lifecycle - Period Close for how locked periods affect reversals - Bulk Posting Drafts for the bulk operations on Drafts - Activity Log to see who reversed what and when

Last updated on May 03, 2026

The 10 Transaction Templates

What templates are Most businesses post the same shapes of transactions over and over: - A coffee sale - A vendor payment - A bank transfer - A Bitcoin purchase - A monthly subscription expense Instead of filling in the same form fields each time, BitBooks gives you transaction templates. Pick a template, fill in the variables (amount, date, contact), save. The categorization, accounts, and structure are pre-set. The 10 default templates BitBooks ships with 10 templates covering the most common Bitcoin business operations: | # | Template | What it does | |---|---|---| | 1 | Sale | Customer paid you (cash or BTC). Money in, recorded as Sales income. | | 2 | Expense | You paid a vendor. Money out, recorded against an expense category. | | 3 | Payment Received | A customer paid an outstanding invoice. Money in, reduces Accounts Receivable. | | 4 | Payment Made | You paid an outstanding bill. Money out, reduces Accounts Payable. | | 5 | BTC Purchase | You bought Bitcoin. Fiat out of one wallet, BTC into another. | | 6 | BTC Sale | You sold Bitcoin. BTC out, fiat in. | | 7 | Manual Journal Entry | Custom entry for adjustments, depreciation, etc. (Advanced Mode.) | | 8 | Wallet-to-Wallet Transfer | Moving money between two of your own wallets. | | 9 | Lightning Receive | Customer paid via Lightning. Sats in, recorded as Sales. | | 10 | Lightning Send | You paid a vendor via Lightning. Sats out, recorded as Expense. | The first 6 cover ~80% of all transactions for a typical Bitcoin business. How to use a template When you click New Transaction, the modal opens in a default mode. You can pick a template from the type/template selector at the top. New Transaction modal with the template picker showing all 10 templates as a scrollable list or grid Pick one. The form pre-fills: - The transaction mode (Standard, Split, Transfer) - The default category for that template - The default direction (in or out) - Any specific helper fields You then fill in the variable parts (amount, contact, exact category if it differs, date, memo) and save. Templates speed up data entry. The form fields you'd otherwise pick from dropdowns are pre-selected. Template details Sale - Mode: Standard - Direction: Money in - Default category: Sales - Wallet: pick at entry time - Use for: customer payments for products or services Expense - Mode: Standard - Direction: Money out - Default category: Other Expenses (you'll usually change to specific) - Wallet: pick at entry time - Use for: paying vendors, buying supplies, software subscriptions Payment Received - Mode: Standard - Direction: Money in - Default category: Accounts Receivable (a contra-credit, reducing receivables) - Use for: when a customer pays an invoice you previously issued Payment Made - Mode: Standard - Direction: Money out - Default category: Accounts Payable (a debit, reducing payables) - Use for: paying a vendor invoice you previously received BTC Purchase - Mode: Transfer - From wallet: a fiat wallet - To wallet: a BTC wallet - Use for: buying Bitcoin BTC Sale - Mode: Transfer - From wallet: a BTC wallet - To wallet: a fiat wallet - Use for: selling Bitcoin (note: realized gain/loss may need a separate entry, see Recording a Bitcoin Sale) Manual Journal Entry - Opens the Advanced Mode (Journal Entries) form - Free-form: you write the debits and credits - Use for: anything that doesn't fit Simple Mode (depreciation, accruals, equity events) Wallet-to-Wallet Transfer - Mode: Transfer - Pick both wallets - Use for: moving money between your own accounts (hot to cold, checking to savings) Lightning Receive - Mode: Standard - Direction: Money in - Default wallet: your primary Lightning wallet (configurable) - Default category: Sales (often "Sales: Lightning") - Use for: customers paying via Lightning Lightning Send - Mode: Standard - Direction: Money out - Default wallet: your primary Lightning wallet - Default category: depends on what you bought - Use for: paying vendors via Lightning Customizing templates The default categories and wallets in templates are based on common patterns. You can override at entry time (pick a different wallet, different category). For deeper customization (changing defaults, adding new templates), this requires development. Reach out to support if you need a custom template for your business; we may build it as a config option. When to skip the template If your transaction is unusual enough that the template wouldn't help, just use New Transaction and pick the mode (Standard/Split/Transfer) directly. You're not required to use a template. For very irregular entries (depreciation, equity events, multi-currency adjustments), use Manual Journal Entry which drops you into Advanced Mode. Templates and Bulk Posting After creating several Drafts using templates, you can bulk-post them all at once. Templates don't change the bulk-post behavior; they just streamline the creation step. See Bulk Posting Drafts. Common questions "Why do I need a Lightning template if Lightning Receive is just a Sale?" It is just a Sale, but the template pre-selects the right wallet (your Lightning wallet), the right default category (Sales: Lightning if you have it, otherwise Sales), and saves clicks. For high-volume Lightning operations where you post 50+ Lightning sales per day, the template savings add up. "Can I make my own templates?" Not in the current UI. The 10 defaults are baked in. For custom templates, contact support. "I always use the same contact for cash sales. Can I default that too?" Templates don't currently default the contact. Workaround: when entering a sale, the contact dropdown remembers your most-recent contact, so it's one click to repeat. Where to go next - Creating a Transaction (Simple Mode) for the general entry flow - Recording a Bitcoin Purchase for the BTC Purchase template in detail - Recording a Bitcoin Sale for the BTC Sale template in detail - Bulk Posting Drafts for batch processing many Drafts

Last updated on May 03, 2026