Home Bitcoin Features Lightning vs On-Chain: How BitBooks Handles Both

Lightning vs On-Chain: How BitBooks Handles Both

Last updated on May 02, 2026

What "Lightning" and "on-chain" mean

Bitcoin has two settlement layers:

  • On-chain is the main Bitcoin network. Transactions are written to the blockchain. They're settled (with confirmations) within ~10 minutes to an hour. Used for larger amounts.
  • Lightning is a layer-2 network on top of Bitcoin. Transactions settle in seconds. Used for everyday payments, especially small amounts.

A coffee shop typically uses Lightning (5,000 sats for a coffee, paid in 2 seconds). A treasury might use on-chain (moving 5 BTC to cold storage).

Many businesses use both.

How BitBooks treats them

The same. To BitBooks, a Lightning sale and an on-chain sale are both "BTC came in." The accounting is identical:

  • Wallet balance goes up
  • Income account (Sales, etc.) goes up by the dollar equivalent
  • The transaction is recorded with its sat amount, date, and rate

The wallet you assign matters (Lightning sales hit your Lightning wallet, on-chain sales hit your on-chain wallet), but the accounting structure is the same.

What changes is some metadata:

  • Lightning transactions have a payment hash and a memo
  • On-chain transactions have a transaction ID (txid), an address, and a confirmation count

BitBooks records what the wallet provider gives us. You don't have to think about it.

Settlement and "cleared" status

The biggest practical difference is settlement timing.

Lightning

Lightning payments settle in seconds. By the time they appear in BitBooks, they're effectively final.

Cleared status: usually Cleared as soon as it imports.

On-chain

On-chain transactions need confirmations. Most wallets consider 1 confirmation enough for small amounts and 6+ for large amounts.

A pending on-chain receive (0 confirmations) is Not cleared. It becomes Cleared once confirmed enough.

A pending on-chain send is also Not cleared until it confirms. If a transaction has 0 confirmations, there's a small chance it never confirms (the network can drop unconfirmed transactions). Treat unconfirmed receives as provisional.

Routing fees vs network fees

Lightning routing fees

Most Lightning wallets pay routing fees on your behalf (the recipient sees the gross amount, the fee is implicit in the path). For a 5,000-sat sale, you typically receive all 5,000 sats and the fee is invisible.

For high-volume Lightning operations, you may want to track routing fees as a separate expense. Configure your wallet provider to surface fee data, then create a "Lightning Network Fees" expense account, and post a small entry per fee. Most small businesses ignore this.

On-chain network fees

On-chain transactions cost network fees, paid in sats. The fee scales with transaction size and current network congestion.

When you send on-chain, the network fee is deducted from the amount sent. Example: you send 0.1 BTC, the recipient receives 0.0995, the 0.0005 went to network fees.

To record the fee:

  • Bake it in. Just record the actual amounts sent and received. The fee is implicit.
  • Itemize. In Advanced Mode, three lines: receiver gets X, network fee is Y, total leaving your wallet is X+Y. Use this if you want fees on the P&L.

The fee account would be "On-Chain Network Fees" under expenses (sub-type COST_OF_SALES if Bitcoin operations are central, or G&A if incidental).

Different wallets for different layers

Most Bitcoin businesses end up with at least two wallets:

  • A Lightning wallet for daily ops (Blink, Phoenix, Strike)
  • An on-chain wallet for treasury and larger transactions (Coinbase, hardware wallet, cold storage)

BitBooks treats them as separate wallets. Each has its own balance, its own connector (or manual flow), its own sync settings.

You can also have a Lightning + on-chain combo wallet that does both (some providers support this). In BitBooks, you'd typically still split it into two wallets if the underlying provider treats them as separate balances.

Auto-sync support

Currently:

  • Blink (custodial Lightning + on-chain) is supported via Bitcoin Connections
  • More providers being added

For unsupported wallets (hardware wallets, self-custody software wallets), use Creating a Wallet by Hand and enter transactions manually or via CSV.

Common questions

"Should I record Lightning and on-chain to the same Sales account?"

Either approach works:

  • One Sales account for all Bitcoin sales, regardless of layer. Simpler.
  • Two Sales accounts (Sales: Lightning, Sales: On-Chain) if you want to see each on the P&L separately. Useful for analyzing which channel is growing.

Pick based on whether the distinction matters to your business decisions.

"Do I need to track Lightning channel funding?"

Only if you run your own Lightning node. For users of custodial Lightning (Blink, etc.), the provider handles channels and you don't see them.

If you run your own node, channel funding is more accounting-aware: opening a channel locks BTC, closing returns it. You'd record these as transfers between your "Cold Storage" wallet and a "Lightning Channel Reserve" wallet. Talk to your accountant if this applies.

"What about taproot, sidechains, drivechains, etc.?"

These all eventually settle to on-chain Bitcoin. BitBooks treats them like any on-chain transaction: an amount, a date, a wallet. The protocol details don't affect bookkeeping.

"What about stablecoins (USDT, USDC) on Lightning?"

Some Lightning wallets support stablecoin transactions (Taproot Assets, others). When supported, BitBooks treats them as transactions in their own currency (USDT, USDC), separate from BTC. The wallet would need to expose them as a separate currency-balance.

Where to go next