---
title: Referral commissions
description: Agreements with the people who bring you business — the rate, the dates it applies between, who pays the referrer, and the compliance record a professional body asks for. Off by default, with a shadow mode that calculates without owing anybody anything.
product: TSync Intelligence 11.3.6
language: en
canonical: https://docs.tsync.pro/modules/tsync-referrals/
source: https://docs.tsync.pro/llms.txt
---

# 🤝 Referral commissions

Somebody sends you a client — an architect, a consultant, a former customer — and you pay them a percentage.
**Referrals** is where that arrangement is written down: the rate, the period it applies to, how the payout will
be documented, and the reasoning that says this arrangement was allowed on purpose.

The module is **off by default**, and here that is not routine caution. A commission module switched on by
accident starts producing **money owed to people outside your company**, calculated from transactions nobody
reviewed.

> **What is in this version.** Agreements, rates with history, programme membership and the compliance record.
> Automatic claims, accrual, payouts and statements are **not** built yet — this release is the record the
> later ones will calculate from.

## Turning it on

**Referrals → Referral settings** has one decision at the top, the **mode**:

- **Off** — nothing is calculated. You can still prepare agreements here; nothing is owed to anybody.
- **Shadow — calculate, pay nothing** — everything is calculated against your real transactions so you can
  compare it with what you pay today, **without creating an obligation**. This is how you check the numbers
  before trusting them.
- **On** — commissions become real.

On the same page you set the defaults every new agreement starts from: the **attribution window** (how long
after a referral a sale can still be attributed to it), the **default currency**, and how a payout is
documented. Two switches decide what has to be in place before anyone is paid — **an approved invoicing
profile**, and **the anti-bribery clause accepted**.

## Who can do what

Three separate permissions, and the third is deliberately not part of the second:

| Permission | Allows |
|---|---|
| **View referral agreements and amounts** | reading agreements and the amounts calculated from them |
| **Create and edit referral agreements** | writing them |
| **Approve a referral payout** | authorising the money to leave |

Whoever calculates a commission should not be the person who authorises paying it. Granting *manage* does not
quietly grant *approve*.

## The partner comes first

A referral agreement is made with an **economic partner** who carries the **referrer** role. If nobody has it
yet, the page says so and points you back: open **Economic partners**, give that partner the *referrer* role,
then come back here.

That order is on purpose. A referrer is a business relationship — with a name, a tax code and an address —
before it is a commission line.

## An agreement

**Referrals → New agreement** asks for:

- **the partner** and a **title** you will recognise later;
- a **status** — *Draft · Active · Suspended · Terminated*;
- **valid from / valid to**, and whether it **renews automatically**;
- the **attribution window in days** — how long after a referral is declared a sale can still be attributed to
  it;
- the **currency** (leave it empty to use the account default);
- **how the payout is documented** — *the partner issues an invoice*, or *we issue a self-billed statement*.

That last one is a real fork, not a preference. **A freelancer cannot issue a fiscal invoice.** Assuming
everybody can leaves half your referrers unpayable, and you discover it at the end, when the commission is
already owed.

### The compliance record

The lower half of the form is the part people are tempted to leave empty, and the one that is worth the most
later. It records **who pays the referrer**:

- *the client pays their own adviser* — if your client already pays this person for advice, a commission from
  you is a second payment for the same advice;
- *we pay the referrer*;
- *not recorded* — which is not a neutral state, and the list shows it in amber.

Beside it: the **profession** and **professional body**, the **due-diligence** trail (who did it, when, when it
is due for review, and the conclusion), whether the **anti-bribery clause** was accepted, and — in your own
words — **why this arrangement is acceptable**. Professional codes ask for that reasoning to be recorded in
writing, and a note written today is worth more than a reconstruction written when somebody asks.

### Rate history

**Editing an agreement opens a new version instead of rewriting what already happened.** A rate is applied as
it stood **on the day of the transaction**, so raising a percentage in June does not silently re-price
everything settled in March. The **Rate history** table at the bottom shows each version, from when to when,
with the current one marked *in force*.

This is the single most important thing to know about the module: your past is never edited by a change you
make today.

## What you will see on the list

**Referrals** lists the agreements with the partner, the title, the status, who pays the referrer and the
validity period. When the module is **off**, a note at the top says agreements can be prepared but nothing is
calculated; in **shadow** mode it says commissions are being calculated and nothing is payable.

## Claims: who brought the buyer, and when they said so

A **claim** is a **dated declaration**, made **before** that buyer reaches you. That is the whole feature: the
moment, plus its trail. A "referred by" field filled in after the sale records a conclusion, not a claim — and
it helps nobody when, a year later, somebody disputes who brought the customer.

**Registering one.** Referrals → *Claims* → **Register a claim**. Choose the referrer, write the buyer **as
they named them**, and say which way they told you. That is it.

**The expiry is worked out once, at registration**, from the agreement's window. It is never recalculated: if
you change the agreement tomorrow, today's claims keep what they were promised today.

**Three states, not two.** A claim is *not decided*, *approved* or *declined*. "Not decided" is not the same
as "declined" — the first is a queue item, the second is an answer.

**A decline needs a reason.** Without one, it is the same conversation again in three months.

**Approving freezes the attribution trail:** which version of the agreement was in force, which rule won, and
**which rules it beat**. You can open the trail at any time. A rule changed next month does not re-decide what
was already settled.

**Retroactive claims** are **refused by default**: if the person named was already your customer, the claim is
declined at registration, with an explanation — rather than discovered at payout, when the commission is
already owed. Switchable in settings, together with the "how long counts as existing" threshold.

