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

# Sales overview

> How the Sales section is organized - Plans, Products, Promotions, Memberships, Orders, Finance, and Cash - and how plans, orders, transactions, invoices, and payments fit together.

**Sales** is where you set up what your gym sells and follow the money it brings in. It replaces the old **Revenue** menu and also holds **Promotions** (formerly under **Marketing**) and **Memberships** (formerly under **Members**). Owners and managers set up the catalog here, and front-desk staff and bookkeepers use it to review orders, chase what is owed, and reconcile the till.

The register itself is a separate rail item, [Point of Sale](/pos/point-of-sale). Sales is where you manage what the register sells and review what it took.

## The Sales section

Go to **Sales** in the left rail (`/sales`). It opens on the first tab you can access, usually **Plans**. Each tab appears only when your role has permission for it.

| Tab | What it holds | When to use it |
| - | - | - |
| [Plans](/sales/plans) | Membership and pass templates | Set up pricing tiers, recurrence rules, and usage limits. |
| [Products](/sales/products) | The catalog of sellable items, with sub-tabs for packages, stock, and rentals | Define retail and add-on items sold at the point of sale and on signup forms. |
| [Promotions](/sales/promotions) | Vouchers and discounts | Run trials, intro offers, and promo codes. |
| [Memberships](/sales/memberships) | Every membership sold from your plans | Pause, renew, cancel, and track usage. |
| [Orders](/sales/orders) | Every basket bought at the desk, in the portal, or through a booking | Review, complete, or cancel a purchase and everything it created. |
| **Finance** | Money owed and collected, as tabs (see below) | Audit transactions, collect payments, issue invoices, and manage wallets. |
| [Cash](/sales/cash) | The cash drawer and expenses | Count the till and record what your gym spends. Only shown when the cash module is on. |

### Products sub-tabs

**Sales** > **Products** groups the catalog with the pages that sell and stock it:

* **Products** - the [catalog](/sales/products) itself.
* **Packages** - fixed-price [bundles](/sales/packages) of plans and products.
* **Stock** and **Ingredients** - on-hand counts and recipe ingredients, when [inventory](/sales/inventory) is on.
* **Deliveries** - supplier [deliveries](/sales/deliveries) with invoice scanning, when inventory is on.
* **Rentals** - [gear lent out](/sales/rentals) and still to come back, when rentals are on or gear is still out.

### Finance

**Sales** > **Finance** (`/finance`) gathers everything about money that has moved into one tab, with its own sub-tabs. It opens on **Transactions**.

| Sub-tab | What it lists |
| - | - |
| [Transactions](/sales/transactions) | Every obligation: what someone owes you |
| [Payments](/sales/payments) | Every settlement: how money was collected, and who recorded it |
| [Invoices](/sales/invoices) | Numbered invoice and pro-forma documents |
| [Bill Runs](/sales/bill-runs) | Batches that sweep a period of transactions into invoices |
| [Wallet](/sales/wallet) | Each member's store-credit balance |
| **Wallet movements** | Every credit and debit across all wallets |

### Cash

**Sales** > **Cash** appears once you turn on the cash module under **Settings** > **Sales** > **Cash Registry & Expenses**. It has three sub-tabs: **Overview** (cash on hand and expenses by category), **Expenses**, and **Ledger**. See [Cash registry and expenses](/sales/cash).

## The money model

Sales is built on three concepts that are deliberately kept separate. Once you have the model in your head, every Finance screen lines up.

* A **transaction** is what someone owes you. One row per obligation (a booking fee, a membership charge, a signup fee). Its `paymentStatus` is one of `pending`, `paid`, `overdue`, `void`, `partially_paid`, `refunded`, or `cancelled`.
* A **payment** is how money was collected. One row per settlement event, linked to one or more transactions.
* An **invoice** is a document that groups outstanding transactions for a contact, with a number and a due date. Invoices don't move money on their own.

This separation is why you can record a payment without ever issuing an invoice (for example, taking cash at the front desk for a single booking), and why an invoice can contain transactions from several different bookings or memberships.

## How a charge usually flows

The typical flow for a paid activity is:

1. A booking, membership, or signup fee is created. 1Club writes a **transaction** with `paymentStatus = pending` (or `paid` if the amount is zero).
2. Either the system or an admin collects payment. That can happen up front (Stripe Payment Element in the member portal, or an admin recording a manual payment), at check-in if the booking policy says so, or later from an invoice.
3. When the payment succeeds, 1Club creates a **payment** row, links it to the transaction(s) via `payment_transactions`, and flips the transaction's status to `paid`. Pending bookings tied to that transaction are confirmed.

Invoices are optional. They get created when:

* You manually invoice a transaction from its details page.
* You run a [bill run](/sales/bill-runs), which sweeps every pending non-void transaction for a period and groups them into invoices.
* A scheduled bill run fires on a cron (configured under **Settings** > **Billing** > **Automated Billing**).

## Recurring memberships

For recurring plans, an hourly job (`recurring-transactions`) does three things:

* Creates the next `membership_recurrence` transaction when a billing period rolls over.
* For memberships flagged **Require payment upfront**, it attempts to charge the contact's default Stripe payment method when the recurrence becomes due. If no default method is on file or the charge fails, the transaction stays `pending`.
* Marks any `pending` transaction whose due date is in the past as `overdue`.

It does not send invoices and it does not retry failed charges. Retries are manual: open the transaction or invoice and use **Charge** or **Add payment**. See [Plans](/sales/plans) for how a plan's fields drive this behavior.

## Settings for Sales

Setup that you do once lives under **Settings**, in two categories:

* **Settings** > **Sales** - **Point of Sale**, **Inventory Management**, **Rentals**, **Cash Registry & Expenses**, and **Payment terminals**. The switches here turn the matching tabs and register features on, and **Payment terminals** connects the card readers the register takes payment on.
* **Settings** > **Billing** - **General** (currency, [billing entities](/settings/billing-entities), tax rates, revenue accounts, [payment methods](/settings/payment-methods), [external programs](/settings/external-programs)), [**Pricing Rules**](/settings/pricing-rules), [**Seasons**](/settings/seasons), and **Automated Billing** (scheduled [bill runs](/sales/bill-runs#scheduled-bill-runs)).

## Related

* [Point of sale](/pos/point-of-sale) - the register where in-person sales are rung up
* [Plans](/sales/plans)
* [Products](/sales/products)
* [Orders](/sales/orders)
* [Transactions](/sales/transactions)
* [Payments](/sales/payments)
* [Invoices](/sales/invoices)
* [Payment methods](/settings/payment-methods)
* [Export](/settings/export) - CSV and QuickBooks bundle for accounting handoff.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.