Bitcoin Invoice Guide: How to Bill Clients in BTC

Bitcoin invoicing confuses merchants because the asset is volatile and the UX is unfamiliar to most B2B payers. That does not mean Bitcoin billing is unprofessional — it means you need more structure than pasting a bech32 address into an email. This guide covers the technical and commercial decisions for billing clients in BTC while maintaining accountant-grade records.

Bitcoin invoicing vs sending a wallet address

A Bitcoin invoice is a structured payment request. A wallet address is a destination. The difference matters for reconciliation, audits, and client trust.

If you have never structured a crypto invoice, read what is a crypto invoice first. Bitcoin is one settlement asset within that model.

BIP-84 address derivation for invoicing

BIP-84 defines hierarchical deterministic (HD) wallet derivation for native SegWit addresses (bc1...). For invoicing, the critical property is generating a unique address per invoice from your master extended public key (xpub) without exposing private keys to the invoicing server.

The flow:

• You hold your Bitcoin wallet seed or hardware device
• You register your BIP-84 xpub with the invoicing platform
• Each invoice receives a unique derived address (e.g., bc1q...invoice89)
• Payment to that address is cryptographically bound to your wallet
• Private keys never leave your custody

This is the same non-custodial pattern described in what is non-custodial crypto invoicing. The platform watches the chain; it cannot spend your funds.

Why unique addresses per invoice: If you reuse one address for multiple open invoices, you cannot determine which payment settles which obligation. Unique derivation solves reconciliation at the protocol level.

BIP-84 vs legacy formats: Use native SegWit (bc1) for lower fees. Legacy (1...) and nested SegWit (3...) addresses still work but cost more on-chain. Modern invoicing platforms default to BIP-84.

Verify your provider's derivation path matches BIP-84 standard: m/84'/0'/0'/0/n for mainnet. Review security documentation and developer verification to confirm binding integrity.

Confirmation policy: when is an invoice "paid"?

Bitcoin confirmations are probabilistic finality. Your confirmation policy defines the threshold before marking an invoice paid and delivering goods or services.

Recommendation for most B2B merchants: One confirmation for invoices under $25,000; three confirmations above that threshold. Adjust based on your risk tolerance and industry.

Unconfirmed (0-conf) acceptance is rarely appropriate for B2B billing. Your client's wallet may broadcast a transaction that never confirms during fee spikes. Wait for at least one block.

Document your confirmation policy in invoice terms. Clients should know that "payment received" means on-chain confirmation, not merely "sent from wallet."

Volatility quoting strategies

Bitcoin's price moves. Your invoice quotes a fiat amount; the BTC settlement amount must account for movement between issuance and payment.

Practical approach for B2B:

• Quote invoice total in USD (or local fiat)
• When client initiates payment, display BTC amount based on current spot rate
• Set a 30-minute payment window with a locked rate
• If window expires, recalculate on next payment attempt
• Record fiat equivalent at confirmation for accounting

For clients who cannot tolerate BTC volatility at all, offer stablecoin settlement alongside Bitcoin. Multi-chain USDC acceptance is covered in how to accept stablecoin payments across multiple chains. Bitcoin and stablecoins are not mutually exclusive on the same invoice platform.

Building a professional Bitcoin invoice

Header and commercial fields

Include everything a traditional invoice requires:

• Invoice number and dates (issue, due)
• Seller legal name, address, tax ID
• Buyer legal name and billing contact
• Line items with descriptions, quantities, rates
• Subtotal, tax, total due in fiat

Bitcoin-specific payment block

• Accepted asset: BTC
• Network: Bitcoin mainnet
• Deposit address: unique bc1 address (derived, not static)
• Expected BTC amount: quoted per your volatility policy
• Payment link: hosted checkout page
• Confirmation requirement: "Invoice marked paid after 1 on-chain confirmation"

Terms and conditions

• Payment window for rate lock
• Late payment policy
• Who bears mining fee (typically payer)
• Refund policy (BTC refunds are operationally complex — define upfront)

Apply custom branding so the payment page does not look like a hobbyist wallet request.

Client education: reducing payment failures

Most B2B payment failures are education failures, not technology failures.

Email template snippet for first-time BTC payers:

> This invoice accepts Bitcoin payment. Click the payment link, copy the address or scan the QR code, and send the exact BTC amount shown from your wallet. Payment is confirmed after one blockchain confirmation (~10 minutes). Do not send from an exchange withdrawal unless the exchange supports custom amounts and bc1 addresses.

Common client mistakes to preempt:

• Sending from an exchange with delayed withdrawals
• Sending wrong amount (exchange fees deducted from send)
• Using legacy address format when bc1 is required
• Assuming "sent" equals "confirmed"
• Sending BTC while invoice rate window expired

For repeat clients, education burden drops. For enterprise accounts, consider a 15-minute call with their AP team before the first BTC invoice.

Automatic payment detection

Manual block explorer reconciliation does not scale. Production Bitcoin invoicing requires watching derived addresses and marking invoices paid when confirmations meet your policy.

