Transactional sweeping

Transactional sweeping is a settlement model where the amount swept to the merchant’s business account exactly matches the net value of all transactions for a given day.

This approach is commonly used when you need a clear relationship between individual payments (and refunds) and the final payout amount. It simplifies reconciliation and mirroring funds which are settled in the merchant account, or being taken out in refunds or payouts.

We recommend that you use it alongside automated reporting.

How it works

At the end of each day, we calculate the net total of all transactions for that day — including payments and refunds — and sweep that amount to your business account.

• If the daily balance is positive, that amount is swept.
• If the daily balance is negative, no sweep occurs. The balance is then carried over and included in the calculation for the next day.

Sweeps are calculated using only transactional activity. Manual top-ups to the merchant account (for example, from a business bank account that you’ve already enabled to top up your merchant account) are ignored for sweeping purposes.

The amount in a merchant account is calculated based on the payments that have settled and payouts/refunds that have been executed. Any payments that have been executed, but not settled, don't count when determining how much to sweep.

Example

In this example, a sweep of £1160 will be made to your business account.

📘

If you want to ensure a minimum float in the merchant account, you'll need to deposit that in advance.

The sweeping logic does not preserve float amounts automatically. You can manage the float using topups from business accounts and payouts to business accounts.

📖

Enable transactional sweeping

We handle all configuration — there is no self-serve setup or API integration required. To enable it, reach out to us.

References for swept payments

The reference field on swept payments follows a unique format.

<For example, in the code TFE4JO900020250701,

• T refers to TrueLayer
• FE4JO9 is a portion of your client ID
• 000 is the specific payout number of the sweep run
• 20250701 is the date, in YYYYMMDD format.

Often, the payout number of a specific payout will be 000. However, for large sweeps (>100k EUR or >1m GBP) the sweep may be split into multiple payouts. Each of these payouts has a different payout number, in the order that they are executed.

Transactional sweeping report fields

In a transactional sweeping report, each row represents a transaction that is part of the sweep. The report breaks down each of the payments that contribute

Transactional sweeping reports contain these fields for each transaction:

• amount, the amount paid in major units, eg 14.62
• currency, the currency of the transaction, eg GBP
• transactionType, the type of payment.
  If you enable granular payout types, an extended range of transaction types can display here. See the table below for a breakdown of each possible transaction type.

• transactionId, the ID of this specific transaction

• sweepReference, a reference for the sweeping payout that included the transaction

• sweepCreatedAt, the creation date and time of the sweeping payout that included this transaction, eg 2024-10-03T14:33:56.891Z.

• paymentId, the ID of the payment that created this transaction unless it is a refund or reversal

  • For refunds, this will be the ID of the payment that this transaction is a refund for.
  • For reversals, this will be the ID of the payment that this transaction has reversed.

• payoutId, the payout ID of the transaction. Only exists for payouts.

• refundId, the refund ID of the transaction. Only exists for refunds and auto-refunds.

• merchantAccountId, the ID of the merchant account

• transactedAt, the date and time that the transaction moved into or out of the merchant account (ie the

• reference, the reference associated with the transaction

• remitterAccountHolderName, your user's name. Exists for external deposits, closed-loop payments and returns.

• remitterIban, your user's IBAN. Only exists for external deposits, closed-loop payments and returns.

• paymentSourceId, the ID of the payment source (ie merchant account)

• userId, the ID for the user that made the transaction. Exists for closed-loop payments, payouts and refunds

• beneficiaryType, which appears for payouts and refunds. This is the type of account that the transaction is going into.
  This field can also be used to distinguish different payout types if you don't enable the granular types option. This can be one of the following values:

  • external_account
  • payment_source
  • business_account
  • user_determined
  • For refunds, the only value that can display is payment_source.
  • For auto-refunds, the only value that can display is external_account.

• beneficiaryAccountHolderName, the name on the account that the transaction is going into. Only exists for payouts, refunds and reversals.

• beneficiaryIban, the IBAN of the account that the transaction is going into. Only exists for payouts, refunds and reversals.

• reversedByTransactionId , the transaction ID of the reversal that corresponds to this payment. Exists for external deposits, closed-loop payments and returns.

• reversalForTransactionId , the ID of the payment that is being reversed. Only exists for reversals.

• reversalForTransactionType, the transactionType of the corresponding inbound transaction this row is a reversal for. Only exists for reversals. It will be one of the following:

  • external_deposit
  • closed_loop_payment

• returnedByTransactionId, the ID of the transaction that returned the funds back to the merchant account.

• returnForTransactionId, the ID of the corresponding outbound transaction that this row is a return for

• returnForTransactionType, the transactionType of the corresponding outbound transaction that this row is a return for. It is one of the following:

  • payout
  • refund
  • sweep
  • auto_refund
  • reversal.

• autoRefundedByTransactionId, the ID of the corresponding auto-refund for external deposits that have been auto-refunded.

• refundForTransactionId, which is the ID of the transaction that this payment is a refund for. For a refund, this indicates the corresponding closed-loop payment that has been refunded. For an auto-refund, this indicates the corresponding external deposit that has been auto-refunded.

• Metadata, if requested

  • The columns will have a heading in the form meta:{metadata_key}. For example, for a transaction with this example metadata, the following columns will be included in the report
  JSON

  {
  	"custom_transaction_id": "1234-5678-90ab-cdef",
  	"sku_id": "42-ref-32"
  }
  

  meta:custom_transaction_id	meta:sku_id
  1234-5678-90ab-cdef	42-ref-32

  • The number of metadata columns is dynamic and can vary from one generated report to the next since metadata columns are only added to the report when a transaction within the report has a value for that metadata key.