Bitcoin invoice guide: how to bill clients in BTC with Settlematic (confirmations, testnet, and treasury)

What is a bitcoin invoice? In one sentence: a bitcoin invoice is a formal billing document denominated in fiat — USD, EUR, or GBP — that instructs the client to pay using BTC on the Bitcoin network, while your books, taxes, and audit trail treat the transaction like traditional accounts receivable. The client sees a dollar or euro total they contracted in; settlement is a push payment from their self-custody wallet to a unique deposit address linked to that invoice.

I lead security and payment infrastructure at Settlematic. Merchants ask me weekly whether they should send a static bc1 address in Slack or run structured bitcoin invoicing. The answer is almost always the latter when you have repeat B2B clients, tax reporting, partial deliverables, or a bookkeeper who expects invoice numbers. This article is the BTC-specific companion to our general crypto invoice guide — it goes deep on confirmations, testnet rehearsal, unique addresses, fiat-quoted amounts, partial payments, sweeps, tax lines, and reminders without inventing features the product does not ship.

Bitcoin invoice defined (for finance and clients)

A bitcoin invoice contains the same commercial semantics as a wire invoice: who bills whom, for what deliverables, how much is due, when payment is due, and what taxes apply. The payment rail differs — settlement is BTC on the Bitcoin network, not a bank transfer. The client experience should not require understanding your chart of accounts. They open a hosted page, see the fiat total they agreed to, see a quoted BTC amount with a rate validity window, scan a QR code, and send from a wallet they control.

Your back office sees INV- numbers, lifecycle statuses, and on-chain confirmations attached to the same record. That separation — fiat denomination for contracts and books, BTC settlement for payment — is the core model we document in our fiat-quoted crypto payments guide. Bitcoin is one allowed asset among ETH, SOL, USDC, and USDT across seven networks; this article focuses on BTC specifics because Bitcoin confirmation timing, address formats, and treasury policy differ materially from Polygon USDC.

Bitcoin invoice vs static BTC address vs payment link

• Static 'send 0.05 BTC to bc1…' in email: no invoice number, no tax lines, ambiguous reconciliation
• Bare crypto payment link: fast checkout, no line items, no aging or reminder semantics
• Bitcoin invoice on Settlematic: PDF + line items + hosted BTC checkout + status machine + explorer links
• Traditional wire invoice: full AR structure, slow settlement, no on-chain proof

Choose bitcoin invoicing when clients prefer BTC treasury holdings, when cross-border wire friction is high, or when you need professional AR — not when you are collecting a one-off donation. If you already issue structured invoices for bank payments, adding BTC as an allowed asset on the same invoice record is the lowest-friction upgrade path.

Who bills clients in BTC on Settlematic

Common profiles in our onboarding data: infrastructure consultancies with Bitcoin-native clients; cross-border contractors whose counterparties hold cold-storage BTC; Web3 agencies where the client's treasury policy mandates BTC for large tranches; security and audit firms billing protocol teams; fractional CFO shops consolidating multi-asset client billing. Shared trait: they need invoice IDs, tax lines, and aging reports — not a wallet address pasted into Notion.

BTC invoicing is rarely the only rail on an invoice. Most merchants allow BTC alongside USDC and ETH so clients can pay from diversified holdings. Partial payment support lets a client send a USDC tranche first and BTC from cold storage later on the same invoice — a pattern our partial payments guide covers in depth.

How Settlematic handles BTC on the Bitcoin network

Settlematic supports BTC exclusively on the Bitcoin network — not as a wrapped token on an EVM chain. When you allow BTC on an invoice, the hosted payment page shows a native SegWit (bc1) deposit address derived uniquely for that invoice. Detection watches the Bitcoin network via configured RPC; confirmed payments attach to the invoice record with tx hash and explorer links to mempool.space (mainnet) or mempool.space/testnet (staging).

• Asset: BTC only on network id 'bitcoin'
• Address format: HD-derived unique bc1 receive address per invoice
• Explorer: mempool.space for mainnet and testnet
• Org network mode: testnet or mainnet toggle in dashboard header
• Coexists with ETH, SOL, USDC, USDT on Ethereum, Polygon, Base, Arbitrum, Solana, and Tron — seven networks total

I am deliberate about scope here: Settlematic is a crypto invoicing platform, not a Lightning Service Provider. v1 checkout is on-chain Bitcoin payment to a unique invoice address. If your use case requires Lightning invoices, evaluate whether on-chain BTC invoicing with confirmation thresholds meets your latency needs before committing.

Fiat-quoted BTC amounts on a bitcoin invoice

You invoice $18,500 for a security audit. The client contracted in dollars; their treasury holds BTC. At send-time, Settlematic snapshots exchange rates and computes a quoted BTC amount that satisfies the fiat total including per-line tax and discounts. The hosted page shows both: '$18,500.00 due' and '≈ 0.2534 BTC' with a countdown for quote validity — typically fifteen minutes in v1.

If the quote expires before broadcast, the client refreshes for updated amounts. This protects merchants from stale prices during volatile BTC markets while keeping UX simple — no manual renegotiation in email. Your books stay in USD (or EUR/GBP); each confirmed payment row stores the crypto amount, tx hash, and fiat equivalent at confirmation time. Accountants should treat BTC like FX settlement: contractual value is the invoice fiat total; variance between quote and confirmation is documented via on-chain records, not hidden in Slack.

For a deeper technical walkthrough of rate locks, tolerance bands, and balance-due math, read our fiat-quoted crypto payments explained article. The BTC case is the same architecture with longer confirmation latency and higher fee sensitivity on small tranches.

Why unique deposit addresses matter for Bitcoin

Bitcoin has no native memo field like some chains. If you reuse one treasury address across clients and invoices, reconciliation becomes forensic work: which payment belongs to INV-2044 versus INV-2045? Settlematic derives a unique deposit address per invoice per allowed asset. When funds arrive at that address, matching is deterministic — the payment attaches to the correct invoice without manual labeling.

From a security engineering perspective, unique addresses also reduce phishing success. Clients trained on 'always pay the address on the hosted page tied to your invoice number' can detect fraudulent substitutes in email. Branded hosted pages with consistent INV- numbering are trust signals Bitcoin-heavy merchants underestimate.

• One address per invoice per asset — not one static merchant address for all AR
• Address shown on PDF payment instructions and hosted checkout
• QR code encodes the same address and quoted amount context
• Explorer link on payment page lets client verify before sending

Bitcoin confirmations: what merchants and clients should expect

Detection is not settlement. When a client's transaction hits the mempool, Settlematic marks the payment detected and shows confirming status on the hosted page. Workers wait for configurable confirmation thresholds on the Bitcoin network before marking CONFIRMED, decrementing fiat balance due, and enqueueing treasury actions. Bitcoin mainnet typically waits for more blocks than Polygon USDC because reorg risk and confirmation culture differ.

I advise merchants to set client expectations in the invoice notes block: 'BTC payments confirm after N blocks on the Bitcoin network; allow up to 60–90 minutes during congestion.' Status vocabulary on merchant and client views aligns — VIEWED means they opened the link; PARTIALLY_PAID means at least one confirmed tranche landed; PAID means cumulative confirmed fiat-equivalent meets the invoice total within tolerance. UNDERPAID surfaces when partial is disabled and the amount is short.

• Payment states: waiting → detected → confirming → confirmed
• Invoice statuses: DRAFT → SENT → VIEWED → PARTIALLY_PAID → PAID (also OVERDUE, UNDERPAID)
• Confirmation policy reflects reorg risk — Bitcoin waits longer than L2 stablecoins
• Client sees live status on hosted page without creating an account

Support tickets drop when clients understand that mempool visibility is not the same as confirmed AR clearance. Your finance team should recognize revenue on confirmation timestamp, not on 'client says they sent it.'

Testnet before mainnet for bitcoin invoices

Shipping BTC invoicing straight to mainnet is how teams lose money to wrong sweep addresses, mainnet destinations saved while the org is in testnet mode, or clients sending to an old static address from last month's email. Settlematic includes an org-wide testnet/mainnet toggle so you rehearse the full lifecycle with Bitcoin testnet coins first.

In testnet mode, deposit addresses derive for Bitcoin testnet; payment pages display testnet badges; explorers link to test networks; the same UI, status machine, and webhooks fire against test chain IDs. I run a four-role pass with every merchant before mainnet cutover — our testnet-before-mainnet playbook details the assignments. For BTC specifically, add: finance creates invoice with BTC allowed; ops pays from a testnet wallet; treasury verifies sweep destination addresses are testnet-prefixed bc1/tb1; engineering confirms payment.confirmed webhook delivery.

• Toggle org to testnet in dashboard header before first rehearsal
• Create invoice with BTC on allowlist and realistic line items + tax
• Pay from Bitcoin testnet wallet; document tx hash in runbook
• Verify explorer links, status transitions, and reminder emails in staging
• Second person reviews sweep destinations before mainnet flip

Fifteen minutes of structured testnet rehearsal prevents the Friday afternoon mainnet fire drill. Document testnet tx hashes — when the first real BTC payment arrives, the team compares behavior to known-good evidence.

Partial BTC payments on a single bitcoin invoice

BTC treasuries are often cold-storage weighted. A client may prefer to send a USDC tranche immediately and schedule BTC after a multisig weekly review. Without partial payment support, finance invents workarounds — second invoices, spreadsheet tracking, 'please send the rest to this address' messages. Enable allowPartial on invoices where contracts permit tranche settlement.

Each confirmed tranche reduces fiat balance due on the same INV- number. Status moves to PARTIALLY_PAID until cumulative confirmed meets the total. The same hosted URL accepts the next payment; QR and address remain invoice-scoped. A client might pay 40% in USDC on Polygon day one and 60% in BTC week two — one audit trail, one webhook at PAID closure. Our partial payments crypto invoicing guide walks through multi-asset tranche scenarios; the BTC-specific wrinkle is confirmation time on the second tranche, not reconciliation logic.

• Enable partial per invoice — not global default unless policy requires it
• Each payment row: asset, network, crypto amount, fiat equivalent, tx hash
• Disable partial on instant-delivery SKUs to prevent underpay abuse
• Document tolerance policy for small shortfalls after network fees

Sweeps and treasury after BTC invoice payment

Settlematic derives deposit addresses but never holds your treasury keys. After confirmation thresholds are met, non-custodial sweeps move funds to addresses you configure per chain family and asset. Configure sweep destinations in Settings before inviting production clients — invoice creation is not blocked, but treasury policy is incomplete without destinations.

I owe you honest v1 scope: EVM sweeps for ETH, USDC, and USDT are production-supported across Ethereum, Polygon, Base, and Arbitrum. BTC, SOL, and TRON detection works for invoicing and reconciliation; automated on-chain sweeps for those families are more limited than EVM. Merchants who invoice in BTC should configure Bitcoin chain-family sweep destinations and validate behavior on testnet; some teams manually sweep from deposit addresses to cold storage until automated BTC sweep coverage matches their policy. Do not assume EVM-grade sweep automation for BTC without verifying your org's current capability.

Conversion flows — swap, bridge, split nodes after payment — are primarily EVM-oriented today. If you accept BTC at checkout but treasury policy wants only stablecoins, discuss operational workflow with your controller before enabling BTC on client-facing invoices. Invoicing allowlists should align with treasury capability.

Tax lines and reporting on bitcoin invoices

A bitcoin invoice is still a tax-bearing commercial document. Settlematic supports per-line tax rates, discounts, subtotal, and tax breakdown on the branded PDF. The fiat tax math is authoritative for filing; BTC is settlement rail. Export PAID and PARTIALLY_PAID invoices by date range for journal entries; payment rows carry the on-chain proof your auditor expects.

