A crypto invoice is a receivable with three jobs: quote an amount, bind a destination, and produce an audit trail when the chain confirms.
Most “crypto invoices” fail the second job. They are a PDF, a network dropdown, and a treasury address reused across every client. That is a request for payment. It is not an invoice the finance stack can close without a human matching tx hashes.
The object, not the asset
Quote in USD (or EUR). Settle in USDC, USDT, EURC, ETH, or BTC. Those are orthogonal. If you quote ETH, you turned AP into a trading desk. If you quote USD and settle USDC, you still need a rate lock for a defined window, or the payer and you will argue about basis points.
The invoice also has to name the chain. USDC on Ethereum is not USDC on Polygon. A shared address plus “pay USDC” is how wrong-chain tickets start.
Binding at issuance
The useful pattern is one address per invoice, generated when the invoice is issued — BIP-84 on Bitcoin, CREATE2 on EVM, a PDA on Solana. Funds go to an address that only that invoice owns. Matching is “did this address receive enough after finality,” not “who paid our hot wallet at 14:03.”
That is different from a vendor temp wallet that later sweeps to you. If the vendor can move the funds before you can, that is custody, whatever the landing page says.
What you should get back
- Invoice id, quoted fiat, locked rate, expiry
- Chain, asset, exact destination
- Tx hash, confirmations, paid / underpaid / expired
- A signed webhook so your ERP is not polling a dashboard
PDF is a view. The invoice is the ledger object plus the on-chain binding.
Settlematic Collect does this as a live product: fiat-quoted invoices, invoice-scoped addresses, watch-only matching. Gateway is sandbox. We do not operate as your wallet.
Longer canonical: what is a crypto invoice. Product: settlematic.com.
Top comments (0)