Current situation and processes

Debian's funds are held externally in a distributed way by Trusted Organizations. TOs provide the legal structure, auditing and payments handling. There are about 5 relevant TOs[1] as of now.

Debian has an (contractual?) understanding with TOs that funds and spending are controlled by Debian, but legally held by TOs. In this way Debian is like a virtual company distributed across multiple legal entities.

Income includes donations and fees paid by corporate sponsors. Expenses include hardware, travel expenses and costs for organizing conferences. Currently income and expenses are booked by the TO in the corresponding area or jurisdiction. (US, EU, Asia, etc.)

Reimbursement process

Most smaller expenses for travel or conferences are paid upfront by team members, who are later reimbursed by a related TO. Debian only handles the approval process. The actual payment and legal requirements (invoices) are done by TOs.

The current process is based on a ticket system (RT)[2] and is mostly email based. Rough steps (excluding pre-approval) are outlined on [4]:

  1. Team members open a ticket and give unstructured details on the expense. Often attachments, like invoice copies are added.
  2. Senior team members (DPL) approve the payment.
  3. Office staff of the relevant TO arranges the actual flow of funds or requests further details. TO may have their own form and reimbursement system.
  4. Reimbursement ticket is marked as "Resolved" in the ticket system

Reporting process

The Debian treasurer is required to publish accounts of incoming and outgoing funds, especially how outgoing funds were used.[5] This process depends on accounts published by TOs and only limited information is available.

Requirements review

Possible implementations

To better fulfill the requirements outlined above, on [5] and in the Debian constitution[3], small improvements to the current system could be made. Larger changes to the process are currently not possible due to the requirements of TOs and a dependence on the historic email-based process.

The next sections outline possible projects around improving the reimbursement and reporting process.

Structured reimbursement emails

Category: travel
Detail: hotel
Currency: EUR
Amount: 123.45

Category: travel
Detail: flight
Currency: GBP
Amount: 89.00

Java Script wizard to prepare reimbursement emails

To ensure the standardized email structure suggested above, a simple Java Script wizard could be implemented. This "reimbursement wizard" would lead users through multiple steps to select the correct TO, generate the reimbursement email from a template and present a link to the correct TO form at the end.

This wizard page would provide users with a one-stop place to start the reimbursement process, allow some improvements (like new fields) later and ensure the expense data is collected. Categorical fields, like expense category and currency could be added as dropdown to ensure consistent data entry.

If this simple Java script wizard can't be embedded in a wiki page, it could be hosted as static website on Debian's own servers. No backend would be used or data stored to avoid compliance issues. Email is still used to authenticate the sender.

Extract structured data from ticket system (RT)

RT provides a way to add extensions (in Perl?). If organizationally possible, an RT extension could be used to parse structured data in reimbursement emails and add them as custom fields or RT workflows.

If RT extensions aren't feasible, the API interface could be used to parse each reimbursement ticket and save the extracted data in a structured format, like CSV or JSON.

Regular expense reporting

The data extracted from from reimbursement tickets (emails) could be used to generate regular (monthly or quarterly) expense reports without waiting for annual TO reports. After extracting the structured data from RT, expenses can be grouped and graphed using Python Pandas and Matplotlib.

Annual financial report

TOs follow an annual accounting cycle and complete data on Debian-related income and expenses only becomes available on that cycle. These TO reports are in various formats, like PDFs.

If not currently done, those varying TO reports could be converted into a machine-readable format, like CSV when files come in and then proper accounting reports could be compiled using the open source command line tool ledger[6]. Input files (reports from various TOs) could be kept in a git repository and the report built using a Makefile.