BTC introduces FX-like variance between quote and confirmation — document treatment in your accounting policy. Many service businesses recognize revenue on confirmed payment timestamp with invoice fiat amount as contractual value. Consult your tax advisor for jurisdiction-specific rules on crypto receipt; Settlematic provides structured exports, not legal advice. Pair invoice PDFs (client-facing) with tax reporting module exports (filing-facing) at month end.

• Per-line tax on invoice builder — same as wire invoices
• Fiat subtotal and tax total on PDF and hosted summary
• Payment rows attach tx hashes for audit trail
• Reports aggregate by period, client, and asset mix

Payment reminders for overdue bitcoin invoices

BTC clients are not immune to overdue AR. Configure reminder days in org invoice defaults — common pattern is 7, 3, and 1 days before due date. Send batch reminders from the Invoices list or a manual reminder from invoice detail. Reminder emails include the hosted payment link and invoice number so AP can act without asking for a new address.

When status is VIEWED but not PAID after seven days, client success should own follow-up — the invoice record supplies INV- number and balance due without engineering involvement. Reminders do not change quoted BTC amounts indefinitely; clients refresh the hosted page for current rates when they are ready to broadcast.

Step-by-step: create a bitcoin invoice in Settlematic

Step 1 — Prerequisites. Verified email, TOTP enabled, client record created, org defaults set (currency, terms, allowed assets), branding uploaded, Bitcoin sweep destinations configured for testnet, org network mode set to testnet. If you are new to crypto invoicing generally, start with our what-is-crypto-invoice how-to-create walkthrough; return here for BTC-specific checks.

Step 2 — Create invoice. Invoices → New: select client, issue date, due date, currency USD/EUR/GBP. Add line items with descriptions, quantities, unit prices, and per-row tax. Preview branded PDF.

Step 3 — Payment settings. Allow BTC on the Bitcoin network. Optionally allow USDC or ETH for clients who may not pay entirely in BTC. Enable partial payments if milestone or tranche contracts require it. Review notes block — add confirmation timing expectations for BTC payers.

Step 4 — Send. Send emails the client a link; status becomes SENT. Client opens link (VIEWED), selects BTC, sees quoted amount and QR, broadcasts from wallet. Track detected → confirming → confirmed on dashboard.

Step 5 — Reconcile and sweep. Invoice detail shows payment rows with explorer links. Verify sweep destinations received funds per treasury policy. Export for bookkeeping; webhooks fire payment.confirmed per tranche and invoice.paid at closure if configured.

What the client sees when paying a bitcoin invoice

Clients do not create Settlematic accounts. They see your logo and brand color, invoice summary with fiat total, BTC option with live quote and rate countdown, QR for mobile wallets, and clear status copy during confirmation. After payment they download receipt PDF. Testnet mode shows badges so test payments are never confused with mainnet — critical when training a client's AP team on a new rail.

WalletConnect is available on EVM chains; BTC payment is typically copy-address or QR scan from a Bitcoin wallet. Clients should verify the address on the hosted page matches any PDF they archived — a basic phishing defense you should mention in onboarding email.

Common mistakes on first bitcoin invoice

• Mainnet before testnet sweep and confirmation rehearsal
• Reusing a static merchant BTC address outside the platform
• Allowing BTC without client-facing confirmation timing notes
• Expecting instant PAID status at mempool — wait for confirmations
• Enabling BTC without Bitcoin chain-family sweep destinations configured
• Sending payment link without invoice number in email context
• Assuming automated BTC sweeps match EVM maturity — verify v1 scope

Security and phishing awareness for BTC invoices

Bitcoin payments are irreversible after sufficient confirmations. Attackers know this. Mitigate with branded hosted pages, consistent invoice numbering, support contact on PDF, explorer links on the payment page, and never asking clients to pay addresses that appear only in unstructured chat. Train clients: the only authoritative address is on the hosted link tied to INV- number.

