npoacct
  1. npoacct
  2. Reimbursements

Requirements

Requirements for the Reimbursement and Outgoing Payment Request System

Overview

One short-term goal of the Non-Profit Accounting Project is to create a system that allows (a) members of an organization, and external parties, to submit requests for reimbursement or request for payment like invoices, and (b) the organization's bookkeepers, accountants, and managerial approvers to review those requests, add them to the organization's books, and prepare payment. The primary motivation for this project is to save time both groups spend on handling reimbursement requests and outgoing payments, and reduce turnaround time for these requests, and to help members file complete requests that are easy for bookkeepers to review and accept.

Members of the organization could be employees, members of projects represented by the organization, or others doing work to advance the organization's mission—anyone who the organization might want to reimburse or pay.

The system should not make assumptions about specific reimbursement policies or invoicing requirements. Instead, it should be possible for a bookkeeper or administrator to define follow-up questions and what responses are and are not eligible for reimbursement or payment. Early versions may require sysadmin-level technical expertise to do this, but ultimately it should be doable by a bookkeeper with appropriate privileges.

Requirements for first release

Defining the request form

Requests for payment have four states: Draft, Submitted, Accepted, and Rejected.

Administrators can define questions to ask the requestor about the entire request, and about each expense in the request. The system can display forms, validate answers, and record answers for questions with the following types of answers:

Other types like boolean and date would be nice, but I think they could be expressed with the types above.

It is expected that one question about expenses will be the type of expense (e.g., airfare, accommodations, meals, office supplies). The administrator must be able to define follow-up questions that are asked based on the expense type, to request additional information as required by policy. For example, Conservancy requires airfare search results to be attached to airfare reimbursement requests. Requestors should be prompted for this documentation when submitting reimbursements for flights, and not for other expenses.

Requestor workflow

Requestors can log in and see the status of all their requests. They can also create a new request, which starts in the Draft state.

When they view a report, it shows the questions and answers about the entire report, and a list of associated expenses. Viewing a specific expense similarly shows all the questions and answers about it.

When a report is Draft state, the requestor can edit any answer in the report or an associated expense. They can also add an expense, which begins by asking them questions common to all expenses, and then follow-up questions as necessary based on those answers.

When an Draft report has at least one expense associated with it, and all questions have been answered, the requestor may submit the request for approval, along with optional notes about the request. Once the request is submitted, it moves to the Submitted state. Bookkeepers receive an e-mail notification that the request is ready for review, including the notes written by the requestor.

Bookkeeper workflow

Bookkeepers can log into the system and see all requests.

When bookkeepers review a Submitted report, they can change the report's state, and include a note explaining why the report was moved to that state (for example, the bookkeeper moved the request back to Draft because a specific receipt was insufficient documentation). When they do this, the system sends email to the requestor letting them know about the change, including the rationale provided by the bookkeeper.

The bookkeeper can export any request to the books. The first release of the software will simply provide an archive that includes all of the request's supporting documentation, plus a .ledger file with entries for each expense. However, note that when building this feature in the code and UI, it should be relatively generic. Exporting should remain abstract enough that integration with other accounting systems remains simple and straightforward. Note that even the mechanics could be different; for example, an SQLedger exporter may add entries to the system directly, rather than providing the bookkeeper with a file download.

Requirements potentially for first release

These are features that we would like the system to have, and it may make sense to make them requirements of the first release depending on how it's built.

Requirements for later releases

These are features that we would ultimately like the system to have. We would also like to release a first version as early as possible, to start getting feedback from users and generating more development interest. It's good to keep these in mind when architecting—in particular, we may choose an existing system to use, or framework to build on, based on its ability to support these features. However, they needn't be a focus of development effort for the first release.

Desired features

These are features that we would also, ultimately, like the system to have. But they're not as critical as the features in the previous section, and they don't need to hold as much sway over the choice of a base system or framework.