Skip to main content
The Revenue menu (route /billing) is where you set up what you sell and track what you’re owed and what you’ve collected. Its money model is built on three concepts that are deliberately kept separate. Once you have the model in your head, every screen in the menu 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 via a join table.
  • 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.

​
The Revenue menu

The Revenue menu opens on Plans. Its tabs, in order: Payment acceptance is configured elsewhere: Payment methods lives under Settings because it’s a one-time setup of which methods (Stripe, cash, bank transfer, wallet) your organization accepts.

​
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, 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 bill runs).

​
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 for how a plan’s fields drive this behavior.

​
What lives where

  • Plan templates: Revenue > Plans.
  • Products and packages you sell: Revenue > Products and Revenue > Packages.
  • Point-of-sale orders: Revenue > Orders.
  • Transaction obligations: Revenue > Transactions.
  • Settlement events and the Created by column: Revenue > Payments.
  • Invoice documents, PDFs, and payment links: Revenue > Invoices.
  • Batch invoice generation: Revenue > Bill runs.
  • Stripe connection, manual payment methods, tax rates, revenue accounts, automated bill runs: Settings > Billing.