> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1club.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Transactions

> The per-obligation records behind every booking, membership, signup fee, and product sale - the source of truth for what's owed.

A transaction is a single line of "X owes Y for Z." Every chargeable event in 1Club - a booking, a membership creation, a recurring membership period, a signup fee, a product sale, an external program entry - writes exactly one transaction. Settlement happens separately through [payments](/billing/payments) linked over a join table.

Open the page at **Billing > Transactions**. The grid pages on the server and is tab-filtered into **All**, **Pending**, **Overdue**, **Paid**.

## Anatomy of a transaction

Each row carries:

* **Date** of the obligation.
* **Type** (`booking_creation`, `booking_cancellation`, `membership_creation`, `membership_recurrence`, `membership_signup_fee`, `membership_cancellation`, `product_sale`, `external_program_entry`, `checkin_creation`).
* **Description** describing what was billed.
* **Contact** the transaction is against.
* **Amount**, **Tax amount**, **Total amount**, and **Currency** (the organization currency at the time of creation).
* **Payment status**: `pending`, `paid`, `void`, `failed`, `settled`, `overdue`, `partially_paid`, `refunded`, or `cancelled`.
* **Invoiced** flag. Once a transaction has been wrapped into an invoice (manually or by a bill run), this is `true` and the obligation will not be picked up by future bill runs.
* Optional foreign keys to a **booking**, **membership**, **product**, **external program**, **tax rate**, and **revenue account**.
* Optional **parent / child** links, used to chain related entries together (for example a `booking_cancellation` referencing the original `booking_creation`).

Zero-amount transactions are auto-marked `paid` at creation, so a free booking still produces a transaction but it never blocks anything.

## How transactions get created

Most of the time you won't create transactions by hand. They arrive when:

* Someone is **booked** into a class, an area, or with an instructor. The booking flow writes the transaction at the price implied by the membership or the override.
* Someone **buys a plan**. You get `membership_creation` plus, when applicable, `membership_signup_fee`.
* A **recurring membership period rolls over**. The hourly `recurring-transactions` job writes the next `membership_recurrence` transaction.
* A booking is **cancelled** with a refund or charge policy. You get `booking_cancellation` linked to the original.
* A **product** is sold through the POS.

You can also create one by hand from the page header **Add** button - for example to record an ad-hoc charge that doesn't correspond to a booking or membership.

## Transaction actions

From a row or from the details page:

* **Add payment.** Available when the status isn't `paid` or `void`. Opens the payment dialog, where you pick a payment method (manual or Stripe) and record the settlement.
* **Add invoice.** Available when the transaction hasn't been invoiced yet, has a contact, and isn't `void`. Wraps the single transaction into a new one-line invoice and navigates to the invoice page.
* **Void.** Available for any transaction not already `void`. Marks the transaction `void` so it stops showing as owed and stops being picked up by bill runs. Voiding is a soft delete - the row remains for audit.
* **View** opens the details page.

## Batch actions

Multi-select in the grid unlocks two batch operations:

* **Charge.** Calls Stripe for every selected transaction's contact, charging their default payment method. The results dialog summarises which transactions succeeded, which failed, and the reason for each failure (no default method, charge declined, etc.). It uses idempotency keys built from the transaction ID and current date so reruns on the same day won't double-charge.
* **Record manual payment.** Opens a dialog where you choose a configured manual payment method (cash, bank transfer, etc.) and a payment date, then writes a payment row against each selected transaction. Transactions already `paid` or `void`, or with zero remaining balance, are skipped and counted in the summary so you can see exactly what landed.

## Transaction details

Beyond the same fields shown in the grid, the details page exposes:

* The **payment method** column lists each payment row linked to this transaction with amount and date, each linking to the payment.
* The full tax breakdown when a tax rate applied (rate name, percentage, description).
* **Recurrence info** for `membership_recurrence` transactions: auto-renew flag, billing frequency, and the period start/end dates.
* The linked **booking** or **membership** as a clickable card.
* A **Transaction relationships** card showing the parent and any children, so you can trace a cancellation back to the original booking or follow a chain of recurring periods.
* All linked **Payments** in a grid at the bottom, including partial and refunded payments.

## How payment status flows

When a payment is recorded, its outcome determines the transaction's new status:

| Payment outcome      | Transaction status |
| -------------------- | ------------------ |
| `succeeded`          | `paid`             |
| `failed`             | `pending`          |
| `cancelled`          | `pending`          |
| `refunded`           | `refunded`         |
| `partially_refunded` | `partially_paid`   |

A successful payment also flips any pending booking on that transaction to `confirmed`.

The hourly job that processes recurring memberships also runs a sweep that flips any `pending` transaction with a date in the past to `overdue` (start of UTC day). `overdue` is treated as a flavor of `pending` when invoice status is derived.

## Caveats

* The user-facing "outstanding transactions" query treats anything not `paid` as payable, so theoretically a `cancelled` transaction could surface there until it's explicitly excluded.
* Voiding a transaction doesn't refund associated payments. If money was actually collected and now needs returning, refund the payment first, then decide whether to void the obligation.

## Related

* [Payments](/billing/payments) - the settlement events linked to transactions.
* [Invoices](/billing/invoices) - how to wrap transactions in a sendable document.
* [Bill runs](/billing/bill-runs) - sweeping pending transactions into invoices in bulk.
* [Booking policies](/operations/booking-policies) - decides when a booking's transaction is created and when it must be paid.