# Expenses in the Ledger ## Expense Types Expenses in the ledger are used to represent various kinds of financial activities. Therefore, in order to properly understand expense transactions you need to first look at the “Expense Type” field: 1. **Invoices** are expenses submitted by an expense submitter paid against submitted invoices. 2. **Reimbursements** are expenses submitted by an expense submitter that have already been paid by the expense submitter who is asking to be reimbursed against a receipt or another proof-of-payment. 3. **Virtual Card Charges** are expenses created on the platform when expenses have been paid using virtual credit cards. 4. **Settlements** are expenses generated by the platform based on and to account for debt transactions (PLATFORM\_TIP\_DEBT & HOST\_FEE\_SHARE\_DEBT) that accumulate on the platform. These are typically paid from the Fiscal Hosts to the platform. 5. **Grants** are also represented as expenses by which funds are typically transferred within a Fiscal Host from a fund account to recipient collectives. ## Expense Transactions An expense transaction group will typically include: 1. A pair of EXPENSE transactions. 2. A pair of PAYMENT PROCESSOR FEE transactions.
A table showing an example of an expense. The first transaction has a Kind "Expense," a Type "CREDIT," an Account "Vendor D," and an Amount "$213.00." The second transaction has a Kind "Expense," a Type "DEBIT," an Account "Collective B," and an Amount "-$213.00." The third transaction has a Kind "Payment Processor Fee," a Type "DEBIT," an Account "Collective B," and an Amount "-$13.00." The fourth transaction has a Kind "Payment Processor Fee," a Type "CREDIT," an Account "Stripe," and an Amount "$13.00."
## Unpaid Expenses Fiscal Hosts are able to mark expenses as unpaid when they encounter a payment error (it is the responsibility of the Fiscal Host admin to verify that the funds paid are accounted for). When an expense is marked as unpaid a new transaction group is created in which: 1. The expense is credited back to the paying collective and debited from the payee. 2. Payment processor fees for transactions are **not** reversed since they are typically not refunded by the payment processors. In such cases, Fiscal Hosts cover the not-refunded payment processor fees. This is represented in the ledger with a pair of PAYMENT\_PROCESSOR\_COVER transactions.
A table showing an example of transactions associated with an expense that has been marked as unpaid. The first transaction has a Kind "Expense," a Type "DEBIT," an Account "Vendor D," and an Amount "-$213.00." The second transaction has a Kind "Expense," a Type "CREDIT," an Account "Collective B," and an Amount "$213.00." The third transaction has a Kind "Payment Processor Cover," a Type "DEBIT," an Account "Fiscal Host C," and an Amount "-$13.00." The fourth transaction has a Kind "Payment Processor Cover," a Type "CREDIT," an Account "Collective B," and an Amount "$13.00."
A complete transaction set for an expense marked as unpaid will therefore include: 1. The expense payment transactions are one transaction group. 2. The expense "unpaid" transactions are a second transaction group. 3. Relationships between the transactions in the two transaction groups. Each transaction in the expense transaction group (except the payment processor fees) will have a Refund Transaction ID that points to the opposite transaction in the "unpaid" transaction group. 4. The expense transactions will be marked as REFUNDED. 5. The related "unpaid" transactions will be marked as REFUND.
A table showing an example of an expense that was marked as unpaid. The table is a combination of the two above with a few exceptions. There is now a property for transaction group: the first four original transactions are in one group, where as the four that were generated when the expense was marked as unpaid are in another group. The first two transactions associated with the expense now have a property that says "REFUNDED," while all four of the transactions associated with the expense being marked as unpaid have the property "REFUND." There is now a property for "Transaction ID." For the transactions with the property "REFUNDED," they also have a property called "Refund Transaction ID," that has the value of the corresponding transaction's ID.
It is possible to imagine these two transaction sets side by side:
This is the same table as the one above, except the two transaction groups are now visualized as next to each other with arrows connecting the transactions that correspond to one another.
## Perspectives of Unpaid Expenses From the perspective of the payee (the person or organization being paid) the expense was first credited and then debited from their account:
A table showing an expense that was marked as unpaid from the perspective of the payee. The first transaction has the property "REFUNDED," the Kind "Expense," the Type "CREDIT," and the amount "$213.00." The second transaction has the property "REFUND," the Kind "Expense," the Type "DEBIT," and the amount "-$213.00." Both have the Account "Vendor D."
From the perspective of the paying Collective, an expense and payment processor fee were first debited from the Collective, and then when the expense was marked as unpaid, the funds were credited back to the Collective together with credit from the Fiscal Host to cover the payment processor fees:
A table showing an example of an expense that was marked as unpaid from the perspective of the Collective. The first transaction has a property "REFUNDED," the Kind "Expense," the Type "DEBIT," and the Amount "-$213.00." The second transaction has the Kind "Payment Processor Fee," the Type "DEBIT," and the Amount "-$13.00." The third transaction has a property "REFUND," the Kind "Expense," the Type "CREDIT," and the Amount "$213.00." The fourth transaction has a property "REFUND," the Kind "Payment Processor Cover," the Type "CREDIT," and the Amount "$13.00."
From a Fiscal Host's “Operational Funds” perspective, an “Unpaid” expense leaves only a PAYMENT PROCESSOR COVER transaction debited from the Fiscal Host to the Collective to cover the un-refunded payment processor fees:
A table showing an example of what an expense that is marked as unpaid looks like from a Fiscal Host's "Operational Funds" perspective. There is only a single transaction, it has a property of "REFUND," the Kind "Payment Processor Cover," a Type "DEBIT," the Account "Fiscal Host C," and the Amount "-$13.00."
From a Fiscal Host “Managed Funds” perspective, an “Unpaid” expense looks the same as it does from a collective perspective:
A table with an example of an expense that has been marked as unpaid from the perspective of a Fiscal Host's "Managed Funds." It is identical to the above table of an expense that has been marked as unpaid from a Collective's perspective.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://documentation.opencollective.com/advanced/ledger/expenses-in-the-ledger.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.