Contributions in the Ledger

Learn more about how Contributions and Refunds are reflected in Open Collective's ledger.

Contributions

1. A contribution will typically include a pair of CONTRIBUTION transactions and a pair of PAYMENT_PROCESSOR_FEE transactions.

2. If the contribution is made to a Collective 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.

3. If a Fiscal Host has a revenue share agreement with the platform then there will also be a pair of HOST_FEE_SHARE transactions:

   1. If HOST_FEE_SHARE applies and the payment processor supports it, the contribution will be split during processing: the Fiscal Host and the platform will each receive their portions, and the HOST_FEE_SHARE amount will be sent directly to the platform.

   2. If that is not possible, the entire contribution amount (minus the payment processor fee) 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.

Refunded Contributions

When contributions are refunded, a new transaction group is created. It contains a set of opposite (relative to the contribution itself) transactions:

1. The contribution is returned: debited from the Collective and credited to the contributor

2. The host fees are returned: debited from the Fiscal Host and credited to the Collective.

3. The host fee share paid to the platform is returned: it is debited from the platform and credited to the Fiscal Host.

4. The host fee share debt is cancelled: it is debited from the Fiscal Host and credited to the platform.

5. Payment processor fee transactions are not reversed since they are typically not refunded by the payment processors. In such cases, Fiscal Hosts cover the payment processor fees that have not been refunded, 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:

1. The contribution transactions are one transaction group.

2. The refund transactions are a second transaction group.

3. There is a relationship 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.

4. The contribution transactions will be marked as REFUNDED.

5. The related refund transactions will be marked as REFUND.

It is possible to imagine these two transaction sets existing side by side:

Perspectives of Refunded Contributions

From a contributor's perspective, a refunded contribution looks like a straightforward pair of opposite transactions: a debit when the contribution was made and a credit when it was refunded.

From a Collective's 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 collective perspective:

Disputed Contributions

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: