Canonical: https://builtonarc.app/guides/usdc-invoicing-on-arc

# USDC invoicing on Arc: terms, FX timing, and proof of payment

Updated 2026-09-02. How USDC invoicing on Arc differs from fiat invoicing — payment terms, FX at invoice vs settlement, partial payments, and proof of payment.

> Invoicing in USDC on Arc works structurally like invoicing in any foreign currency today — the differences that matter are when the exchange rate is fixed relative to invoice issuance and payment, how partial payments are handled without a card network's split-payment tooling, and what counts as proof of payment on a settlement rail with no bank intermediary to issue a confirmation. Nothing described here is live yet; Arc mainnet is 16 September 2026.

## Payment terms carry over, mostly unchanged

Net-30, net-60, early-payment discounts, late fees — none of this is specific to the payment rail, and a USDC invoice can carry the same terms a fiat invoice would. What changes is enforceability mechanics: a traditional invoice's late-payment consequence often runs through a banking or factoring relationship; a USDC invoice's practical enforcement is closer to any other unsecured B2B receivable, since there's no automated late-fee assessment or account freeze available through the payment rail itself. Build your collections process accordingly rather than assuming the rail enforces terms for you.

## The FX question: rate at invoice time, or rate at payment time

This is the one genuinely new decision an invoicer needs to make deliberately, and it doesn't have a single right answer. If your invoice is denominated in USDC (effectively USD) but your business reports in another currency, or vice versa, you have to decide whether the exchange rate used is the one at invoice issuance or the one at actual payment — and state that explicitly on the invoice, because USDC itself doesn't fluctuate meaningfully against the dollar (it's a dollar-pegged stablecoin), but the currency you're converting to or from does. A 30-day payment term creates real exposure to rate movement between issuance and settlement if that's not pinned down in writing. This is standard foreign-currency-invoicing practice, not something unique to stablecoins, but it's worth stating on every USDC invoice explicitly rather than assuming the counterparty shares your default assumption. Built on Arc's <a href="/stablecoin-fx-on-arc">FX on Arc guide</a> covers where conversion spreads actually sit if a conversion leg is involved.

## Partial payments: no card-network split, so state your own rule

A card processor can often handle a partial payment against an invoice as a native feature. A USDC transfer is just a transfer — there's no invoicing-system-level enforcement that a payment must match the invoiced amount exactly unless your own invoicing software or a payments provider builds that reconciliation logic for you. Practically, this means you need a stated policy for what happens if a customer sends less than the invoiced amount (or, less commonly, more): does it count as partial settlement with a balance still due, does your system flag it for manual review, or does your invoicing tooling handle threshold-based auto-matching? Ask any invoicing or payments provider you evaluate exactly how they handle an underpayment or overpayment against an invoice reference — this is a real gap in some early-stage tooling in this category.

## Proof of payment: the transaction hash is the receipt, but it needs context

A confirmed USDC transaction has a transaction hash, visible on a block explorer, that is in one sense stronger proof of payment than a bank transfer confirmation — it's independently verifiable by anyone, immediately, without waiting on a bank's confirmation process. But a transaction hash by itself doesn't say which invoice it was for; that link exists only if your invoicing system captured a reference (a memo field, a unique receiving address per invoice, or a provider that maps incoming transactions to invoice IDs automatically). Treat "we can prove the payment happened" and "we can prove which invoice it was for" as two separate claims — the first is close to automatic with a blockchain-based rail, the second requires the same reconciliation discipline covered in Built on Arc's <a href="/how-to-accept-usdc-payments-on-arc">accept-payments guide</a>.

## What to set up before sending a first USDC invoice

Concretely: a stated FX-timing rule if any currency conversion is involved, a stated partial-payment policy, and either a unique payment reference per invoice or a provider that generates one automatically so a confirmed transaction hash can be matched back to the invoice it settles. None of this requires new invoicing software necessarily — it requires the same rigor already applied to any foreign-currency B2B invoicing, adapted for a rail where no bank intermediary is doing reconciliation for you by default.

{{entries:category=payments-payouts}}

Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.



Sources:
- [Circle Announces Founding Validator Cohort and Major Integrations for Arc](https://www.circle.com/pressroom/circle-announces-founding-validator-cohort-and-major-integrations-for-arc-ahead-of-september-16-mainnet-launch)
- [Arc | The Economic OS — official site](https://www.arc.io/)

## Questions

**Does a USDC invoice need different payment terms than a fiat invoice?**

No — net-30, early-payment discounts, and similar terms carry over unchanged. What differs is that enforcement (late fees, collections) isn't automated by the rail the way some bank-integrated invoicing tools handle it.

**Does USDC's value fluctuate, creating FX risk on invoices?**

USDC is a US-dollar-pegged stablecoin and does not carry meaningful independent price volatility. FX exposure arises only when converting to or from a different currency (your reporting currency, or a customer's local currency) — pin down whether that conversion uses the rate at invoice time or payment time.

**What happens if a customer underpays a USDC invoice?**

There's no automatic handling unless your invoicing or payments provider builds it — decide and state your policy (partial settlement with balance due, manual review, threshold auto-matching) before it happens, not after.

**Is a blockchain transaction hash sufficient proof of payment?**

It proves the transfer happened and is independently verifiable. It does not, by itself, prove which invoice it was for — that link requires a payment reference captured at the point of transfer.

**Is any of this live on Arc yet?**

No — Arc mainnet launches 16 September 2026. This guide describes practices to set up in preparation, using Arc testnet for validation where applicable.