Expenses in the Ledger
Last updated
Last updated
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:
Invoices are expenses submitted by an expense submitter paid against submitted invoices.
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.
Virtual Card Charges are expenses created on the platform when expenses have been paid using virtual credit cards.
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 fiscal hosts to the platform.
Grants are also represented as expenses by which funds are typically transferred within a fiscal host from a fund account to recipients communities.
An expense transaction group will typically include:
A pair of EXPENSE transactions.
A pair of PAYMENT PROCESSOR FEE transactions.
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:
The expense is credited back to the paying community and debited from the payee.
Payment processor fees 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 and this is represented in the ledger with a pair of PAYMENT_PROCESSOR_COVER transactions.
A complete transaction set for an expense marked as unpaid can therefor look like:
As a result, the ledger footprint of an expense marked as unpaid includes:
The expense payment transactions are one transaction group.
The expense "unpaid" transactions are a second transaction group.
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.
The expense transactions will be marked as REFUNDED.
The related "unpaid" transactions will be marked as REFUND.
It is possible to imagine these two transaction sets side by side:
From the perspective of the payee (the person or organization being paid) the expense was first credited and then debited from their account:
From the perspective of the paying community an expense and payment processor fee were first debited from the community and then, when the expense was marked as unpaid, the funds are credited back to the community together with credit from the fiscal host to cover the payment processor fees:
From a fiscal host “Operational Funds” perspective an “Unpaid” expense leaves only a PAYMENT PROCESSOR COVER transaction debited from the fiscal host to the community to cover the un-refunded payment processor fees:
From a fiscal host “Managed Funds” perspective, an “Unpaid” expense looks the same as it does from a community perspective:
