Every experienced freelancer eventually reaches the same crossroads: a trusted colleague passes them a project they cannot take themselves, an understanding forms, hands are shaken — figuratively or literally — and then comes the awkward part. How much does the person who sent the work actually get? When do they get it? Who pays whom, and how? And what happens if the client pays late, pays in installments, or the project balloons in scope?
These questions are worth answering precisely, because referral relationships are among the most valuable things a freelancer can build. They are warm leads, pre-qualified clients, and trust transferred by proxy. Getting the mechanics right — the percentage, the documentation, and the actual payment moment — turns a handshake habit into something that scales reliably.
This article walks through the entire sequence: how to calibrate a referral fee, how to document it so both parties are protected, where the common breakdowns happen, and how to use onchain payment routing to remove the manual settlement step entirely.
Why referral fees between freelancers deserve a formal framework
Freelancer referral fees are fees, often a percentage of a job, charged to a freelancer when they are referred to a client by another freelancer. That definition is simple enough, but the implementation is rarely straightforward. Many freelancers operate on informal reciprocal referral arrangements with no written agreement. Informality works fine when projects are small, relationships are old, and memories are reliable. It breaks down when the project is a $25,000 USD (~$38,500 AUD) brand overhaul, the client pays in three tranches over eight weeks, and one party's recollection of "what we agreed" differs slightly from the other's.
The deeper issue is structural. When you refer a freelancer to a client, you put your reputation on the line even if you're not involved in the project. If the freelancer fails to meet the client's standards, it can reflect poorly on you, since you're the one who referred them. That reputational exposure is the real justification for a referral fee — not just the introduction, but the ongoing implied endorsement. Anyone bearing that risk deserves to be compensated reliably, and reliability requires structure.
What a referral fee actually compensates
Before settling on a number, it helps to understand what the fee is actually paying for. There are at least three distinct contributions a referring freelancer makes:
The warm introduction. They surface an opportunity that would otherwise cost the receiving freelancer time, advertising spend, or platform fees to find. Even a small percentage can add up meaningfully over time if referral relationships are cultivated consistently.
The vetting and framing. A good referrer does not simply forward an email address. They brief the client on what to expect, calibrate the client's budget and expectations, and brief the receiving freelancer on the client's working style and priorities. That is genuine pre-sales and account management labor.
The reputational guarantee. The client took the meeting or signed the contract partly because someone they trusted vouched for the work. That vouching carries weight and risk in equal measure.
Another variable to consider is the level of involvement of the person referring the business. If someone sends just a quick email to make an introduction to a potential client, that's a very low level of involvement — they're making the introduction, but they aren't doing much to close the business. If another person sets up a meeting with a potential client and joins that meeting to help facilitate the sale, that's a very high level of involvement.
This spectrum matters when setting a percentage. A forwarded email and a fully managed handoff should not command the same fee.
What percentage is fair — and how to calibrate it
Referral fees can be anywhere between 5% and 25% of the cost of the project, though this can change depending on the business, the industry, and the scope of the project in question.
A more granular breakdown helps in practice:
| Referral fee | Referrer's involvement | In practice |
|---|---|---|
| 2–5% | A brief email introduction with minimal context | The referring freelancer opened a door and stepped back immediately |
| 5–10% | A proper warm introduction: a message explaining the client's needs, the project scope, and why the receiving freelancer is the right fit | A small percentage of the project's overall fee, rewarding your colleague for sending you the referral and incentivizing them to send more |
| 10–15% | The referrer stays involved through the proposal or pitch stage, helps negotiate scope, and may sit in on the kickoff call | Could start at the higher end of the range where the referrer deals more directly with the client |
| 15–20% | The referrer functions almost as an account manager for the duration of the project: client communication, managing expectations, absorbing first-line feedback | Some consulting arrangements structure finder's fees as a recurring percentage of revenue from the referred client for the duration of the relationship, not just the first project |
| Above 20% | The referrer is a subcontractor who brought the client, manages the client relationship, and bills the client directly before passing work downstream | Unusual for pure referrals, but justifiable |
Typically, the larger the deal, the smaller the percentage of the referral fee. A 10% referral fee on a $2,000 USD ($3,080 AUD) logo project is $200 ($308 AUD) — easy to absorb. A 10% referral fee on a $60,000 USD ($92,300 AUD) platform build is $6,000 ($9,230 AUD) — a meaningful cost that changes the economics of the engagement. As deal size increases, it is reasonable for both parties to negotiate toward the lower end of the band.
Flat fee versus percentage
While you can charge a flat fee, this can work against your favor. Setting a flat fee can discourage other freelancers from taking on the work because of the discounted amount, and it can also hurt you as it limits how much you make. Percentage-based fees scale naturally with project size and remove the need to renegotiate when scope changes. Unless the arrangement is very predictable and the project size is reliably consistent, percentage structures serve both parties better.
Three concrete scenarios
Scenario 1: The overflow referral
Maya is a freelance UX designer with a full pipeline. A client she has worked with for two years comes back asking for help with a secondary product. She cannot take it on. She refers the project to a UX colleague, Tom, who has relevant product experience.
Maya's contribution: a warm email introduction, a briefing call with Tom, and a note to the client explaining why Tom is the right fit. She stays available for occasional questions but is not involved in delivery.
Appropriate structure: 8% of the total project fee, payable when the client pays the final invoice.
If the project is $18,000 USD ($27,700 AUD), Maya's referral fee is $1,440 ($2,216 AUD). Tom invoices the client for the full $18,000. When the client pays, Tom transfers $1,440 to Maya. Simple — if it actually happens cleanly.
The problem: if the client pays in installments (say, $6,000 USD upfront, $6,000 at midpoint, and $6,000 on delivery), Tom may defer Maya's payment until the end, leaving Maya holding reputational risk for months without compensation. A good written agreement specifies whether the referral fee is paid proportionally on each tranche, or deferred to final payment and on what timeline.
Computed from Scenario 1: 8% of each $6,000 tranche is $480. Both options total $1,440; only the timing differs.
Scenario 2: The specialty pass-through
Jared is a brand strategist. He handles positioning and messaging for marketing agencies. A long-term agency client asks him for video production — outside his skill set entirely. He refers a video production company run by Priya, whom he trusts to handle the relationship professionally.
Jared's contribution: the introduction, active endorsement, and an expectation-setting call to align the agency on budget. He then steps back entirely.
Appropriate structure: 5% of the production fee, payable within 14 days of the client's full payment.
If the production engagement is $35,000 USD ($53,900 AUD), Jared's fee is $1,750 ($2,695 AUD). At this scale, the written agreement should specify exactly what triggers payment and who sends whom the funds. Priya receives $35,000 from the client and owes $1,750 to Jared. There is no ambiguity about timing as long as both parties agreed to it in writing before the project started.
Scenario 3: The two-freelancer subcontracting arrangement
Sophia is a full-stack developer who regularly handles large web projects. One project requires advanced data visualization work she is not qualified to do efficiently. She brings in Felix, a data engineer, as a subcontractor. Felix's scope is $12,000 USD ($18,480 AUD) within a $50,000 USD ($77,000 AUD) total project.
This is not a referral in the traditional sense — Sophia is a party to the contract, managing Felix's work and billing the client directly. But the economic logic is identical: the client pays Sophia, and Sophia owes Felix his $12,000. Getting that $12,000 to Felix promptly after the client pays Sophia is the mechanic that needs to work.
In all three scenarios, the fundamental problem is the same: one payment arrives, and it needs to split cleanly and immediately between two or more parties. The sequence of invoicing, transferring, confirming, and reconciling introduces delays, manual effort, and the risk that one party simply does not pay on time.
Documenting the agreement properly
Referral fees should be treated as a condition in a contract — you cannot just slip them in at a later date. The most important thing you need to do is be upfront about it and let both parties involved know early on that there will be a referral fee.
The documentation does not need to be elaborate. For small, straightforward arrangements — a freelancer referring a client to a colleague, for example — a simple one-page letter of agreement covering the trigger event, fee percentage, and payment timeline is sufficient.
A functional referral fee agreement between freelancers covers six items:
1. The parties. Full legal names and business names of the referrer and the receiving freelancer.
2. The project. A brief description of the work being referred — client name, project type, and approximate scope or budget.
3. The percentage or amount. State the fee as both a percentage and an illustrative dollar figure at the expected project value.
4. The trigger event. This is the most important clause. Does the referral fee become payable when the client signs the contract? When the client pays the first invoice? When the client pays in full? Be specific. "When the freelancer is paid" is ambiguous when installment payments are involved.
5. The payment timeline. How many days after the trigger event does the referring freelancer receive their fee? Seven days is generous; thirty days is the outer limit of what is reasonable.
6. Scope change provisions. If the project expands significantly, does the referral fee apply to the full expanded amount? Establish this before it becomes a negotiation under pressure.
Make sure you put your referral fee in writing — create a one-page letter of agreement and have both parties sign it. A signed document is not about distrust. It is about protecting a professional relationship from the ambiguities that good intentions cannot prevent.
Where the mechanics break down
The documentation handles intent. The mechanics handle execution. Most referral fee problems are not about disagreements over what was agreed — they are about the operational friction of actually transferring money after a payment arrives.
Delayed client payment cascades
Watching a payment due date pass with no money in your account is one of the most stressful parts of freelance life. You've delivered the work, you've sent the invoice, and now you're left wondering whether to follow up, wait it out, or assume the worst. For the referring freelancer, this stress is doubled: they are waiting on the receiving freelancer, who is waiting on the client. The chain introduces multiple points of delay.
Late payments go beyond inconvenience — they create ripple effects that affect a business for weeks. Cash flow instability is the most immediate problem. When the referrer is waiting on their share, they have no visibility into the client's payment status and no contractual relationship with the client to pursue it.
The "I'll pay you when I have it" problem
A common failure pattern: the client pays the receiving freelancer in installments or slowly. The receiving freelancer, cash-flow-conscious, absorbs the first payment for their own expenses and defers the referrer's share until the full project fee is in. Weeks pass. The referrer follows up. It becomes an awkward exchange between colleagues who have an ongoing professional relationship they do not want to damage.
Many freelancers spend hours chasing invoices that should have been paid automatically, time that could have gone toward billable work or business development. This is true for referral fees as much as it is for primary project payments.
Manual transfer errors
When the receiving freelancer finally sends the referral fee, they send it manually — a bank transfer, a PayPal payment, or a wire. They may miscalculate based on a pre-tax versus post-tax invoice amount. They may round down. They may send to the wrong account. Each of these is a small problem in isolation but corrosive to a professional relationship over time.
The scope creep problem
The client expands the project. The original $18,000 USD ($27,700 AUD) engagement becomes $26,000 USD ($40,000 AUD). The referral fee agreement specified a dollar amount rather than a percentage. The referrer believes the fee should scale with the expanded project. The receiving freelancer believes the original dollar amount was the agreement. Without a clause covering scope changes, this becomes a negotiation that neither party wants.
The settlement layer problem — and how onchain routing solves it
All of these problems share a root cause: the referral fee has to be manually extracted from a single incoming payment and rerouted to a second party. That extraction step is where trust, timing, and human error interact badly.
This is precisely the problem that onchain payment routing is designed to eliminate.
shaka.deal is a B2B payment router on Ethereum. When a deal involves multiple parties who each hold a right to a share of an incoming payment, shaka.deal allows those shares to be pre-set before the money arrives. When the client pays, the router distributes to every party simultaneously — in a single transaction, at preset proportions, with finality.
In the context of a referral arrangement between two freelancers, the mechanics work like this:
- Agree on the split before the project startsThe referring and receiving freelancers agree — as they would in a written agreement — that 8% of the project fee goes to the referrer and 92% goes to the receiving freelancer.
- Configure the routingThose percentages are encoded on shaka.deal. The referrer's wallet address and the receiving freelancer's wallet address are registered as the two recipients, with the 8/92 split applied.
- The client pays to the routing addressRather than paying the receiving freelancer directly, the client sends the total payment — $18,000 USD equivalent — to the deal's routing address on Ethereum.
- The router distributes instantlyshaka.deal routes $1,440 to the referrer and $16,560 to the receiving freelancer in the same transaction. Neither party waits for the other to manually transfer anything. There is no "I'll send it over later." There is no rounding error. There is no cash flow delay.
The key property here is simultaneity. Both parties receive their shares in the same moment the payment settles. The referring freelancer is not in a queue waiting for the receiving freelancer to remember to send funds. The receiving freelancer does not need to manage a two-step payout process that requires them to handle someone else's money before forwarding it.
shaka.deal is non-custodial: it routes funds, it never holds them. The moment the client's payment arrives, the distribution executes and the router's involvement ends. There is no intermediary position where funds sit waiting to be claimed or forwarded.
Onchain payments are also final. Unlike traditional wire transfers or card payments, a settled transaction on Ethereum cannot be reversed after confirmation. This is a meaningful property for referral arrangements: the referrer's $1,440 cannot be recalled, reversed, or put in dispute after delivery. Once it settles, it is theirs.
Handling multi-tranche payments
Many large freelance projects involve phased payments: 30% upfront, 30% at midpoint, 40% on delivery. This structure works cleanly with onchain routing because the split configuration stays constant across transactions.
Each time the client sends a tranche, the router applies the same 8/92 distribution. The referrer receives their proportional share of each tranche — not a lump sum at the end, not a manually timed transfer after the project concludes. Both parties' cash flows are synchronized automatically.
This also eliminates the most common fairness argument in referral disputes: the referrer arguing that deferring all payment to the final tranche unfairly concentrated their exposure at the end of a project. With proportional per-tranche distribution, both parties share the timing risk equally.
When three or more parties are involved
More complex arrangements — a referring freelancer, a receiving freelancer, and a subcontractor engaged by the receiving freelancer — involve three simultaneous payees from a single client payment. Manual settlement across three parties introduces compounding delays and friction. Each additional party in the chain is another point where timing, error, or awkwardness can materialize.
shaka.deal handles multi-party distributions in a single transaction. A three-way split — say, 8% to the referrer, 72% to the project lead, and 20% to the subcontractor — can be configured as preset shares. When the client's payment arrives, all three parties are settled simultaneously. No one waits on anyone. No one handles anyone else's money.
This matters most when the parties have unequal leverage. A subcontractor or referring freelancer typically has no direct relationship with the client and no ability to enforce payment timing independently. Removing the human forwarding step from the settlement sequence removes the vulnerability entirely.
Practical checklist for setting up a referral split
Before the project starts, run through the following:
- Written agreement signed. Both parties confirm the percentage, the trigger event, and the payment timeline.
- Scope change clause included. Establish whether the fee applies to the original scope only or to the full engagement including change orders.
- Payment method aligned. If using onchain routing, both parties need compatible wallets. Confirm this before the client is given payment instructions.
- Client briefed. The one surefire way to implement referral fees is to be completely open about it with both sides — tell both the client and the freelancer you're referring, and if somebody doesn't agree with the deal, they can walk out. Transparency with the client removes any risk of the arrangement appearing covert or creating conflicts of interest later.
- Split configured before payment is requested. Never ask the client to pay before the routing is set. Reconfiguring after payment has arrived creates manual reconciliation work that defeats the purpose.
- Tax treatment documented. Referral fees are considered taxable income by the IRS — and equivalent treatment applies in most jurisdictions including Australia. Both parties should record the fee as revenue in the period received. If the amount is significant, a brief note to an accountant is worthwhile.
Building referral relationships that last
A referral arrangement that pays cleanly and promptly strengthens the professional relationship it was built on. The referring freelancer knows that every introduction they make will generate their fee automatically and immediately, without follow-up, without awkwardness, and without depending on the receiving freelancer's cash position at any given moment.
That reliability changes behavior. Freelancers who have clean, functioning referral arrangements tend to make more referrals. They think of each other when new opportunities arise. They actively position each other to clients as trusted specialists. Client referrals and the income generated from fee-splitting agreements are not only an important revenue stream, but also serve to assist those clients in need of quality representation when a professional is unable to take on all prospects themselves as a result of availability or differing practice areas.
The inverse is equally true. A referral relationship that produces awkward follow-up conversations, delayed payments, and disputed amounts eventually produces no referrals at all. The professional friction poisons the goodwill that made the relationship valuable.
Getting the mechanics right is not just about the money. It is about sustaining the kind of professional network that generates meaningful work over years, not just the occasional opportunistic handoff.
Summary: the five-part framework
Building a reliable referral fee arrangement between freelancers reduces to five decisions made clearly before the work begins:
- Scope of the referrer's contribution. Cold introduction, warm handoff, or active account involvement — this determines the percentage range.
- The percentage or amount. Percentage is better than flat fee for variable-scope projects. Calibrate to the project size and the referrer's level of involvement.
- The trigger event. When exactly does the fee become payable? Tie it to a specific payment event, not a vague milestone.
- The settlement method. Manual transfer or onchain routing. If the arrangement involves significant sums, multiple tranches, or more than two parties, onchain routing with a tool like shaka.deal removes the friction and the trust dependency from the settlement step.
- Documented agreement. A signed one-page letter is sufficient. Ambiguity is the enemy of professional relationships, and clarity is cheap.
Freelancers who build referral networks with this level of intentionality tend to find that the mechanical work of setting it up is a small investment against the compounding value of introductions that flow both ways, reliably, over the course of a career.
