Home Troubleshooting

Troubleshooting

Things going wrong, and how to fix them.
By Miguel Abascal
6 articles

My Wallet Balance Doesn't Match: How to Fix It

The short answer If the balance in BitBooks doesn't match what you see at your wallet provider (Blink, your bank, your hardware wallet), one of six things is usually going on: 1. Drafts. There are unfinished entries that aren't on reports yet 2. Pending sync. Recent transactions haven't imported yet 3. Pending confirmations. Bitcoin transactions that exist but aren't fully settled 4. Opening balance set wrong. The wallet's start date or amount is off 5. Manual transactions duplicated. Someone entered a transaction by hand that the auto-sync also imported 6. A real bug in the data. Rare, but it happens This article walks you through how to check each one, in the order that's most likely to find the answer fast. Before you start, gather two numbers Open your wallet provider in another tab and write down: - The current balance (what your provider shows) - The most recent transaction (date, amount, direction) Now in BitBooks, open the wallet's detail page (Wallets → click the wallet name). You'll see a balance there too. The difference between the two numbers is your puzzle. Let's solve it. Check 1. Look for Drafts Drafts don't show up in your reported balances or on the Insights page. But the wallet's internal balance might still include them, depending on which page you're looking at. Go to Transactions in the sidebar. Filter by your wallet (top-left filter). Look for any rows with a Draft badge. Transactions page filtered to one wallet, with a Draft row highlighted If you see Drafts: - They might be legitimate work in progress. That's fine, leave them as Drafts and your real balance is still correct. - They might be forgotten imports waiting for review. Open them, fix any details, post them. - They might be duplicates. See check 5. After posting or deleting any Drafts, refresh the wallet page and see if the balance now matches. Check 2. Has the wallet synced recently? On the wallet's detail page, look for the Last synced timestamp. - Synced just now / minutes ago. Sync is current. Move to the next check. - Synced hours ago. Possible there's a transaction that hasn't imported yet. Click the Sync now button and wait a few seconds. - Never synced / Error. Sync isn't running. See Connecting Your Bitcoin Wallet for reconnection steps. If you click Sync and the balance updates, you found the issue. New transactions usually import within seconds. Wallet detail page showing "Last synced: 2 minutes ago" with a Sync Now button Check 3. Pending vs settled transactions Bitcoin has confirmation states that bank money doesn't. A Lightning payment can be in-flight (en route, not yet settled). An on-chain payment can be unconfirmed (broadcast, not yet in a block) or partially confirmed (in a block, but waiting for more confirmations). In BitBooks, transactions have a Cleared status: - Not cleared. Recorded but not yet confirmed at the wallet provider - Cleared. Confirmed, settled, real - Reconciled. You've reviewed and matched it during reconciliation Your wallet provider might be showing you the settled-only balance, while BitBooks shows you everything (including not-cleared). Or vice versa. To check: filter Transactions by your wallet, look for entries with Not cleared status. Add up those amounts. That's the difference. If your provider's balance is lower than BitBooks' balance, the difference might be a not-yet-cleared incoming transaction. The Bitcoin is on its way but not fully arrived. If your provider's balance is higher than BitBooks' balance, the provider might be including a transaction BitBooks hasn't picked up yet (run another sync to be sure). Check 4. Verify the opening balance When you first connected this wallet, whether by hand or through a Bitcoin Connection, you set an opening balance and a start date. The opening balance is what was in the wallet on the start date, and BitBooks treats it as truth. If the opening balance was wrong, every running balance after it will also be wrong. To check: 1. Go to Wallets, click the wallet name 2. Look for the wallet's Opening balance and Start date 3. Cross-check: at your wallet provider, what was the balance on the start date? If they don't match, you have your answer. The fix: - For wallets you created manually, you can edit the opening balance from the wallet's settings (Edit wallet). - For wallets connected via Bitcoin Connections, contact support. There are some safety rails around editing connected-wallet opening balances after-the-fact. Wallet detail page with Opening balance and Start date highlighted in the metadata Check 5. Duplicates from manual entries This is the most common source of mismatches when a wallet is partly auto-synced and partly hand-entered. Common scenario: you manually recorded a transaction last week. Later, you connected the wallet to BitBooks. The auto-sync didn't know about your manual entry, so it imported the same transaction again. Now you have two entries for one event, and the wallet balance is off by exactly that amount. To find duplicates: 1. Open Transactions, filter by your wallet 2. Sort by date (newest first) 3. Look for two entries with the same date, same amount, same direction, that you remember happening only once If you find duplicates: - Delete the manual one (the one you typed in) if it's still a Draft - Reverse the duplicate if the manual one was already posted - Don't delete the auto-synced one. It'll just come back on the next sync, and the underlying record at your provider will keep producing it Two transaction rows on the same date with identical amounts, side by side, with one marked for deletion Check 6. Run the Trial Balance A Trial Balance is a one-page summary that totals every debit and every credit across all your books. If the two totals don't equal each other, something is broken at a deeper level. Go to Reports, click Trial Balance. Trial Balance report showing matched debit and credit totals at the bottom - If debits = credits at the bottom, your books are internally consistent. The mismatch with your wallet provider is one of the issues above (drafts, sync timing, opening balance, duplicates), not a deeper data problem. - If debits ≠ credits, there's a real data integrity problem. Don't try to fix this yourself, contact support and we'll look at it. Mismatched debits and credits should not happen, and if it has, we want to investigate the root cause, not just patch the number. What does not cause balance mismatches A few things that look suspicious but are fine: "My Posted entries don't match the bank statement to the dollar" That's normal during the month. Your wallet provider's balance shows everything including pending transactions. Your books show everything posted, which excludes Drafts but includes Posted-but-not-yet-cleared. They'll only fully agree after reconciliation. See What is Reconciliation. "BitBooks shows my BTC balance in dollars and the value keeps changing" That's the Bitcoin price moving, not your balance. The amount of BTC in the wallet is fixed; the dollar equivalent changes as the price changes. Switch to one of the BTC display modes (see BTC Display Modes) to see the BTC amount stable. "I closed last month and now January's numbers are different from what I exported in February" If they're Posted numbers, they shouldn't change after a month is closed (period close locks them). If they did change, something is wrong, contact support. If they're Insights dashboard numbers (which include some real-time recalculations like Bitcoin's current value), those can shift over time as exchange rates fluctuate. The reports themselves are stable; the dashboard's "current value" recomputes. Quick diagnostic checklist Print this, save it, whatever, works as a fast triage: □ Are there Drafts on this wallet? Post or delete them □ Was the last sync recent? If old, click Sync Now □ Any "Not cleared" transactions? That's likely the gap □ Does the opening balance match what was in the wallet on the start date? Fix it if not □ Any duplicate entries? Reverse or delete the duplicate □ Does the Trial Balance balance? If not, contact support If you've gone through all six and the balance still doesn't match, contact support with: - The wallet name - The amount of the mismatch (e.g., "BitBooks shows 0.5 BTC, my provider shows 0.52 BTC, difference is 0.02") - The date you noticed it - Whatever you've already checked from the list above We'll dig in from there. Where to go next - See What is Reconciliation for the formal process of matching books to a wallet statement - See Cleared vs Uncleared Transactions for the full explanation of those statuses - See Reversing a Posted Entry for the right way to undo a duplicate - See Trial Balance Report for what the Trial Balance is and how to read it

