Transaction Fields

These additional fields have been deprecated but may still apply to older transaction records:

Transaction Kinds

Each transaction is of a single “kind.” The following are the "kinds" of transactions:

Introduction

At the heart of Open Collective is a ledger that records all the financial activities that take place on the platform. The ledger is our source of truth. It is the foundation that makes possible crowdfunding contributions, added funds, grants and expenses. All these financial interactions generate transactions that are recorded in the ledger.

Most users interact with the ledger indirectly by making contributions and submitting expenses and for most users that is enough. However, as the platform has grown, larger organizations who rely on the platform, primarily fiscal hosts and medium-to-large collectives, need to use information from the platform for accounting purposes. In response to these needs we are making the ledger itself more visible, accessible and legible to users.

Immutability

The transparency at Open Collective relies on the ledger to be a trustworthy source of information. Therefore, transactions on the ledger cannot be modified. Transactions can only be added to the ledger. There are rare cases where platform support does intervene in the ledger to:

1. Mark a transaction as deleted - the transaction is not really deleted, it still exists in the ledger, however it is marked as deleted and is no longer included in calculations and will not appear in transactions lists or exports.

2. Reassign a transaction to a different account. The transactions itself is not modified but the account to which it is related can be changed.

When are transactions generated?

Transactions are generated either when:

1. Via the platform: financial transactions are confirmed via payment processors:

   1. A contribution is successfully charged and confirmed by a payment processor (such as Paypal, or credit cards via Stripe).

   2. A contribution is refunded.

   3. An expense is successfully paid through a payment processor (such as Wise or Paypal).

   4. An expense is marked as unpaid (when payment does not reach its destination).

2. Off the platform: financial transactions that occurred off platform are documented on the platform.

   1. A fiscal host adds (see Added Funds) funds that have arrived in their bank accounts and assigns them to their designated collective.

   2. Off platform (manually paid) expenses are documented on the platform by fiscal hosts.

3. Inside the platform: money is moved between collective accounts within the same fiscal host.

Read more about individual transactions.

Read more about transaction pairs, groups, and perspectives.

Accessing the Ledger

The ledger can be accessed:

1. Directly in the platform via the dashboard Transactions tool.

2. As exported CSV Files

3. Through the API

Browse the Open Collective Ledger with the Dashboard Transactions tool. We have designed it to look and operate more similar to a 'bank statement.

To view the Transactions page navigate to your Dashboard and then Transactions. Utilize the account switcher to switch between accounts.

In the transactions table you can see the Date and Time of the transaction, the account, the Recipient/Sender, the Kind of transaction and the Net amount with the Currency.

Contextual Transactions

The transactions you see are based on the context in which you are using the tool.

