How to Track Lightning Payments with Clams Accounting

Lightning Network transactions create a bookkeeping puzzle that most accounting software simply ignores. Channels open and close. Routing fees accumulate in millisatoshis. Force closes leave HTLCs hanging for days. Generic tools treat all of this as noise, leaving node operators to reconcile the mess manually.

Clams was built specifically to handle this complexity, offering native Lightning support that captures channels, payments, and fees with proper double-entry accounting. Here's how to set it up for accurate tracking and tax-ready reports.

Understanding What Needs Tracking

Before diving into setup, it helps to understand what Lightning activity actually generates from an accounting perspective.

Every channel open is a funding transaction that moves bitcoin from your on-chain wallet into a 2-of-2 multisig. That's a transfer between your own accounts, not a taxable event, but it needs recording. Channel closes (cooperative or forced) reverse this, sometimes with different amounts due to routing activity. Force closes add another layer of complexity with anchor outputs and time-locked HTLCs.

Then there's the ongoing activity: payments sent, invoices received, routing fees earned, and rebalancing operations. Each of these has different tax implications depending on your jurisdiction. Routing fees are typically income. Rebalancing is internal movement. Payments for goods or services might trigger capital gains on the bitcoin spent.

Clams handles all of this natively, distinguishing between transaction types and applying appropriate accounting treatment.

Connecting Your Lightning Node Directly

The cleanest approach is connecting Clams directly to your node for real-time sync. This captures everything automatically without manual exports or reconciliation gaps.

For LND Nodes

Clams supports LND connections via gRPC or Lightning Node Connect (LNC). You'll need to generate connection credentials from your node and enter them in the Clams connection settings. Once connected, Clams pulls your complete channel history, all payments sent and received, routing activity, and channel states.

The sync captures cooperative closes, force closes, anchor outputs, and HTLC roles (both offered and received). It also matches on-chain funding and closing transactions to their corresponding channel operations, giving you a unified view of on-chain and off-chain activity.

For Core Lightning Nodes

Core Lightning users connect via Rune authentication. The V1 Beta release from February 2026 added direct Core Lightning sync without requiring a proxy, simplifying the setup significantly. You can also upload node data directly if your node runs offline or behind restrictive firewalls.

Once connected, the sync behavior mirrors LND: full channel history, payment tracking, and automatic categorization of routing fees versus other activity.

Importing from Mobile Wallets

Not every Lightning wallet supports direct node connections. Phoenix, Wallet of Satoshi, and similar mobile wallets don't expose the interfaces Clams needs for automatic sync. For these, you'll use CSV imports.

Export your transaction history from your wallet (most have this option in settings), then use Clams' Import connection feature. The key is properly categorizing each transaction type:

• INVOICE for Lightning payments received
• PAY for Lightning payments sent

Each row needs a timestamp, amount (in BTC, SAT, or MSAT), and transaction ID. Fees are optional but recommended for accurate cost basis tracking. The import process validates your data format and flags any issues before committing.

This approach requires periodic manual exports, but it's far better than spreadsheet tracking for wallets that don't support direct connections.

Setting Up Cost Basis Methods

Clams supports FIFO (first-in, first-out), LIFO (last-in, first-out), and HIFO (highest-in, first-out) cost basis methods. Your choice affects capital gains calculations significantly, so pick the method that aligns with your tax strategy before processing transactions.

The double-entry ledger tracks each lot of bitcoin separately, maintaining cost basis through Lightning payments, channel operations, and on-chain transactions. When you spend bitcoin via Lightning, Clams calculates gains based on your chosen method and the specific lots being depleted.

This lot-level tracking is particularly valuable for routing node operators who see constant small movements. Generic tools either treat all bitcoin as fungible (incorrect for tax purposes) or require manual lot assignment (impractical at scale).

Categorizing Transactions Properly

Clams applies smart categorization to distinguish different types of Lightning activity, but you'll want to review and adjust as needed for your specific situation.

Routing fees earned are typically categorized as income, which is correct for most jurisdictions. Rebalancing operations (circular payments through your own channels) are flagged as internal transfers with no tax impact. Payments for goods and services need proper expense categorization.

The software handles the mechanical complexity of Lightning (HTLCs, channel states, on-chain anchoring), but the semantic meaning of each transaction, whether it's business expense, personal spending, or something else, requires your input.

Generating Tax Reports

Once your Lightning activity is tracked and categorized, Clams generates capital gains reports broken down by lot. You can see exactly which bitcoin was sold, when it was acquired, and the resulting gain or loss.

For routing node operators, the income reporting captures all fees earned with timestamps and amounts. This is essential for quarterly estimated taxes or annual filings where Lightning income needs declaration.

The reports are designed to be audit-ready, meaning they include the underlying transaction data and methodology, not just summary numbers. If a tax authority questions your reporting, you have the documentation to support it.

What Clams Handles That Spreadsheets Don't

The complexity that makes Lightning accounting difficult isn't any single transaction type; it's the interactions between them. A force close involves an on-chain transaction, pending HTLCs, anchor outputs, and eventually resolved payments. Tracking this in a spreadsheet means manually reconciling multiple data sources and hoping you don't miss anything.

Clams handles the matching automatically: funding transactions link to channels, closes link to settlements, HTLCs resolve to their final states. The double-entry system ensures everything balances, and discrepancies surface immediately rather than hiding until tax season.

For individual users running a single node, this saves hours of manual work. For LSPs and professional operators handling thousands of channels, it's the difference between manageable accounting and chaos.

Getting Started

The practical first step is connecting your primary Lightning node and letting Clams sync your history. Review the imported data to ensure channels, payments, and fees appear correctly. Set your cost basis method and verify the categorization makes sense for your activity patterns.

From there, it's ongoing maintenance: periodic review of new transactions, proper categorization of spending, and quarterly or annual report generation. The heavy lifting happens at setup; after that, Clams handles the mechanical complexity while you focus on the decisions that require human judgment.

Lightning accounting is genuinely hard, but it doesn't have to be a mess. The right tooling makes the difference between dreading tax season and having accurate, defensible records ready when you need them.