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!](https://www.bountysource.com/issues/588271-provide-monthly-invoices?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

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/gittip/www.gittip.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. :smile: 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... :smile:

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? :tongue:

[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/gittip/www.gittip.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/gittip/www.gittip.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]

:beers:

[seanlinsley]

@whit537 this ticket is labeled as ready; is this going to be implemented before we start collecting user emails?

[chadwhitacre]

@seanlinsley Sure, why wouldn't it? Of course it'll be even better to send out statements via email but that's orthogonal, no?

[seanlinsley]

It just seems like it'd be easier to develop a layout for emails and PDFs or whatnot all at the same time.

[chadwhitacre]

Didn't get to this in time for @alexpott, so I'm releasing this back to the pool (i.e., I'm unassigning myself and taking it out of "Ready to Start").

[chadwhitacre]

+1 from @RobSpectre via Hangout.

[chadwhitacre]

Dropping back to ★★☆ while we clear out actual bugs on ★★★.

[balupton]

+1. If you need help with invoice format, here is the format that Bevry uses: https://docs.google.com/document/d/1CNlVy3vhELMCxzsaytzG9AhLLs_XQ4q8pro6bFyKyUA/edit?usp=sharing — 110 of them sent to date, so gone through a few revisions from clients.

An invoice should be generated and emailed with each credit card deduction. All invoices should be able to be seen from your gittip account. They should be downloadable in PDF format (via print instructions should be fine).

[chadwhitacre]

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

[gergelyke]

Thanks! Would be great to have this asap :)

[chadwhitacre]

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

[chadwhitacre]

IRC

[chadwhitacre]

Sent to person in question on FD1483:

Greetings! Chad Whitacre here from Gratipay. We've received a request from your patron on Gratipay to provide an invoice, and since invoices aren't something we've totally figured out yet, we could use your help! :-)

From your patron's point of view, you are the originator of the services they are paying for. Since Gratipay is designed to preserve a "no strings attached" ethos by hiding from you exactly who your patron is, what we propose to do is to write the invoice to them on your behalf. To do that I believe what we'll need is your legal name, and your address.

Would you be able to provide that for us? Thanks! :-)

[chadwhitacre]

Have received info back. Crafting invoice now.

[chadwhitacre]

Turns out the EU has extensive documentation on invoicing. IRC

[chadwhitacre]

Then of course there's http://en.wikipedia.org/wiki/Invoice.

[chadwhitacre]

While each tip amount is between the seller (tippee) and the buyer (tipper), the fee is between Gratipay and the buyer (tipper).

[chadwhitacre]

So really we want an invoice for each transfer(!). I guess we really do want a monthly statement summarizing the activity.

[chrisdev]

:+1: to monthly summary

[chadwhitacre]

Okay! It turns out that there's a whole established accounting practice called "self-billing," wherein the customer writes the invoice and sends it to the supplier together with their payment. It seems to be well-established in the EU; the UK has the best docs I've found:

https://www.gov.uk/government/publications/vat-notice-70062-self-billing/vat-notice-70062-self-billing

The practice appears to be less established in the U.S., but not unheard of.

I propose that we implement the "company giver" use-case on Gratipay as a form of self-billing. (The only viable alternative is charity, which we'll also support [#249], but companies are not optimized for charitable giving, they're optimized to pay for goods and services. We want to go with the grain in order to tap into the wealth that is currently tied up in corporations.) What does this look like?

• Implement business identity verification (#988).
• Verified business can only give to other verified businesses (but what about US sole proprietors?).
• Add a tips.note field, filled out by tipper (#222) and used as the description in invoice line-items.
• Add a tips.vat field, filled out by tipper, and used to compute the output tax due shown on the invoice.
• Generate an invoice for each transfer (parallel to the receipts for exchanges). Tipper sees full info, tippee has "To:" hidden (though cf. #236).
• Split out fees as an invoice from Gratipay.
• Implement a monthly summary that includes both invoices and receipts.
• Mail it!
• Update ToS as needed.
• Feel out disputes ("That VAT is wrong!").

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