# Architect fee payment milestones: allocate an agreed fee
Source: https://korrel.ai/blog/architect-fee-payment-milestones
Published: 2026-10-13
Updated: 2026-10-12
Topic: architect fee payment milestones
Tags: proposals, cost-tracking
---
## What should architect fee payment milestones show?

Architect fee payment milestones assign parts of an agreed fee to named events in the delivery programme. They do not calculate that fee.

This is our recommended working method. The operational instructions below are first-party recommendations, not findings from customer or industry research.

Cost the scope first. Then decide when each allocated amount will be ready for billing.

Keep four things separate: the output, the event that triggers billing, the planned issue date and the expected payment timing. Add the client input needed to reach that event. A stage label alone cannot explain all of these.

This guide covers the operational payment schedule. It does not provide contract wording, advice on legal enforceability or instructions for statutory payment notices. Use your appointment and professional advice for those matters.

The [ARB guidance on terms of engagement](https://arb.org.uk/wp-content/uploads/Guidance-document-Terms-of-engagement.pdf) explains why clear fees, payment schedules and responsibilities matter. It also directs architects to experts for particular legal matters. Treat the worksheet below as a delivery record, not a substitute for that advice.

## Start with the fee and scope you have already costed

Write the agreed fee at the top of your worksheet. State whether it includes VAT. Specify whether expenses and consultant fees are included too. Use the same basis for every milestone amount and for the final total check.

Do not start with an attractive percentage split. Check that the work you priced matches the outputs you plan to bill. If the scope or fee is still unresolved, finish that work first.

Our guide to [setting a stage based fee that survives design changes](/blog/stage-fee-that-survives-design-changes) covers the earlier decision. This worksheet starts after you have costed the stages and defined their boundaries.

List the included outputs. Give each output a short identifier, such as concept package C1 or planning package P1. Use the identifiers in your proposal. Keep them in the delivery programme and billing record too, so the client can recognise the same work in each place.

The [RIBA Plan of Work](https://www.architecture.com/knowledge-and-resources/resources-landing-page/riba-plan-of-work) describes stage outcomes, tasks and information exchanges. Use that structure to name the work where it fits your appointment. Do not present your payment split as a RIBA rule.

## Use this milestone allocation worksheet

This example is invented. Its practice, project, fee, amounts and dates do not describe a customer or an industry benchmark.

The already-costed fee is £30,000, excluding VAT. Expenses and consultant fees are outside this example.

The invented appointment covers concept design, spatial coordination and a defined technical package. It does not cover construction or handover services. The payment allocations divide the existing fee; they do not estimate the cost of each stage.

| Named stage output | Allocated amount | Milestone trigger | Planned issue date | Payment timing | Client dependency |
|---|---|---|---|---|---|
| Concept design: option review C1 | £4,500 | Issue C1 review pack | 11 January 2027 | Invoice on issue; expected payment 14 calendar days later | Confirm brief and supply measured survey before work starts |
| Concept design: selected concept C2 | £4,500 | Issue C2 concept pack | 25 January 2027 | Invoice on issue; expected payment 14 calendar days later | Return one combined response to C1 by 18 January |
| Spatial coordination: planning package P1 | £9,000 | Issue the defined P1 package to the client | 22 February 2027 | Invoice on issue; expected payment 14 calendar days later | Confirm selected concept and supply consultant inputs by 1 February |
| Technical design: coordination package T1 | £6,000 | Issue T1 coordination pack | 22 March 2027 | Invoice on issue; expected payment 14 calendar days later | Return combined comments and confirm equipment information by 8 March |
| Technical design: final defined package T2 | £6,000 | Issue T2 package with its document register | 12 April 2027 | Invoice on issue; expected payment 14 calendar days later | Close listed coordination decisions by 29 March |
| Total allocated | £30,000 | All listed outputs | Not applicable | Not applicable | Not applicable |

The balance check is £4,500 + £4,500 + £9,000 + £6,000 + £6,000 = £30,000. The unallocated balance is £0. Concept design totals £9,000, spatial coordination £9,000 and technical design £12,000.

These are choices for this example, not standard fee shares. The assumed payment timing is also invented. Replace it with the timing confirmed for your appointment. Calculate each forecast receipt date from the actual invoice date, not automatically from the planned issue date.

Keep the output descriptions beside the worksheet. For each package, identify the drawings, report or register it contains. State the included review and the information needed to issue it. The table should reference those descriptions, not replace them.

## Separate the trigger from the date

The milestone trigger is an event you can observe that makes the amount ready for billing. A client dependency is an input needed to reach that trigger.

The planned issue date is only a forecast. Payment timing describes what happens after the invoice.

Do not merge them into a cell labelled “payment due at Stage 3”. Name the event for the project lead and finance team. Record what to update if the programme moves.

In the invented example, P1 triggers on issue of the defined package to the client. A planning decision is not that trigger. The worksheet does not assume that a planning submission and a favourable planning decision are the same event.

If your appointment uses client acceptance instead of issue, record that event accurately. Identify the responsible client contact in the supporting record. Keep any legal meaning of acceptance in the appointment, not in an improvised worksheet note.

For P1 issued and invoiced on 22 February, the example forecasts receipt on 8 March 2027. If issue moves, update that forecast. Do not report the invoice as issued merely because its planned date has arrived.

## Test the schedule against delivery and client inputs

Review the worksheet with the project lead and the person who raises invoices. Does each output justify its own billing action? Check the gaps too. Decide how much work you will allocate to each event.

If a stage contains two distinct packages, you can allocate its existing amount across two milestones. The example divides concept design between C1 and C2; it does not charge £9,000 for each package.

Splitting a milestone must not duplicate the fee.

Check the sequence of client inputs. A survey needed before concept work should not appear as a dependency for the final package. Give each input an owner and a requested date in the delivery record. Record missing inputs before you promise an issue date.

Test one delay. If the client response to C1 arrives late, identify which later outputs must move. Update planned dates and forecast receipts separately. Keep the amounts unchanged unless the agreed scope or commercial arrangement changes.

Test one added service too. Check the appointment before treating a new planning response after refusal as part of P1. Use a separate assessment for [charging for a planning resubmission](/blog/how-to-charge-planning-resubmission) before adding its fee to the schedule.

## Keep billing progress separate from project cost

Check delivery costs separately from billing readiness. Compare costs with the estimate even when a milestone is ready for billing. Record costs incurred before issue too.

Review actual time and expenses against the work you costed. Use [project cost variance by role](/blog/review-project-cost-variance-by-role) to investigate extra hours, staff mix or changed rates. Do not move an allocation merely to hide a cost overrun.

Keep one current schedule. Retain its earlier versions. Record the actual issue dates and invoice references in your billing records, along with recorded payments.

A planned receipt is not evidence that money reached the bank.

Korrel supports fixed-amount, percentage-based and deliverable-linked payment milestones, with due dates and notes. It carries milestones and deliverable links into a project when you convert a proposal. Projects are created from proposals only.

Korrel does not create or send native invoices, collect payments or verify bank receipts. Use your separate invoicing process for those tasks. The worksheet's separate fields are a working method, not a claim that Korrel provides each field as a dedicated control.

For the next proposal, check the allocated total before internal sign-off. Confirm the output identifiers with the team. Check the dependencies and operational timing with them too. The [proposals hub](/blog/topics/proposals) covers the related scope and proposal decisions.

[Sign up for Korrel](https://app.korrel.ai/signup) to keep proposal deliverables and payment milestones together before you carry them into delivery.