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

# Spend Gating

> Hold project spend to a Business Unit threshold, and require approval before a project can spend past that funded level.

Spend Gating adds an approval layer for project spend. When it is on for an account, each project can spend up to its funded level without an extra approval. Spending past that level requires a budget request and an approval. Projects inside the funded level launch as usual.

Accounts that leave Spend Gating off see no change: no extra fields, no checks, no budget emails.

## Turn the feature on

A Rep Data admin enables **Spend Gating** for the account in **Accounts Management**, in the **Spend Gating** section, with the **Enable Spend Gating** toggle.

The toggle does not enforce gates until setup is complete:

* Every Business Unit has a **Spend Threshold**
* At least one **Budget Approver** is assigned

While gating is enforcing, every new Business Unit must have a Spend Threshold, including Business Units created through the API.

Turning Spend Gating off stops enforcement. Open budget requests can remain, but projects are no longer gated.

## Spend threshold and funded level

Limits are set on the **Business Unit**, not as one shared pool for the account. Client-facing name is Business Unit.

| Term | Meaning |
| - | - |
| **Spend Threshold** | Required currency amount on the Business Unit. The amount a project tagged to that Business Unit can spend without an approved increase. |
| **Funded level** | The room under the current cap. At creation this is the Spend Threshold. After an approval it is the approved maximum. |
| **Effective budget** | The approved maximum, if one has been granted. Otherwise the Business Unit Spend Threshold. |
| **Requested Budget** | Optional amount the researcher asks for on the project. Above the threshold, this starts a budget request. |

Each project tagged to a Business Unit is funded up to that unit's threshold on its own. Launching several projects does not draw down one shared Business Unit balance.

Lowering a Spend Threshold applies to projects funded after the change. It does not reduce the funded level of projects that were already funded.

The threshold uses the Business Unit currency.

## Configure Business Units

When Spend Gating is on, the Business Unit table shows the spend settings. People with the **Business Unit configuration** permission can edit them. Account admins have that permission by default. It can also be granted to other users, and it applies only on the account where it is granted.

<Steps>
  <Step title="Open the Business Unit">
    Create or edit the Business Unit. A new Business Unit starts with every current Budget Approver selected.
  </Step>

  <Step title="Set the Spend Threshold">
    Enter the currency amount. The Business Unit cannot be saved without a threshold while gating is enabled.
  </Step>

  <Step title="Confirm Budget Approvers">
    Keep the full list or remove people so only the right approvers remain. The Business Unit cannot be saved with zero approvers. Requests for that Business Unit go only to the approvers on its list.
  </Step>

  <Step title="Set the escalation timeout">
    Set how many hours a request can sit before it escalates. The default is **24 hours**. At the timeout, account admins receive one escalation notice. The request stays open and can still be decided.
  </Step>
</Steps>

## User permissions

These user settings appear only when Spend Gating is enabled for the account.

| Permission | What it allows |
| - | - |
| **Business Unit configuration** | Create and edit Business Units, thresholds, approvers, and the escalation timeout |
| **Budget Approver** | Review budget requests in **Approvals**, and be eligible for assignment on a Business Unit |

Both permissions are per user and per account. A person with access to more than one account can manage Business Units or approve requests only on the accounts where the permission is on.

## Create a project

When Spend Gating is on, project creation asks for the Business Unit and two extra fields.

| Field | Required | What happens |
| - | - | - |
| **Business Unit** | Yes. Exactly one. | The project is funded up to that unit's Spend Threshold. |
| **Requested Budget** | No | Blank, or at or under the threshold: the project is created and no request is sent. Above the threshold: the project is created and a budget request goes to that Business Unit's approvers immediately, while setup continues. |
| **Research Docs** | Hidden, optional, or required — set on the account | Free-text pointer to the research record. Captured on every project that shows the field, including projects that never hit the gate. |

The Requested Budget helper text uses the selected Business Unit's threshold. Changing the Business Unit before you save updates that helper text.

The Business Unit can be changed until the project goes live or a budget request is sent. After that it is locked. **Research Docs** stays editable. It is a pointer, not a budget control.

A project has **one open budget request**. A later ask updates that request (new amount, approvers notified again). It does not create a second open request. One approval covers the work held on that project, up to the granted maximum.

## Project budget line

With Spend Gating on, project pages show spend against the cap: estimated spend, the denominator (approved maximum, or the Spend Threshold if none has been granted), a progress fill, and remaining headroom.

* The fill turns **amber at 85%** of the denominator
* When an approved maximum exists, a mark shows where the original funded level sits
* **Request Budget** opens the budget request from the project

Spend used for this line, and for gate decisions, comes from **source-level buy price (BCPI)**. Completes that are reconciled out are removed from the total. Survey-level totals are not the source of the number. The line can be a few minutes behind. The launch check uses a fresh total.

## Launch and field to the funded level

On launch, Research Desk compares cumulative spend plus the cost of the action to the effective budget.

| Situation | What happens |
| - | - |
| At or under the effective budget | Launch continues. No modal and no email. |
| Over the effective budget | A gate modal explains the check and takes the budget request. The requested amount is prefilled when the project already has one. The project still launches and fields up to the remaining funded level. |
| Approval arrives before spend hits the cap | Fielding continues. The project is not paused. |
| Spend hits the cap first | Fielding pauses at the cap. The requester is emailed. Completes already collected stay on the project. Fielding resumes automatically when the request is approved. |

The pause check runs about every **15 minutes**, so a project can spend a short way past the cap before it pauses.

Further over-budget launches while a request is open use that same open request. One approval releases the held work that fits under the granted maximum.

<Warning>
  A pending request does not pause a project by itself. The project keeps fielding until it reaches the funded cap.
</Warning>

## Resume after the cap

The same budget check runs when you relaunch or resume a project.

If project spend is already over the maximum budget, further launches are blocked — including **Scheduled Launch** — until a higher budget is approved. There is no remaining funded amount to field into. Use **Request Budget** on the blocked launch state to open the request modal.

If spend is still under the maximum, surveys and sources can launch. They still pause if they later reach the cap.

## Approve or deny a request

**Approvals** appears in the navigation (checkmark icon) for users with the Budget Approver permission.

| Tab | Use |
| - | - |
| **Budget Requests** | Open requests for the Business Units you approve, including requests that started in SightX. SightX requests include a link back to the SightX project. |
| **Business Units** | Read-only view of Business Unit configuration, so you can check the threshold and approver list without leaving Approvals. |

On a request you can:

* **Approve** — the amount starts as the requested budget. You can enter any other positive amount. That amount becomes the project's enforced maximum immediately.
* **Deny** — a comment is required. The funded level does not change, and live fielding is not interrupted. The researcher can revise the request and send it again.

There is no in-product thread beyond the comment. A full budget history log is not part of this release. Approvers work from the open requests on the Budget Requests tab.

Desk is the approval surface for both Research Desk and SightX. SightX does not have its own approver screens. Budgets are tracked separately in each system. For work that exists in both, the system where it started owns the gate, so the same project is not gated twice.

## Emails

Messages come from **Research Desk Budget System** ([clientsuccess@repdata.com](mailto:clientsuccess@repdata.com)).

| Email | When | Who | Subject |
| - | - | - | - |
| Budget request | A request is created, or the open request's amount changes | Budget Approvers on the Business Unit | Budget approval request: project name |
| Escalation | The Business Unit escalation timeout passes with no decision | Account admins | Escalated - budget approval request pending: project name |
| Approved | An approver approves | Requester | Budget Approved: project name |
| Approved at a different amount | The approved amount is not the requested amount | Requester | Carries the approved amount, not the requested amount |
| Denied | An approver denies | Requester | Budget request denied: project name |
| Paused at budget limit | The project hits the funded cap while a request is still open | Requester | Paused at budget limit: project name |

The request email links approvers to the review screen and includes the Research Docs value when the project has one. The denied email includes the approver's comment. The paused email tells the requester that fielding resumes when the request is approved. No separate action is required to restart.

## Related guides

* [Creating Projects](/research-desk/guides/01-creating-projects)
* [Admin and User Management](/research-desk/getting-started/04-admin-and-users)
* [Scheduled Launch](/research-desk/guides/14-scheduled-launch)
* [Billing and Margins](/research-desk/guides/22-billing-and-margins)
* [Reconciliation](/research-desk/guides/07-reconciliation)


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