Last updated on May 03, 2026

Bitcoin Connection Sync Stopped Working

How to recognize the problem Signs that auto-sync is broken: - The wallet's status shows Error on the Wallets page (instead of Synced) - New transactions at the wallet provider aren't showing up in BitBooks - The "Last synced" timestamp is days old when you expect minutes - A red dot or warning icon next to the wallet name Wallets page with one wallet showing an Error status badge Step 1: trigger a manual sync Sometimes a transient error resolves itself: 1. Open the wallet (click its name in the Wallets list) 2. Click Sync Now 3. Wait a few seconds If it succeeds: the status changes to Synced, recent transactions show up. You're done. If it fails again: continue diagnostic steps. Step 2: check the error message The wallet detail page usually shows a message describing the failure. Common ones: | Error message | What it means | |---|---| | "Authentication failed" | Your provider credentials are no longer valid | | "Connection timed out" | Provider's API is slow or unreachable | | "Rate limit exceeded" | We're being throttled by the provider; will recover automatically | | "Provider not found" | Service-side issue (rare) | For "Authentication failed," go to Step 3. For others, wait an hour and retry (Step 1). Most resolve themselves. Step 3: reconnect the wallet (for auth errors) If credentials at the provider have changed (you rotated your password, the provider invalidated a session), the connection needs refreshing. 1. Go to Admin → Connectors 2. Click the wallet 3. Click Reconnect (or Disconnect, then re-add via Add Connection) Wallet detail page with the Reconnect option visible in the actions menu The flow: 1. BitBooks asks for your vault password (to unlock the existing credentials slot) 2. You sign in to the wallet provider (fresh auth) 3. BitBooks updates the stored credentials 4. Sync resumes After reconnecting, click Sync Now to verify it works. Step 4: check the provider directly Sometimes the issue is at the provider's end: - Sign in to your wallet provider (Blink, Coinbase, etc.) directly - Confirm your account is active - Confirm your transactions are visible there - Check the provider's status page for outages If the provider has an outage, BitBooks can't sync until they're back. Wait it out. If your account is locked or suspended at the provider, you'll need to resolve that first. Step 5: check the credential vault The Bitcoin Connections vault holds your provider credentials. If something is wrong with the vault (rare), you might need to reset. Symptoms: - Reconnecting doesn't help - Multiple wallets connected via the same vault all fail - The "Forgot password?" or vault-related screens appear unexpectedly The fix: from Admin → Connectors, look for "Reset vault" (this disconnects all wallets and clears the vault; you'll reconnect each one fresh). See The Bitcoin Connections System. This is rarely needed. Most sync issues are at the individual-wallet level. Step 6: contact support If you've worked through Steps 1-5 and sync is still broken: Send to support: - The wallet name - The error message (screenshot if possible) - When sync last worked (approximate) - Steps you've tried Most issues are resolvable. Some require backend changes (e.g., a provider API change we need to adapt to). Either way, we'll dig in. What to do while sync is broken You don't have to stop working: - Enter transactions manually for the broken wallet. Use Simple Mode (Transactions → New Transaction). You're effectively running it as a manual wallet temporarily. - Don't dispose of transactions at the provider that BitBooks hasn't yet captured. They'll auto-import later when sync is restored. - Note the disruption in your records (a quick log of "sync broken Mar 15 to Mar 20" so you can re-verify later). When sync is restored, BitBooks should pull in any missed transactions. Reconciliation at month-end will surface anything that didn't import. What auto-sync handles vs doesn't handle It's worth knowing what auto-sync covers: Handles automatically - New transactions appearing at the provider - Updates to confirmation status - Balance refreshes Does NOT handle automatically - Provider API breaking changes (we adapt manually) - Provider account suspensions (need your action) - Cross-account transfers within the provider (some providers) - Old transactions from before the connection date (you'd manually import these) For the things sync doesn't handle, manual entry or CSV import is the workaround. A worked example Monday morning. You open BitBooks. The Blink wallet shows Error. Step 1: click Sync Now. It fails after 5 seconds with "Authentication failed." You remember: you changed your Blink password last night. Step 3: go to Admin → Connectors. Click Blink wallet. Click Reconnect. BitBooks asks your vault password. You enter. The Blink sign-in popup opens. You sign in with your new password. The popup closes. You click Sync Now. Status changes to Synced. The 12 transactions from the weekend now appear in BitBooks as Drafts. Total time: 3 minutes. Routine. Common questions "How often does sync run?" Every few hours by default. Click Sync Now any time for an immediate refresh. "What if I disconnect and reconnect a wallet, will I lose history?" No. Disconnecting only ends the live link. Historical transactions stay. When you reconnect (using "Attach to existing wallet"), you re-link to the same wallet without losing anything. "Will reconnecting create duplicate transactions?" Auto-sync deduplicates by the provider's transaction ID. So a transaction that was imported before, and is in the provider's history again, won't be re-created. You're safe. Where to go next - How Auto-Sync Works for the sync mechanics - The Bitcoin Connections System for the credential vault details - Disconnecting or Re-syncing a Connected Wallet for the disconnect/reconnect flow - Connecting Your Bitcoin Wallet for the full setup

Last updated on May 03, 2026

Transactions Showing Twice (Duplicates)

What duplicates look like Two (or more) entries with: - Same date - Same amount - Same direction (both money in, or both money out) - Same wallet - Possibly different contacts or memos If you remember the actual event happening only once, you have duplicates. Why duplicates happen Most common causes: Manual entry plus auto-sync You manually entered a transaction last week. Then auto-sync ran and imported the same transaction. Now there are two: yours plus the auto-import. This is the #1 source of duplicates. The auto-sync doesn't know about your manual entry; it imports based on the provider's record. Re-imported CSV You imported a bank statement CSV. Then the next month's CSV included some overlap. Both imports created entries. CSV imports usually let you specify a date range to limit; if you didn't, you get overlap. Auto-sync with a glitch Rarely, auto-sync runs twice quickly and dedup logic doesn't catch the second pass. Recent versions of BitBooks dedupe by provider transaction ID, so this is rare. Older sync runs may have produced this. Multiple users entering the same thing Two team members each entered the same transaction without checking the other. Common in busier teams without coordination. How to find duplicates From the Transactions page 1. Filter by wallet 2. Sort by date (newest first or oldest first) 3. Scan for runs of identical-looking entries Duplicates often cluster: same day, same amount, same direction. Easy to spot when sorted. Transactions table sorted by date with two identical-looking rows highlighted From the General Ledger 1. Reports → General Ledger 2. Filter to the wallet's account 3. Look for repeated entries The GL shows running balance; a duplicate entry doubles the impact, which can be obvious. From reconciliation Reconciliation surfaces duplicates automatically. If your wallet has 30 transactions but BitBooks has 32, two of the 32 are likely duplicates. How to fix duplicates Three options depending on the duplicate's status: Both are Drafts Easiest case. Pick one to keep, delete the other. For an auto-sync duplicate: delete the manual entry. The auto-import is the fresh source of truth, and the auto-sync will keep producing it. One is Posted, one is Draft Delete the Draft. Keep the Posted one. If the Draft was the auto-import and the Posted was manual: posting the auto-import again would just create more confusion. Delete the auto-import Draft. Both are Posted Reverse one of them. Pick the one with worse data quality (less complete contact, unclear memo, less likely to be the "real" record). The reversal creates a reversing entry that cancels the duplicate. Both stay in the books with a clear audit trail. Reverse confirmation dialog on a Posted transaction If the duplicate was the auto-import: reversing the auto-import means the next sync may try to re-import it. Watch for that and reverse again if it happens. Or reverse the manual one and let the auto-import be the source of truth going forward. Preventing future duplicates Don't double-enter If a wallet auto-syncs, don't ALSO enter transactions manually. Pick one source. Use the deduplication keys When importing CSV, BitBooks deduplicates by transaction ID where the CSV provides one. If your bank's CSV doesn't include unique IDs, deduplication is limited; pick a clean date range to avoid overlap. Coordinate the team If multiple people enter transactions, agree on a process: "the Lightning auto-sync handles all Lightning sales; nobody enters Lightning sales manually," or "Brandon does the bookkeeping on Mondays; nobody else touches it those days." Reconcile monthly Monthly reconciliation surfaces duplicates within a month, before they multiply. Catch them early. A worked example Reconciling Blink for March. You expect 145 transactions, BitBooks has 147. You scan the Transactions list filtered to Blink, sorted by date. Two pairs of identical entries on March 12 and March 18: same time, same amount, same direction, same memo. You investigate March 12: a Lightning receive of 8,000 sats. The auto-sync imported it on March 12. You manually entered it on March 13 (you'd seen the Blink notification and assumed it wasn't already in BitBooks). You delete the manual one (still in Draft status). Now Blink has 146 entries. Same for March 18. Now Blink has 145 entries. Reconciles. Time to clean up: 5 minutes. Common questions "Can I run a 'find duplicates' report?" Not as a built-in feature today. The workaround: export the Transactions list to Excel, sort by amount and date, look for adjacent rows with identical values. Pivot tables can help. A "duplicate detection" feature is on the roadmap. "What if the duplicate is in a closed period?" You can't directly delete or edit Posted entries in a closed period. The fix: reverse one of them (the reversal lands in the current period, which is allowed). The closed period's books stay as-is, the current period absorbs the correction. "My sync keeps creating the same duplicate every day. How do I stop it?" The provider is providing the same transaction with a different ID each time, defeating dedup. Talk to support; this is a sync bug we want to fix. Where to go next - Bulk Posting Drafts for the bulk-action workflow - Reversing a Posted Entry for the reversal mechanics - How Auto-Sync Works for sync mechanics including dedup - Reconciliation for catching duplicates at month-end - My Wallet Balance Doesn't Match for the balance-side perspective

