
Show HN: Quaderno.io – Invoicing for Stripe - polimorfico
http://quaderno.io
======
zaroth
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?

~~~
lifeisstillgood
> 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.

~~~
polimorfico
Actually we are a EU base company, so we support the Data Protection Directive
:)

~~~
afarrell
Where in the EU, OOC?

~~~
polimorfico
Spain and Germany.

------
jot
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.

~~~
polimorfico
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 ;-)

~~~
jot
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.

~~~
polimorfico
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 ;)

------
logn
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/](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](http://xero.com) and get a lot more features. They too do
Stripe invoicing.

------
PanMan
So, this sends an invoice after your customers paid? Isn't it normal that you
send an invoice which the customer then pays?

~~~
polimorfico
In most European countries, Canada, Australia... customers always need an
invoice to properly include the expense and the taxes in their accounting
books.

~~~
elithrar
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.

------
xytop
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 :)

~~~
jot
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.

------
thibaut_barrere
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](https://docs.recurly.com/vat#vat_valueadded_tax)

~~~
jamesdeer
Need to be able to handle UK only VAT as well.

Recurly is a pain in the ass as it forces you to charge VAT on all EU
customers when under UK law we do not need to.

RARGH!

~~~
malditojavi
Only if you and your customer are VAT registered
[https://www.gov.uk/invoicing-and-taking-payment-from-
custome...](https://www.gov.uk/invoicing-and-taking-payment-from-
customers/invoices-what-they-must-include)

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

------
webbruce
Would be nice to see an example invoice

------
DiabloD3
So when is Stripe going to buy these guys out?

