Partial Payments on Crypto Invoices: How Multi-Tranche Settlement Works

B2B payments are not always single transfers. Enterprise treasuries batch payouts. DAO multisigs split approvals across weeks. Clients accidentally underpay by gas-deducted amounts or overpay to round up. Milestone contracts specify 40% on kickoff, 30% at midpoint, 30% on delivery — three payments, one commercial obligation.

Crypto invoicing without partial payment support forces merchants to issue three separate invoices for one milestone schedule, or manually track wallet deposits against open AR — both error-prone. This guide explains how multi-tranche settlement works on non-custodial crypto invoices: underpayment, overpayment, tranche schedules, reconciliation, and webhook events integrators need.

Why partial payments exist in B2B crypto billing

Card networks handle partial capture natively. On-chain payments are push-based — the invoicing platform must aggregate inbound transfers against an open invoice object. Non-custodial systems do this by monitoring a single bound deposit address for multiple incoming transactions.

Architecture: one address, many transactions

Non-custodial partial payment tracking relies on:

• Unique deposit address per invoice — BIP-84 derivation, CREATE2 forwarder, or Solana PDA bound at issuance
• Per-transfer detection — each confirmed tx increments amount_received
• Cumulative threshold — invoice status transitions at configured completion rule
• Webhook per event — payment.received, invoice.partially_paid, invoice.paid
• Immutable binding — address cannot change mid-invoice so late tranches still route correctly

The platform never pools funds — each transfer lands at the invoice address until swept to merchant treasury. See non-custodial sweeps explained for post-payment consolidation.

Custodial processors track partial payments on internal ledgers. Non-custodial systems track on-chain reality — the distinction matters for audit: your evidence is tx hashes, not processor balance entries.

Invoice states for partial payment workflows

Tolerance rules matter for stablecoins: a €10,000 invoice might close at €9,999.50 received if within 0.01% rounding tolerance — configurable per org. BTC and ETH invoices need wider tolerance or exact-amount enforcement because FX and fee deductions vary.

Display balance due on the hosted payment page so clients sending tranche two know the remaining amount.

Tranche schedules: contractual vs organic

Contractual tranches

Milestones defined in SOW:

• Tranche 1: 40% on signature — €4,000 of €10,000
• Tranche 2: 30% on design approval — €3,000
• Tranche 3: 30% on delivery — €3,000

Implementation options:

For DAO clients, a single invoice with partial tracking often works best — the governance proposal references one invoice PDF while multisig executes multiple payments over time.

Organic partial payments

Client sends what treasury approves without following a schedule. Partial status accumulates until threshold met. Finance follows up on balance due via email and dashboard.

Underpayment: detection, tolerance, and remediation

Underpayment occurs when amount_received < amount_due after a confirmed transfer.

Common causes:

• Client deducted network fees from send amount (wrong — fees are separate on most chains)
• Wrong token or network — payment not detected (separate issue, not partial)
• Multisig approved reduced amount vs invoice
• Decimal precision error (USDC 6 decimals vs display rounding)

Platform behavior:

• Detect transfer; increment amount_received
• Set status partially_paid
• Fire payment.received webhook with tranche amount and running total
• Show balance due on payment page and merchant dashboard
• Send automated reminder if configured

Merchant remediation:

• Contact client for balance transfer to same invoice address (binding ensures attribution)
• Issue credit note and new invoice only if original invoice expired or address rotated
• Do not accept "make up" payments to a different address without manual reconciliation

Configure minimum partial payment amount if micro-payments create noise — e.g., ignore dust below €1.

Overpayment: tolerance, credit notes, and refunds

Overpayment when amount_received > amount_due + tolerance.

Document overpayment resolution in your payment terms. Non-custodial refunds require merchant-initiated outbound tx — the platform does not hold funds to deduct automatically. For small overages on stablecoin invoices, many merchants absorb or credit rather than pay refund gas.

Webhook: invoice.overpaid or payment.received with overpayment_amount field — verify schema in developer documentation.

Reconciliation across multiple tx hashes

Each partial payment produces a distinct on-chain record. Accounting exports should list:

Month-end close ties each tx hash to fiat value at confirmation timestamp. How to reconcile crypto payments covers batch workflows.

Unique per-invoice addresses eliminate ambiguity — all tranches share one address, all txs map to one invoice ID. Shared-wallet partial payments require memo matching that fails on exchange withdrawals.

Webhook events for integrators

Integrators building ERP, fulfillment, or notification flows should handle:

payment.received

Fires on each confirmed inbound transfer to the invoice address.

invoice.partially_paid

Summary event when status transitions to partially paid (may co-fire with payment.received).

invoice.paid

Fires when cumulative received meets completion threshold.

invoice.overpaid

Fires when received exceeds tolerance — triggers ops review workflow.

Integration requirements:

• Verify webhook signatures — see crypto payment webhooks reconciliation
• Idempotent processing — same event may retry; key on event_id or tx_hash
• Do not fulfill on first payment.received unless business rules allow partial delivery
• Log cumulative state for support debugging

Test full partial flows in the demo sandbox before production webhook deployment.

Confirmation policy per tranche

Each tranche should meet confirmation thresholds before incrementing amount_received:

Premature crediting of unconfirmed transfers risks double-spend or reorg reversal. On-chain payment confirmation lists indicative policies.

Partial payments vs multiple invoices

Prefer single-invoice partial tracking when tranches settle against one commercial obligation. Prefer multiple invoices when tranches are legally distinct (separate deliverables, separate tax points).

UI and client communication

Hosted payment pages should show:

• Original quoted amount
• Amount received so far
• Balance due
• List of confirmed payments with tx links (optional, for transparency)
• Same deposit address for all tranches — critical client education

Email templates for partial status: "We received €4,000 of €10,000 for Invoice INV-2026-0842. Balance due: €6,000. Pay to the same link."

DAO clients appreciate tx hash visibility — aligns with public treasury transparency norms.

Non-custodial security considerations

Partial payments do not change custody model — funds still land at merchant-bound addresses. Security review points:

• Address binding immutable for invoice lifetime
• No platform ability to redirect mid-tranche
• Sweep only after merchant policy (per tranche or on full payment)
• Webhook authenticity via HMAC signatures

Read security architecture and what is non-custodial crypto invoicing.

Edge cases

Client pays from multiple wallets. Same deposit address accepts any sender — all txs aggregate. No action needed.

Client pays wrong network. Not detected as partial — funds may be lost or require manual recovery. Invoice specifies network prominently; validate in UI.

Invoice expires with partial payment received. Merchant policy: extend invoice, issue credit note for received amount, or refund partial via on-chain send. Platform should preserve partial payment history on expired invoices for audit.

Concurrent txs in same block. Detection order may vary; cumulative total is commutative. Webhook order may not match block order — integrators use cumulative fields, not event sequence.

Stablecoin depeg during multi-week tranche schedule. Fiat quote is fixed at invoice issuance; USDC amount is computed at send time per platform rules. Document depeg policy in terms of service.

Platform configuration in Settlematic

Settlematic Collect enables partial payment tracking per invoice or org default:

• Toggle partial payments on milestone and large B2B invoices
• Set completion tolerance for stablecoins
• Configure reminder cadence for open balances
• Export payment arrays with tx hashes for accounting
• Fire webhooks per developers event schema

Pair with recurring billing for retainers that occasionally split across two monthly treasury votes — see recurring crypto invoices.

Gateway supports partial payment patterns for high-value checkout where cart total may be paid in tranches — same detection architecture.

Putting it together

Partial payments make crypto invoicing viable for enterprise treasuries, DAO multisigs, and milestone contracts — without sacrificing per-invoice reconciliation. One bound address, cumulative on-chain detection, clear invoice states, and webhook events per tranche give finance and integrators the same visibility card partial capture provides, without custodial float.

Enable partial tracking on large B2B and milestone invoices, configure tolerance and reminders, test multi-tranche flows in the demo, and integrate webhooks via developers. Settlematic Collect and Gateway implement non-custodial partial settlement with full tx-hash audit trails — review security before production use.

DAO and multisig payment coordination

DAO clients paying milestone invoices through multisig treasuries introduce governance latency unrelated to invoicing software. A 40/30/30 tranche schedule may span six weeks if each tranche requires separate governance vote, signature collection, and on-chain execution. Set invoice due dates and reminder cadence accounting for governance cycles — not just calendar net-30 from issue date. Include in SOW: "Client acknowledges multisig approval timelines; overdue status applies only after governance-approved payment window expires."

Provide DAO treasurers with cumulative payment status visible on hosted payment page — public transparency norms favor showing tx hashes of completed tranches. When governance approves tranche two before tranche one confirms on-chain, do not fulfill milestone two work until tranche one detection completes — contract enforcement remains merchant responsibility regardless of DAO internal votes.

Accounting treatment of partial payments across fiscal periods

Partial payments spanning fiscal year boundary create reporting complexity. US cash-basis taxpayers generally recognize income when payment received — a $10,000 invoice with $4,000 received December 28 and $6,000 January 5 splits income across tax years. Accrual taxpayers may recognize full amount at invoice date regardless of payment timing — partial payments affect AR, not necessarily revenue recognition timing. Coordinate with CPA before first multi-tranche invoice crosses year-end.

Export partial payment arrays with per-tranche timestamps for audit defense. Month-end close should show partially paid invoices in AR aging with balance due, not as fully paid with unexplained variance. See month-end reconciliation for partial payment row handling in reconciliation worksheets.

Partial payments in subscription and usage-based hybrids

SaaS and API businesses combining usage-based billing with crypto settlement sometimes issue invoices where final amount is unknown until period close. Partial payment support still applies when clients prepay estimated amounts or pay in tranches against a true-up invoice issued after usage calculation. Pattern: issue estimated invoice at period start (optional partial payment), issue true-up invoice at period end with balance due reflecting actual usage minus prepayment received.

Webhook integrators should key fulfillment on invoice.paid for true-up invoice, not prepayment tranche, unless contract explicitly allows service continuation on partial prepayment. Document prepayment credit application in invoice line items — "Less prepayment received per INV-2026-0088: -$2,000" — so clients and accountants understand cumulative obligation.

Support workflows for partial payment disputes

When clients dispute partial payment status ("we sent full amount"), support should verify: sum of confirmed on-chain transfers to invoice address, configured tolerance rules, whether any transfer arrived on wrong network (not counted as partial), and whether client sent from exchange that deducted fees from send amount. Provide explorer links for each credited tranche and running total from platform dashboard — on-chain evidence resolves most disputes without escalation.

Escalate to finance when cumulative received plus documented pending unconfirmed transfer still falls short — never mark paid manually without on-chain confirmation meeting policy thresholds. Manual overrides destroy audit trail and webhook integrity for integrators downstream.