🤝 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:

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:

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:

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.