Last updated on May 03, 2026

Wrong Exchange Rate on a Transaction

How to recognize the problem You see a multi-currency transaction with a rate that doesn't match what you actually got, or doesn't match the market rate for that day: - A BTC transaction from yesterday at $80,000 per BTC, but the market that day was around $85,000 - A EUR transaction recorded at 1.05 EUR/USD when you remember the rate being 1.08 - A transaction stuck in Pending status because a rate didn't fetch This article walks through diagnosing and fixing. Step 1: confirm what rate was used Open the transaction. Click into its detail. Scroll to the line items. Each line in a multi-currency entry shows: - The transactional amount and currency - The functional value - The exchange rate - The rate source provider - The rate timestamp The rate is what was used. Note the value. Transaction line detail showing the exchange rate, source, and timestamp Step 2: confirm what rate it should be Two ways to check: Look up the historical rate yourself For BTC: go to CoinGecko, look up BTC/USD historical price for the transaction's date. Compare. For fiat: go to Open Exchange Rates' historical page or any reputable rate source. Compare. If they match, BitBooks used the right rate. The "wrong" rate is just what the market was that day. Move on. If they differ significantly, continue. Check the rate provider's data The rate source provider is shown in the line detail. If BitBooks used "OPEN_EXCHANGE_RATES" but you'd expect a different rate, the issue might be that provider's data for that day was off. Step 3: decide whether to fix it Three scenarios: The rate is just slightly different (rounding cents) Don't fix. Rounding differences between rate providers are normal. The accounting is fine. The rate matches the date's market but you got a different actual rate Common when you trade through an exchange that adds a spread. The "market" rate was $80,000 but you actually paid $80,400 effective rate after fees. Two options: 1. Accept the market rate as recorded. Implicit fee is a $400 difference between cost basis and actual cash out. 2. Override with your actual rate. Edit the line, manually set the rate to $80,400 / 1 BTC. The line's functional value updates accordingly. The second is more accurate but requires you to know your actual rate. The rate is wildly off (10%+ different from any reasonable market rate) Probably a provider data issue or a pinned-at-wrong-time problem. Investigate: - Check the rate timestamp; is it the right time? - Try fetching the rate from a different provider for that date - If the issue persists, contact support How to manually override a rate For a posted entry, you may need to reverse and re-enter rather than edit (depends on which fields are edit-locked). For a Draft, you can edit directly. For a Draft journal entry: 1. Open the entry 2. Click into the multi-currency line 3. The rate field is editable; click to change 4. Enter the rate you want 5. Save For a posted multi-currency line, the rate is locked. Reverse and re-enter with the correct rate. Journal entry line detail with the rate field editable, showing a manual rate being entered "Pending" rates A rate can be Pending when BitBooks couldn't fetch it at the time of transaction creation. Causes: - The rate provider's API was down - A rate-limit throttled us - The currency pair isn't supported by the provider - The transaction date is in the future The line shows "Pending" instead of a value, and the functional total includes a placeholder. To resolve: 1. Click the Retry pending rates banner at the top of the Transactions or Journal Entries page 2. BitBooks tries to fetch again 3. If successful, the rate fills in and the transaction is recalculated If retry doesn't work after several attempts, the rate may not be auto-fetchable. Manually enter it (see Manual Override above). Banner across the top of Transactions reading "X rates pending" with a Retry button Bulk-fixing wrong rates If many entries have the wrong rate (e.g., you imported a CSV with stale rates that need to be refreshed): 1. Filter Transactions / Journal Entries to the affected period 2. Open each entry, fix the rate 3. (For Draft entries) re-fetch via "Retry pending rates" if applicable There's no bulk rate-correction tool in the current UI. For many corrections, contact support; we may have backend tools to help. Common questions "Why doesn't BitBooks just use the actual exchange rate from my exchange?" Because we don't have a real-time feed from every exchange. We use one or two reference providers (Open Exchange Rates for fiat, CoinGecko for BTC). For your actual trade-time rate, you'd manually enter it. A future version may integrate exchange-specific rate feeds. "What rate is best for my multi-currency lines: market or actual?" Depends on the use case: - For ongoing operational entries (you bought something in EUR while traveling): market rate is fine - For trade entries (you bought BTC at an exchange, exact rate matters): actual rate For high-volume trading, accept market rate everywhere and book a separate "Exchange Spread" expense for the difference. "My BTC rate fluctuated 5% during the day. What's 'the' rate?" BitBooks uses 5-minute buckets for BTC. The rate at the bucket containing your transaction time is used. So a 14:00 transaction uses the 14:00-14:05 bucket, not the day's average. If you need a specific intraday rate (e.g., your trade executed at 14:23:17), the closest 5-minute bucket should match closely. Where to go next - How Exchange Rates Work in BitBooks for the rate fetching system - How Currency Conversion Works for the conversion mechanics - Reversing a Posted Entry for how to fix a posted entry's rate - The Three-Currency Model for the broader currency framework

