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]:
- Team members open a ticket and give unstructured details on the expense. Often attachments, like invoice copies are added.
- Senior team members (DPL) approve the payment.
- 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.
- 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
- need to aim for real-time financial data (bank balances, expenses that have been approved but not yet claimed, etc)
- isolation of data, infrastructure and decision-making for each trust organization due to incompatibility between jurisdictions
example: a US-based TO must be sensitive about data or decisions relating to Cuba due to the US embargo against Cuba. It may be best if nobody with US connections makes decisions relating to events in Cuba. Yet the European Union considers the sanctions "obsolete and illegal" and a TO based in the EU may be able to make decisions or process data in a way that would be troublesome in the US. The legal structure (independent trust organizations in different countries) combined with independent technical infrastructure may allow Debian some flexibility while not breaking laws anywhere.
- expense process
- is email a mandatory part of the workflow, an optional thing that has to be available for people who want it, or can it go away?
- the DPL (now or in future) may delegate some approvals so it is better to use a generic word like "Approver" and avoid references to the DPL
- make it easy for people to self-service (e.g. don't need to bother the Approver when they withdraw a request)
- need to handle cases where the expense currency and/or reimbursement currency are not the same as the trust organization currency, e.g. SPI uses USD, somebody from Canada uses their credit card ($CAD) to pay a hotel in Europe (EUR), the amount they eventually get back from SPI should match the CAD amount that was charged. The date their card payment is processed may be when they make the booking or it could be on check-out and if there is a gap of several months between reservation and travel then the FX rates could easily change
- event and travel expenses:
- can we capture data about events, e.g. before somebody makes a request to go to event Foo, they have to put Foo into a list of events?
- should there be a mechanism to log both the requester and beneficiaries in more detail (e.g. if one person submits a request on behalf of a group expense)
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
- logging the requests and the receipts in a Git repository, with signed tags for approval?
creating a MoinMoin extension for submitting data through the wiki, similar to the Wikimedia Foundation's process?
- processing requests through RT
using a structured email syntax similar to the way we write DEP-5 copyright files, the template could be placed in a hyperlink too, e.g. click here for email template
Category: travel Detail: hotel Beneficiary: developer1@debian.org,developer2@debian.org Event: https://wiki.debian.org/Events/....../FooBar Currency: EUR Amount: 123.45 Category: travel Detail: flight Beneficiary: developer1@debian.org Event: https://wiki.debian.org/Events/....../FooBar 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.