provide monthly invoices

[chadwhitacre]

was: make receipts look like software invoices

So @Wolfr can deduct as a business expense.

We have receipts. They look like this:

What needs to look different?

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Wolfr]

This was an idea I had without having seen the receipt. The image you show
has a chance to be accepted but its small. My bookkeeper doest know what
gittip is.

It would help if it stated invoice instead of receipt. If it was letter
size. It needs the name and address of both businesses. It needs to state
the nature of the services provided but this could be generic (software
development support).

I.e. if I support jresig it could state that I help support jquery
development. Now I can prove to the taxman that my sites are using jquery
and this helps my business. So that in turn makes it deductible from my
costs and the circle is complete.
On Jul 22, 2013 2:35 AM, "Chad Whitacre" notifications@github.com wrote:

So @Wolfr https://github.com/wolfr can deduct as a business expensehttps://twitter.com/wolfr_/status/358959551602630657
.

We have receipts. They look like this:

[image: receipt]https://f.cloud.github.com/assets/134455/832226/af6706e8-f23c-11e2-95d1-b4813124b40c.png

What needs to look different?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1199
.

[chadwhitacre]

Thanks for the feedback, @Wolfr. Since people give for different reasons on Gittip we'd have to make the "software development support" line-item a variable that you'd fill in somehow. Otherwise this is definitely something we can provide. @jeresig has actually asked for a monthly invoice as well. We originally had #83 for this but that got diverted into the weekly receipt as above. I'm not seeing another ticket for monthly invoices, so let's use this one! :)

I did start a statements-json branch towards this.

[mvdkleijn]

My two cents:

Since no value is ever exchanged (i.e. you're not paying someone in order to receive something in return), all of the givers donate and/or gift funds. The reason for the donation doesn't matter from a tax perspective I believe. The reason only matters to the person / organisation doing the giving.

The only thing that does matter from a tax perspective is whether or not the receiving party is a registered non-profit according to the giver's tax department.

You could solve that tidbit by allowing receiving parties to enter 1) where they are registered entities and 2) what, if any, registration number they have. This could then be printed on the invoice.

Also interesting would be the question if "gifting" is the same as "donating". In Dutch tax-law, individuals can "gift" a certain amount to others without paying taxes, but I believe gifts are one-time and donations are recurring.

Gittip is neutral in all of this.

[domenkozar]

This would rock, as in EU if a company wants to donate, they need an invoice for it. How can I help?

[domenkozar]

Invoice also needs to include VATID from "user" for taxing reasons

[chadwhitacre]

@iElectric Can you say more about the VATID from the user? Which user?

[mvdkleijn]

@whit537 @iElectric VAT ID is for companies only. If you sell something as a company AND provide extra value, a Value Added Tax should be applied by the seller. If the buyer is a company, they can (but don't have to) supply a VAT ID to the seller, allowing the seller to apply a 0% VAT. (within the EU at least)

However... in my opinion, a gift does not fall under VAT because no value was added and no business transaction took place. It's a one-way gift. Since the donor/seller is not legally required to add VAT tax, there is no reason for the receiver/buyer to provide a VAT ID.

Heck, since the receiver isn't a company, no VAT ID exists.The gift is to the Gittip user, not to Gittip itself. Gittip is an intermediary / bank like entity. The monthly invoice is made by Gittip on behalf of the Gittip users.

[domenkozar]

The receiver could be an NGO. If gittip would issue monthly invoice on behalf of NGO to the company sponsoring it, by Slovenian law, VATID of the company paying must be on the invoice.

[mvdkleijn]

@iElectric That's a very specific use-case. 😄 Good point though.

[domenkozar]

I agree :) It's a very specific use case we have for our hackerspace https://www.gittip.com/Kiberpipa/ and I guess for now we will have to use paypal for such use cases (sadly this will be the majority of sponsorships). If there is anything I can do to make it happen, do shoot :)

[chadwhitacre]

@iElectric Ah, so you're the one behind Kiberpipa. I've seen the Twitter traffic and wondered what was going on. :-)