Last updated on May 03, 2026

Report Numbers Look Wrong

What "wrong" usually means Report numbers can look wrong for several reasons. Before assuming there's a bug: 1. The number might be right, just unexpected 2. The number might reflect data you forgot about 3. The number might be wrong because the underlying data is wrong Investigate before acting. Don't post correcting entries until you understand the cause. Step 1: drill into the number The most powerful tool: click any number on any report. It opens the General Ledger filtered to that account, showing every transaction that contributed. For example, if your P&L says "Software Subscriptions: $9,500" and you're surprised: 1. Click the $9,500 number 2. The page navigates to GL Detail for Software Subscriptions 3. See every transaction: dates, amounts, contacts, memos Drill-down view showing the transactions behind a P&L line Skim the transactions. Often the number is right; one big transaction (an annual subscription) accounts for the unexpected total. Step 2: filter by date If the number covers a longer period than you thought, change the date range: - "Year to date" includes January through today; that's potentially 12 months in December - "Last month" might be the calendar month or rolling 30 days; check - Custom ranges let you pinpoint A number for a custom March 1-15 will look different from a number for all of March. Step 3: check the currency If your organization has a reporting currency (a secondary view), reports can display in either functional or reporting currency. The toggle is at the top of the report. If the number is in a different currency than you thought, the absolute value will look different. Confirm which currency the report is showing. Step 4: check for posted-but-not-cleared Reports include all Posted entries by default. Posted-but-not-yet-cleared transactions affect the numbers. If you expect "the cleared portion only," that's a different filter. The Reconciliation report or a custom GL view can isolate cleared vs not. Step 5: check for archived accounts or wallets If you archived a wallet that had transactions, those transactions still affect historical reports. They might show under a "(archived)" tag. Toggle "Show archived" on the Chart of Accounts or Wallets to see archived items. If a number is appearing because of an archived item, you can either: - Accept it (the historical data is valid; archiving just hides the entity from new entries) - Investigate whether the archive was a mistake (re-activate if so) Step 6: run the Trial Balance If a number on the Balance Sheet or P&L looks wildly wrong (off by hundreds or thousands more than you'd expect), the issue may be deeper than a single transaction. Run Reports → Trial Balance. If debits don't equal credits, there's a data integrity issue. See Trial Balance. Mismatched Trial Balance = real bug. Contact support before trying to fix. Common causes of "wrong" numbers Drafts you forgot about Drafts don't show on reports, but you may be expecting them to. Check the Transactions / Journal Entries pages filtered to status = Draft. Real but un-posted entries wouldn't be in your reports yet. Period-end timing A transaction dated April 30 vs May 1 might land on different months. If a vendor invoice arrived on May 2 for April 28 work, the date you used affects which month it hits. Accrual vs cash differences If your books are accrual basis (BitBooks default), revenue is recognized when earned (invoice date), not when paid. A January invoice paid in February shows as January revenue, not February. This trips up users who expect cash-basis ("I haven't gotten the money yet, why is it on the P&L?"). FX conversion artifacts Multi-currency transactions translate to functional currency at the rate of the day. If rates moved, totals can look off compared to a "naive" sum. Reversed entries A reversed entry has zero net effect (it cancels itself), but if you're looking at the original entry alone, you might see it in the GL with status Reversed. The reversal is a separate entry. Both stay in the audit trail. Account categorization changed If you reclassified an account (changed its sub-type), the report layout shifts. The number didn't change; its location did. What to do if the number is genuinely wrong If after drilling, you've identified that a transaction is wrong (wrong amount, wrong account, wrong date): If the transaction is a Draft Edit it directly. Save. If the transaction is Posted (in current period) Reverse it. Post a new corrected entry. See Reversing a Posted Entry. If the transaction is in a closed period Don't reopen the period casually. Post a current-period correcting entry instead. See Period Close. What to do if you can't find the cause If after drilling, filtering, and investigation, you still can't explain the number: 1. Run the Trial Balance for the period; verify debits = credits 2. Run the Activity Log for the period; look for unusual changes 3. Re-run the report after re-fetching pending rates 4. Contact support with the report, the period, and what you've checked Most "wrong" numbers turn out to have a logical explanation. Some are bugs. Either way, support can help. Common questions "My P&L for last month is different than what I exported last week." If the period was open at the time of the export, new entries (or edits) since then could change the number. Once a period is closed (Lock Date set), the numbers should be stable. "My YTD is off by exactly the amount of one transaction." Drill in. Check the date of the transaction; is it actually within the YTD range? Sometimes a transaction landed in a different month than expected. "My Insights page numbers don't match my Reports page numbers." Should match. If they don't, possible causes: different date ranges, different currency views, the Insights page caching while Reports is live (try refreshing). If still mismatched, contact support. Where to go next - Trial Balance for the books-health-check - General Ledger for transaction-level detail - Activity Log for the audit trail - Reversing a Posted Entry for fixing a wrong posted entry - My Wallet Balance Doesn't Match for wallet-specific number issues

