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

# Lead Return

> When Tera returns a lead after Pre-Underwriting, what the returned status contains, and how it is billed.

**Lead Return** sends a lead back to you, unbilled, when Tera cannot take it forward after Pre-Underwriting. The submission's `status` becomes `returned`. A return is **final**.

Lead Return applies **only** when your supplier agreement includes the Lead Return term. Without it, Tera never returns a lead and `returned` never appears on your submissions.

## When a lead is returned

After an accepted submission becomes an Application, Tera runs Pre-Underwriting on it.

| Pre-Underwriting result | With Lead Return |
| - | - |
| Automated check finds a severe adverse result | Returned immediately |
| Automated check finds an adverse result, or the lead needs review | Held for broker review. Stays `accepted`, not billed, not returned |
| Broker review finds the lead clean | Continues. Becomes billable |
| Broker review finds an adverse or severe adverse result | Returned |

* A lead held for review is never returned because of the review alone. That includes a review caused by a Tera system fault or evidence Tera could not verify.
* Affordability outcomes never return a lead.
* A returned lead is final. Tera does no further matching, lender submission, or broker work on it. Under your agreement you may place the lead elsewhere.

## What the customer sees

The customer sees Tera's standard, neutral Pre-Underwriting decline screen wherever they are in the Tera application journey. Tera does not send a decline email, does not give the customer a reason, and does not mention you.

## Returned status object

A returned submission keeps its `application_reference` and `application_created_at`, and carries a `return` object. `return` is present **only** when `status` is `returned`.

```json theme={null}
{
  "environment": "production",
  "submission_id": "22222222-2222-4222-8222-222222222222",
  "external_reference": "harbourview-enq-2001",
  "level": "application",
  "status": "returned",
  "received_at": "2026-08-29T10:15:02.000Z",
  "decided_at": "2026-08-29T14:40:00.000Z",
  "application_reference": "TBF-7K2M9QXA",
  "application_created_at": "2026-08-29T10:15:09.000Z",
  "billing": {
    "billing_status": "not_billable",
    "billable_at": null,
    "billing_model": "pre_underwriting_cleared",
    "not_billable_reason": "returned"
  },
  "return": {
    "reason_category": "outstanding_ccjs",
    "reason_category_version": "v1",
    "returned_at": "2026-08-29T14:40:00.000Z"
  }
}
```

| Field | Meaning |
| - | - |
| `return.reason_category` | One Return Reason Category. See below. |
| `return.reason_category_version` | Version of the category list. Currently `v1`. |
| `return.returned_at` | When Tera returned the lead. `decided_at` is set to the same time. |

`handoff` never appears on a returned submission.

`returned` is not `rejected`. `rejected` means the submission failed at intake and no Application was created. A returned lead had an Application.

## Return Reason Categories

Each return carries exactly one curated category. When several apply, the most specific one wins, in the order below. Tera does not share scores, counts, amounts, thresholds, ruleset versions, or raw Pre-Underwriting reason codes.

| `reason_category` | Meaning |
| - | - |
| `company_dissolved_or_insolvent` | The company is dissolved, or in liquidation, administration, winding-up, or another insolvency process. |
| `outstanding_ccjs` | The business has outstanding County Court Judgments. |
| `adverse_credit_profile` | Satisfied or historic County Court Judgments, or an adverse credit score or band. |
| `weak_financial_position` | Negative net assets or material charges over the business. |
| `overdue_filings` | Statutory accounts are overdue. |
| `pre_underwriting_criteria_not_met` | The lead does not meet Tera's Pre-Underwriting criteria and no more specific category applies. |

Tera bumps `reason_category_version` when it adds, removes, or re-maps a category. Treat an unrecognised `reason_category` as `pre_underwriting_criteria_not_met`.

## Billing

Agreements with Lead Return use the `pre_underwriting_cleared` billing model.

| Point in the journey | `billing_status` | `not_billable_reason` |
| - | - | - |
| `received` | `pending` | `null` |
| Application created | `pending` | `null` |
| Pre-Underwriting clears the lead (automated clean result or broker clean) | `billable` | `null` |
| Lead returned | `not_billable` | `returned` |

A lead is never billable and then returned: billing stays `pending` until the lead clears. In sandbox, billing is always `not_billable` with reason `sandbox`, including for a returned lead.

The API records billing for reconciliation only. It does not invoice. If you pay in advance, returned leads are reconciled as credit or replacement under your agreement.

## Learn about a return

Tera sends a [`submission.status_changed` webhook](/guides/webhooks) when a lead is returned. Use a [status read](/guides/status-polling) to recover a missed event.


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