Purpose of Software:

1. Track donor information.
2. Track individual donations and their associated data, for pre-accounting, donor listing, and acknowledgement purposes, both for the SPI board and for each individual Associated Project.
3. Track expense/payment requests, in general and per-project, and forward them to the bookkeeper.
   
4. Aggregate reporting on fundraising, expenses and balances available both for the SPI board and for each Associated Project.

Usability:

1. Software must be easy to understand and teach interns and temporary help how to use.
2. Software must not require more keystrokes/clicks than is reasonably necessary for information; it should not be necessary to enter the same transaction data twice, or to re-enter data already present in the system.

Architecture:

1. Web-based, or otherwise directly and securely sharable with several members of the board.
2. Should use as many OSS components as reasonably possible, with preference to components already familiar to members of the SPI board and admin infrastructure.
3. Must be backed by a real SQL database which permits ad-hoc queries and connection to external reporting tools.
4.  Preferred to be extensible/modifiable since we are likely to needs for new capabilities in the future.
5. Software may be 100% unified, or may be in the form of separate donor vs. accounting packages.  In the latter case, we may not do the accounting functions at all, but rely on import/export into external accounting packages.  The rest of this spec is based on the expectation that we don't have unified accounting functions.

Security:

1. Must support level-based or feature-based (preferred) rights management which is well-enforced, including differences between read-only and modification access.
2. Must support an audit trail for data modifications.  Audit trail for connections is also desirable.
3. Must be secure from a moderately knowledgable and determined attack (such as SQL injection), as well as from automated cracker scripts.  

Donor Management:

1. Must support both individual donors and corporate donors.
2. Must support entry of name, address, company, whether donor is the company or the individual, e-mail address, phone, anonymity preference, and notes and easy re-use of this informaton for successive/automated donations.
3. Desired extra information: track spouse/partner/coworker names, extra phone numbers and e-mail addresses and street addresses, wire transfer information, web page, company logo (where appropriate).

Donation Management:

1. Data to track: Pledge, received and deposited dates.  Orignial amount, currency, exchange rate (populate from last), Payment method, payment method fees (auto-populate), other fees, designation(s) and subdesignation(s) (see below), whether it's subject to SPI commission, transaction number (if applicable) and check number & bank (if applicable), entered by & date, modified by & date, flag for "unrelated business income".
2. Designations: All contributions must support "splitting" the donation into multiple designations, preferably to any number of them (but limiting at 5 splits would be acceptable).  Each of these splits would require a "designation" which is identical to Associated Project names, and would offer an optional "sub-designation".  Examples: Designations would include: Debian, PostgreSQL, Gallery.  Sub-designations for Debian would include DebConf6 and DebConf7.  It would be nice for sub-designations to support expiration dates (when they stop appearing in menus).
3. SPI commission: if "spi commission"=true for the donation, 5% of the total donation after fees should be automatically split to the "SPI General" designation.
4. There should be some mechanism to update existing donations in batch with receipt/deposit information.
5. It should be possible to check over donations, and fix them, before exporting to the accounting function/software.
6. Donations should be exportable, in batch, to the accounting function or software.
7. Donations should support tracked line-item corrections after accounting export.
8. Ideally, we should have some way to track "in-kind" donations as well.  Needs thought.
9. Thank-you note tracking is desired but might be added later.

Payment Requests

1. Data to track: payee (same data as Donors, maybe same table), amount requested, currency, designation & subdesignation, requested by, dates requested, approved, due, approved by, payment method (with details if not in the donor profile), payment fees, fees designation (should default to payment desingation) purpose, tax category, details, flag advance payment vs. compensation.
2. Bonus points: allow uploading/storage of supporting documents for the payment.  May be more appropriate in accounting system.
3. Payment requests should be exportable to the accounting sw/function in batch.
4. Ideally, "request" and "approval" permissions should be separate.
5. Payment adjustments (particularly fees) should be possible, singularly or in batch, after export.

Reporting

1. Monthly/Annual financial report: should report amounts recieved, paid, and balance forward by designation and sub-designation.
2. Donor detail: should mail to each designation "owner" once per month, a list of all of their donors, with split amounts and all available contact information for thank-you notes.  Format negotiable but probably CSV is best.  GPG encryption may be required.
3. Bonus Points: on-demand online designation totals (balance forward, monthly payments and donations with detail) available on the web.  This would eliminate the need for (2).  However, it would be required that each designation owner be only able to see their own designation funds.
4. Reconciliation report: list of donations & payments for an arbitrary period, with amounts & adjusted amounts.

Other Functions

1. System must be able to import donation information (CSV format) from external credit card processors.