Last updated on May 03, 2026

How to Reset a Stuck Draft

What "stuck" means You have a Draft entry that's misbehaving: - It won't save (every save fails) - It won't post (the Save and Post button does nothing or errors) - It won't delete (the Delete button errors) - The form shows old values that you can't change - The browser shows a spinner that never resolves Most of these are transient. A few simple steps clear them up. Step 1: refresh the page The simplest fix: 1. Save the form (or close it without saving if save isn't working) 2. Reload the browser (Ctrl+R or Cmd+R) 3. Open the Draft again This clears any stale form state. About 80% of "stuck" Drafts resolve here. Step 2: check for required fields If the form won't save, look for required-field errors: - Wallet (every transaction needs one) - Amount (must be a positive number) - Date (must be a valid date) - Direction (money in or money out) - Currency (usually inferred from wallet, but may need explicit selection) Errors usually show inline next to the field. Scroll the form looking for red highlights. For journal entries: debits must equal credits. The form footer shows the running total; if it's not zero (balanced), save fails. Form with a required-field error highlighted in red Step 3: try a different browser Browser extensions or cached state can interfere. Open BitBooks in a different browser (or an incognito window). Try the action there. If it works: the issue is your primary browser's state. Clear cache for the BitBooks domain or disable extensions. If it still doesn't work: the issue is server-side or in your data. Continue diagnosing. Step 4: check the network tab If you're comfortable with browser developer tools: 1. Open DevTools (F12) 2. Click the Network tab 3. Try the action that's failing 4. Look at the failed request The response (red rows) often shows an error message that hints at the cause: - 400 = bad data (form fields invalid in some way) - 401/403 = permission issue - 500 = server error (rare; report to support) Send the error response to support if you can't interpret it. Step 5: check the period lock If you're trying to save a Draft with a date in a locked period, save will fail with an error: "Locked period." Either: - Change the Draft's date to a current-period date - Reopen the locked period (with caution; see Reopening a Closed Period) For everyday clean-up, changing the date to today is the easier path. Step 6: check for pending exchange rates If the entry has multi-currency lines and one currency's rate is Pending, save may behave oddly. Look at the line detail; if rate is shown as Pending, click Retry pending rates to resolve. Once rates resolve, the entry can post. Step 7: try deleting and starting over If the Draft is genuinely stuck and Steps 1-6 don't help: 1. Open the Draft 2. Click Delete (Drafts can be deleted, unlike Posted entries) 3. If delete fails too: contact support with the Draft's ID If delete succeeds, recreate from scratch. Often the new entry posts cleanly because the stuck-state quirks don't repeat. When delete won't work If even delete fails: - The Draft might be in an inconsistent state on the server - A related entity (a wallet, a contact) might have a constraint preventing deletion - A bug Send to support: - The Draft's slug or ID (visible in the URL when you have the Draft open) - The error you're seeing - What you've tried Most stuck-Draft scenarios are resolvable on the backend. Preventing future stuck Drafts A few habits that help: Save frequently Don't keep a half-finished Draft open for hours. Save what you have, come back later. Browser state lasting a long time is more likely to drift out of sync with the server. Don't open the same Draft in multiple tabs Two tabs editing the same Draft can produce inconsistent state. Pick one. Refresh before posting in long-running sessions If you've been working in BitBooks for hours, refresh before posting big entries. Long-running sessions accumulate cruft. Use Save and Post when you're sure If you're sure the entry is right, click Save and Post rather than two clicks. Reduces the window where things can go wrong mid-flow. A worked example You've been entering March's transactions. You're on entry #15. You click Save. Spinning wheel. Three minutes pass. Nothing happens. Step 1: refresh the browser. Reopen entry #15. The form shows the data you'd typed. Try save again. It works this time. The original spinner was likely a network glitch or backend hiccup that didn't resolve. Refresh kicked it loose. Common questions "I've been waiting 5 minutes for save to complete. Is it still saving?" No. Saves should be near-instant. After 30 seconds with no result, assume it failed and refresh. The data you typed is still in the form (browser-side); you can re-save after refresh. "My Draft says 'unsaved changes' but I can't save. What now?" The unsaved changes are in your browser, not on the server. Try Step 1 (refresh) but copy your data out first (e.g., into a text file) so you don't lose it. After refresh, paste the data into a new Draft. Save fresh. "What if my organization has a custom workflow that requires a specific value to save?" Some org configurations require certain fields (e.g., approval threshold means amounts above a level go into Pending). The form should tell you what's required. If you're getting save errors but no clear message, contact support. Where to go next - Draft vs Posted for the entry lifecycle - Bulk Posting Drafts for handling many Drafts at once - Period Close for understanding locked periods - Wrong Exchange Rate on a Transaction for rate-pinning issues

Last updated on May 03, 2026