Contributions in the Ledger
Last updated
Last updated
A contribution will typically include a pair of CONTRIBUTION transactions and a pair of PAYMENT_PROCESSOR_FEE transactions.
If the contribution is made to a community that is hosted by a fiscal host and if that host charges a hosting fee then there will also be a pair of HOST_FEE transactions.
If there is a fiscal host and the fiscal host has a revenue share agreement with the platform then there will also be a pair of HOST_FEE_SHARE transactions.
If HOST_FEE_SHARE applies and the payment processor is able, when the contribution is processed, to split the funds and direct part to the fiscal host and another part to the platform then the HOST_FEE_SHARE amount is passed directly to the platform. If that is not possible then the entire contribution (minus the payment processor fee) amount is directed to the fiscal host and a pair of HOST_FEE_SHARE_DEBT transactions are also created to account for money owed by the fiscal host to the platform. The debt transactions are later aggregated and used to generate an expense through which the fiscal host pays the platform and the debt is reconciled.
As a result, a single contribution can result in a set of transactions:
Find out more about Platform settlement expenses.
When contributions are refunded, a new transaction group is created. It contains a set of opposite (relative to the contribution itself) transactions:
The contribution is returned: debited from the community and credited to the contributor
The host fees are returned: debited from the fiscal host and credited to the community.
The host fee share paid to the platform is returned: is debited from the platform and credited to the fiscal host.
The host fee share debt cancelled: debited from the fiscal host and credited to the platform.
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.
As a result, the ledger footprint of a refunded contribution includes:
The contribution transactions are one transaction group.
The refund transactions are a second transaction group.
Relationships between the transactions in the two transaction groups. Each transaction in the contribution transaction group (except the payment processor fees) will have a Refund Transaction ID that points to the opposite transaction in the refund transaction group.
The contribution transactions will be marked as REFUNDED.
The related refund transactions will be marked as REFUND.
It is possible to imagine these two transaction sets existing side by side:
From a contributor perspective a refunded contributions looks like a straightforward pair of opposite transactions - a debit when the contribution was made and a credit when it was refunded.
From a community perspective a refunded contribution looks slightly less symmetric because the PAYMENT PROCESSOR FEE transaction is not refunded and is instead reflected by the PAYMENT PROCESS COVER transaction:
From a fiscal host “Operational Funds” perspective a refunded contribution looks symmetrical except for the PAYMENT PROCESSOR COVER transaction:
From a fiscal host “Managed Funds” perspective a refunded contribution looks the same as it does from a community perspective:
A dispute occurs when a contributor files a complaint with a payment processor (usually because of suspected fraud). If a dispute is settled in favor of the fiscal host the contribution transactions in the ledger remain unchanged. If a dispute is settled in favor of a contributor the transaction will be refunded (and refund transactions will be created in the ledger).
Regardless of the dispute outcome, payment processors charge a dispute fee (paid by the fiscal host) which is recorded in the platform as an additional pair of PAYMENT_PROCESSOR_DISPUTE_FEE transactions:
