Learn

You got paid in USDC. Your books don't know that.

Your client would rather pay in stablecoins, so you let them. The money arrives. And then reconciling it back to the invoice turns out to be worse than a normal payment, not better.

By Pelle Brændgaard

I know this one first-hand. At the company I run, we happily accepted stablecoins from customers, right up until we hired a real VP of finance who put a stop to it almost on day one, over exactly this: the reconciliation and accounting uncertainty. (I have also spent years building a payments company, so I had watched it from the other side too. The pain was real enough that we ended up building a product to solve it, for ourselves and for the industry.)

Here is the pattern. Your international client would rather pay in USDC, because a wire is slow and expensive and they are sitting on stablecoins anyway. So you do the obvious thing: you send a normal invoice and write the wallet address and the amount at the bottom. The money shows up in minutes. Great.

Then month-end arrives, and the trouble starts.

Why is a stablecoin payment harder to book, not easier?

Because now you have a payment sitting on-chain, an invoice sitting in your email, and nothing connecting the two. A bank transfer at least lands in an account your bookkeeping can see, with a reference line. An on-chain payment lands in a wallet, identified by a transaction hash that means nothing to your books.

Multiply that by every client and every month. At year-end you are matching transaction hashes to PDF invoices by hand, converting each one to its US dollar value on the day it settled, and hoping you did not miss one. Founders who run mixed books say exactly this:

“The worst part is closing monthly books when you’ve got both fiat and crypto on the balance sheet: categorizing crypto transactions is extremely time-consuming and expensive.” (YC founder on private YC forum)

“If you have crypto on your company’s balance sheet, you have to account for it, and existing bookkeeping workflows just aren’t set up for that.” (YC founder on private YC forum)

Whose fault is this?

Not the stablecoin’s. This is the part I find genuinely interesting, coming from payments. Stablecoins did not create a bookkeeping problem. They exposed one that was always there.

Think about what an invoice actually is: a promise. You are owed money. When the money arrives, that promise is settled, and your books should record both halves as one connected event: the receivable goes away, the cash appears, tied to the same invoice. That was always the correct shape. Getting paid by bank transfer just let you get away with keeping the promise and the settlement in two separate places, because the bank statement was legible enough to reconcile by hand later.

Stablecoins remove that grace. The settlement is instant and the record is a hash, so the gap between “I sent an invoice” and “this money is that invoice” is suddenly your problem, in the open, every month.

What does doing it right even look like?

The mechanics are not exotic. A stablecoin receipt should be recorded at its US dollar value on the settlement date, tied to the invoice it pays, with the original amount kept as a note. One connected record, not two loose ones. The hard part was never the accounting rule. It is that the invoice, the payment, and the ledger entry live in three different systems that do not talk to each other.

I have opinions about how that gets fixed, and I am building one of them, so take that as disclosed. But you do not need my product to see the shape of the problem: the invoice and the money should be one record, and right now, for you, they are not.

The next one is quieter and costs more: the free cloud credits that are hiding your real burn.

Read next: Your cloud credits are hiding your real burn rate