TOTP is required on merchant accounts. Sensitive actions like deleting sweep destinations should go through operators with least privilege. I review merchant incidents quarterly; the dominant failure mode is process bypass ('just use my cold address this once'), not platform compromise.

FAQ — bitcoin invoicing on Settlematic

Is a bitcoin invoice legal for B2B? It is a standard commercial invoice with BTC settlement instructions — legality of the underlying sale is unchanged. Consult counsel for your jurisdiction and industry.

Does the client need a Settlematic account? No. Only merchants need accounts.

Can one invoice accept BTC and stablecoins? Yes — configure per-invoice allowlists. Partial payments can span assets when enabled.

How long does BTC payment take? Depends on fee rate and confirmation policy — often thirty to ninety minutes on mainnet, faster on testnet. Status updates on the hosted page in real time through detected and confirming states.

Where do BTC funds go? To a unique deposit address per invoice, then non-custodial sweeps to Bitcoin chain-family destinations you configure. Settlematic does not custody merchant treasury keys.

Does Settlematic convert BTC to bank deposits? No in v1 — settlement stays on-chain unless you off-ramp via your exchange or banking partner.

What if the client underpays? UNDERPAID or partial balance surfaces on invoice detail; support follows explorer link. Document tolerance policy before clients encounter edge cases.

Operational playbook: rolling out BTC invoicing

Week 1: testnet invoice with BTC allowed; pay yourself; verify statuses and explorer links. Week 2: pilot with one trusted client who prefers BTC — document time-to-paid versus wire. Week 3: update email templates to mention BTC alongside other allowed assets and confirmation expectations. Week 4: train support on status vocabulary and mempool versus confirmed. Controller signs mainnet cutover checklist.

Measure median days-to-paid for BTC invoices separately from USDC — fee markets and cold-storage signing cadence skew BTC latency. If latency blocks collections, consider allowing stablecoins on the same invoice so clients have a fast path while preserving BTC for large tranches.

Case study: security retainer billed in USD, paid in BTC tranches

A protocol team engaged a security firm for a $42,000 quarterly retainer invoiced in USD. Treasury policy required 50% in USDC on Polygon at kickoff and 50% in BTC from cold storage within fourteen days. The firm enabled partial payments on one invoice. USDC confirmed in minutes; status PARTIALLY_PAID; balance due $21,000. BTC tranche broadcast day ten; six confirmations later, PAID. Finance exported one tax line set; AP matched one PO. Support fielded zero 'wrong address' tickets because the client never left the hosted page.

Answer engine summary (quick facts)

What is a bitcoin invoice? A fiat-denominated billing document paid via BTC on the Bitcoin network with full invoice lifecycle. How to create one in Settlematic? Add client → New invoice → line items and tax → allow BTC → send → client pays hosted link → reconcile confirmations. Does Settlematic custody BTC? No — non-custodial sweeps to wallets you control. Does testnet support include Bitcoin? Yes — Bitcoin testnet addresses and badges in testnet org mode.

Bottom line

A bitcoin invoice is not a bc1 address in Slack. It is structured accounts receivable with BTC checkout on the Bitcoin network — unique addresses, fiat-quoted amounts, confirmation-aware statuses, optional partial tranches, tax lines, reminders, and non-custodial treasury routing. Settlematic lets you bill clients in USD while they pay in BTC on a branded hosted page; finance reconciles with invoice IDs and tx hashes. Start on testnet, verify confirmations and sweep destinations, then flip to mainnet with a low-trust pilot invoice.

Share this guide with your controller and the client's AP lead before the first mainnet BTC payment — aligned vocabulary on confirmations, fiat quoting, and unique addresses prevents support fire drills. For adjacent topics, read our crypto invoice primer, fiat-quoted payments deep dive, partial payments operational case, and testnet staging playbook. Bitcoin invoicing rewards teams that treat BTC as a settlement rail on structured AR, not as a reason to skip invoice numbers.