A freelance deposit payment protects the start of a project; milestone payments protect the middle. For short, tightly scoped work, a deposit plus final balance may be enough. For longer or higher-risk work, split the fee around objective deliverables and approvals so unpaid work cannot accumulate. No single percentage, including 50% upfront, is right for every project.

A 50% deposit can leave you carrying more payment risk than a 30% deposit.

It happens when a 50/50 project leaves half your fee tied to a final approval that keeps moving, while a project with 30% upfront collects another payment at a real midpoint.

The percentage on the first invoice is only one part of the decision. A useful freelance payment schedule answers a harder question:

How much work can you complete before the next payment becomes due?

That matters even more on projects that run for weeks, require several client approvals, involve outside costs, or end with a high-value handoff such as source code, editable design files, production access, or a launch.

For Nigerian freelancers working with international clients, there is another clock to consider. An invoice becoming due and money becoming usable are separate events. The payer, currency, transfer rail, review process, and cash-out route can all affect that gap. The guide to how Nigerian freelancers receive payments from US, UK, and EU clients covers that part of the workflow.

The schedules and contract wording below are planning examples, not legal or tax advice. Contract enforceability, deposits, refunds, payment disputes, and cancellation rights depend on the agreement, jurisdiction, and payment method.

Deposit, milestone, and final balance solve different problems

These three payments should not be treated as interchangeable percentages.

A deposit covers the beginning.

A milestone prevents the middle of the project from becoming one long stretch of unpaid work.

A final balance gives the project a defined commercial close.

A short project may need only the first and last. A longer project often needs all three.

The percentage matters less than your unpaid exposure

A useful way to test a freelance payment schedule is to estimate your unpaid exposure at different points in the project. This is a planning metric, not an accounting standard:

Unpaid exposure = value of work completed + non-recoverable project costs - payments received

Suppose you quote $4,000 for an eight-week project.

With 50% upfront and 50% at final delivery, you receive $2,000 before starting. Once you have completed $3,500 worth of work, however, $1,500 of that completed value is still unpaid.

Now imagine a different schedule:

• 30% before work begins

• 30% after the first major deliverable

• 25% after the second major deliverable

• 15% at final handoff

The starting payment is smaller, but payment follows the work more closely.

This is why asking “Should freelancers ask for 50% upfront?” does not have one useful answer. A 50/50 structure can be excellent for a short, bounded project and awkward for a long project with six weeks of work between the first payment and final acceptance.

The shape of the work matters.

Software projects, for example, often have natural checkpoints such as discovery, staging, integrations, QA, and production handoff. The walllet.com guide to client scope and contracts for freelance software developers shows how acceptance criteria and technical milestones can follow those stages.

Match the payment schedule to the project

Four variables matter more than copying somebody else’s deposit percentage.

1. How long is the project?

A three-day audit does not need the same payment architecture as a four-month product build.

Every extra week between payments increases the amount of time, attention, and capacity you are financing before the next payment arrives.

2. How clear is the scope?

A tightly specified deliverable is easier to place behind a deposit and final balance.

A project with unresolved requirements, dependencies, or client decisions needs smaller stages. Otherwise, the payment schedule may assume certainty the work itself does not have.

3. Where are the real approval points?

A milestone should exist where the client can inspect something meaningful.

Examples:

• research findings approved before design begins;

• information architecture approved before high-fidelity UX work;

• a staging build accepted before integration work;

• campaign strategy approved before production;

• edited cut approved before final mastering or exports.

A UX project already has natural decisions between discovery, structure, design direction, and final delivery. The freelance UX designer workflow is a useful example of work where payment stages can follow actual decision stages rather than arbitrary calendar dates.

4. What are you handing over?

The final payment risk changes when the last step gives the client something difficult to reverse.

That could include:

• source files;

• source code;

• repository ownership;

• production credentials;

• editable design files;

• raw project files;

• master exports;

• final publishing access;

• domain or hosting control.

Define what counts as final handoff before starting the project. Do not invent that condition after an invoice becomes overdue.

A good milestone describes something the client can verify

“50% when we are halfway done” is a weak milestone.

Halfway through what?

“Payment due when Phase 2 is complete” is not much better if Phase 2 has no acceptance criteria.

A usable milestone should identify:

1. the deliverable;

2. what is included;

3. the expected delivery point;

4. how the client approves it;

5. the amount triggered;

6. what happens next.

Upwork’s current fixed-price guidance gives a useful platform example. It tells users to define a clear deliverable, estimated delivery date, and agreed payment amount for each milestone. When work is formally submitted on Upwork, the platform gives the client 14 days to approve it or request changes; if no action is taken, the platform releases the funded milestone automatically. That 14-day rule belongs to Upwork. A direct-client contract does not inherit it automatically.

For direct clients, write your own review process into the agreement.

Weak trigger

Payment 2 is due when the design is nearly finished.

Nobody can reliably prove when “nearly finished” happened.

Better trigger

Milestone 2 is triggered when the five agreed desktop screens have been delivered in Figma and the client sends written approval of the agreed screen set.

For development work:

Milestone 3 is triggered when the staging build contains login, dashboard, and CSV export functionality described in the acceptance checklist and is ready for client review.

The clearer the trigger, the less room there is for “I thought we were paying after the next thing.”

Build the schedule before you start calculating percentages

A simple decision model looks like this:

These are planning patterns, not mandatory percentages.

A project can also change structure after discovery. If you learn during the first paid phase that the implementation is much larger than expected, write a new scope and schedule rather than forcing the original milestones to absorb the uncertainty.

Once the timing is clear, the receiving route should be equally clear. Keep your freelance payment route as clear as your payment schedule with walllet.com: receive global income, hold in USD, and cash out to naira when you need it.

Client approval needs a deadline of its own

A milestone can be perfectly written and still fail if the approval process has no clock.

Consider this sequence:

1. You deliver the agreed work on Monday.

2. The client says they will review it.

3. Nothing happens for nine days.

4. You cannot start the next phase because approval is missing.

5. You cannot invoice because payment depends on approval.

6. Your calendar remains reserved for a project that is not moving.

The problem is no longer the deposit percentage. The approval rule is controlling your cash flow.

Define a review window before work starts.

Sample business wording:

Please review each milestone within three business days of delivery. Feedback received after that review window may move the remaining project dates. The next phase begins after the required approval and payment conditions for the previous milestone are complete.

Three business days is only an example. Choose a review period that fits the type of work and the client’s decision process.

Also decide what silence means. Do not assume silence counts as acceptance unless your written agreement and applicable rules support that treatment.

For clients with procurement teams, several approvers, or internal legal review, a longer approval window may be realistic. Price and schedule around the real process instead of writing a deadline nobody can meet.

Revisions should not reset the payment clock forever

A client can approve the direction and still request revisions.

The payment schedule should distinguish at least two things:

Revision within scope: a requested adjustment to the agreed deliverable.

Change request: a request that expands or alters the agreed work.

Examples of change requests include:

• adding pages;

• adding a new feature;

• targeting another audience;

• producing another format;

• adding a platform;

• rebuilding an approved direction;

• changing a major dependency;

• requesting work that was explicitly excluded.

A useful rule is to define how many revision rounds or what revision scope is already included, then require separate approval for additional work.

Sample wording:

The project includes two revision rounds within the agreed scope. Requests that add deliverables, features, channels, formats, or previously excluded work require written approval of the additional fee and revised schedule before the extra work begins.

That distinction is especially important in recurring marketing work, where a vague monthly scope can absorb endless extra requests. The guide to freelance digital marketing rates and retainers shows why output, revision rights, and client dependencies need to be priced together.

Do not let a new request quietly become a condition for releasing payment on work that already satisfied the original milestone.

Cancellation and refunds need a reconciliation rule

A deposit does not eliminate cancellation risk.

It also does not answer what happens to the money if the project stops.

Before work begins, the agreement should address questions such as:

• What work has already been completed?

• What costs have already been committed?

• Is the upfront payment credited toward the total project fee?

• What happens to work completed beyond payments already made?

• What happens to any amount that has not yet been earned under the agreement?

• Does cancellation affect access to unfinished work?

• What happens if the client disappears rather than formally cancelling?

Avoid assuming the word “deposit” automatically makes money refundable or non-refundable. The treatment depends on the contract and applicable law.

A neutral reconciliation clause can start from this logic:

If the project ends before completion, the parties will reconcile payments against work completed and agreed project costs according to the signed agreement. Any remaining payment or refund obligation will follow those terms and applicable law.

Have jurisdiction-specific cancellation, refund, or termination language reviewed where the amount or risk justifies it.

Invoice when the trigger happens

Do not finish Milestone 2, start Milestone 3, and remember three days later that the invoice was never sent. The trigger and invoice should stay close together. A milestone invoice should make the payment easy to reconcile with the project. Include:

• project name;

• milestone or stage;

• amount;

• currency;

• invoice date;

• due date;

• deliverable or trigger;

• payment instructions;

• previous payments where useful;

• remaining project balance where useful.

For an international client, verify the receiving details before the invoice goes out. A perfectly timed invoice still creates a cash-flow problem if the client uses the wrong payment route or the transfer enters review.

If the payer says the money was sent but you cannot use it, treat that as a payment-state problem rather than silently moving the project forward. The guide to freelance payments that are held, reviewed, or delayed explains how to distinguish those states and what evidence to keep.

Final payment and final handoff should refer to specific things

“Final payment is due at completion” sounds clear until freelancer and client disagree about what completion means.

Completion might mean:

• the work is ready for review;

• all included revisions are finished;

• the website is deployed;

• the source files are transferred;

• the client signs off;

• the project passes an acceptance checklist;

• the freelancer completes handover documentation.

Choose one.

Then describe what is delivered before that point and what belongs to final handoff.

For a designer, the client may review exported screens before receiving organized editable files.

For a developer, the client may review a staging build before final repository transfer or production handoff.

For a motion designer, the client may approve a review export before receiving final masters and project files, if those files are included in the agreement.

Do not hold back assets that your contract already requires you to deliver earlier. Set the order before work begins.

Also avoid leaving an unnecessarily large percentage for the final step of a long project. A project can be 90% economically complete while the final launch waits on one client dependency.

Three sample freelance payment schedules

The following schedules are synthetic examples. They show how payment can track the shape of the work. They are not recommended percentages for every freelancer or client.

Example 1: Small $600 project

Project: focused audit with a defined final report
Duration: short, tightly scoped

Why it works:

There is little value in creating several tiny invoices when the project has one meaningful production phase and one final deliverable.

What still needs definition:

• review period;

• included revision or clarification round;

• cancellation treatment;

• final handoff condition.

Example 2: Medium $2,400 UX project

Project: research synthesis, structure, and interface design
Duration: several weeks

The second payment arrives before most production work has accumulated.

If the client delays approval after research, the project pauses before the freelancer has completed the full interface package without another payment.

Example 3: Long $8,000 software project

Project: multi-stage product implementation
Duration: several months

Only 10% remains at the final handoff because most of the project value has already been created and paid for through earlier stages.

The exact split could be completely different. The useful feature is the sequence: significant new work does not accumulate behind one distant final invoice.

Upfront payment and milestone payments are not Net 7, Net 15, or Net 30

These terms answer different questions.

A deposit or milestone tells you what event creates the payment obligation or invoice trigger.

A Net term tells you how long the client has to pay after the invoice date or other agreed starting point.

They can appear together:

Milestone 2 invoice is issued after written acceptance of the agreed deliverable and is due Net 7.

That does not make Net 7 a milestone. It is the due-date term attached to the milestone invoice.

Net 7, Net 15, Net 30, invoice dates, and due-date terminology deserve their own decision framework, especially for freelancers dealing with corporate procurement cycles.

Before you sign: run this payment-schedule check

A payment schedule is ready when both sides can answer these questions without guessing:

• What must be paid before work starts?

• What exactly triggers each later invoice?

• How much is due at each stage?

• How long does the client have to review work?

• What happens to the schedule if approval is late?

• Which revisions are included?

• What creates a paid change request?

• What happens if the project pauses or is cancelled?

• What does final handoff include?

• How much money is still unpaid at the point where most of the work is already complete?

• Which currency and payment route will the client use?

• What has to happen before the next phase starts?

A strong freelance payment schedule reduces ambiguity before ambiguity becomes expensive. Your contract can define when a client needs to pay. The payment route determines what happens after the client sends the money. Move from “invoice sent” to money you can actually use with walllet.com for receiving global income, holding USD, spending online, converting, and cashing out in Nigeria.