Skip to main content

Donation Receipt Generator — independent adversarial review

Reviewer: Fable 5.1 (independent; did not author the sources) · Date: 2026-09-25 Scope: sources/donation-receipts/{rules.yaml, test-cases.yaml, receipt-templates.md, open-questions.md} Method: read all four files end to end; re-fetched the primary sources with 20 WebFetch calls (budget: 20/20 used); extracted the full text of IRS Pub 1771 (Rev. 11-2023) from the downloaded PDF. Nothing in the source files was edited.

Severity: Critical = the tool as specified could produce a legally defective receipt or expose a church to a penalty · High = materially misleading instruction to the treasurer · Medium = wrong/blocking behaviour in a realistic case · Low = wording, consistency, citation hygiene.

Totals: 20 findings — 3 Critical · 3 High · 7 Medium · 7 Low.

Critical​

R-01 — A typed name on a browser PDF is not a signature; the tool must present the download as INCOMPLETE until signed, and must not claim "read-only" unless it actually encrypts​

Location: rules.yaml CA-11 (rule text, notes); receipt-templates.md §1 "Signature" note, F-CA-18; open-questions.md Q3, Q16. Problem: Reg. 3501(2) is a hard rule with exactly two exceptions, neither of which a browser tool can meet:

  • (3) facsimile signature — only where all receipt forms are pre-imprinted with name/address/registration number AND serially numbered "by a printing press or numbering machine" AND kept at the s.230(2) address until completed.
  • (3.1) — VERIFIED this pass: it applies only to "another recipient of a gift" (non-registered qualified donees), and it is the same pre-printed-form rule. It gives a registered charity nothing. rules.yaml quotes "(3) or (3.1)" in the excerpt without saying (3.1) is irrelevant to churches; a reader could think it is an e-signature exception. It is not.

There is NO regulatory e-signature provision. The only support for an electronic signature is CRA administrative guidance (computer-generated receipts page, modified 2020-02-24), and it is phrased as "should", not "must": "receipts should be in a read-only or non-editable format"; "the document should be encrypted and signed with an electronic signature"; "the use of a secure electronic signature should be kept under the control of a responsible individual authorized by the charity." CA-11's rule text says the PDF "must follow" this guidance — the source says "should". Keep the strictness as product policy, but cite it honestly.

Consequences the spec does not yet handle:

  1. The downloaded PDF has a blank line and a printed name. Under 3501(1)(i)+(2) it is not yet an official receipt. The UI must say so in those words ("This is not a valid official receipt until an authorized individual signs it") and the download button should not be labelled as if it emits a finished receipt.
  2. "Flattened, read-only PDF" (CA-11 (2), templates §1) is only true if the implementation sets PDF encryption with modify-permission denied (e.g. jsPDF's encryption option; pdf-lib cannot encrypt; browser print-to-PDF cannot). Without that, the PDF is trivially editable in any PDF editor and the "cannot readily be altered" chapeau of 3501(1) is not met by the tool's own claim. Either implement owner-password encryption or delete the word "read-only" from every surface and put the "non-editable" burden on the signer's e-signature (Acrobat digital signatures lock the document, which does satisfy "cannot readily be altered" + "signed with an electronic signature" in one step — recommend that as the primary e-path).
  3. If the treasurer prints and hand-signs, the SIGNED receipt exists only on paper; the "save your copy" notice (R-04) currently tells them to save the unsigned PDF. Reg. 3501(5) speaks of a receipt form "together with the duplicate thereof" — the duplicate should match what the donor got. Instruct: sign two printouts (donor copy + church duplicate) or scan the signed one. Excerpt & URL: Reg. 3501(2): "Except as provided in subsection (3) or (3.1), every official receipt shall be signed personally by an individual referred to in paragraph (1)(i) or (1.1)(i)." Reg. 3501(3.1): "Where all official receipt forms of another recipient of the gift are (a) distinctively imprinted with the name and address of the other recipient of the gift, (b) serially numbered by a printing press or numbering machine, and (c) if applicable, kept at a place referred to in subsection 230(1) of the Act until completed as an official receipt, the official receipts may bear a facsimile signature." — https://laws-lois.justice.gc.ca/eng/regulations/C.R.C.,_c._945/section-3501.html (current to 2026-09-03). CRA: https://www.canada.ca/en/revenue-agency/services/charities-giving/charities/operating-a-registered-charity/issuing-receipts/computer-generated-receipts.html (2020-02-24). Fix: In CA-11: (a) add a note that 3501(3.1) is for non-registered qualified donees and does not help; (b) change "must follow" to "CRA guidance says receipts should…; this tool treats it as mandatory"; (c) replace "exports a flattened, read-only PDF" with the implementation truth (encrypted with modify denied, OR unencrypted + explicit instruction to apply a locking digital signature); (d) add a mandatory pre-download banner "Not a valid official receipt until signed by an authorized individual"; (e) add the signed-duplicate instruction. Add a test case: download without signer name → blocked; and one asserting the banner text.

R-02 — Nothing stops an unregistered church from generating a document titled "Official donation receipt for income tax purposes"​

Location: rules.yaml CA-02 (validate loosely, "do not hard-reject on format"), F-CA-04; receipt-templates.md §1 title line; open-questions.md Q7. Problem: Only a registered charity or other listed qualified donee may issue official receipts; the CRA sample page (verified) says "Only registered charities, RCAAAs, RJOs, and RNASOs receive registration numbers for receipt purposes." The spec requires the registration number field to be non-blank but deliberately accepts anything containing "RR". A church that is incorporated as a non-profit but never registered with the CRA (very common) can type "N/A", "pending" or its incorporation number and produce a document that looks exactly like an official receipt. That is the single most damaging output this tool could emit, and the current rules have no gate, no attestation and no warning. The ITA penalties for issuing receipts without being registered / with false information (s.188.1(9) 125%; s.188.1(7)–(8) 5%/10% for incomplete receipts) were NOT fetched this pass — cite them as HYPOTHESIS until verified — but the CRA statement above alone justifies the gate. Excerpt & URL: "Only registered charities, RCAAAs, RJOs, and RNASOs receive registration numbers for receipt purposes." — https://www.canada.ca/en/revenue-agency/services/charities-giving/charities/sample-official-donation-receipts.html (2021-12-01). Reg. 3501(1)(b): "the registration number assigned by the Minister to the organization". Fix: (1) Mandatory attestation checkbox before any CA receipt: "This organization is a registered charity (or other qualified donee) listed on the CRA List of charities, and the name/address/number below are exactly as they appear there" + link to the CRA List of charities search. (2) Validate the number against ^\d{9}RR\d{4}$; on mismatch show a blocking warning with a one-click "I have checked the CRA List and this is correct" override (rather than silently accepting). The format itself remains unverified from a primary source (both BN pages 404'd this pass; see "Could not verify"), so keep the override. (3) Add refer text: "Not registered? You cannot issue official donation receipts. You may issue a plain thank-you letter that is NOT titled 'official receipt' and carries no registration number." (4) US mirror (Low): the template's disclosure sentence presumes the organization is described in IRC §170(c); add a one-line attestation, no format check.

R-03 — The stateless design makes duplicate serial numbers likely; the spec never defines which action "consumes" a serial number​

Location: rules.yaml CA-03, CA-12 (3), CA-16; open-questions.md Q17; receipt-templates.md §1 UI text. Problem: The treasurer types the serial (Phase 1 = option (a)). Real flow: they generate, notice a typo in the address, go back, fix it and generate again with the same serial — two PDFs, one serial, no record of the first. Or they close the tab and re-enter the same "next number" tomorrow. Meanwhile the CRA rule for an erroneous receipt that was never sent is not "discard it" — it is: prepare a new receipt AND "keep both copies of the original and mark 'cancelled' on them" (verified). So under CRA guidance even a mistaken first download consumes a serial number and must be retained. The spec has no concept of "issued"; it cannot tell the treasurer when a number has been used up. Excerpt & URL: CRA: if a receipt "was prepared but not yet sent to the donor, the charity may create a new receipt instead. In this case, they must keep both copies of the original and mark them 'cancelled.'" — https://www.canada.ca/en/revenue-agency/services/charities-giving/charities/operating-a-registered-charity/issuing-receipts/correcting-replacing-official-donation-receipts.html (2017-06-22). CRA "What information": "a unique serial number" (2018-11-02). Reg. 3501(1)(c), (4), (5). Fix: Define two states explicitly in rules and UI: Preview (watermarked "PREVIEW — not a receipt", no serial printed or serial greyed, unlimited edits) and Issue (serial printed; download; the number is now consumed). On Issue, show: "Receipt No. {serial} is now used. Write it in your receipt log now. If you find an error after this point, do not reuse this number — use 'Replace a receipt' (CA-12) and keep this copy marked 'cancelled'." Offer a one-line CSV/text "log entry" download (serial, donor, amount, date issued) alongside the PDF. Implement Q17 option (c) as a soft helper: remember the last serial issued in this browser and warn (not block) if the new one is <= it. Add test cases: same serial entered twice in one session → warning; Replace mode with replaces_serial == serial_number → reject.

High​

R-04 — The retention notice tells the treasurer to keep a copy but omits three things the CRA actually requires of that copy​

Location: rules.yaml CA-14 (display text), F-CA-22; receipt-templates.md §1 UI text. Problem: Verified CRA text imposes: (1) electronic records must stay electronic — "Books and records that are created and maintained in electronic format must be kept in an electronically readable format, even if your charity has paper printouts" — so a printout alone of a browser-generated receipt is not enough; the PDF file must be kept; (2) records "must be kept at the Canadian address that you have on file with us" — a treasurer's personal laptop/cloud in another city is a question the notice should raise; (3) the computer-generated receipts page says donor records should be kept on "non-erasable media, such as CD-ROMs or printouts, with copies kept off-site for recovery purposes" and "copies of email-issued receipts must be retained by the charity". Plus R-01(3): the copy should be of the signed receipt. The current sentence covers none of this. Excerpt & URL: https://www.canada.ca/en/revenue-agency/services/charities-giving/charities/operating-a-registered-charity/books-records.html (2025-09-08); computer-generated receipts page (2020-02-24), quotes above. Fix: Replace the F-CA-22 text with: "Save the PDF file itself (not just a printout) — the CRA requires electronically created records to be kept in electronic form. Keep a copy of the SIGNED receipt. Store it with your church's records at the address on file with the CRA, with a backup copy elsewhere. Keep receipt copies at least two years after the end of the year of the gift (your donation records: six years). This tool keeps nothing." Add retention_notice_contains: [pdf_file, signed, canadian_address, backup, two_years] to a test case.

R-05 — The US "contemporaneous" warning fires too late: donors can file in late January, not April 15​

Location: rules.yaml US-08 formula and notes; test-cases.yaml US-TC-17; receipt-templates.md §2 "Timing". Problem: The statute (verified) makes the acknowledgment good only if the donor "obtains" it on or before the EARLIER of filing date or due date. The IRS accepts returns from roughly the last week of January. A statement issued February 20 is already useless to a donor who filed February 1 — and early filers are exactly the refund-seekers a church will hear from. Warning only after April 15 (US-TC-17) tells the treasurer that Feb–Apr issuance is safe; it is not. Also the test is when the donor receives it, not the date printed on it — a January 31 issue date mailed February 3 may miss a February 1 filer. Excerpt & URL: §170(f)(8)(C): "an acknowledgment shall be considered to be contemporaneous if the taxpayer obtains the acknowledgment on or before the earlier of—(i) the date on which the taxpayer files a return for the taxable year in which the contribution was made, or (ii) the due date (including extensions) for filing such return." — https://www.law.cornell.edu/uscode/text/26/170. Pub 1771 p.3: "Charities typically send written acknowledgments to donors no later than January 31 of the year following the donation." Reg. 1.170A-13(f)(3) same test — https://www.law.cornell.edu/cfr/text/26/1.170A-13. Fix: Three-tier message keyed to date_issued: ≤ Jan 31 (Y+1): "on time — send now"; Feb 1 – Apr 15: "Late for any donor who has already filed. Ask donors whether they have filed before they rely on this; a donor who filed cannot use it and would need to amend." (yellow); after Apr 15: "Only donors on extension can still use this" (red); after Oct 15: "Cannot serve as a contemporaneous acknowledgment for anyone; still useful as the §170(f)(17) record if the donor has not yet filed an amended return" (or simply red). Change US-08 notes to say the test is the date the donor OBTAINS it. Update US-TC-17 and add a Feb-issue test.

R-06 — The issue-date override permits backdating​

Location: rules.yaml CA-04 formula: "date_receipt_issued = today's date (treasurer may override; must be >= last gift date)". Problem: Reg. 3501(1)(f) requires "the date on which the receipt was issued" — a fact, not a choice. The only constraint specified is >= last gift date, so a treasurer generating on March 1 can print "issued February 15". A receipt with a false issue date is a false receipt; and Reg. 3501(6) deems a receipt spoiled when the received date is wrong — the issued date is at least as sensitive. The override exists presumably for "I printed it yesterday and am regenerating" — that is a replacement situation (R-03), not a date edit. Excerpt & URL: Reg. 3501(1)(f): "the date on which the receipt was issued;" — laws-lois URL above. Fix: date_receipt_issued = today (device date, shown, not editable). If a wrong device clock is the concern, allow editing only with a confirmation "The date issued must be the actual date you issue this receipt." Same for US F-US-14. Remove the ">= last gift date" phrasing (it implies earlier dates are otherwise fine); keep the check as an error.

Medium​

R-07 — Donor-address hard gate demands Canadian-format parts; the regulation only says "address"​

Location: rules.yaml CA-06 formula "REQUIRE … donor.address (street, city, province, postal)", F-CA-13; test-cases.yaml CA-TC-14. Problem: Reg. 3501(1)(g) requires "the name and address of the donor" — nothing about province or postal code. Snowbirds, US-resident family members, missionaries abroad and rural donors with a PO box/RR/lot-and-concession address would be blocked or forced to invent a province. Blocking is fine; the field structure is not. Excerpt & URL: Reg. 3501(1)(g) quoted above; CRA: "the name and address of the donor must appear on the receipt" (what-you-need-know, 2018-11-02). Fix: Require a non-empty free-text address (≥ 2 lines or ≥ 10 characters); offer structured Canadian fields as an optional helper. Add a test: US-address donor → receipt generated.

R-08 — Corporate / organizational donors: first-name gate blocks a receipt the regulation allows​

Location: rules.yaml header scope ("from INDIVIDUALS"), CA-06 ("first name … REQUIRED"), F-CA-09/F-CA-11 required. Problem: Reg. 3501(1)(g) requires first name and initial only "in the case of an individual". A business or foundation cheque is a common church gift. The header says individuals are the Phase 1 scope, but there is no refer rule or UI path for "donor is an organization" — the treasurer will type the company name into "first name" to get past the gate, producing an odd receipt. Either support (name + address, no first-name gate) or refer explicitly. Excerpt & URL: Reg. 3501(1)(g) above. Fix: Add donor.kind in {individual, organization}; for organization require legal_name + address only; note that the "true donor" rule still applies (CRA: cannot receipt "donations of business property to individuals unless written evidence proves personal ownership"). Add CA-TC for a corporate donor and a US equivalent.

R-09 — No warning against double-receipting gifts made through a receipting intermediary (e.g. CanadaHelps)​

Location: rules.yaml CA-15 (list of non-receiptable situations), CA-05 notes on e-transfers. Problem: Many Canadian churches receive online gifts through platforms that are themselves registered charities and issue the official receipt to the donor (CanadaHelps is the typical case). The church must not issue a second official receipt for the same gift. The spec's list of "cannot receipt" cases does not include "already receipted by an intermediary charity". Mechanics of specific platforms were NOT verified this pass — label the platform example as HYPOTHESIS in UI help — but the underlying principle is the verified "true donor / one receipt per gift" rule and the intermediary text on the CRA page ("Intermediaries collecting funds — the actual donors are the true donors"). Excerpt & URL: what-you-need-know page (2018-11-02), intermediary bullet. Fix: Add to CA-15: "(f) a gift already receipted by another registered charity that collected it on your behalf (some online giving platforms do this) — do not issue a second receipt." Add a checkbox in the gift row: "Received via a third-party platform" → show the warning.

R-10 — Open question Q5 (lost receipts) is already answered on the CRA page; rules.yaml understates the source​

Location: rules.yaml CA-12 notes ("the fetched page text did not state a rule for a donor who lost their receipt"); open-questions.md Q5. Problem: The CRA "Correcting or replacing" page (verified this pass) covers lost receipts directly: a replacement may be issued for a receipt "that was lost or had errors", with "all the required information", "the serial number of the original receipt" and "a statement that it replaces the original receipt", the original kept and marked cancelled. Phase 1's treatment is right; the open question can be closed and the confidence note corrected. Excerpt & URL: as quoted; URL in R-03. Fix: Move the lost-receipt sentence into the CA-12 excerpt; delete Q5 or mark "RESOLVED 2026-09-25".

R-11 — Foreign-currency gifts: the spec says "CAD only" but never tells the treasurer what to do with a USD cheque, and the UI has no currency label​

Location: open-questions.md Q9; no rule id; receipt-templates.md amount lines print "$". Problem: A US-dollar cheque or a USD e-transfer to a Canadian church is routine near the border and in immigrant congregations. "$" on the receipt is ambiguous. I could not find a CRA page on foreign-currency receipting via the hub (unverified — see list). The safe Phase 1 behaviour is explicit, not silent. Excerpt & URL: none fetched — UNVERIFIED. (Common practice — HYPOTHESIS pending a CRA source — is to receipt the CAD value at the exchange rate on the date received.) Fix: Add rule CA-19 (refer): currency selector fixed to CAD with the label "Amount of gift (CAD)"; if the treasurer indicates the gift arrived in another currency, refer: "Receipt the Canadian-dollar value your bank credited (or the Bank of Canada rate on the date received — confirm with the CRA/your accountant), and note the original currency in your records." Print "CAD" (and "USD" on the US statement) next to every amount. Add a test case.

R-12 — FMV == payment: US-14's formula allows what US-04 and US-TC-20 reject​

Location: rules.yaml US-04 formula "REQUIRE FMV <= P (else reject)" + notes "If FMV == P there is no contribution at all … the generator rejects"; US-14 formula assert 0 <= FMV <= P; test-cases.yaml US-TC-20 (invalid). Problem: Three statements, two behaviours. FMV <= P passes FMV == P; the notes and the test case reject it. An implementer following the formula will ship a $0.00 deductible line that US-TC-20 says must not exist. Fix: Make both formulas assert 0 <= FMV < P and US-14 item (2) "equals or exceeds the payment". (Pub 1771 p.7 supports rejecting: "no donative element involved … such as in a typical museum gift shop sale".)

R-13 — Mailed gifts: the rules assign the postmark year but do not tell the treasurer to keep the envelope, nor which date to print in the itemized table​

Location: rules.yaml CA-05; test-cases.yaml CA-TC-16; F-CA-21. Problem: The CRA page (verified) adds: charities should retain the stamped envelope as documentation. CA-TC-16 records both date_received: 2027-01-04 and postmark_date: 2026-12-30 but the expected output does not say which appears in the per-gift table (F-CA-21) or on a single receipt's "Date gift received" line. Per CRA the date of donation IS the postmark date, so that is the date to print; the arrival date belongs in the church's records. Fix: CA-05 formula: date_of_donation = postmark_date if received_by_mail else date_received; print date_of_donation; UI tip "Keep the postmarked envelope with your records." Add date_printed_for_gift_2: "2026-12-30" to CA-TC-16.

Low​

R-14 — Field labels drift from the CRA sample​

Location: receipt-templates.md §1 ("Location receipt issued"; "Nominal benefit … de minimis"). Problem: The CRA sample (verified) uses "Place issued", "Date gift received", "Date receipt issued", "Receipt No.", "Registration No.", "Donor name", "Authorized signature", and the footer label "Name and website of the Canada Revenue Agency". "De minimis" is not CRA vocabulary (CRA: "nominal", "too minimal to affect the amount of the gift"). Fix: Use "Place issued"; reword the nominal description to "Nominal benefit (FMV $X) — too minimal to affect the gift (CRA nominal threshold)".

R-15 — Ambiguous 80% error text​

Location: test-cases.yaml CA-TC-08, CA-TC-21 ("more than 80% of the gift ($80.00)" / "($40.00)"). Problem: Reads as if the gift were $80 / $40. Fix: "The advantage ($81.00) is more than 80% of the gift (80% of $100.00 = $80.00)."

R-16 — US-11 30-day rule is now verified; upgrade the note​

Location: rules.yaml US-11 notes ("not fetched verbatim"); open-questions.md Q13. Excerpt & URL: §170(f)(12)(C): acknowledgment is contemporaneous "if the donee organization provides it within 30 days of" the sale (or the contribution, for vehicles the charity keeps) — https://www.law.cornell.edu/uscode/text/26/170. Fix: Quote it; tool text can say "within 30 days".

R-17 — No handling for goods PLUS intangible religious benefits in the same gift​

Location: rules.yaml US-02 enum goods_status in {none, provided, intangible_religious_only}; US-14 (6). Problem: Reg. 1.170A-13(f)(2) requires a description/GFE of goods other than intangible religious benefits AND, separately, the intangible-religious statement when applicable; Pub 1771's $75-membership + $20-poster example shows a mixed case. The enum forces the treasurer to drop one. Practical effect is small (the goods line is what matters), but the UI should say "choose 'provided' and describe only the tangible goods". Fix: Add helper text, or a fourth enum value provided_plus_intangible_religious that prints both (b) and (c).

R-18 — Input schema inconsistency in cumulative test cases​

Location: test-cases.yaml CA-TC-02 (no statement_year), CA-TC-16 / CA-TC-20 (statement_year), CA-TC-20 uses near_cash while others use advantage_is_cash_or_near_cash. Fix: Normalize field names; an implementer generating fixtures from these will otherwise fork.

R-19 — US-15 invariant vs goods_status: provided with FMV 0​

Location: rules.yaml US-15 ("a gift with FMV == 0 prints exactly one of US-03 or US-05"), US-14. Problem: provided + FMV 0.00 is accepted by US-14 but violates US-15. Reject it in US-14 ("if goods were provided, the estimate must be > $0; if it is genuinely worthless, choose 'none'").

R-20 — Donor name is not a statutory CWA element; keep it required but cite it as a product rule​

Location: rules.yaml F-US-04 (satisfies: [US-14]), US-14 (4). Problem: Neither §170(f)(8)(B) nor Reg. 1.170A-13(f)(2) lists the donor's name (verified). Requiring it is right (the donor must show whose acknowledgment it is), but rules text should not imply a statutory basis. Also, receipt-templates.md §2 note "Field labels are not prescribed by the IRS" is correct — good. Fix: Add note to F-US-04: "Not a statutory element; required so the acknowledgment identifies the donor."

Confirmed correct (spot-checked against primary text this pass)​

  • CA-01 title wording; 3501(1) chapeau "cannot readily be altered" — exact.
  • CA-03 "unique serial number"; 3501(4) replacement wording — exact.
  • CA-04 3501(1)(e) "the date on which or the year during which the gift was received" — exact; CRA sample labels the field for cash gifts by year.
  • CA-05 postmark rule — exact.
  • CA-06 3501(1)(g) — exact; joint accounts "one or both names" — confirmed.
  • CA-12 3501(5) "duplicate" wording; CRA unsent-receipt rule — exact.
  • CA-13 "canada.ca/charities-giving" — confirmed on sample page.
  • CA-14 two years / six years / Canadian address / electronically readable — exact.
  • US-01/02/03/04/05/06/07/08/09/12/13: every Pub 1771 quotation checked against the extracted PDF text (Rev. 11-2023) — exact, including the 2015 sample dates, the $125/$62.50/$12.50 2023 figures, the $10/$5,000 penalty, "small print", "no donative element", and the SSN sentence.
  • §170(f)(8)(A)–(C), (f)(17); §6115(a)–(b); Reg. 1.170A-13(f)(1) non-aggregation, (f)(5) definition, (f)(8) $75 membership — confirmed.
  • US-TC-05 matches the Pub 1771 $100/$40/$60 example exactly.
  • Arithmetic in every computed test case re-derived: all totals and boundary comparisons are correct (CA-TC-05/06/07/19/20, US-TC-03/04/06/18/19).

Verified this pass (20/20 fetches + 1 local PDF extraction)​

  1. Income Tax Regulations s.3501 — laws-lois (two fetches; chapeau, (1)(c),(d),(e),(f),(g),(i),(j), (1.1), (2), (3), (3.1), (4), (5)). Current to 2026-09-03.
  2. CRA — Computer-generated receipts (2020-02-24).
  3. CRA — What information must be on an official donation receipt (2018-11-02).
  4. CRA — Sample official donation receipts (2021-12-01) — at /charities-giving/charities/sample-official-donation-receipts.html; the URL cited in rules.yaml CA-01/CA-07 notes (under /issuing-receipts/) returns 404 — fix the citation.
  5. CRA — What you need to know to issue an official donation receipt (2018-11-02).
  6. CRA — Correcting or replacing official donation receipts (2017-06-22).
  7. CRA — Books and records (2025-09-08).
  8. CRA — Issuing receipts hub (link inventory).
  9. CRA — Checklist: Issuing complete and accurate donation receipts (2018-11-02).
  10. 26 U.S.C. §170 — (f)(8), (f)(12)(C), (f)(16), (f)(17) (law.cornell.edu).
  11. 26 U.S.C. §6115 (law.cornell.edu).
  12. 26 CFR §1.170A-13(f) (law.cornell.edu).
  13. IRS — Charitable contributions: written acknowledgments (28-Jun-2026).
  14. IRS Pub 1771 (Rev. 11-2023) — full text extracted from the downloaded PDF with pypdf.

Could NOT verify (unfetchable or out of budget) — treat as unverified​

  • Registration-number format 123456789RR0001: CRA charities business-number page and the general BN page both returned 404. Still no primary text (Q7 stands).
  • Any CRA page on foreign-currency gifts: none linked from the Issuing-receipts hub; not found (R-11).
  • CRA "Questions and answers about issuing receipts": 404 at the guessed URL.
  • ITA s.248(30)–(32) verbatim (Q1 stands).
  • Folio S7-F1-C1, the Split-receipting page, Guide P113, the "When should a charity issue a receipt" page, "What is a gift", gift-card and FMV pages — not re-fetched; the first agent's quotations were not independently re-verified, but nothing in them conflicts with the regulation text I did verify.
  • Reg. 5800(1)(d) (two-year receipt retention regulatory basis); ITA s.188.1 penalties (cited in R-02 as HYPOTHESIS).
  • 26 U.S.C. §6714 verbatim; Reg. 1.6115-1; Reg. 1.170A-15; Pub 526; Form 1098-C page.
  • Current-year (2026) token-item inflation figures (Q10 stands).