Reconciling crypto invoice payments for your accountant
A finance-focused guide to matching on-chain receipts to invoices, handling partial payments, and preparing exports your bookkeeper can actually use.
Accountants do not want wallet screenshots. They want invoices tied to payments, payments tied to bank or exchange records, and aging that matches reality. Crypto adds complexity — multiple chains, volatile rates, partial txs — but the reconciliation goal is unchanged: every dollar of revenue is traceable.
Start from the invoice, not the transaction hash
In Settlematic, the invoice is the system of record. Each invoice has a fiat total, line items, client, due date, and status timeline. On-chain receipts attach to that record via unique deposit addresses. Your bookkeeper begins with 'show me all PAID and PARTIALLY_PAID invoices in June' — not 'show me all incoming USDC'.
The reconciliation record set
- Invoice ID and client legal name
- Fiat amount due and balance remaining
- Crypto asset, network, and amount received
- Transaction hash and confirmation time
- Exchange rate at quote time (for audit trail)
- Sweep destination(s) and timestamps
Handling partial and multi-tx payments
When partial payments are enabled, each confirmation reduces balance due. Export reports should list tranches, not only final state. For month-end, decide policy: recognize revenue on final tranche vs pro-rata — consult your accountant for jurisdiction; Settlematic supplies timestamps and amounts either way.
Stablecoins vs volatile assets
USDC and USDT settlements map cleanly to fiat books when you treat them as dollar-equivalent at receipt, documenting the on-chain proof. ETH and BTC introduce FX-like variance between quote and confirmation. Many teams invoice in fiat, accept stablecoins only, and use conversion flows to move volatile receipts into preferred holdings — simplifying books while staying flexible at checkout.
Exports and ERP sync
CSV and PDF exports filter by date range, client, and status. Webhooks (invoice.paid, payment.confirmed) push events to middleware that maps into QuickBooks, Xero, or a data warehouse. Idempotent consumers keyed on event ID prevent duplicate journal entries.
Month-end checklist
- Aging report matches dashboard outstanding total
- Every CONFIRMED payment has a matching invoice in PAID or PARTIALLY_PAID
- Sweep txs on explorers match expected destinations
- Unapplied on-chain funds (wrong asset sent) documented with client follow-up
- Tax lines on invoices align with jurisdictional rules you have configured
Crypto invoicing does not remove the need for accounting judgment — it removes the need to reconstruct context from scattered chats. Give your accountant structured data and the conversation shifts from 'what was this payment for?' to 'how should we recognize it?'