42 comments

[ 8.2 ms ] story [ 203 ms ] thread
So, this sends an invoice after your customers paid? Isn't it normal that you send an invoice which the customer then pays?
Yeah, to me that rather sounds like a receipt not an invoice.
Where I live (the Netherlands), a receipt is usually just a small slip of paper you receive in a supermarket of gas station (as a private person). An invoice is usually only send to businesses and are more comprehensive than receipts.

A lot of e-merchants I order at (even professionally) require immediate payment during checkout, and send the invoice only after the order is shipped.

Back on topic: I rather like these "simple" solutions, but the pricing seems to high for my taste, if you think of it: they are just generating and mailing PDF's. Also, invoices usually have requirements that are different per country, so I doubt their solution is universal enough.

Thanks for the comment! Yes, pricing might seem a little bit high, but the service also includes expenses tracking, estimates, multi-users access, invoice customization...

Invoices are equal in all the EU countries: number, date, customer data, vendor data, items, VAT... And Quaderno supports multi-currencies, multi-languages, and multi-taxes :)

In most European countries, Canada, Australia... customers always need an invoice to properly include the expense and the taxes in their accounting books.
But this is called 'receipt' :)
A Stripe receipt doesn't include customer data, taxes, discounts, Tax ID, etc.
Typically called a "tax receipt" - i.e. a receipt that breaks down the tax component and includes the seller's business number and trading name. Receipts from larger companies are often tax receipts; it's typically smaller businesses that you may need to specifically request from (usually from those with simple registers).

Tax invoices are still invoices: issued before payment.

In the US, I often times see invoice/receipt used interchangeably.
Spain requires invoices after paying, for tax purposes, and they are slightly different than a receipt if you want to claim money back for them when doing your taxes.
(comment deleted)
Speaking of "XXX for Stripe", is there someone working on a "EU VAT handling for Stripe" ?

Currently, implementing VAT on Stripe (like Recurly does [1]) is a major pain, and I know of several companies which turned to other subscription systems just because of this.

[1] https://docs.recurly.com/vat#vat_valueadded_tax

Quaderno manages all the EU VAT. You just have to include some metadata in your Stripe charges and Quaderno makes the Tax Invoice.
By handling VAT properly, I mean this, to be accurate:

- determine automatically if VAT is applicable based on buyer and seller countries, and show the appropriate price on checkout

- support VAT bypassing when a valid VAT id is entered (if valid + buyer in EU but not in seller country, then the VAT must be removed)

- if US buyer pricing is 100, in my case for a french buyer the pricing will be 100 + 20 of VAT, so the total is increased

- handle invoicing

Does Quaderno handles this? I was under the impression that not, but could be mistaken!

Forgot to add - thanks for shipping this! Will be most likely useful to some of my clients :-)
Yes, Quaderno handles many of that requirements. Just create a Stripe Plan for every VAT case and assign a plan to your customer based on his country. Quaderno will create an invoice with tax amounts and all the tax data.

I've just updated the homepage to add an example. Thanks for the feedback!

Including reverse charging?

VAT is complicated! Varies a lot depending on the goods you are selling as well.

That's the next step we want to give: send a credit note every time you make a reverse charging.
It also depends on whether it is goods you are selling. If you're providing services rather than a physical product, it's even worse, because now you don't even know where the services are deemed to have been supplied until you've read a whole bunch of rules.
Here in the UK HMRC let you geolocate the buyer on IP address which is handy
You should think about price per invoice generated. For small site it can be expensive to spend 24$ each month if they have just few customers. From other side, big services which handle hundreds of thousands of customers will be very happy with 48$ but I doubt that you will be happy with such client :)
VAT support could be a good price differentiator in the EU. A VAT registered company should be turning over so much that this cost is negligible.

I'd recommend against price per invoice. Most businesses prefer fixed, predictable costs for things like this.

Is there an easy way to see some sample invoices/receipts? I didn't notice it. You should let prospects enter their email and get some fake invoices sent along to see how it looks. Sounds like a good incentive for me to give you my email address.

Do you think it's best for YOU to send the email directly to my customer, or really shouldn't it come from me? What about the confidentiality of my customer records. You mention 3GB of storage, are you keeping these invoices around on your server?

The Stripe API is powerful, but you definitely open up your data to 3rd parties when you leverage it like this.

Could you bundle a 'self-hosted' version which could be run internally?

> You should let prospects enter their email and get some fake invoices sent along to see how it looks. Sounds like a good incentive for me to give you my email address.

And that's why we love HN. I suspect they are working on it right now:-)

I would be concerned about the customer record confidentiality issue. Here in Europe we could only consider working with you if you were signed up to the EU Safe Harbor Act. Its pretty minimal for you - and makes my life easier as I can actually not break UK law.

Actually we are a EU base company, so we support the Data Protection Directive :)
Aha (sheepish look)

That's great really - I guess there is a new -ism, sexism, ageism now Delawareism - the unjustified prejudice that everything is an American company.

Good luck !

The sample invoices are a very good idea :)

