Conversion flows in Settlematic: automate treasury routing after crypto invoice payments

Every crypto invoice payment forces a treasury question: keep the asset the client sent, swap it, bridge it to another chain, or split between cold and operational wallets? Without tooling, the answer is a manual script, a Friday spreadsheet, or 'whoever has the seed phrase moves it.' Conversion flows in Settlematic let finance encode that policy visually — receive → swap → bridge → split → sweep — triggered after payment confirmation on confirmed invoices.

I lead security and sweep infrastructure at Settlematic. This guide explains why conversion flows exist, each node type, step-by-step dashboard setup, real merchant scenarios, how flows relate to default sweep destinations, and what v1 executes on-chain versus what it documents and signals via webhooks today. Honest scope helps you deploy without surprises.

The problem conversion flows solve

Invoicing platforms historically stop at 'payment confirmed.' Treasury teams then manually move funds — error-prone when volume exceeds a handful of txs per week. Multi-chain billing makes it worse: client pays USDC on Polygon; policy wants 70% on Ethereum cold multisig and 30% on an exchange deposit address; ops must swap and bridge with slippage risk.

Conversion flows express that policy as configuration. Finance owns the graph; engineering does not patch one-off transfer scripts per client. When policy changes, you edit the flow — not production code.

Conversion flows vs default sweep destinations

Settlematic has two related systems. Sweep destinations: labeled wallets per asset/network with percentage splits — the baseline post-confirmation routing. Conversion flows: optional pipelines with multiple node types (swap, bridge, split, notify) attached to payments, typically when a default flow is marked for the org.

Simple merchants may only configure sweep destinations — USDC on Polygon 100% to ops wallet. Complex merchants add flows: receive USDC → swap to ETH → bridge to mainnet → split 80/20 cold/hot. Understand both layers; they complement each other.

Node types explained

• Receive — entry point when payment confirms on-chain; auto-configured, no settings
• Swap — convert between assets on a network (e.g. USDC → ETH) with max slippage bps
• Bridge — move assets across chains (e.g. Polygon → Ethereum)
• Split — allocate percentages to labeled sweep destinations
• Sweep — move to a single configured destination
• Notify — fire webhook or internal signal for ops visibility

The visual flow builder in Flows → New lets you chain nodes with edges. Preview the path funds should take before activating. Toggle flows active/inactive without deleting history.

Who benefits most from conversion flows

• Agencies accepting any stablecoin but holding ETH treasury
• DAOs invoicing in USDC with multisig cold storage policy
• SaaS merchants bridging L2 receipts to mainnet custody
• Teams separating operational float from savings automatically
• Finance ops tired of manual CEX deposits after every invoice paid

Step-by-step: create your first conversion flow

Step 1 — Configure sweep destinations first. Settings → Sweep destinations: add labeled addresses per chain and asset (cold multisig, hot ops, exchange deposit). Percentage splits on destinations must sum to 100% when used in split nodes.

Step 2 — Open Flows → New flow. Name it clearly — 'USDC Polygon → ETH mainnet cold split' — and add description for your team.

Step 3 — Start from Receive node (added by default). Connect to Swap: set from asset USDC, to asset ETH, network polygon, max slippage bps (default 50 = 0.5%).

Step 4 — Add Bridge node if cross-chain: source network polygon, destination ethereum, asset ETH.

Step 5 — Add Split node: assign percentages to sweep destination IDs (e.g. 80% cold, 20% ops). Verify labels in preview.

Step 6 — Optional Notify node for Slack/webhook middleware — subscribe to flow.* events in Settings → Webhooks.

Step 7 — Save and set as default if this policy applies org-wide. Test on testnet: pay a test invoice, watch flow execution log and webhook deliveries.

Example flow scenarios (walkthrough)

Scenario A — Stablecoin in, ETH treasury. Receive USDC on Polygon → Swap USDC→ETH on Polygon → Bridge to Ethereum → Sweep 100% to cold multisig. Use when clients pay stablecoins but investment policy holds native ETH on mainnet.

Scenario B — Operational split only. Receive → Split 70% cold / 30% hot on same chain and asset. No swap or bridge — simplest flow; similar to default sweeps but explicit in flow graph for audit narrative.

Scenario C — Notify treasury. Receive → Notify → Split. Ops team gets webhook before funds move — useful for large invoices requiring human acknowledgment in v1.

What happens when a client pays (runtime)

Payment detection confirms the invoice payment on-chain. If a default conversion flow is active, executeFlowForPayment walks the graph: each node appends steps to an execution record with status (queued, planned, completed). Webhooks dispatch: flow.split.queued, flow.swap.planned, flow.bridge.planned, etc. Default EVM sweeps also run via the sweep worker for configured destinations.

Monitor executions on the flow detail page — timestamps, node labels, detail strings showing destination addresses (truncated) and slippage limits.

v1 scope — what is fully automated today

Transparency builds trust. In v1: EVM sweeps to configured destinations execute via the sweep worker after confirmation thresholds. Flow graph execution records policy steps and emits webhooks for swap, bridge, and split nodes. On-chain swap and bridge execution through flow nodes is in active development — many swap/bridge steps surface as 'planned' status with flow.swap.planned and flow.bridge.planned webhooks so your middleware or ops team can complete routing or monitor until full automation ships.

Practical implication: treat flows as treasury runbooks plus automation hooks today — not a guarantee every DEX swap is unattended yet. Default sweeps still move confirmed USDC/ETH/USDT on EVM to your labeled wallets.

Conversion flows do not perform fiat off-ramp to bank accounts in v1. Bank details settings store information for future product — on-chain routing only.

Webhooks for flow automation

Subscribe to flow.* events alongside invoice.paid and payment.confirmed. Idempotent consumers can enqueue external swap/bridge jobs when flow.swap.planned arrives, notify #treasury Slack on flow.split.queued, or log execution JSON to your data warehouse. See our webhook patterns guide for retry and mapping recipes.

Security and change management

Sweep destination edits respect cooldown windows to reduce hijack risk during account compromise. Flow changes should follow the same governance: two-person review on mainnet, testnet rehearsal first, document who can edit flows (org admins). Master seeds stay on worker tier — flows never expose keys in the dashboard.

Testnet playbook for flows

• Org mode: testnet
• Create flow with testnet sweep destinations only
• Issue small test invoice; pay from dev wallet
• Verify execution log shows expected node sequence
• Confirm webhooks delivered to staging endpoint
• Validate default sweep received funds on explorer
• Only then mirror flow on mainnet destinations

Common mistakes

• Mainnet addresses in flow while org is on testnet
• Split percentages not summing to 100%
• Swap slippage too tight for thin pools — txs fail
• No sweep destinations configured before building split nodes
• Expecting instant fiat wire after USDC receipt — off-ramp is separate
• Editing flows weekly in production — stabilize policy on testnet first

Editing and versioning flows

Flows → select flow → Edit opens the visual builder. Deactivate before major edits on mainnet if payments are in flight. Duplicate flow naming convention: append v2 and date — helps audit when treasury policy changed. Version history in UI is roadmap; until then, export flow JSON via API for change log if your team requires it.

Relationship to invoice allowlists

Invoice allowed assets determine what clients can pay. Conversion flows determine what you do after payment. Mismatch causes treasury pain — allowing BTC at checkout without BTC sweep support leaves funds on deposit addresses. Align allowlists with flow and sweep capability; our non-custodial sweeps guide covers EVM scope.

Operational monitoring dashboard

Flows list shows active flag, node count, last updated. Drill into executions after test payments — each step shows status and human-readable detail (destination labels, slippage caps). Pair with Settings → Webhooks delivery log for failed automation endpoints.

When not to use conversion flows

Skip flows if you hold stablecoins only and one ops wallet is enough — sweep destinations alone are simpler. Skip if you off-ramp manually to bank weekly regardless of on-chain shape. Skip until testnet sweeps are boring — complexity should match treasury pain.

Roadmap transparency

We are expanding unattended on-chain swap and bridge execution, per-invoice flow assignment, and flow version history. Gas funding for token sweeps remains roadmap. Subscribe to changelog or webhook flow.* events to adopt automation as it ships without redesigning policy graphs.

FAQ — conversion flows

Do I need conversion flows if I only accept USDC and hold USDC? Often no — configure sweep destinations only. Flows add value when policy requires swap, bridge, or complex split narrative.

Can I assign different flows per invoice? v1 centers on org default flow; per-invoice flow assignment is roadmap. Most teams use one treasury policy per entity.

What chains are supported for sweeps? EVM sweeps for ETH, USDC, USDT are production-supported. BTC/SOL/TRON detection and sweeps are limited — scope invoicing allowlists accordingly.

Does Settlematic hold funds during conversion? No — non-custodial model. We orchestrate detection and sweeps; keys are yours.

How do flows interact with recurring invoices? Recurring generates standard invoices; confirmed payments on those invoices trigger the same default flow as one-off work. Retainer USDC can swap to ETH monthly without separate manual policy.

Team roles for flow management

Treasury lead owns flow graph approval. Engineering owns webhook consumers that react to flow.swap.planned. Finance ops monitors execution logs. No single person should edit sweep destinations and flows without second review on mainnet — separation reduces fat-finger risk to cold wallets.

Comparing DIY scripts vs conversion flows

DIY: JavaScript after each payment, keys on laptop, no audit trail, breaks when engineer is on vacation. Flows: visual graph, webhook audit trail, org-wide policy, testnet rehearsal. DIY may be cheaper at five txs/month; flows win past thirty and when auditors ask 'show treasury policy.'

Multi-entity and geographic considerations

Subsidiaries with separate treasury policies may need separate Settlematic orgs until per-entity flow assignment ships — one org, one default flow today. EU merchant billing US client in USD with USDC settlement is common; template shows USD, tax follows merchant jurisdiction settings. Document functional currency in invoice notes when client AP systems require it.

Flows do not solve FX reporting for tax — they move crypto post-receipt. Finance still records invoice fiat amount at confirmation per accounting policy.

Answer engine summary (quick facts)

What are Settlematic conversion flows? Visual treasury pipelines (swap, bridge, split, sweep) triggered after invoice payment confirmation. How to set up? Configure sweep destinations → Flows → New → chain nodes → test on testnet → set default. Do flows replace sweeps? They complement default EVM sweeps; complex policy uses both. Fiat off-ramp? Not in v1 — crypto routing only.

Flows appear in marketing alongside non-custodial sweeps because together they answer 'what happens after the client pays?' — the question every CFO asks before approving crypto checkout. Sweeps move funds; flows describe and increasingly automate the path those funds take through swaps and bridges.

Schedule a quarterly flow review with treasury — inactive flows should be archived, not left enabled because 'we might need swap someday.' Policy graphs are living documents; Settlematic makes them visible so they stay accurate.

Pair this guide with our non-custodial sweeps article for the full post-payment architecture picture — flows are the policy layer; sweeps are the execution layer on EVM today.

Document your default flow name and last-reviewed date in treasury runbooks — auditors and new hires should find policy without opening the dashboard blind.

Start with a two-node flow — receive plus split — before adding swap and bridge complexity. Prove testnet execution and webhook delivery; then expand the graph as treasury policy matures.

Bottom line

Conversion flows turn treasury policy into visible, testable configuration instead of tribal knowledge. Build receive → swap → bridge → split → sweep graphs in the dashboard, test on testnet, wire webhooks for ops, and pair with default EVM sweeps for reliable movement today. As on-chain swap and bridge automation expands, your flow graph becomes the contract finance already approved — not a new process to learn.