GoCardless UK: payout Transactions or Events export?
Updated · 3 min read
For a GoCardless UK Direct Debit payout, Transactions and Events answer different questions. A transaction export includes current payment status; an events export helps establish movements associated with the payout. Neither the customer’s latest status nor the payout’s estimated arrival alone proves the actual bank credit.
The desktop apps export date, description, and amount as CSV. Open CSV in Excel to save an XLSX workbook. Statement support varies: verify the result against your own PDF.
Export from the same payout breakdown
Open Payments → Payouts, select the GBP payout and inspect Payout breakdown. Use Export Transactions and Export Events for that same payout. Retain payout ID, reference, currency and arrival information with the payment identifiers and original files.
The Transactions specification includes current resources.status, gross, fees and net amounts. The Events source separately identifies credits and debits with payment and payout links. Do not substitute an API payout-items schema for the merchant UI export; a documented API is not proof that your downloaded CSV has every API field.
Keep fees in the cash bridge
Distinguish counting successful customer payments from explaining payout value. Fee rows remain part of the latter even though they are not successful customer collections. Filtering all non-payment entries out of the working file can make the payout impossible to explain.
Use the existing fixture’s signed components to keep payment counts and payout value separate:
| Stipulated component | GBP movement | Cash-bridge treatment |
|---|---|---|
| Collection credits | 300 | Include the actual credited events |
| Debit event | -50 | Retain its historical event link |
| Fees | -6 | Include in net value, not successful-customer count |
| Net payout | 244 | Compare with the independent bank observation |
The Transactions field definitions name resources.status as the current resource status. Keep that status observation separate from the event records used to rebuild a past payout.
The synthetic payout exercise stipulates 300 credited collections, a 50 debit event and 6 of fees, producing 244. Counting customer collections excludes the fee as a customer, but calculating net cash retains the 6 deduction. A payment whose current status later becomes failed is not retroactively removed from the preserved historical event record without checking the corresponding debit event.
Separate history from current state
A confirmed Direct Debit can fail late. Keep the event history and its actual payout membership alongside current status, rather than rebuilding a past payout by selecting only today’s successful payments. Check the bank’s observed reference, destination and GBP amount before marking the payout received.
Unknown event links or a missing bank receipt remain exceptions. This example checks signed components and population choices; no Direct Debit, live export or API request was executed. It does not infer partner revenue-share semantics from merchant payout fields.
For a PDF-only bank source, download LocalExtract. It processes one PDF locally to date,description,amount CSV; it does not access platform accounts or synchronize accounting records.
Official sources and scope
Documentation checked October 16, 2026. Official reference 1 — gc-payouts · Official reference 2 — gc-transactions · Official reference 3 — gc-events · Official reference 4 — gc-payments · Official reference 5 — lead-03
LocalExtract Team
We build LocalExtract, a desktop bank statement converter. Questions or corrections? Contact · Editorial policy