We send the invoices on your behalf. Your customers will see only you emails address, not ours.

As we're an European based company, we support the European Data Protection Directive. All your customer records are safe.

At this moment we don't have plan to develop a 'self-hosted' version. But we can considere it in the future.

Thanks for your feedback!! ;-)

> We send the invoices on your behalf. Your customers will see only you emails address, not ours.

If you're not doing this with my SMTP credentials those emails are going to go straight into most folks' spam folders, as I have properly set up SPF records.

In that case you can add our mail server to your SPF records.
So when is Stripe going to buy these guys out?
Fantastic value proposition with perfect timing. Three companies I'm working with need a solution to this problem in the next 10 days.

I would literally have paid for three $24 subscriptions by now but sadly it failed to meet my expectations.

Some immediate problems:

1) I can't add the metadata it requires to my Stripe transactions without writing code which I will then have to maintain. I'm using WuFoo's Stripe integration to create the transactions.

2) I connected a Stripe account but I can't work out how to import existing transactions at all. (Maybe above issue is blocking this.)

3) Why is connecting Stripe the 5th step in setup when it's the core part of the value proposition and could be first?

4) I'm feeling annoyed and frustrated that time has been wasted building features I don't care about (Expenses, Estimates, Contacts and Delivery Notes) when it doesn't do the core thing I want to buy it for.

Here's how I'd like it to work:

Step 1) I sign up and give my credit card details immediately. (I would have trusted you with a money back guarantee)

Step 2) I connect my Stripe account and you instantly show me a list of invoices I can download or email to customers.

Step 3) I change my company details until invoices are rendered correctly.

No step 4 or 5.

An extra bit of logic which would be fine for my immediate purposes:

- When I add my UK/EU VAT registration number include VAT, at the UK rate, on all invoices where Stripe reports that country of the customer to be an EU country.

e.g.

A $50 payment in Stripe from someone in the UK, France etc should result in an invoice for $41.67 + $8.33 VAT

A $50 payment in Stripe from someone in the US, Canada etc should result in an invoice for $50 + $0.00 VAT

(Once we hit significant revenue we might need something more complex but right now all I care about is making sure we're properly accounting for VAT.)

Brilliant idea! I very much hope all this is helpful.

We have already fixed the issue #3. You're right: Stripe connection should be the first step.

Metadata are optional. You only have to use them if you need to add extra info, like VAT rates.

I see you include the VAT on the final amount. But there are some people who prefer to add the VAT to the final amount if needed. In your case, $60 for EU customers and $50 for non-EU customers. With the use of metadata, the user decides which logic he prefers.

Thanks for all your feedback! There are some really interesting and useful ideas. Hope to give you some good news soon ;-)

Good stuff! It's still not pulled in any payments for me (I tried reconnecting).

On the VAT rate it wouldn't matter which way I (or other customers) preferred to do it. That decision would have already been made when the payment was taken otherwise I'd have to process another payment via Stripe - very messy for accounting. The example could have also been:

A $60 payment in Stripe from someone in the UK, France etc should result in an invoice for $50 + $10 VAT

A $50 payment in Stripe from someone in the US, Canada etc should result in an invoice for $50 + $0.00 VAT

Something like this should do the trick (I guess you have the second half of this already):

    def get_tax_amount(stripe_payment)
      if stripe_payment.metadata.tax.nil?
        if customer.auto_eu_vat_on? && EU_COUNTRY_CODES.include?(stripe_payment.country_code)
            return stripe_payment.amount * (EU_VAT_RATES[customer.country_code]/100)
          end
        else
          return 0.0
        end
      else
        return stripe_payment.amount * (stripe_payment.metadata.tax/100)
      end  
    end


Critically with my current payment mechanisms I only find out the customer's country when they checkout with Stripe. I don't want to ask them before that to keep the form field count low and work within WuFoo's constraints. I don't know if I need to charge a customer VAT until after they have paid. (I conscious that I'm effectively either my giving EU customers a discount or charging non-EU customers a premium but that's not a concern at the moment.)

The only cases I can think of that would require metatdata are:

1) A $60 payment in Stripe from someone in Germany where the company's EU VAT number is provided in metadata should result in an invoice for $60 + $0.00 VAT

2) If I'm selling products that have different VAT rates. That's unlikely if your market is primarily software / digital products like Stripe's market.

Good news! We've developed a new feature in Quaderno.io to automatically calculate the EU VAT after the payment was taken. And you do not have to use Stripe metadata! Hope you like it ;)
Would be nice to see an example invoice
I feel less guilty about buying something simple like this (when I could make it myself) when there's a reasonable one-time payment. I bought the optional features at http://invoiceable.co/ for about $150 for PayPal invoicing. Note that I'm not totally happy with them though because they have mixed content on their SSL invoice page for clients and use non-SSL links in default emails.

Also for the price of Quaderno you could just buy http://xero.com and get a lot more features. They too do Stripe invoicing.

To clarify for US readers that might be confused, as I was initially: think of this as "(Tax) Receipts for Stripe".