How can I fairly give the option to be paid in Bitcoin?

Question

I'm a freelancer who bills per hour and invoices my clients at the end of the month. The total amount is represented in my local currency.

I also give the option for my clients to pay in Bitcoin at a 10% discount. The way I currently do it is by adding my Bitcoin address to the invoice and then add the discounted, equivalent Bitcoin price at the time of sending the invoice.

This isn't all too fair. Or rather it is unfair to both parties since, for them, the client may not have anticipated the exchange rate at the point of invoicing; and, for me, I need to wait until the client pays me (within the constraints of the payment due date, naturally) which may lead to an unfavourable exchange rate.

How can I structure the agreement so that it's fair for both parties while still charging in two possible currencies like this?

Answer 1

When you decide to accept multiple currencies as payment, you need to decide what the price will be for each currency. That price really needs to stay fixed between the invoice date and the due date.

You have decided that you will set the Bitcoin price by using the exchange rate at the time of invoice creation and then knocking 10% off, and that is fine. However, as you noted, the value of Bitcoin is very volatile, and that amount of Bitcoin probably won’t be the same value as the other currency by the time the payment happens.

That is the risk you take when you offer to accept Bitcoin. If the volatility bothers you, then you should stick with a more stable currency.

Answer 2

I would not hand out a BTC address and hope the exchange rate stays relatively stable until the client can pay so that everything stays fair.

Rather, you could include a link to a bitcoin payment page on the invoice that directs them to a page online where they can pay using bitcoin at the current exchange rate at the time of payment for an amount equal to 90% of the full invoice amount. This can be done with one of the crypto payment services, or by setting up a self-hosted one such as BTCPay Server.

Answer 3

If you're a big company that accepts payment in one currency but has expenses in another (i.e. you're building widgets in Mexico where you pay for everything in pesos and selling widgets in America where your customers pay in dollars at some later date), you hedge against fluctuations in the exchange rate to ensure that you don't end up losing money if currencies move against you. You can do the same thing (though it's one more thing for you to manage and one more expense for your business).

For example, if 1 BTC = $50,000 on the day you generate an invoice for $5,000 (0.1 BTC - 10% discount = 0.09 BTC), you can buy an option to sell 0.09 BTC on the invoice due date for $4,500. If the client sends you 0.09 BTC immediately, you're satisfied. If they send you 0.09 BTC later when 1 BTC = $40,000, you exercise your option and get your $4,500. If the client sends you 0.09 BTC later when 1 BTC = $60,000 then, presumably, you're happy and don't exercise your option. Depending on the country in which you live and the trading platforms you have access to, you may be able to use a contract for difference (CFD) to produce the same sort of hedge.

Of course, buying this option (particularly for an asset like BTC which is very volatile) isn't free-- you'd be paying someone to take on the volatility risk. So it would be one more expense for your business to manage. Depending on your clients and your tolerance for risk, you can adjust how much you hedge. If you generate $50,000 in invoices for the month for all clients but you know that many of them aren't set up to pay in bitcoin, you probably don't need to hedge a full bitcoin. And if you're willing to take a discount for bitcoin, you can probably choose a strike price of the option that is less than the current value (i.e. you accept the risk of a 5% drop but use the option to hedge against a larger drop) which will make the option less costly. Of course, you'd need to adjust for the ability/ willingness of your clients to pay in bitcoin, the probability that they'll be watching the exchange rate to figure out which currency to use, and the expense of the different options along with your tolerance for exchange rate risk.

Answer 4

There are two options that I am aware of for multi-currency invoicing, and you should always specify what the system will be in the initial contract that gives rise to the invoice(s).

Option 1: Specify the exchange rate up front so that you can calculate the Bitcoin amount at the time you create the invoice. In this example you might say "Invoices will be calculated in US$ and a Bitcoin amount will also be provided, this will be a 10% discount on the US$ price using the exchange rate from [site] on the invoice date. [Client] may choose to pay the US$ amount via bank transfer or the Bitcoin amount via transfer to [Bitcoin wallet]; in either case, the payment is due within X days of the invoice date and late payments will attract an additional charge [blah blah blah]"

Option 2: Allow the client to determine the Bitcoin amount at the time they make the payment. In this example you might say "Invoices will be calculated and provided in US$ which should be paid by bank transfer. Alternatively payment may be made in Bitcoin to [Bitcoin wallet] at a 10% discount rate from the US$ price calculated at the time of making the payment. In either case, the payment is due within X days of the invoice date and late payments will attract an additional charge [blah blah blah]"

The factors to consider are whether you need/want to know exactly the amount you will receive in advance, who you want to carry the exchange rate risk, how much you want to have to check the calculations made by the client at the time of making the transfer, etc.

Answer 5

Since (I assume) few or none of your expenses are fixed in BTC and you "think" in your local currency.

You may use the formula pretty much popular in economies where the local currency is unstable:

The customer owes XXX.xx (whatever your preferred currency is), or the BTC equivalent at the rate published in (reputable authoritative source) at the moment of the payment with additional 10% discount.

Answer 6

You just can't accept multi-currency payments if the exchange rate is not stable.

Nowadays Bitcoin is too volatile even for the purpose of being used as a payment method.

Emphasizing/exaggerating it: you work your day at morning for Bitcoins, but you don't know if you can afford dinner at evening, or buy a new car.

That's not just Bitcoin, which is just the best fit as an example, it is a problem of multi-currency. Nowadays, fiat currencies are decently stable each other. Cryptos that are stable with fiat currencies (stablecoins!!) exist, so they are not such of a problem.

But think about inflational and better hyper inflational currencies, of which history has examples. If your purpose is to convert the alternate coin other than spending it for your living, you better not accept alternate currencies.

You do always have two option: one is to accept the payment in any other currency giving the payer the duty to check the exchange rate. Nothing different from cyber extortionist to ask you "send us any amount of Bitcoins worth 1000$ at the time you buy them". In this case the price is set to one currency (dollars?) and both parties suffer rate risk.

In the latter case, you compute your own due amounts at your desired exchange rate, but the value worth can change significantly over time.

What I am going to say with this answer is, even if the exchange rate between Indian Rupee and Czech Koruna is oscillating, you know very well how many Pilsens you'll be drinking after your job.

With oscillating cryptos, we all need to establish an economy where one can buy daily asset with crypto (food, gasoline, probably not utilities bills). By that time, invoices in crypto will gain a lot more sense.

Another point of view of this answer is the market where the alt currency will be spent. In the world of fiat coins, you should also be aware of how and where you will be spending the money. The price of a single commodity (such as... beer) is dramatically and substantially different by country (compare Czechia with Denmark for example).

This assumes you are getting paid for your living, not to accumulate liquid assets. In the example right above, if you get paid in CZK you buy a certain amount of things in Czechia. But if you get paid the same worth amount in DKK, you'll find it harder to buy things in Denmark.

This ends with a new question then: how are you going to use your crypto assets? Are you going to buy your living?

Answer 7

Is there not a crypto payment system that will allow the client to specify an exact USD value (or whatever your local currency is) of BTC to send, and which will also allow you to see the exact USD value of what you receive at the moment it was transacted? If you can find something like that, then you wouldn't need to put the amount of BTC on the bill, you just tell them the amount in your currency that they owe (minus 10% or whatever) and then they use a payment system where they can send that exact currency's-worth of BTC. Of course, this will leave them to possibly strategically try to wait for a day when BTC is most cheap, but it will still be worth the correct value of $$$ at the moment it arrives, and at least it will eliminate your problem of having to state an approximate/incorrect BTC amount on the invoice, which seemed to be your main problem.

Edit: actually wait a minute, now that I think about it this actually does solve both "problems." Because they can't "strategically" wait for anything. Whether the coins go up or down, they are still giving you the same USD value. The issue only arose because you were giving them a BTC amount on the invoice which they could leverage. I suppose there could be a slight strategy still, but it would only involve what happened to the BTC price after the transaction happens. That is, if the price goes up after, you win (as long as you hold to that higher price); and if it goes down, then they do. But that is complicated enough of a "strategy" that it mostly can be disregarded.