# Revenue Settings

**Revenue Settings** is where you configure how revenue is reported, review each channel's sync configuration, and choose which bank accounts feed cash matching. Open it from **Revenue → Settings** — the page is titled **Configuration** and has two tabs: **Revenue Settings** and **Bank Accounts**.

---

## Overview

Open **Revenue → Settings**. Unlike the rest of the workspace, Settings is not scoped by the channel filter.

## Revenue reporting policies

A **revenue reporting policy** controls whether revenue is reported **gross** (full invoice amount) or **net** (after channel fees) for a given scope. The policies table lists each policy's level, channel, product, reporting basis, source, effective dates, and last update.

To add or change a policy:

1. Select **Add Policy** (or the **Edit** action on an existing row).
2. Choose the **channel** and, optionally, a **product**.
3. Choose the **reporting basis** — **Gross** or **Net**.
4. Set the **effective from** and **effective to** dates.
5. Save.

Validation: the effective-from date cannot be in the past, and effective-to must be on or after effective-from. Use **Delete** to remove a policy you no longer need.

![Revenue Reporting Policies table with the Add Policy button circled](images/settings-reporting-policies.png)

The **① Add Policy** button (circled) creates a new rule. Each row shows the policy's **Level** (Channel default or Org-wide default), **Channel**, **Product**, and **Reporting Basis** (GROSS or NET) — for example, AWS CPPO reports **NET** while Stripe reports **GROSS**. Use the **Edit** action at the end of a row to change it.

## Channel sync configuration

Each connected channel (AWS, Azure, GCP, Stripe) appears as a card showing its connection status (**VERIFIED**), last sync time, and error count. Two values describe how that channel ingests data:

- **Schedule** — **Daily**. This is a fixed *displayed* value, not a choice and not a promise about cadence: the control is locked to Daily, and the effective schedule is set by Suger server-side. A channel with no stored sync configuration actually defaults to **hourly**, and the sync interval Suger reports for connection health varies by channel again. Read this field as *Suger manages the schedule*, not as *this channel syncs once a day*.
- **Backfill Months** — **24**. Also locked. Connecting a channel pulls up to 24 months of history; the amount is not adjustable per channel.

Both fields are read-only, so **Save** re-applies the standard configuration to that channel rather than saving a custom one. Connect a revenue channel first if the list is empty.

:::info
The revenue background jobs have to be running before anything refreshes. They are **off by default**, and no control on this page turns them on — the switch is a single environment-wide setting Suger controls, not a per-organization toggle, so there is no way to have your organization enabled on its own. If a **VERIFIED** channel is not refreshing, contact [support@suger.io](mailto:support@suger.io) to have the state of the revenue jobs checked.
:::

:::info
**Oracle does not appear here, and that is expected.** Suger ingests Oracle Cloud Marketplace revenue from the OCI publisher disbursement report, so Oracle records can show up in your revenue data and in the channel filter — but Oracle is **not** a manageable revenue connection. It has no card on this page, no connection health, no backfill trigger, and no sync interval. This list is limited to AWS, Azure, and GCP as marketplace channels plus Stripe as the payment channel.

The OCI report also only exposes about **three trailing months**, so an Oracle backfill could not reach further back even if it were offered. For anything older, work from the reports in the Oracle Cloud console.
:::

## Bank Accounts

The **Bank Accounts** tab manages the connected accounts used for cash matching against your revenue records.

![Bank Accounts tab with the connect buttons and summary cards circled](images/settings-bank-accounts.png)

The connect actions are circled in orange — **① Connect Plaid** and **② Connect Stripe** — and the summary cards in red: **③ Connected Accounts**, **④ Active Accounts**, and **⑤ Institutions**.

### Summary cards

| Card | Meaning |
|------|---------|
| **Connected Accounts** | Total bank accounts connected for sync and cash matching. |
| **Active Accounts** | Connected accounts currently in an active state. |
| **Institutions** | Distinct financial institutions across connected accounts. |

### Connecting an account

- **Connect Plaid** opens Plaid Link to connect a bank account.
- **Connect Stripe** uses Stripe Financial Connections (requires a connected Stripe integration).
- **Refresh** re-syncs account state.

The accounts table lists each account's name, provider, currency, status, last sync, and provider account reference.

## KPI calculation formulas

The Revenue Settings tab has no KPIs. The Bank Accounts tab shows connection counts:

| KPI | Applies to | Formula | Calculation details |
|-----|------------|---------|---------------------|
| Connected Accounts | Plaid, Stripe Financial Connections | `count(connected bank accounts)` | — |
| Active Accounts | Plaid, Stripe Financial Connections | `count(accounts with active status)` | — |
| Institutions | Plaid, Stripe Financial Connections | `count(distinct institutions)` | Distinct financial institutions across connected accounts. |

:::info
**Base currency and FX.** Amounts across the workspace are converted to a base currency — taken from your revenue configuration, defaulting to USD.

**Which date the rate comes from.** Suger converts at the rate for the record's **invoice date**. When a record has no invoice date, it converts at **the current date** instead — so that record's rate reflects when it was last normalized rather than when the money moved.

**How long the rate lasts.** The converted base amount and the rate used are **stored on the record**, so opening a page or re-running a report never re-converts anything on the fly. They are not frozen permanently, though: every sync re-normalizes that channel's records, which recomputes the base amount and can replace the stored rate. Expect figures to be stable between syncs rather than immutable forever.

**When no rate is available.** If Suger cannot get a rate for the conversion date, it falls back to the most recent rate it has already stored, provided that rate is no more than **35 days** older than the conversion date. Beyond that window Suger will not substitute an older rate.
:::