# How do you structure an invoice that's paid part in fiat and part in crypto?

A split fiat/crypto invoice needs a clear split of the total, a locked-in valuation method for the crypto portion, and separate tracking for tax and accounting purposes.

---


Structuring an invoice paid partly in traditional currency and partly in crypto means clearly specifying the total amount owed, how that total splits between the two payment methods, and critically, exactly how the crypto portion's value is being determined and locked in at a specific point in time — since crypto prices move constantly, an invoice that's vague about when and how the crypto amount is valued creates real room for disagreement about whether the final payment actually matches what was agreed.

This is a genuinely useful structure for freelancers working with clients who want to pay partly in crypto without converting their entire payment, but it requires more precision in the invoice itself than a standard single-currency invoice does, specifically around timing, valuation, and how each portion will be separately documented for your own accounting and tax purposes.

## What does a split invoice actually need to specify clearly?

A properly structured split invoice should state the total amount owed in a single reference currency (typically your own domestic currency or whatever currency the underlying agreement was priced in), the exact split between the fiat and crypto portions (either as a fixed dollar amount for each, or a percentage split applied to the total), which specific crypto asset will be used for the crypto portion, and the exact method and timing for converting the crypto portion's reference currency value into the actual amount of crypto to be sent.

Without this last detail specified clearly, you're left with ambiguity exactly where it matters most — if the invoice states "$5,000 total, $3,000 in bank transfer and $2,000 in crypto" but doesn't specify what exchange rate or timing determines how much crypto equals that $2,000, both you and the client are left guessing, and a price move in the time between invoicing and actual payment can create a real disagreement about whether the right amount was actually sent.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>Reference currency total</b><span>the invoice's total amount owed should be stated clearly in a single reference currency, even when payment splits across two different methods</span></div>
<div><b>Explicit valuation timing</b><span>the invoice should specify exactly when the crypto portion's conversion rate is determined — at invoicing, at payment, or another defined point</span></div>
<div><b>Specific asset named</b><span>which crypto asset (a particular stablecoin, or another token) will be used should be stated explicitly, not left to be decided at payment time</span></div>
</div>
<p class="fig-src">Based on standard practice for structuring mixed-currency invoices involving crypto payment.</p>
</figure>

## How should the crypto portion's valuation actually be determined and locked in?

<figure class="fig">
<figcaption><b>Specifying the crypto conversion on a split invoice</b><span>Removing ambiguity around valuation timing</span></figcaption>
<ol class="steps">
<li><b>Decide on a specific reference price source</b>Name a specific, verifiable price source (a major exchange's quoted rate, for instance) rather than leaving the exchange rate undefined.</li>
<li><b>Decide on the exact timing for that reference price</b>Specify whether the rate is locked at the moment the invoice is issued, at the moment payment is sent, or at some other clearly defined point.</li>
<li><b>State the resulting crypto amount explicitly if possible</b>Where feasible, calculate and state the actual number of tokens owed at invoicing time, rather than leaving the client to calculate it themselves at payment time.</li>
<li><b>Build in a reasonable payment window</b>Specify how long the client has to complete payment at the locked-in rate before the invoice needs to be reissued or the rate reconfirmed.</li>
<li><b>Document the final, actual amounts received</b>Once payment arrives, record the actual fiat amount and actual crypto amount (and its value in reference currency at the time received) for your own accounting records.</li>
</ol>
</figure>

## Why does using a stablecoin for the crypto portion simplify this considerably compared to a volatile asset?

If the crypto portion is paid in a stablecoin pegged closely to your reference currency, the valuation complexity described above mostly disappears — a dollar-pegged stablecoin is designed to track close to one dollar in value, meaning the amount of stablecoin corresponding to a given dollar amount is straightforward and doesn't meaningfully change between invoicing and payment the way a volatile asset's price would. This is a large part of why stablecoins have become a common and practical choice specifically for invoicing scenarios like this, where simplicity and predictability matter more than any potential appreciation from holding a more volatile asset.

Using a volatile, non-pegged crypto asset for the crypto portion instead introduces real price risk for whichever party is affected by the specific timing convention chosen — if the rate is locked at invoicing but the client takes several days to actually send payment, and the asset's price moves significantly in the meantime, one party ends up effectively better or worse off than the originally agreed dollar value intended, purely due to market movement rather than anything either party actually controls.

<aside class="callout">
<span class="callout-label">For most freelance invoicing scenarios</span>
<h4>A stablecoin removes most of the valuation complexity entirely</h4>
<p>Unless there's a specific reason to use a volatile crypto asset for part of your payment, a stablecoin pegged to your reference currency sidesteps most of the timing and valuation ambiguity a volatile asset introduces, making a split invoice considerably simpler to structure and settle without disagreement.</p>
</aside>

## How should you actually record a split payment for your own bookkeeping and tax purposes?

Treat each portion of the payment as what it functionally is for accounting purposes: the fiat portion is recorded as ordinary business income received in your domestic currency, exactly as any standard invoice payment would be, while the crypto portion is recorded as business income valued at its fair market value (in your reference currency) at the time it was actually received — which may differ slightly from the value assumed at invoicing if any time passed between the two, even with a stablecoin, due to minor peg fluctuations or exchange rate differences depending on which stablecoin and reference currency are involved.

This means your books should reflect two separate lines for a single invoice's payment: the fiat amount received, and the crypto amount received along with its reference-currency value at the moment of receipt, which becomes your cost basis for that crypto going forward if you hold it rather than immediately converting it. Keeping this documentation clear and contemporaneous — recorded at the time of receipt rather than reconstructed later — matters considerably for accurately reporting income and for correctly calculating any future gain or loss if you later sell or convert the crypto portion.

## Does a split payment create any complications with how you report income across tax jurisdictions?

Generally, no complications beyond what already applies to receiving a crypto payment at all — the underlying income reporting obligation is the same regardless of whether 100% of an invoice is paid in crypto or only a portion of it is, since in both cases you're recognizing the fair market value of whatever crypto you received as taxable income, in addition to whatever fiat portion you received in the ordinary way. The split structure doesn't create a separate or novel tax treatment — it simply means your total income for that invoice is the sum of two components, each reported according to its own applicable valuation rules, with the crypto component requiring the fair-market-value-at-receipt calculation described above.

Where this can get genuinely more complex is if the crypto portion involves a non-stablecoin asset you intend to hold rather than immediately convert, since you're then also tracking a separate capital gains question for whenever you eventually do sell or convert that holding, on top of the original income recognition at receipt — a meaningfully more involved record-keeping situation than a straightforward stablecoin payment that you convert to fiat shortly after receiving it.

## Should you ask the client to use a specific payment method or platform for the crypto portion?

It's reasonable and often helpful to specify a payment method or platform you're already set up to receive and track reliably, rather than leaving it entirely open to whatever the client finds convenient — a client sending a crypto payment through an unfamiliar method or network you're not prepared to receive can create real friction, delay, or even a failed transaction if, for instance, the wrong network is used for a token that exists on multiple blockchain networks, a common and entirely avoidable mistake when the payment method isn't specified clearly upfront.

Using a payment router or invoicing tool specifically built to handle mixed fiat-and-crypto settlement can simplify this considerably for both sides — generating a single payment request that handles the split automatically, confirms receipt of both portions, and provides a clear record of the transaction for both parties, rather than coordinating two entirely separate payment processes manually and hoping both arrive correctly and on the expected timeline.

## How does this play out for a freelancer actually invoicing this way for the first time?

Call him Aurelio, a freelance video editor whose client, a crypto-focused media company, proposed paying seventy percent of his fee via standard bank transfer and thirty percent in a stablecoin, since the company held a portion of its operating funds in stablecoin and preferred not to convert the entire amount to fiat before paying him. Aurelio, invoicing this way for the first time, initially sent a simple invoice stating the total and the rough percentage split without specifying exactly how the stablecoin amount would be calculated or when.

The client, reasonably, asked for clarification before paying, pointing out they weren't sure whether to calculate the stablecoin amount based on the exchange rate at invoicing or at the time they actually processed payment, which might be several days later. Aurelio revised the invoice to state the total clearly in dollars, specify the exact dollar amount for each portion, name the specific stablecoin to be used, and note that the stablecoin amount would be calculated 1:1 against the dollar portion given the stablecoin's close dollar peg, removing any ambiguity about exchange rate timing entirely. The revised invoice was accepted and paid without further back-and-forth, and Aurelio adopted the same clearer template for every subsequent client requesting a similar split payment arrangement, having learned firsthand how much a small amount of upfront specificity prevented confusion and delay later.

## What's the practical template to follow for any future split fiat-crypto invoice?

State the total amount owed clearly in a single reference currency, specify the exact dollar or reference-currency amount allocated to each payment method rather than only a vague percentage, name the specific crypto asset to be used (preferring a stablecoin where reasonably possible to minimize valuation complexity), state explicitly how and when the crypto amount is calculated relative to the reference currency, and set a clear window for payment to be completed at that agreed valuation before needing to be reconfirmed. Keep separate, contemporaneous records of the actual fiat and crypto amounts received for your own accounting and tax purposes, and consider using a payment tool built specifically for mixed settlement if this becomes a regular part of how your clients prefer to pay you, rather than managing the coordination manually for every individual invoice.

## What should you do if the two portions of payment arrive on different days?

It's common and worth planning for upfront that the fiat and crypto portions of a split payment may not arrive simultaneously — a bank transfer and a crypto transaction move through entirely different systems with different processing times, and there's no reason to expect them to land on the same day even when a client intends to send both promptly. Specify in your invoice or payment terms a reasonable window within which both portions should be completed, and decide in advance how you'll handle a situation where one portion arrives well before the other — whether you'll treat the invoice as settled only once both portions clear, or acknowledge partial payment received while the remaining portion is still in transit.

This matters practically for your own cash flow tracking and for any follow-up communication with the client — a freelancer who assumes an invoice is unpaid because only the crypto portion has arrived so far, when the bank transfer is simply taking its normal few business days to clear, risks sending an unnecessary and potentially awkward payment-reminder message to a client who has, in fact, already initiated full payment as agreed.

## Does the client's own accounting treatment of the split payment matter to you as the freelancer?

Not directly for your own tax or bookkeeping purposes, since your obligation is to accurately record what you actually received and its value at the time of receipt, regardless of how your client characterizes or records the payment on their own books. It can still be worth a brief conversation with a client new to paying this way, though, since a client unfamiliar with properly documenting a split crypto-and-fiat vendor payment may make errors on their own end — misclassifying the transaction, failing to retain adequate records for their own tax reporting, or simply being confused about what documentation they should request from you to support their own books.

A short, friendly note confirming the final amounts received and their respective values, sent once payment is complete, serves both sides well — it gives the client clear documentation for their own records and gives you a simple, unambiguous paper trail confirming exactly what was agreed and received, which is useful if any question about the transaction arises on either side later.

## Is there a reason to prefer a split payment over simply asking to be paid entirely in one method or the other?

Sometimes, yes, and it's worth understanding why a client might genuinely prefer this structure rather than assuming it's simply added complexity for no real benefit. A client holding a portion of their operating funds in stablecoin, as in Aurelio's example, may prefer not to convert that entire holding to fiat before paying a vendor, since conversion can involve its own fees or tax implications on the client's end; a split payment lets them pay from each pool of funds they already hold without an unnecessary conversion step on their side. From the freelancer's perspective, a split arrangement can also be a reasonable middle ground for someone who wants some exposure to holding crypto as part of their income without converting their entire fee into a volatile or unfamiliar asset all at once — receiving a known, reliable fiat majority while experimenting with a smaller crypto portion.

Neither party is obligated to accommodate this structure if it doesn't suit them, and a freelancer uncomfortable with the added bookkeeping complexity described throughout this article is entirely reasonable in simply requesting full payment in their preferred single method instead. But understanding why a client might ask for a split in the first place helps frame the conversation as a reasonable accommodation worth considering on its own merits, rather than an unusual or suspicious request without a clear underlying rationale.