This sounds like "make Gittip play nice with charities" (#249).

Here's a sketch of an invoice:

The "From" there is Kiberpipa and the "To" is "Acme Co."

Maybe "From" should be Gittip? If Acme Co is giving to multiple receivers then they probably want an invoice with all of those receivers as line-items.

Whose VAT goes where? I think it's Acme Co's VAT, right?

[domenkozar]

@whit537 yup, gittip really rocks :-)

• From should really be Gittip yes, since you are issues the invoice
• VATID goes somewhere to "To" field, doesn't really matter much

[mvdkleijn]

@iElectric @whit537 Sorry to butt in here... 😄

If "From" is Gittip, it means Gittip is the seller / funder... doesn't seem right. That would be like putting the bank's name there. I believe "From" should be the Gittip user that's doing the donating, not Gittip itself.

Be careful here that we're not entering into implicit legal agreements just because we generate an invoice on behalf of a donating user.

From is the donating user, To is the receiving user.

[mvdkleijn]

Unless @whit537 is saying that Gittip LLC is doing the actual donations, not the Gittip userbase? 👅

[mvdkleijn]

I would also explicitly state that it concerns a gift and that the fee is actually a payment processing fee.

(so its a recognizable cost, not a payment for a service provided by Gittip, which would constitute a sale)

[wimleers]

We were talking about this very problem today; it would enable many small Drupal shops to start tipping more!

[domenkozar]

I'd say gittip can only issue invoice on behalf on itself, but I don't know anything about US laws.

[mvdkleijn]

I'd say gittip can only issue invoice on behalf on itself, but I don't know anything about US laws.

An invoice is sent from the seller/donor to the customer/receiver... Since Gittip is not the one donating, it cannot be on the issued invoice in the From section.

Gittip can send an invoice on behalf of its donating user since it is the donating user that is gifting money, not Gittip. It would be similar how an online accounting system would send an invoice on behalf of the account owner, not itself. The only thing I can possibly imagine that could block it is if the donating user would have to give Gittip permission to send an invoice on their behalf.

[chadwhitacre]

Here's what GitHub does, btw (I'm updating Gittip's billing info at GitHub as part of #1506, that's why I noticed):

[mvdkleijn]

by the way... ’invoice’ is the wrong word... invoice implies sales. It's a receipt from the receiving gittip user to the donating user for ’monies received’.

[chadwhitacre]

I sent a one-off invoice to Heroku for the month to date. I'm waiting to hear back from them whether it's sufficient.

[mvdkleijn]

I'd like to re-iterate...

by the way... ’invoice’ is the wrong word... invoice implies sales. It's a receipt from the receiving gittip user to the donating user for ’monies received’.

Its even in the screenshot @whit537 referred to.. GitHub (for example) correctly refers to it as a receipt. It's not an invoice. (and never will be) Calling it that will just make it unclear.

[chadwhitacre]

Fwiw, I've been thinking in terms of a "statement" showing activity on the account for the month in question.

[MikeFair]

In the US both the giver and the receiver need to receive the receipt (and
as Martijn said; it is a receipt) as both need it for tax purposes. The
receipt/record must be printed as coming from the user and not gittip
because that will mess up the 501c3's public support test (which means you
can't have too much coming from the same entity).

The end user needs the receipt so they have it for their tax return filings
and can actually take the deduction.

For cases like the Drupal small projects, there's the Software Freedom
Conservancy, which acts as an umbrella to give small projects official
501c3 status.
On Nov 12, 2013 7:07 AM, "Martijn" notifications@github.com wrote:

I'd like to re-iterate...

by the way... ’invoice’ is the wrong word... invoice implies sales. It's a
receipt from the receiving gittip user to the donating user for ’monies
received’.

Its even in the screenshot @whit537 https://github.com/whit537 referred
to.. GitHub (for example) correctly refers to it as a receipt. It's not an
invoice. (and never will be) Calling it that will just make it unclear.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1199#issuecomment-28300381
.

[MikeFair]

Oh and I forgot to mention the receipt needs to look different for the
entities. For the 501c3, the line items are total amount each user gave
during that organizations fiscal year.

For the end user it's all organizations and totals given to during the
calendar year (which is the de facto fiscal year).
On Nov 12, 2013 7:07 AM, "Martijn" notifications@github.com wrote:

I'd like to re-iterate...

by the way... ’invoice’ is the wrong word... invoice implies sales. It's a
receipt from the receiving gittip user to the donating user for ’monies
received’.

Its even in the screenshot @whit537 https://github.com/whit537 referred
to.. GitHub (for example) correctly refers to it as a receipt. It's not an
invoice. (and never will be) Calling it that will just make it unclear.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1199#issuecomment-28300381
.

[chadwhitacre]

We were talking about this very problem today; it would enable many small Drupal shops to start tipping more!

@wimleers Now that @alexpott is really going for it, I'm hoping to work on this ticket soon.

[chadwhitacre]

+1 from @alexpott in IRC.

[domenkozar]

🍻

[chadwhitacre]

Self-billing makes sense even if/when we break anonymity (#236), because the essence of Gratipay is that the tippee determines the amount.

[chadwhitacre]

An invoice must contain the following information:

1. the date of issue;
2. a sequential number that uniquely identifies the invoice;
3. the supplier's VAT identification number;
4. the customer's VAT identification number (only when the customer is liable to pay the tax on the supply);
5. the supplier's full name and address;
6. the customer's full name and address;
7. a description of the quantity and nature of the goods supplied or services rendered;
8. the date of the supply or payment (if different from the date of supply);
9. the VAT rate applied;
10. the VAT amount payable;
11. a break-down of the VAT amount payable per VAT rate or exemption;
12. the unit price of the goods or services exclusive of tax, discounts or rebates (unless included in the unit price);

http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#item_1.4

[chadwhitacre]

I've mailed two invoices re: FD1483: one a self-billing invoice for software development services, and a second from Gratipay, LLC for payment processing services. I made them manually in Google Docs and printed to PDF. If these pass muster then we can use them as the basis for providing automatic invoices.

[chadwhitacre]

Invoices mailed on FD1483 passed muster with the company in question. Let's do more of that! :-)

[chadwhitacre]

Dribbble, for comparison:

[chrisdev]

@whit537 the "opt ins" are fine.
The charitable organisation can always give explicit guidance to its supports to ensure select the correct options according to its requirements.

[chadwhitacre]

+1 https://gratipay.freshdesk.com/helpdesk/tickets/1940

[chadwhitacre]

One of the things I do for money, is develop Varnish, and the Varnish Moral License is the vehicle I invented for the paperwork.

The way it works is very simple:

• Happy varnish users tell me that they want a Varnish Moral License
• I send them an invoice from my company
• They pay the invoice
• I develop Varnish

http://phk.freebsd.dk/VML/

(via gratipay/inside.gratipay.com#732)

[chadwhitacre]

To: “phk@” at this site
Subject: text of the Varnish Moral License?

Greetings! For the past four years I've been working on a (weird, open-sourcey) startup called Gratipay, which, I am now starting to realize, may be little more than an attempt to productize your Varnish Moral License. An initial question as I come to terms with the implications of this discovery: What is the actual text of the VML that you send to companies that purchase one? If such a text exists, may I share it with the Gratipay community?

[chadwhitacre]

Another example: http://pgloader.io/pgloader-moral-license.html

I shamelessly stole the whole idea from The Varnish Moral License.

[chadwhitacre]

This is the funding model I want to "sell" for other FOSS projects, because it works.

http://queue.acm.org/detail.cfm?id=2636165

[chadwhitacre]

Sounds like there is no official text, though we will likely discover additional bureaucratic hurdles such as NDAs and vendor registration.

[chadwhitacre]

If you run any kind of online business, you’re almost guaranteed to have receipts and invoices. Any healthy business will need to process payments and send receipts for those payments. As ubiquitous as they are, they're emails that are frequently overlooked in terms of value and customer experience. However, a well-designed receipt or invoice can make a great impression on your customers and even help generate additional revenue.

https://postmarkapp.com/guides/receipt-and-invoice-email-best-practices

[chadwhitacre]

I'm calling this done with the invoices we shipped with the new homepage (#4589).