1. If you are individual you will see transactions that are related only to you (expenses you submitted and contributions you made.

2. If you are a collective administrator you will see all the transactions that are related to the collective (all the added funds, contributions made to the collective and expenses submitted to the collective, payment processor and host fees).

3. If you are a fiscal host administrator you will see all of your organizational transactions and all the transactions related to the collectives you host.

Related transactions

Hovering over individual transactions will bring up a blue line to the left. This indicates the groupings of transactions.

Multiple transactions occur from the initial transaction for example based off the below screenshot

• Guest donates $5 to Logseq

This triggers

• Logseq sends a 74 cent in payment processor fees to Paypal

• Logseq sends a 50 cent fiscal host fee to Open Source Collective

• Open Source Collective receives a 50 cent fiscal host fee from Logseq

• Open Source Collective sends a 25 cent platform share to Open Collective

• Open Collective receives a 25 cent platform share from Open Source Collective

Sort

Sort the transactions either by Date (Oldest - Newset) or Effective Date (Oldest - Newest)

View more information

To dive in and review any particular transaction, click to trigger a draw to slide out from the right displaying more information.

• Transaction #

• Account

• Sender/Recipient

• Date and Time

• Effective Date

• Type of Transaction

• Kind of Transaction

• Amount

• Payment Method

• Merchant ID

• Accounting Category

• Group ID

• Opposite transaction ID

• Related contribution

Export CSV

Head to the Exporting Transactions section to find out more.

Extra features for Fiscal Hosts

Transactions for hosted collectives are included in the 'All' transactions view you can use the tabs to only view transactions from the hosted collectives or the fiscal host

We have removed expected funds in this view (these can be seen in the Contributions section)

A fiscal host perspective includes two sets of transactions:

1. Transactions related to the fiscal host organization account (operational funds).

2. Transactions related to the accounts of the collectives hosted (past and present) by the fiscal host (managed funds).

Therefore, the fiscal host ledger includes a large and more complex set of transactions. Lets take the following example where three collectives hosted by the fiscal host each receive each one contribution. This results in three groups of transactions:

The “Operational Funds” perspective (funds that belong to the fiscal host as an organization) would show:

1. Income credited to the as a HOST FEE transaction from each of the three contributions.

2. Platform fees debited from the host to the platform (if there is a revenue share agreement with the platform) as a HOST FEE SHARE transaction.

The “Managed Funds” perspective (funds held by the fiscal host on behalf of collectives) would show an aggregated view of all the transactions from their hosted collectives. In this case it would show:

1. Income credited to each of the collectives as a CONTRIBUTION transaction.

2. Fees debited from each of the collectives for payment processor fees as a PAYMENT PROCESSOR FEE transaction.

3. Host fees debited from each of the collectives as a HOST FEE transaction.

Added funds are funds that are manually added to collective accounts by fiscal hosts when they process manual bank transfers and checks. Added fund related transactions are potentially different from contribution related transactions:

1. They are initiated by a fiscal host admin and not by a contributor.

2. They are created in response to manual data entry (and not automated interaction with a payment processor system).

3. Can be manually dated by the fiscal host admin to reflect when the funds actually arrived. In such cases the “Transaction Date” will show the date (and time) the transaction itself was created in the ledger and and the “Effective date” will show the date entered by the fiscal host admin.

Added funds transaction groups typically look like contributions in the ledger where instead of a pair of CONTRIBUTION transactions there will be a pair of ADDED_FUNDS transactions.

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 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.

4. 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.

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: is debited from the platform and credited to the fiscal host.

4. The host fee share debt cancelled: debited from the fiscal host and credited to the platform.

5. 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:

1. The contribution transactions are one transaction group.

2. The refund transactions are a second transaction group.

3. 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.

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 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 collective 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:

Transaction Pairs

Transactions are always created in complementary pairs: a credit transaction and a debit transaction. For example, when Contributor A makes a contribution to Collective B, two transactions are created:

Or when an expense is paid from Collective B to Payee C, two transactions are also created:

Transaction Groups

Usually transactions are created in groups that have a shared context. For example, when a contribution is made by Contributor A via Stripe to Collective B that is hosted by Fiscal Host C the following transaction group will be created:

1. A pair of CONTRIBUTION transactions.

2. A pair of PAYMENT PROCESSOR FEE transactions.

3. A pair of HOST FEE transactions

Ledger Perspectives

Different users sees a different perspective of the same ledger. The perspective a user sees depends on the account through which they are looking at the ledger. Typically each account sees only transactions related to it. Fiscal hosts are an exception since they see both their own transactions and the transactions of the collectives they host.In the above contribution example, the contributor will see just one transaction - their contribution debited from their account:

A collective admin will see three transactions which correctly represent the contribution and two fees - resulting in a net $8.50 for the collective:

The Stripe account (though it has no users, there is a global Stripe account to which transactions are attributed) will show just the payment processor fee that it charged:

Fiscal hosts see the largest amount of transactions since they see both their own transactions and the transactions of their hosted collectives (for which they are fiscally responsible):

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 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 recipients collectives.

Expense Transactions

An expense transaction group will typically include:

1. A pair of EXPENSE transactions.

2. A pair of PAYMENT PROCESSOR FEE transactions.

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 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:

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.

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

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:

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 are credited back to the collective 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 collective 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 collective perspective:

January 2024: Separate payment processor fees and taxes

From January 2024 payment processor fees and taxes were separated from the transaction record in the ledger.

Over the last couple of years, we’ve received feedback from fiscal hosts and accountants that has prompted us to make a change to the ledger to make more it more consistent and future proof. We’ve modified the ledger so that payment processor fees and taxes are recorded as separate transactions.

This is how payment processor fees and taxes were represented in the ledger until now, as fields/properties of a transaction:

For contributions or expenses made after January 2024, separate transactions will be recorded for payment processor fees and taxes. For example:

CSV Export Backwards Compatibility

The default export configuration hasn’t changed and still includes a column for payment processor fees. However, from 2024, payment processor fees are exported as separate transactions and the payment processor fee column will be set to zero. If you need to continue to export data (from the 1st of January 2024 and onward) with payment processor fees as a column (instead of separate transactions) enable the “Separate transactions compatibility” option. This will convert the newly separated payment processor fee transactions back into transaction columns.

Dashboard Transactions List

In the dashboard transactions tool the new transactions (for payment processor fees and taxes) will appear as separate transactions. In this screenshot the blue line on the right hand side of the table is a visual indicator for a group of related transactions. Here you can see that a (now separate) Payment processor fee transaction is related to the contribution transaction.

From your transactions you can export a CSV file that can be used to further process transactions for your reporting and accounting needs.

To download a CSV of your transactions click on the 'export CSV' button in the top right hand corner.

If you have applied any filters on the transactions page these will be applied to the export set. At the bottom left corner of the export screen you will see a confirmation of the number of transactions included in that set.

You then have an option to decide which fields you would like to export. The “Platform Default” export is a selection of fields created to answer typical reporting and accounting needs. So it may be a good starting point. If it is, simply click “Export CSV” and your export file will begin to download.

New Preset

You can further customize the export set by selecting which fields will be exported and in what order. For this select “New Preset.”

Presets are shared within your organization so when defining a New Preset, ensure you give it a meaningful name so that your fellow admins will be able to recognize and utilize it.

Select your desired fields in the 'Available fields' section.

Reorder your selected fields in the 'Selected fields for export' section.

You are also able to clear the selection to start your preset from scratch

Save and Export your Preset

You have the option to save the preset, this will make it available to all admins of your Collective/Fiscal Host.

Export a Sample to test the data set before committing and downloading the full CSV via Export CSV.