E-mail
Revenue Canada has specific requirements for Charitable Receipts that are not met by CiviCRM 3.2. This page is intended to collect the reporting requirements for Revenue Canada, the organizational use cases, and the technical specs for an enhancement to core or preferably an optional component / module that Canadian charities could (download and) enable.
Kirk Schmidt is hoping to look into this by the fall of 2010.
One major requirement is that all receipts have a unique number associated with them. I believe there may be requirements around issuing a replacement receipt as well, perhaps mentioning the first one's number and creating a second number. Not sure though.
As well, some organizations may want to bundle multiple donations into a single receipt issued in February.
Political receipting requires the date that a donation was received as well the date the receipt for it was issued to be printed on the receipt.
Currently, there is no good way to track monies received that are 'receiptable' versus non-receiptable when some of the money is going to the cost of providing a good or service while some is not. The typical case here is a fundraising dinner, where the cost of providing the dinner is not receiptable, but the amount over and above that is receiptable. It might be useful in this case to allow CiviContribute pages to allocate the money they take in to more than one donation type. I put a note on this into a wiki page for future CiviContribute enhancements but can't find it at present.
Would be nice to leverage other CiviCRM functionality to produce receipts as an action available after a search has taken place.
49 Comments
Hide/Show CommentsJun 24, 2010
Mordechai Bookbinder
This would be a GREAT additional component for CiviCRM, Joe, for without it, Canadian Charities will be stymied and less likely to use it.
Here are some considerations:
the Canadian Revenue Agency requires that:
Apr 12, 2011
JoeMurray
Hi Mordechai,
Thanks for the feedback.
Listing other resources here (updated April 11, 2011 due to changes in the urls):
It seems Adam King has some working software for receipts(see http://civireceipt.unnormal.ca/), but I'm not yet clear on how it is implemented, whether it is available as a recipe to follow for configuring things and/or as software for download, and whether it complies with all Revenue Canada requirements (eg the one about duplicate being printed on reissued receipts).
More input / suggestions welcome, especially distilling down the Revenue Canada requirements, and how people would like to see it work in CiviCRM.
Cheers,
Joe
Jul 06, 2010
Sarah Gladstone
The feature in the upcoming CiviCRM 3.2 described at: http://issues.civicrm.org/jira/browse/CRM-5461 seems like it will help the staff using CiviCRM view previously printed tax receipts.
Sep 11, 2010
Lars
Australian tax receipts have very similar requirements so this module will not be of limited usefulness to Canada only.
Feb 09, 2011
Nolan Andres
Hi there...
I should note that we (PeaceWorks - http://www.peaceworks.ca/node/141) have developed a Civi module for CRA-compliant Canadian Tax Receipts. We haven't had time to publish it yet, but it's pretty much ready for public use. We developed it for a single client, and it requires a couple hours to make it more generically configurable (e.g. set up your own logo, etc.) but as it currently stands, the module:
...we did check out the code referred to by this post in the Drupal forums: http://groups.drupal.org/node/12979#comment-240173
...the folks at Unnormal were kind enough to share the code with us...thanks, guys!!!
...but their approach exposed a URL that accepted an ID and then streamed out a PDF in response, which seemed a bit of a security risk to us, so we built our module instead.
We'd be happy to share, and have been planning to release this module "properly" for a few months but haven't yet had time to do so. Feel free to contact me directly. If there's demand, we'll move this ahead more quickly.
Feb 10, 2011
Sarah Gladstone
How can I download this module?
Feb 10, 2011
Nolan Andres
Thanks for your interest, Sarah!
I've received a fair amount of correspondence from Joe already, and he's encouraging us to "release early, release often". :)
At the moment, I'm aiming to have this module released by the end of next week (I'm not willing to release it without removing the last bits of client-specific code, and although it's only a couple hours' work, I have to have it inserted at a reasonable spot in our pipeline). That would be Friday, February 18, 2011. I'll post back here if anything changes on that front, or with a link to the module page.
I hope that's soon enough for everyone! :)
Feb 18, 2011
Nolan Andres
Hello everyone,
Regretfully, I'm going to have to push back our module release date. The response has been encouraging, so to that end at least, we have held its spot in the pipeline, and we're now aiming to release it next week. I'm hoping for sooner than Friday (the 25th) but it may end up that day depending on how things go. Nevertheless, we're gratified to see that this module will in fact be used, and we're committed to getting it out there as promptly as possible.
Sorry for the delay!
peace,
Nolan
Feb 25, 2011
Nolan Andres
Hi there,
Just a note to let everyone know that we still plan to launch what will be officially a "pre-release" version of the module today (Friday, Feb 25, 2011), likely in the evening. Please see http://www.peaceworks.ca/node/143 for details. Initially, the pre-release will be made available directly from our website, but only during the interim period while we await completion of the code review from Drupal.org. Thanks for your patience!
peace,
Nolan
Feb 26, 2011
Nolan Andres
Unfortunately, we've had to push this back again due to issues generalizing the mail-out aspect. That work has now been completed, however, and we just have a bit of tidying up to do. Pre-release launch date now Monday, Feb 28 - afternoon. Have a good weekend!
Feb 26, 2011
Nolan Andres
The module is now available! We're in process of moving it to drupal.org, but for now, you can get a pre-release beta version from our website. See the page link above.
Mar 03, 2011
Jack Eisenberg
Hello, Nolan,
I am a member of an ad hoc IT advisory committee, researching software that may be used to replace a 24-year-old software package in use at our local Jewish Community Centre. I hadn't really thought about the implications of requiring a CRA-compliant receipt until coming across this thread on the wiki.
I have not worked with Drupal before, having used Joomla instead. From what I've read, your module is Drupal-specific, which to me means we'd need to select Drupal as our CRM if we intended to use your module. Is that a reasonable assumption, or will your package be easily convertible to a Joomla-compatible version once it is released to the CiviCRM community?
Mar 29, 2011
Nolan Andres
Hello, Jack...
Good question. We haven't worked on Civi/Joomla! connections for a number of years, so our knowledge of this is a little bit dated.
The module we created is definitely Drupal-centric, but we proofed the concept by just hacking the code into place originally. Then we pulled it out into a module afterward once we understood the problem space better. Technically, we could probably massage things into a Joomla! module, but we'd have to brush up on things a bit first. Someone else would certainly be welcome to do so, though. See my next post.
Apr 08, 2011
Jesse Williams
Hello Jack.
I do work for the Unitedway in Halifax, Nova Scotia. We run CiviCRM under Joomla and also would like to have CRA compliant charitable reciepts. Perhaps we could share the cost of development?
Let me know if you are Interested, you can email me directly ---> jesse (at) eastwindcycle.com
Mar 29, 2011
Nolan Andres
We've put the code up on drupal.org in a sandbox. Feel free to check it out:
http://drupal.org/sandbox/peaceworks/1094974
Apr 12, 2011
JoeMurray
Many thanks to Nolan, who has really moved the bar forward. For those in Canada (and I think Australia), you should note that to be compliant you need to print and mail the receipts. As one of the Revenue Canada links above indicates (http://www.cra-arc.gc.ca/chrts-gvng/chrts/prtng/rcpts/cmptr-eng.html), if the receipts are to be sent by email then it is also necessary to digitally encrypt them. We're looking at doing that in CiviCRM by this fall, and will add features like allowing a single receipt for a period like a year.
May 30, 2011
Alan Dixon
I'm not sure I'm reading those requirements the same way ...
1. I'm pretty sure that canadahelps.org (for example) doesn't do this.
2. these technical requirements are dangerous (e.g., you could follow these recommendations to the letter and then publish the decryption key on the website or something dumb like that). More significantly, the requirement doesn't identify what the security issue(s) are that they're trying to address.
In other words, I don't think we should wait or expect encrypted mail from CivICRM for this project.
But, perhaps there's a simple pdf encryption that could be implemented that would provide a minimal kind of protection from email interception, assuming that's the risk?
More ranting:
"the use of a secure electronic signature should be kept under the control of a responsible individual authorized by the charity; and"
this is wacky, they seem to be worried about someone misusing the electronic signature. Any signature that goes out by email is going to be insecure in the sense that someone can grab a copy and reuse to nefarious purpose (e.g. faked receipts, etc.). I really hate when security concerns result in technical requirements that don't actually address the problem, but create complexity ...
May 30, 2011
JoeMurray
I spoke with Revenue Canada last week to press them on whether the items saying they 'should' be done for electronic receipts were mandatory or optional and they were very insistent that they are mandatory.
If you wish to dispute the requirements then Revenue Canada would be a better place than this to raise the concerns.
The encryption technology is used to prevent people from a) creating additional pdf's or other electronic receipts without the knowledge of the issuing charity, or b) modifying the receipts to increase the amount on them using something like Adobe Acrobat. Or rather, if an organized fraud along these lines does occur, then Revenue Canada will be able to trace which receipts were validly issued.
This kind of digital signing and encryption is a fairly standard pdf functionality. See http://www.adobe.com/security/digsig.html for more general details. CiviCRM's pdf library supports the encryption: http://www.tcpdf.org/
May 30, 2011
JoeMurray
Um, with regard to 'wacky' control issue: I think you're a bit mistaken. It's the PKI difference between public and private keys, and it is the responsibility of the appropriate individual to keep the private key private. That's no different than keeping the private key of an SSL cert private. Sure, an admin could send out the private key to Amazon's SSL cert and break its security, but that doesn't (generally) happen because people are (generally) trustworthy.
May 30, 2011
Alan Dixon
Well, it really depends on what security issue they're trying to address, which isn't clear.
Yes, PKI will assure that that it hasn't been modified in transit (to the recipient), but I don't see that as a big risk. If the risk is a recipient modifying their pdf, then this seems like a not-helpful measure - who is actually going to look at the digital signature? An auditor? Wouldn't they check against the actual records of the issuing organization?
More to the point - is that what they mean by electronic signature? I'd assumed that was referring to the graphic copy of the actual person's signature, which needs to be part of the PDF. There's certainly no way to prevent it's misuse.
As an aside .. re: being able to modify the PDF - Karin took a PDF reciept from canadahelps.org and edited it without any trouble...
But yes, there's no point in speculating about revenue canada in here, and if you think all we need to do is add encryption with tcpdf, then we can do that. We don't have to do anything in civicrm for that right?
May 31, 2011
JoeMurray
The technology is designed to make auditable who issued a receipt and whether it was modified after it was issued. It is not intended to prevent modification as I understand it (see the Adobe page I referred to). So your CanadaHelps.org test doesn't show they aren't compliant, and even if they weren't compliant at the moment that wouldn't mean that new implementations or other implementations won't get in trouble with Revenue Canada if they aren't compliant.
I haven't checked which pdf library is being used by Nolan's module, but I imagine it also will have encryption/signature options. You don't need to do anything in CiviCRM for this - I just referred to their tcpdf library since I'd looked at it already.
May 31, 2011
Alan Dixon
Here's a helpful page: http://www.cra-arc.gc.ca/chrts-gvng/chrts/plcy/cps/cps-014-eng.html
In particular, the section "Sending electronic official donation receipts by e-mail on the Internet" where they clarify their use of 'electronic signature' (earlier, they use it in the sense of the signature facsimile).
From that section, it seems they have two security concerns:
1. Modification after reception, for which they only require it to be non-editable (item 9.)
2. Modification during transmission, for which they want the "electronic signature", meaning encryption w/ PKI.
So ...
1. I'd suggest that the modifications that Karin's lawyer added (the watermark), makes this solution more than compliant with security concern 1. (item 9.).
2. Item 2 ... from a useability point of view, I'd be concerned about the number of times a reciept was sent by email and not opened because of the encryption (which presumably would require some human understanding on the other end, since the recipient won't normally have their own PKI set up ...). In combination with the duplication issue (i.e. only one reciept issued and then subsequent ones marked 'duplicate'), I'm thinking that it might be smarter to NOT send them by email, but instead to send them a link (using a hash/token kind of technique) that they can use to download over an ssl connection (since ssl has solved exactly the problem of modification during transmission!).
With that solution, then it could even be monitored whether the use has made use of the link (which can expire after x number of days), and then have a human intervention process to solve the inevitable problems.
May 30, 2011
Alan Dixon
Karin has just finished cleaning this module up and after a bit of testing with other clients, we'll be happy to offer those cleanups back.
May 30, 2011
JoeMurray
Great. Does it support a single receipt for all donations within a period like a year, and reissuing receipts according to Revenue Canada requirements for duplicates (I think the issue org needs to track which ones are re-issued, and the duplicate receipt has to have some special notation that it is a duplicate on its face).
May 30, 2011
Alan Dixon
1. single receipt - i don't think so, haven't seen it.
2. reissuing - well, i seem to recall that in the past, reissuing meant making a new sequence and having a note on it that the old one was invalid, but this code will keep track and after the first time only issue a pdf with a red 'copy' across it, so maybe ...
May 31, 2011
Karin Gerritsen
After looking at the module that Peaceworks made available (they really jump started this), we decided to take the approach to first add a solid Tax receipting feature for both off-line as well as on-line contributions. Then later on this can be expanded to add automated Tax receipting features for on-line contributions. So in addition to the features Peaceworks had already implemented and that are the core of this: [adding a Print Tax Receipt and an Email Tax Receipt button to the View Contribution screen; keeping track of whether a receipt has already been issued or not -> duplicate status; checking with CiviCRM -> to see if the contribution is indeed tax-deductible or not] I've basically (I've attached a snapshot below):
- I've made some edits to make the upload dir work with multisite drupal installs as well
- added a new field set in the module's Drupal configuration side for Email message variables (off line contributions are not associated with a contribution page and I've eliminated that section for now -> until there is a way to make it work with PayPal eg it just didn't seem like a solid option at this point - so many charities use PayPal. Moneris for which the module was originally written is very expensive).
- added a security feature: you can upload a watermark (background image) - which I placed behind the $amount on the receipt
- added a source field (which can be used to add eg a NOTE: replaces tax receipt #...)
- shrunk and moved the duplicate copy text
So:
1) no single receipts: receipting is per contribution and that's clean / clear / and much easier to check duplicate status (or not) for. To do receipting per Name, or perhaps even per household address (in Canada spouses can lump/share/split contributions) would add quite a bit of complexity without any real benefit other than reducing the number of Emails w/ tax PDF receipts on the receiver's end.
2) the keeping track of duplicates that Peaceworks has at the core of this works really well. I've tested it back and forth now and it has yet to fail. Even after a tax PDF receipt has already been printed (Print Tax Receipt) by an Administrator a subsequent Email sent to the contributor (Email Tax Receipt) will already be marked "duplicate copy".
We're very fortunate that the charity I'm working for has its own in-house accountant (a BDO partner). He has been extremely valuable in terms of interpreting CRAs requirements. He has received an explicit ok from CRA on the 'unique ID number -> CiviCRM contribution ID' vs 'serial number'. He has also reviewed the CanadaHelps receipts and where we are compared to that and he is very happy with us sending these (below) as a regular PDF. CanadaHelp PDFs are easily edited with an online PDF editor. In addition all PDFs can be 'Photoshopped'. The new watermark background feature makes this quite difficult to do for our receipt. Our accountant's take on all this is that if people want to be fraudulent they will find a way. So we're trying to make it more difficult to edit our Tax receipts than it is to edit others (like CanadaHelps). This is similar to what we say about bears here in Western Canada: you only need to be a faster runner than the person standing next to you.
-- Karin
May 31, 2011
JoeMurray
As mentioned, Karin, when I specifically referred to the electronic receipting requirements for Charities with Revenue Canada they were adamant that they were not optional but required. It seems your testing and the BDO partner's understanding of the requirements weren't quite right in terms of producing something that wasn't editable. If he asked Revenue Canada if it was okay to send documents that were editable or could be photoshopped, of course he would be told yes. That is not a part of the requirements.
If you've received an official letter from Revenue Canada stating that their digital encryption/receipting stipulations on their website are not required, it would be really useful to me and my clients if you could post it here.
It is useful to know that the Contribution ID can serve as the unique ID and that a separate consecutive set of receipt IDs is not required. Given that they are consecutively generated it will be possible to identify gaps and also if a sequence has never been officially used.
May 31, 2011
JoeMurray
Thanks for all of your great work testing and enhancing this code, Karin. I'm going to work on allowing a single receipt to be issued for multiple contributions since some of my clients who mail hardcopies of receipts want that functionality to reduce handling and mailing charges.
Jun 01, 2011
Karin Gerritsen
Hi Joe, Alan and others,
I'm very pleased to report that the Accountant who works with one of my charities (a fellow with many credentials; a partner at BDO Canada LLP) has asked - again - and received - again - confirmation (today - this is as current as can be) that the receipts created by the module we're about to start using to manually issue CRA compliant Tax receipts by Print and Email are good as - is: no encryption required - I quote:
"When I talked to CRA a few minutes ago I was told that what we’re doing is adequate. We could do more (such as enTrust) but it’s not necessary. The supervisor I spoke with said that as long as the document is not easily manipulated, the Charity has done its part and if someone wants to fraudulently change the receipt, it’s the fraudster’s issue, not ours. As he said, with today’s technology no matter how well you secure the document, if someone really wants to change it, they can do so. He said that in the old days they’d use WhiteOut and type in a new number, so now they just use more sophisticated tools."
I certainly trust and have full confidence in his understanding of the conversation he had with a CRA supervisor and we're moving ahead. I'm not an accountant. I actually try not to talk to CRA. I certainly wouldn't be able to have a conversation about the differences between could, should and must. I much prefer binary things. I'm happy leaving the interpretation and clarification of CRA requirements up to someone who is very qualified to do so. Especially if it saves me a lot of work :-), and more importantly if it will avoid lots of potential user-issues and other headaches with electronic signatures.
We're well into beta testing now. We've identified a few more features eg the ability to enter a specific From: Email address as well as a cc- Email receipt option for archiving purposes. I'll be implementing these later this week. I'm excited that the charity I developed it for has given me an OK to share my edits to Peacework's module with the Drupal community. Of course it's up to you if you wish to use it. No-one has to do anything. Just trying to contribute and want you all to know that I'm doing so based on very solid information.
Jun 02, 2011
Donald A. Lobo
Would be great if we can do the foll and all participants are in agreement:
1. Integrate Karin / Alan's work into the peaceworks module and up the revision number
2. Work with CiviCore on IRC and get any core changes into the next 3.4.x release (if any)
3. Blog and document this on the wiki and use this as the "main" supported method for Civi-CRA folks
4. Would be good if we can figure out a good deployment strategy for such modules. UK has the civicrm_giftaid module (and is stored/maintained in civi repository), and most PP's are country-specific
This will come up once 3 is done, and plans for a D7 release etc. Would be good to have someone lead this effort
Jun 03, 2011
Karin Gerritsen
Thank you. I've tried to contact Nolan to talk about this and as it turns out he is on a - I'm sure well deserved - vacation until June 20. So, this will have to wait as I think it's important that he and I touch base again first. In the mean time, I'll start looking at putting the automated receipting for online donations back in, test and debug it and will try to make automated receipting work with eg PayPal - see issue http://drupal.org/node/1125036 - PayPal is such a commonly used Payment Processor. In my opinion if automated receipting is a feature of the module then it just has to work with PayPal to make it a useful contributed module.
-- Karin
Jun 03, 2011
Alan Dixon
Any reason that we can't just include a link to the reciept download on the thankyou page instead of trying to hook into the payment processor? That would also solve the problem of 'ensure not modified in transmission' criteria (yes, i know that we don't have to worry about it, but it still might come back to bite us and also email is just one of those technologies with too many mysteries).
Jun 03, 2011
Karin Gerritsen
Ok, I had already forgotten about that idea. Yeah, if you'll help me :-) Right now I know more about hooks than civicrm checksum. It may actually be a simpler solution to add the "automated receipting for online contributions" feature as from what others said the hook that the org Peacework's module calls is never invoked when PayPal is used.
-- Karin
Aug 01, 2011
Mathieu Lutfy
Hi Karin, Alan, Joe,
Thank you for your great work so far. This looks very promising, and will be of great help to smaller charities who need a quick way to generate valid tax receipts.
Is there a public repository for the latest code? i.e. Karin's improvements? I would love to contribute and help this move forward.
Mathieu (bgm on IRC)
Aug 09, 2011
Karin Gerritsen
Hi Mathieu,
I just got back from vacation. We've had two non-profits work with the most recent beta version over the past month. I've not had a chance yet to check in to see how they have been making out and/or what further edits may be necessary.
-- Karin
Sep 15, 2011
Kasia Wakarecy
Hello,
We have a client who is also interested in this module and willing to contribute money to have it happen. We (Freeform Solutions) are also certainly interested in helping with testing and coding - please let me know how we can chip in,
Kasia
(kasia at freeform dot ca)
Sep 16, 2011
Karin Gerritsen
Hi,
I'm just waiting to hear back for some final feedback from the office staff person who has been using the beta version. These are just details as I know they have already started using the module to issue their 2011 Tax Receipts.
In response to Lobo's post:
1) I've integrated my additions/edits w/ the Peaceworks module. Quite a few edits, so I'll post it on drupal.org in new sandbox project - within the next week so that you can all access it. It will be great to have some extra eyes to have a good look at the code.
2) No edits to CiviCRM core required.
-- Karin
Sep 16, 2011
Kasia Wakarecy
Once the recent updated to the Peaceworks modules are applied by Karin, we will get engaged in testing it in real life scenarios and if needed, discuss and contribute bug fixed. Once our client(s) use the module for a while, we all may be able to learn from that, improve, write new specs for UI etc. and then possibly have it implemented directly in CiviCRM so that there is no dependency on Drupal (so that Joomla folks can use it too). I suspect that the end of 2011 fiscal year (by April 2012) will be a big test for this module, and if it passes, we are in clear to get it going for CiviCRM direct implementation.
We are getting anxious to get started!
Kasia
(kasia at freeform dot ca)
Sep 24, 2011
Karin Gerritsen
I've put the code up on drupal.org in a sandbox on drupal.org:
http://drupal.org/sandbox/semperit/1289724
-- Karin
Mar 21, 2012
Karin Gerritsen
Update March - 2012
http://drupal.org/sandbox/semperit/1289724
New feature: the Issue Tax Receipt button in the CiviCRM View Contribution screen now has a Maple Leaf icon that is white if the Tax Receipt has NOT yet been issued and is red if the Tax Receipt already has been issued. Administrative Staff can press the Issue Tax Receipt button again - to issue a copy marked duplicate - but now they no longer need to check the Email archive to see if they already had issued a receipt previously.
Install file now includes a revised install and hook_update_N() so that pre-Drupal Sandbox versions of this module can now easily upgrade to the current version without having to rename Tables manually.
Other that the css and the icons to add the maple leaf icon to the Issue Tax Receipt button and the install/update hooks this revision includes a lot of restructuring and clean up of code as well as some more help in the configuration form for the module settings.
I've also created a D7 version - and am now considering asking for permission to promote this sandbox project to a full Drupal project so that it is easier to do releases / versions. LLLC has now been using this module for >>1y - and it works / they like it a lot.
Future:
-- Karin
May 04, 2012
Kevin Field
What are the chances of this functionality making its way into the WordPress version of CiviCRM in the near future?
May 04, 2012
Karin Gerritsen
This is a Drupal module - it's not in the CiviCRM code base.
May 04, 2012
Kevin Field
My bad. I'm having to rapidly get my feet wet with CiviCRM and am still new here. I guess what I meant was–even if this is perhaps not the best place to ask--has anyone heard of a similar plugin in the works for WordPress?
May 04, 2012
Kevin Field
Also, where can I download the D7 version? I installed the one from the sandbox page and I'm unable to enable it in the Drupal modules manager because it's for D6.
May 04, 2012
Karin Gerritsen
I don't have the D7 version online (not easy to do versions with Drupal Sandbox). That's why I'm looking at applying to get it promoted to a full Drupal project. Then we can do versions - bug/issue tracking.
May 04, 2012
Kevin Field
Can you temporarily create a second sandbox for it?
May 04, 2012
Karin Gerritsen
You can take the D6 code and make some small edits to make it work for D7. Re: the Drupal Field API and of course the .info file.
May 04, 2012
Kevin Field
I may have to pass on that one. I'm not even familiar with using Drupal yet, let alone coding for it. Is there any official way I can support the "full Drupal project" strategy?
May 04, 2012
Karin Gerritsen
Knowing that you're interested will help me get back onto this soon. It's a review of code (standards, security issues).