**"Buyer informed"** is a **record**, not a clearance. It blocks no payment and certifies nothing — it is
evidence you have if you need it.

**One customer earns for one claim.** Two people can both claim the same buyer, and you can approve both — the second approval is somebody telling you they made the introduction too, not a mistake. Only the one who **declared first** earns on that customer. The others are listed in the recompute's skipped lines, naming the claim that won, so "why does my claim produce nothing" has an answer.

**A claim that expired, or that the referrer withdrew, stops earning.** The window on the agreement is what decides it — that is what it is for.

## The commission ledger

Referrals → *Commission ledger*, one month at a time.

Every line carries **two separate states**, deliberately:

| | |
|---|---|
| **Approval** | draft → earned → **recognised** (booked by accounting) |
| **Payment** | unpaid → partly payable → payable → paid |

A commission can be **recognised and unpaid**, or **payable and unapproved**. One "status" column could not
tell you which.

**Payable in proportion.** Invoice 10,000, customer pays 5,000, and half the commission is payable. The
collected percentage is shown beside the figure so you can check it. Switchable to "nothing until paid in
full".

**The base** is **net** by default — excluding VAT, after discount. Worth looking at once: it is the figure
the percentage applies to.

**Every invoice of the month counts** — not just the first one. A customer who buys three times in a month earns the referrer three lines.

**Drafts and cancelled invoices earn nothing.** A commission on a draft would be money owed on a document nobody has issued; one on a cancelled invoice would outlive the sale it was paid for.

**Recompute the period** rewrites the month's automatic lines. It never touches lines entered by hand, and
never anything **recognised** — a recompute does not undo a decision a person made.

**And it tells you what it skipped, and why:** "no rule matched (9), no invoice in period (3)". A recompute
that writes nothing and says nothing is indistinguishable from one that correctly found nothing.

**A reversal is a negative line** linked to the original. The old line is not edited: the total of a month
already reported must not change quietly.

**Check for drift** compares each settled line against its source document today. If the invoice has changed,
a **discrepancy** opens — a row somebody has to close, with an explanation.

## Settlement: four steps

Referrals → *Settlements*.

There is one switch worth knowing about before you start. **"Pay only commissions that have been
recognised"** (Referrals → *Settings*) is **off** by default, and payment does not wait for recognition. Turn
it on and recording a payout pays only the lines somebody has recognised; the rest **stay in the statement as
still owed** and the screen tells you how many were skipped. Recognise them and the same statement pays them
— it delays money, it never loses it.

1. **Freeze the statement** for a partner and a month. The numbers stop moving while you talk. **Reversible** —
   it is not approval and it is not final.
2. **Approve.** The compliance checks run here, and here you choose the **destination account** — the accounts this partner has already been paid to are offered, and anything you type is remembered for next time. It stays a free field: a bank detail this module cannot verify must not be refused.
3. **Record the payout**, with the document that supports it.
4. The lines become "paid".

**The checks run against the agreement that earned the money**, not against the partner's newest one. If a statement covers lines from several agreements, every one of them is checked, and each finding says which agreement it came from.

**Changing the destination account after approval re-opens the approval.** Approving a payment is approving
where it goes.

**Two document paths, because partners are not alike.** A company issues an **invoice**. A **freelancer
cannot** issue a fiscal invoice — for them the route is a **handover act plus proof of payment**, and both are
required.

## What stops you, and what only warns

The module does not decide whether an arrangement is acceptable. It checks what can be checked and **tells you
what you are looking at**:

**It STOPS you** only when:

- the agreement has **expired**, has not started, or is not active;
- the partner's programme membership is **suspended or revoked**;
- approved invoicing details are missing, or a freelancer registration has expired *(switchable — it depends
  on the jurisdiction)*;
- the anti-bribery clause is not accepted on the agreement *(same)*.

**It WARNS you but lets you proceed** (by ticking that you have read it):

- due diligence is missing, or its review date has passed;
- the engagement model is still "unknown";
- the rate is above the threshold **you** configured and has no sign-off. *The threshold ships empty — we do
  not say what rate is reasonable.*

**A missing "buyer informed" record is YOUR choice to make** — Referrals → *Settings* → *If the buyer was
not told about the commission*:

| | |
|---|---|
| **Only record it** | it is written down and nothing is interrupted |
| **Warn** *(default)* | the payout needs somebody to tick that they have read it, and the tick is stored |
| **Refuse the payout** | no payment until the disclosure is recorded |

It applies **only** where the buyer pays the referrer — that is what makes it a conflict of interest. If you
never use that arrangement, you will never see this.

The module does not decide whether disclosure is required by law, and it never claims a tick discharges
anything. It gives you the switch because what your company requires of itself is your decision, not ours.

> **If the referrer is an architect**, the module flags it — not as an error, but because architects'
> professional rules may require **refusing** such a benefit rather than merely declaring it. Recording a
> disclosure does not discharge that duty. Ask a lawyer; software cannot answer it.

## The report an auditor asks for

Reports → **Third-party referral payments**: per referrer, per period — total, rate (weighted average), base,
due-diligence review date, buyer-informed status, engagement model, open discrepancies. It exports, schedules
by e-mail and charts like any other TSync report.

## What the module does NOT do

- **It does not pay in goods or as a later discount.** Deliberately not built: that route is effectively
  unavailable to a freelancer, and most referrers are one.
- **It gives no verdicts.** No green "compliant" tick, no risk score.
- **No multi-level referrals**, referral links or cookies. Referrals here are between people and under
  contract.

## Removing the module

Uninstalling **drops nothing**. These rows are the record of payments to third parties, and a record of money
is not something a checkbox should be able to delete.