The detection pipeline:

• Invoice created → unique bc1 address derived
• Client broadcasts transaction
• Platform detects unconfirmed tx (optional: show "pending")
• Confirmation threshold met → invoice status = paid
• Webhook fires to your backend
• Tx hash and fiat equivalent stored for export

See detect on-chain invoice payments automatically and webhook patterns for integration details. Test the full cycle in the demo sandbox before mainnet.

Self-hosted vs hosted Bitcoin invoicing

If Bitcoin is your only settlement asset and you have DevOps capacity, BTCPay Server vs hosted crypto invoicing compares the trade-offs in depth. If you want BTC plus USDC on multiple chains from one platform, hosted non-custodial invoicing reduces stack complexity.

Accounting and tax records for BTC invoices

Every paid Bitcoin invoice should produce:

• Invoice number linked to tx hash
• BTC amount received
• Fiat equivalent at confirmation time
• Timestamp of confirmation
• Client identity

Export CSV for QuickBooks, Xero, or your accountant. Bitcoin income is typically taxable at fair market value on receipt — jurisdiction-dependent. See do you pay tax on crypto invoice payments for US, UK, and EU frameworks.

Non-custodial settlement simplifies record-keeping: the tx hash on your wallet is the source of truth. No processor statement lag.

Lightning Network for Bitcoin invoices

Lightning enables instant, low-fee Bitcoin settlement for smaller amounts. Traditional on-chain invoices work for four-figure B2B payments; Lightning suits sub-$500 invoices where confirmation time matters.

Not all hosted invoicing platforms support Lightning natively. BTCPay Server excels here. Evaluate whether your invoice sizes justify Lightning integration or whether on-chain with one confirmation is acceptable for your clients.

Security considerations

• Use hardware wallet or air-gapped seed for the master key behind your xpub
• Never share seed phrases with any platform
• Verify derivation independently via developer tools
• Dedicated business wallet separate from personal holdings
• Monitor for address substitution attacks on compromised dashboards — hash-chained audit logs help; see security architecture

API integration for Bitcoin billing

Developers automating Bitcoin invoice creation should use the developer API:

• POST /invoices with fiat line items and accepted_assets: ["BTC"]
• Webhook invoice.paid with tx_hash, btc_amount, fiat_equivalent
• Sandbox testnet for CI pipelines — test crypto payments in sandbox

Settlematic Gateway supports embedded checkout if invoice documents are not your primary interface.

When Bitcoin invoicing is the right choice

Choose BTC billing when:

• Client explicitly prefers Bitcoin settlement
• You operate in Bitcoin-native industries (mining, certain dev tools, privacy-focused services)
• Cross-border wire alternatives are slow or expensive
• Client holds BTC treasury and wants to spend without conversion

Reconsider when:

• Client has never used Bitcoin and invoice amount is large
• Volatility during payment window creates dispute risk
• Client's AP department cannot process crypto without stablecoin option
• Your operating expenses are fiat-denominated and immediate conversion is costly

Offering BTC alongside USDC on the same invoice platform gives clients choice without maintaining separate systems.

Enterprise BTC invoicing policies

Enterprise clients paying in Bitcoin often require documented policies before first invoice:

Provide a one-page BTC payment addendum with your standard MSA. Include BIP-84 derivation explanation for security reviewers who ask how deposit addresses are generated without sharing private keys.

Enterprise AP may require vendor security questionnaire responses — link security documentation and confirm non-custodial settlement. BTC invoices from non-custodial platforms pass custody reviews more easily than custodial processor float models.

Treasury management after BTC invoice settlement

Receiving Bitcoin creates downstream treasury decisions fiat invoicing avoids:

Hold strategy — Treasury retains BTC as balance sheet asset; mark-to-market quarterly if required. Document cost basis at invoice confirmation FMV.

Immediate convert — Sweep to exchange and sell for fiat operating expenses. Record disposal gain/loss if BTC moved between confirmation and sale.

Scheduled convert — TWAP sell over 24–48 hours for large receipts to reduce slippage. Invoice FMV at confirmation; conversion gain/loss separate line item.

Most B2B service merchants convert within 7 days unless business model is Bitcoin-native. Pair BTC acceptance with USDC default for clients who want crypto speed without BTC volatility — multi-chain stablecoin guide.

BTC vs stablecoin invoicing comparison

Offer both on platform; default quote remains USD with client asset selection at checkout.

Conclusion

Bitcoin invoicing is professional when you treat it like invoicing — not like wallet sharing. Use BIP-84 derived unique addresses, quote in fiat with a clear volatility policy, require appropriate confirmations, detect payments automatically, and educate clients on the first transaction. Non-custodial architecture keeps settlement in your wallet; structured documents keep accountants satisfied.

Start with Settlematic Collect, validate BIP-84 binding in the demo, review security and developer docs, and send your first BTC invoice with the same rigor you would apply to a wire transfer request.